When Android capture unhandled exception, let the app do not crash immediately, but instead give sentry several seconds to upload exceptions to server

[fzyzcjy]

Platform:

• Android -> If yes, which Device API (and compileSdkVersion/targetSdkVersion/Build tools) version?
• Java -> If yes, which Java (and sourceCompatibility/targetCompatibility) version?
• Kotlin -> If yes, which Kotlin (and jvmTarget) version?
• NDK -> If yes, which NDK/CMake version?
• React-Native -> If yes, which version?
• Timber -> If yes, which version?
• Log4j2 -> If yes, which version?
• Logback -> If yes, which version?
• Spring -> If yes, which version?

IDE:

• Android Studio -> If yes, which version?
• IntelliJ -> If yes, which version?
• Other -> If yes, which one?

Build system:

• Gradle -> If yes, which version?
• Buck -> If yes, which version?
• Bazel -> If yes, which version?
• Maven -> If yes, which version?
• Other -> If yes, which one?

Android Gradle Plugin:

• Yes -> If yes, which version?
• No

Sentry Android Gradle Plugin:

• Yes -> If yes, which version?
• No

Proguard/R8:

• Enabled
• Disabled

Platform installed with:

• JCenter
• Bintray
• Maven Central
• Manually

The version of the SDK:
sentry-flutter 5.0.0

---

I have the following issue:

We know that (getsentry/sentry-dart#548), if a crash happens, the user have to start the app again in order to let sentry upload the event to server. However, consider the following two cases:

1. What if the app crash continuously when starting? In this case, sentry never have a chance to upload! This is almost the MOST severe bug an app can have, if it happens. But it even DOES NOT show up in sentry webpage!
2. What if the user does not start the app again? For example, an impatient user. More importantly, a reviewer of the Android app store - often he just test once, see it crash, then reject this app without starting the app again. In this case, the app can never know the bug that the reviewer sees.

Proposal: show a dialog to user saying "bug occurred, please wait for several seconds", while sentry upload event to server in the backend. Instead of simply crashing and quit immediately.

Steps to reproduce:

• see above

Actual result:

• see above

Expected result:

• see above

[marandaneto]

we could work on it together with #1569 so we check that flag and if there was a crash in the last run, we could block the init till sending all the pending events, the downside is, we can slow down App's init and even cause an ANR, so this option should be opt-in by default.

the other option and a bit more aggressive would be sending events in a different process, the downside is, it requires a bit more memory.

[fzyzcjy]

@marandaneto My suggestion is on the shutdown procedure, not the startup of next run. See the reasons above for why I suggest this ;)

[marandaneto]

@fzyzcjy yep I know, but the NDK integration doesn't have a transport that sends an event to Sentry, it only writes a file to the disk which is picked up on restart and sent it over to Sentry via the Java transport, otherwise we have to change quite a lot of things, but we'll take into consideration, whats the best approach and improve from there, thanks.

[fzyzcjy]

@marandaneto We may treat the two differently. For android errors, it can be uploaded before shutdown; for ndk, need to upload the next time.

You are welcome!

[fzyzcjy]

@marandaneto The reason is that, it is much rare for android people to see ndk bugs compared with java bugs, so by adding this proposed feature, a major part (instead of minor part) can be benefited ;)

[romtsn]

We tackled this as part of #2277 - it does not cover all the cases, but just the first point in the original issue. Instead of blocking the main thread after a crash occurs, we are blocking it on the next app start if we encountered a startup crash in the previous run, allowing the app to upload events to Sentry. This will mitigate the recurrent startup crashes issue.

As for the problem when the user never launches the app again, we'll tackle this as part of #598 if ever implemented. Hence, closing the issue