-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Protect against onResume
running in MainMenuActivity
during crash flow
#5679
Conversation
This should not happen as far as we understand, but seems to be occuring in the wild on some devices and is also reproducible in Robolectric
onResume
running in MainMenuActivity
during crash flow
CrashHandler.getInstance(application)!!.registerCrash(application, IllegalStateException()) | ||
|
||
val activity = Robolectric.setupActivity(MainMenuActivity::class.java) | ||
assertThat(shadowOf(activity).nextStartedActivity, notNullValue()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we also check that the new activity is CrashHandlerActivity as the title says? Here you just check if it's not null.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Whoops! Yes absolutely.
@seadowg |
I haven't found an on device way to reproduce, so yeah I'm going to go ahead and merge. |
Protect against `onResume` running in `MainMenuActivity` during crash flow
Fixes this crash.
The crash is fairly rare, but I ended up fixing it while investigating.
What has been done to verify that this works as intended?
New tests.
Why is this the best possible solution? Were any other approaches considered?
I didn't think we'd need to do this, but it seems like some devices might call
onResume
after anonCreate
that callsfinish
and the fact that this is reproducible in Robolectric definitely backs that up.How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
The only thing affected is the flow when reopening the app after a crash, so that would be good to play with.
Before submitting this PR, please make sure you have:
./gradlew checkAll
and confirmed all checks still pass OR confirm CircleCI build passes and run./gradlew connectedDebugAndroidTest
locally.