Firebase-android-sdk: Crashlytics non-fatal uploads never send: Send to Reports Endpoint for non-native reports disabled. Removing Reports Uploader report.

[alex-pathspot]

[READ] Step 1: Are you in the right place?

Issues filed here should be about bugs in __the code in this repository__.
If you have a general question, need help debugging, or fall into some
other category use one of these other channels:

• For general technical questions, post a question on StackOverflow
  with the firebase tag.
• For general Firebase discussion, use the firebase-talk
  google group.
• For help troubleshooting your application that does not fall under one
  of the above categories, reach out to the personalized
  Firebase support channel.

[REQUIRED] Step 2: Describe your environment

• Android Studio version: 4.01
• Firebase Component: Crashlytics
• Component version: 17.2.1
• Android Version 7.0

[REQUIRED] Step 3: Describe the problem

FirebaseCrashlytics.getInstance().recordException(e) records are not uploaded at app relaunch due to "Send to Reports Endpoint for non-native reports disabled."

Steps to reproduce:

1. Enable firebase verbose logging: adb shell setprop log.tag.FirebaseCrashlytics VERBOSE
2. Crash app via null reference produced by app
3. After a delay (ensuring report is saved to disk) close and open the application.
4. At relaunch report upload is rejected due to:
   
   
   
   1. This seems to originate at `firebase-crashlytics/src/main/java/com/google/firebase/crashlytics/internal/report/ReportUploader.java:114
      
      

      Relevant Code:

   
   

Application

    @Override
    public void onCreate() {
        super.onCreate();
        FirebaseApp.initializeApp(this);
        FirebaseApp.getInstance().setDataCollectionDefaultEnabled(new Boolean(true));

MainActivity

@Override
protected void onCreate(final Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        MyCustomExceptionHandler exceptionHandler = new MyCustomExceptionHandler(this);
        Thread.setDefaultUncaughtExceptionHandler(exceptionHandler);
        FirebaseCrashlytics crashInstance = FirebaseCrashlytics.getInstance();
        crashInstance.setUserId(<device_id>);
        crashInstance.setCrashlyticsCollectionEnabled(true);

MyCustomExceptionHandler:

public class MyCustomExceptionHandler implements Thread.UncaughtExceptionHandler {
    private  Activity activity;
    public MyCustomExceptionHandler(Activity activity){
      this.activity = activity;  
    }

    public void uncaughtException(final Thread t, final Throwable e) {
             FirebaseCrashlytics.getInstance().recordException(e);
             try{
                  Thread.sleep(10000);
             } catch (InterruptedException  ex){
                this.activity.finish();
                System.exit(2);
            }
   }
}

Output Log

2020-09-09 10:56:39.910 23455-23478/<our_app> D/FirebaseCrashlytics: Crashlytics is logging non-fatal exception "java.lang.NullPointerException: Attempt to invoke a virtual method on a null object reference" from thread Thread-38
2020-09-09 10:56:39.951 23455-23478/<our_app> D/FirebaseCrashlytics: No log data to include with this event.
2020-09-09 10:56:39.966 23455-23478/<our_app> D/FirebaseCrashlytics: Crashlytics is logging non-fatal exception "java.lang.NullPointerException: Attempt to invoke a virtual method on a null object reference" from thread Thread-39
2020-09-09 10:56:39.976 23455-23478/<our_app> D/FirebaseCrashlytics: No log data to include with this event.
2020-09-09 10:56:49.872 23455-23649/<our_app> D/FirebaseCrashlytics: Executing shutdown hook for Crashlytics Exception Handler
2020-09-09 10:56:49.877 23455-23651/<our_app> D/FirebaseCrashlytics: Executing shutdown hook for awaitEvenIfOnMainThread task continuation executor
2020-09-09 10:56:49.878 23455-23650/<our_app> D/FirebaseCrashlytics: Executing shutdown hook for com.google.firebase.crashlytics.startup
2020-09-09 10:56:50.314 23652-23652/<our_app> D/FirebaseCrashlytics: Crashlytics automatic data collection ENABLED by API.
2020-09-09 10:56:50.315 23652-23652/<our_app> D/FirebaseCrashlytics: Firebase Analytics is available.
2020-09-09 10:56:50.321 23652-23652/<our_app> D/FirebaseCrashlytics: Firebase Analytics listener registered successfully.
2020-09-09 10:56:50.364 23652-23652/<our_app> D/FirebaseCrashlytics: Reading cached settings...
2020-09-09 10:56:50.384 23652-23652/<our_app> D/FirebaseCrashlytics: Loaded cached settings: {"settings_version":3,"cache_duration":86400,"features":{"collect_logged_exceptions":true,"collect_reports":true,"collect_analytics":false,"prompt_enabled":false,"push_enabled":false,"firebase_crashlytics_enabled":false},"app":{"status":"activated","update_required":true,"report_upload_variant":2,"native_report_upload_variant":1},"fabric":{"org_id":"5d10c8d02edc7f9d20001054","bundle_id":"<our_app>"},"expires_at":1599665515524}
2020-09-09 10:56:50.384 23652-23652/<our_app> D/FirebaseCrashlytics: Returning cached settings.
2020-09-09 10:56:50.390 23652-23652/<our_app> D/FirebaseCrashlytics: Mapping file ID is: 00000000000000000000000000000000
2020-09-09 10:56:50.392 23652-23652/<our_app> I/FirebaseCrashlytics: Initializing Crashlytics 17.2.1
2020-09-09 10:56:50.395 23652-23652/<our_app> D/FirebaseCrashlytics: Installer package name is: null
2020-09-09 10:56:50.510 23652-23652/<our_app> D/FirebaseCrashlytics: Exception handling initialization successful
2020-09-09 10:56:50.543 23652-23677/<our_app> D/FirebaseCrashlytics: Found matching FID, using Crashlytics IID: 0661ce2d631b408d8460037f59996b67
2020-09-09 10:56:50.545 23652-23677/<our_app> D/FirebaseCrashlytics: Opening a new session with ID 5F58ED32020C-0001-5C64-BF8AAF1C7061
2020-09-09 10:56:50.618 23652-23677/<our_app> D/FirebaseCrashlytics: Initialization marker file created.
2020-09-09 10:56:50.619 23652-23677/<our_app> D/FirebaseCrashlytics: Registered Firebase Analytics event receiver for breadcrumbs
2020-09-09 10:56:50.620 23652-23677/<our_app> D/FirebaseCrashlytics: Finalizing previously open sessions.
2020-09-09 10:56:50.655 23652-23677/<our_app> D/FirebaseCrashlytics: Closing open sessions.
2020-09-09 10:56:50.656 23652-23677/<our_app> D/FirebaseCrashlytics: Closing session: 5F58ED1402F0-0001-5B9F-BF8AAF1C7061
2020-09-09 10:56:50.656 23652-23677/<our_app> D/FirebaseCrashlytics: Collecting session parts for ID 5F58ED1402F0-0001-5B9F-BF8AAF1C7061
2020-09-09 10:56:50.659 23652-23677/<our_app> D/FirebaseCrashlytics: Session 5F58ED1402F0-0001-5B9F-BF8AAF1C7061 has fatal exception: false
2020-09-09 10:56:50.661 23652-23677/<our_app> D/FirebaseCrashlytics: Session 5F58ED1402F0-0001-5B9F-BF8AAF1C7061 has non-fatal exceptions: true
2020-09-09 10:56:50.662 23652-23677/<our_app> D/FirebaseCrashlytics: Collecting SessionStart data for session ID 5F58ED1402F0-0001-5B9F-BF8AAF1C7061
2020-09-09 10:56:50.683 23652-23677/<our_app> D/FirebaseCrashlytics: Collecting SessionUser data for session ID 5F58ED1402F0-0001-5B9F-BF8AAF1C7061
2020-09-09 10:56:50.686 23652-23677/<our_app> D/FirebaseCrashlytics: Collecting SessionApp data for session ID 5F58ED1402F0-0001-5B9F-BF8AAF1C7061
2020-09-09 10:56:50.691 23652-23677/<our_app> D/FirebaseCrashlytics: Collecting SessionOS data for session ID 5F58ED1402F0-0001-5B9F-BF8AAF1C7061
2020-09-09 10:56:50.692 23652-23677/<our_app> D/FirebaseCrashlytics: Collecting SessionDevice data for session ID 5F58ED1402F0-0001-5B9F-BF8AAF1C7061
2020-09-09 10:56:50.693 23652-23677/<our_app> D/FirebaseCrashlytics: Found Non Fatal for session ID 5F58ED1402F0-0001-5B9F-BF8AAF1C7061 in 5F58ED1402F0-0001-5B9F-BF8AAF1C7061SessionEvent0000000000.cls 
2020-09-09 10:56:50.694 23652-23677/<our_app> D/FirebaseCrashlytics: Found Non Fatal for session ID 5F58ED1402F0-0001-5B9F-BF8AAF1C7061 in 5F58ED1402F0-0001-5B9F-BF8AAF1C7061SessionEvent0000000001.cls 
2020-09-09 10:56:50.695 23652-23677/<our_app> D/FirebaseCrashlytics: Removing session part files for ID 5F58ED1402F0-0001-5B9F-BF8AAF1C7061
2020-09-09 10:56:50.749 23652-23677/<our_app> D/FirebaseCrashlytics: Closed all previously open sessions
2020-09-09 10:56:50.752 23652-23677/<our_app> D/FirebaseCrashlytics: Unsent reports are available.
2020-09-09 10:56:50.752 23652-23677/<our_app> D/FirebaseCrashlytics: Crashlytics automatic data collection ENABLED by API.
2020-09-09 10:56:50.753 23652-23677/<our_app> D/FirebaseCrashlytics: Automatic data collection is enabled. Allowing upload.
2020-09-09 10:56:50.758 23652-23677/<our_app> D/FirebaseCrashlytics: Initialization marker file removed: true
2020-09-09 10:56:51.325 23652-23679/<our_app> D/FirebaseCrashlytics: Server says an update is required - forcing a full App update.
2020-09-09 10:56:51.326 23652-23677/<our_app> D/FirebaseCrashlytics: Checking for crash reports...
2020-09-09 10:56:51.331 23652-23677/<our_app> D/FirebaseCrashlytics: Found crash report /data/user/0/<our_app>/files/.com.google.firebase.crashlytics/nonfatal-sessions/5F58ED1402F0-0001-5B9F-BF8AAF1C7061.cls
2020-09-09 10:56:51.332 23652-23677/<our_app> D/FirebaseCrashlytics: Reports are being sent.
2020-09-09 10:56:51.338 23652-23705/<our_app> D/FirebaseCrashlytics: Starting report processing in 1.0 second(s)...
2020-09-09 10:56:51.573 23652-23679/<our_app> D/FirebaseCrashlytics: Sending app info to https://update.crashlytics.com/spi/v1/platforms/android/apps/<our_app>
2020-09-09 10:56:51.621 23652-23677/<our_app> D/FirebaseCrashlytics: Crashlytics report successfully enqueued to DataTransport: 5F58ED1402F000015B9FBF8AAF1C7061
2020-09-09 10:56:51.622 23652-23652/<our_app> D/FirebaseCrashlytics: Crashlytics automatic data collection ENABLED by API.
2020-09-09 10:56:52.045 23652-23678/<our_app> D/FirebaseCrashlytics: Received Analytics message: 3 Bundle[{params=Bundle[{_o=auto, _sc=LauncherActivity, _si=-7144237981223821230}], name=_vs, timestampInMillis=1599663411770}]
2020-09-09 10:56:52.184 23652-23679/<our_app> D/FirebaseCrashlytics: Update app request ID: 02e3f5d10e8ef07398abdec06be7ee23
2020-09-09 10:56:52.185 23652-23679/<our_app> D/FirebaseCrashlytics: Result was 204
2020-09-09 10:56:52.339 23652-23705/<our_app> D/FirebaseCrashlytics: Attempting to send 1 report(s)
2020-09-09 10:56:52.339 23652-23705/<our_app> D/FirebaseCrashlytics: Send to Reports Endpoint for non-native reports disabled. Removing Reports Uploader report.
2020-09-09 10:56:52.340 23652-23705/<our_app> D/FirebaseCrashlytics: Removing report at /data/user/0/<our_app>/files/.com.google.firebase.crashlytics/nonfatal-sessions/5F58ED1402F0-0001-5B9F-BF8AAF1C7061.cls
2020-09-09 10:56:53.635 23652-23678/<our_app> D/FirebaseCrashlytics: Received Analytics message: 3 Bundle[{params=Bundle[{_o=auto, _pc=LauncherActivity, _pi=-7144237981223821230, _sc=MainActivity, _si=2070087239120173802}], name=_vs, timestampInMillis=1599663413502}]
2020-09-09 10:56:57.428 23652-23678/<our_app> D/FirebaseCrashlytics: Received Analytics message: 3 Bundle[{params=Bundle[{_o=auto, _pc=MainActivity, _pi=2070087239120173802, _sc=LauncherActivity, _si=2070087239120173803}], name=_vs, timestampInMillis=1599663416888}]
2020-09-09 10:56:59.250 23652-23678/<our_app> D/FirebaseCrashlytics: Received Analytics message: 3 Bundle[{params=Bundle[{_o=auto, _et=2686, _sc=MainActivity, _si=2070087239120173802}], name=_e, timestampInMillis=1599663416586}]
2020-09-09 10:56:59.614 23652-23678/<our_app> D/FirebaseCrashlytics: Received Analytics message: 3 Bundle[{params=Bundle[{_o=auto, _pc=LauncherActivity, _pi=2070087239120173803, _sc=MainActivity, _si=2070087239120173802}], name=_vs, timestampInMillis=1599663419331}]

[mrwillis21]

Hi there! Thanks for the report. We are switching over to a new code path in the SDK, which is why you're seeing that particular log. However, before that, please note: Crashlytics report successfully enqueued to DataTransport: 5F58ED1402F000015B9FBF8AAF1C7061

This log suggests that the report is being enqueued to be sent properly (through the new code path), then being cleared from disk: Removing report at /data/user/0/<our_app>/files/.com.google.firebase.crashlytics/nonfatal-sessions/5F58ED1402F0-0001-5B9F-BF8AAF1C7061.cls.

I'll admit, this is a little confusing!

As for missing non-fatals, are you seeing this in a production app or just in this test?

[alex-pathspot]

This is a test build of our application in preparation for the fabric shutdown on Nov 15th. I have seen several of "recordedExceptions" trickle through, but not all of them.

What is the expected delay between Crashlytics report successfully enqueued to DataTransport: 5F58ED1402F000015B9FBF8AAF1C7061 and the event hitting our firebase console?

Additionally, I am not seeing any logs in the firebase console attached to my nonfatal events. There are 6 calls FirebaseCrashlytics.getInstance().log(<string>) in a separate thread prior to calling FirebaseCrashlytics.getInstance().recordException(e); Are logs only associated with fatal errors?

[GrapeJuice787]

I have been seeing the same thing, some reports come through and others do not even when forcing a crash in the same manner. I was able to get 9 crashes to show in Firebase this morning and now back to nothing... we are also migrating from Fabric over to Firebase Crashlytics due to the November deadline. Any update on this @alex-pathspot ?

[alex-pathspot]

@GrapeJuice787 We added a slight delay after logging error (~1 second) to ensure the complete log hit the disk. It appears that Firebase passes the log off to a separate thread and recordException() returns before the exception is actually recorded.

Regarding FirebaseCrashlytics.getInstance().log(<string>) not showing up in recordException(), the only (and not great work around) is to make sure that the recordException() is called in the same thread that called log

Lastly there is a really inconsistent delay between when the records are sent to Firebase and when they appear in the console. With new records, it tends to appear within a matter of minutes. Repeats of the same record can be delayed by over 4 hours.

I'm still _not_ confident that all records are reaching our console, but I haven't dedicated more time to this without more information from @mrwillis21

[mwshubham]

Is this related to using Thread.setDefaultUncaughtExceptionHandler(exceptionHandler);

https://github.com/firebase/firebase-android-sdk/issues/1278#issuecomment-606481792

Removing the code was not the solution, IMO.

I am having the same issue. On using Custom Uncaught Exception Handler, fatal exceptions are not logging.

[Fintasys]

We have the same issue and after removing Thread.setDefaultUncaughtExceptionHandler(exceptionHandler) it start sending the logs again. We would like to keep it, so this is not a solution for us either. Crashlytics 17.2.2

[alex-pathspot]

@mrwillis21
Ideally Crashyltics would provide us an API to provide an Exception handler that is called within crashlytics. EG

Firebase.registerExceptionHandler( exceptionHandler)

That would be called __after__ Crashlytics successfully logs the crash.

[mrwillis21]

Hi everyone, I can see there are a lot of questions here, so I'm going to take them separately.

First off, in terms of crashes being uploaded and how and when that happens, I wrote up an explainer over here on exactly what you'll see in the logs and how to understand what's going on. Please take a look at that for more info. :)

Additionally, I am not seeing any logs in the firebase console attached to my nonfatal events. There are 6 calls FirebaseCrashlytics.getInstance().log() in a separate thread prior to calling FirebaseCrashlytics.getInstance().recordException(e); Are logs only associated with fatal errors?

No, logs are associated with the next event, whether it's a non-fatal or fatal event. However, you will have to manage synchronization on your own - if you're logging an exception on one thread, and a separate thread is calling FirebaseCrashlytics.getInstance().log(...), then it is possible the exception may be captured first, in which case the subsequent logs would be captured in the next event (whether it's another non-fatal or fatal crash).

Is this related to using Thread.setDefaultUncaughtExceptionHandler(exceptionHandler);

Can you please give me more information about what you were doing, what you were expecting, and what you saw when overriding the default exception handler? Generally this should work the same way in both Fabric and Firebase Crashlytics, so I'd love to get more information on what you're seeing.

Ideally Crashyltics would provide us an API to provide an Exception handler that is called within crashlytics. EG

Can you expand on this idea a bit? Normally if you want to add pre-processing to the exception handler, all you'd need to do is something like this, after initializing Crashlytics:

Thread.UncaughtExceptionHandler crashlyticsHandler = Thread.getDefaultUncaughtExceptionHandler();
Thread.setDefaultUncaughtExceptionHandler((thread, exception) -> {
    // do whatever you choose with the exception
    crashlyticsHandler.uncaughtException(thread, exception);
});

Would that work for your use case, or are you looking for something a little different?

[Fintasys]

and what you saw when overriding the default exception handler?

@mrwillis21 As described above crashes won't be reported. When you override the default exception handler all recorded logs won't be send to crashlytics. Once you remove the exception handler the crashes are sent without any problems.
In case there is a issue with the overriding, alex-pathspot proposed an example interface.

[alex-pathspot]

@mrwillis21

regarding your proposal of:

Thread.UncaughtExceptionHandler crashlyticsHandler = Thread.getDefaultUncaughtExceptionHandler();
Thread.setDefaultUncaughtExceptionHandler((thread, exception) -> {
    // do whatever you choose with the exception
    crashlyticsHandler.uncaughtException(thread, exception);
});

This allows for preprocessing but doesn't work well in our application of a device owner Kiosk app where we need complete control of how the application terminates. The call to crashlyticsHandler.uncaughtException(thread, exception); raises a RuntimeException (If I recall correctly), which terminates the application. This prevents us from doing any post-processing which helps guarantee a clean relaunch of our application.

Attempting to do this work as a preprocessing leads to a race condition between our relaunch and Crashyltics finalizing logging of the crash.

My expectations around the proposed interface would be as follows

1. The registered exceptionHandler would run only after the exception had been completely logged to disk
2. The registered exceptionHandler would return a boolean for if it wanted Crashyltics to Terminate the application or not

class FirebaseExceptionHandler 
     public abstract boolean uncaughtException(final Thread t, final Throwable e);

Another potential solution to this problem would be to provide a synchronous recordException method that can be used in the overridden exception handler. The current implementation to recordException appears to be asynchronous, creating a race condition between recordException saving to disk and exceptionHandler terminating the application.

[tiny0Xy9]

@mrwillis21

My code also does not send a crash report if I do the following.

Thread.setDefaultUncaughtExceptionHandler(new MyUncaughtExceptionHandler());
FirebaseCrashlytics crashlytics = FirebaseCrashlytics.getInstance();
crashlytics.setCrashlyticsCollectionEnabled(true);

If you remove this code, the crash will be reported successfully.

Thread.setDefaultUncaughtExceptionHandler(new MyUncaughtExceptionHandler());

[abhishekpatil26]

I solved this issue by adding below line's inside application's onCreate() and logs are visible now on the console, they're getting delayed by 20-30 mins to show on firebase console

FirebaseCrashlytics crashlytics = FirebaseCrashlytics.getInstance(); crashlytics.setCrashlyticsCollectionEnabled(true);

[mrwillis21]

@alex-pathspot

The call to crashlyticsHandler.uncaughtException(thread, exception); raises a RuntimeException (If I recall correctly), which terminates the application. This prevents us from doing any post-processing which helps guarantee a clean relaunch of our application.

Fortunately it doesn't raise a RuntimeException, but simply returns control to the whichever UncaughtExceptionHandler was installed before it. This is _usually_ the system default handler, which is what kills the app process. However, if you override the system default handler before Crashlytics starts up (via Thread.setDefaultUncaughtExceptionHandler), Crashlytics will then hand control back to your custom handler instead of the system default. 😄

You can do that a few different ways, but the simplest is probably to implement your own ContentProvider (similar to FirebaseInitProvider) which instruments your post-processing code, and set that ContentProvider to run before Firebase's by setting its initOrder in your AndroidManifest.xml to a value > 100 (here's the FirebaseInitProvider AndroidManifest.xml for reference).

Here's an example onCreate in a ContentProvider that restarts my app after a crash:

@Override
public boolean onCreate() {
    Thread.setDefaultUncaughtExceptionHandler((thread, exception) -> {
        Context context = getContext();
        PackageManager packageManager = context.getPackageManager();
        Intent intent = packageManager.getLaunchIntentForPackage(context.getPackageName());
        if (intent != null) {
            ComponentName componentName = intent.getComponent();
            Intent mainIntent = Intent.makeRestartActivityTask(componentName);
            context.startActivity(mainIntent);
            Runtime.getRuntime().exit(0);
        }
    });
    return false;
}

And the AndroidManifest.xml entry for it:

<provider
    android:name=".PostCrashHandlerProvider"
    android:authorities="${applicationId}.postcrashhandlerprovider"
    android:exported="false"
    android:initOrder="101" />

Alternatively, you could also disable Firebase's automatic initialization, then instrument your own exception handler before calling FirebaseApp.initializeApp() to initialize Firebase (and Crashlytics) manually as part of your app startup.

---

@Fintasys, @tiny0Xy9 regarding your custom exception handling (MyUncaughtExceptionHandler):

As described above crashes won't be reported.

As long as you get a reference to the Crashlytics handler (by calling Thread.getDefaultUncaughtExceptionHandler() before setting your own) and then your exception handler calls crashlyticsHandler.uncaughtException(thread, exception); after doing what it needs to do, crashes should be reported. Is that not what you're seeing?

[Fintasys]

@mrwillis21 Thanks for your answer. We tried to follow what you have said and we could see crashes being reported after switching the order of calling ExceptionHandler and enable firebase (disabled by default in Manifest) in Application OnCreate:
Before:

Thread.setDefaultUncaughtExceptionHandler(this);
FirebaseCrashlytics.getInstance().setCrashlyticsCollectionEnabled(true)

After:

FirebaseCrashlytics.getInstance().setCrashlyticsCollectionEnabled(true)
Thread.setDefaultUncaughtExceptionHandler(this);

We will do more tests, but so far it looks promising. Crashlytics version 17.1.0

[mrwillis21]

@alex-pathspot @Fintasys Were you able to get this working?

[Fintasys]

@mrwillis21 Before I wasn't really understanding why above changing the order was working (It was due to our custom implementation, so unrelated to migration). But after looking at the Firebase CrashlyticsUncaughtExceptionHandler I understood that it isn't a listener-pattern with the ability of adding multiply listener as I thought and that we need to do the same implementation in order to make it work properly. We were overriding the listener of crashlytics which we shouldn't do - we need to make sure that we also remember and calling the previous default handler.
So here is a stripped example - It might be good to have such an example in the documentations:

public class ThisApplication extends Application implements Thread.UncaughtExceptionHandler {

    private Thread.UncaughtExceptionHandler defaultHandler;

    @Override
    public void onCreate() {
        super.onCreate();

        // Enable crashlytics - disabled by default
        FirebaseCrashlytics.getInstance().setCrashlyticsCollectionEnabled(true);

        // Assign crashlytics's uncaughtExceptionHandler as defaultHandler
        defaultHandler = Thread.getDefaultUncaughtExceptionHandler();

        // Set this class as new default uncaughtExceptionHandler
        Thread.setDefaultUncaughtExceptionHandler(this);
    }

    @Override
    public void uncaughtException(final Thread thread, final Throwable ex) {

        // Do something like restarting app

        // Redirect exception to Firebase Crashlytic's uncaughtExceptionHandler
        defaultHandler.uncaughtException(thread, ex);
    }
}

[mrwillis21]

@Fintasys Good to hear you got it working! That code snippet looks good to me, but I wanted to point out a few things in the interest of clarity for anyone who may be following along:

1) The important part to remember is that in whatever part of your app lifecycle you configure your custom handler like this, you must ensure that Firebase has already been initialized. Running it here in your Application class works well as long as you haven't overridden Firebase's automatic initialization.
2) Restarting the app _before_ calling back to Crashlytics' uncaught exception handler should be okay as long as the app process does not end as part of the restart. If it does, the code that passes execution back to the Crashlytics handler will never run.
3) Unless you have explicitly overridden the value in your AndroidManifest.xml, you should not need to run FirebaseCrashlytics.getInstance().setCrashlyticsCollectionEnabled(true);, as it is actually enabled by default.

[mrwillis21]

Anyone who was not seeing crashes come through, is this still an issue? Have the crashes eventually shown up in your dashboard? If not, I'd love to get more details and make sure we can get this sorted for you. :)

[mrwillis21]

Going to close this out. As one final note - if you're still experiencing this problem, please try our latest SDK release, 17.3.0, and let us know if you're still experiencing any issues.