Status Update
Comments
su...@google.com <su...@google.com>
su...@google.com <su...@google.com> #2
kj...@gmail.com <kj...@gmail.com> #3
Great! Thanks a lot, I'll look for the live updates soon!
lo...@gmail.com <lo...@gmail.com> #4
be...@airbnb.com <be...@airbnb.com> #5
I am unfortunately not able to reproduce the issue. We are seeing this crash affect ~0.05% of sessions (across random screen), so it does seem to be an extremely nuanced race condition.
I understand if you are unable to proceed without full debug logs, however, I think I provided a compelling argument of what causes the bug in the initial ticket.
We have been able to mitigate the issue by installing a back pressed dispatcher when which by the nature of being invoked whenever OnBackPressedDispatcher would have been invoked, has the opportunity to catch the exception in the android framework.
// Register in onCreate / remove in onDestroy of any activity that has an unconditionally enabled `OnBackPressedCallbacks`
val callback = OnBackInvokedCallback {
try {
// Delegate to the "normal" back pressed dispatcher flow.
onBackPressedDispatcher.onBackPressed()
} catch (exception: NullPointerException) {
if (exception.message?.contains("android.os.Handler android.app.FragmentHostCallback.getHandler()") == true) {
throwOrNotify("Api33 back-press dispatcher failed to invoke", exception)
finish()
} else {
throw exception
}
}
}
fe...@gmail.com <fe...@gmail.com> #6
su...@google.com <su...@google.com>
il...@google.com <il...@google.com> #7
The underlying root cause for this issue is that the framework would continue to send OnBackInvokedCallback
callbacks for an ongoing gesture even after the activity is destroyed mid-gesture. This has already been fixed for Android 14.
We already
il...@google.com <il...@google.com>
ap...@google.com <ap...@google.com> #8
Branch: androidx-main
commit d933f4c0ecd6d16970114811f4bfb3f3a95647a6
Author: Jeremy Woods <jbwoods@google.com>
Date: Wed Aug 16 23:59:35 2023
Avoid NPE when calling onBackPressed on Android 13
There is a bug in Android 13 where the on BackPressedDisptacher will
still deliver an onBackPressed signal after an Activity has been
DESTROYED.
As a work around we can catch that error and keep the crash from
happening.
RelNote: "ComponentActivity will no longer show a NPE on Android 13 when
a it gets an `onBackPressed()` callback when `DESTROYED`."
Test: Added test
Bug: 291869278
Change-Id: Idb0555c76dd63173a1fa93e34b8bc622500b9176
M activity/activity/src/androidTest/java/androidx/activity/OnBackPressedDispatcherTest.kt
M activity/activity/src/main/java/androidx/activity/ComponentActivity.java
jb...@google.com <jb...@google.com> #9
This has been fixed internally and will be available in Activity 1.8.0-alpha07
.
Description
Since enabling android 13's
enableOnBackInvokedCallback
setting, our app has been experiencing a number of sporadic crashes originating in android only code.Our app only uses OnBackPressedCallback, and registers using LifecycleOwners. (We do not change OnBackInvokedDispatcher).
I have not been able to create a reliable reproduction, however, have a hypothesis from reading through the source code.
WindowOnBackInvokedDispatcher
is invoking anOnBackPressedDispatcher
with no enabled OnBackPressedCallbacks. The crash itself seems to imply the FragmentManager has been destroyed.OnBackPressedDispatcher
, there isnavigateBack
does not perform apopBackStackImmediate
which is different from the OnBackPressedDispatchersfallback
which ultimately invokespopBackStackImmediate
WindowOnBackInvokedDispatcher
uses asetTopOnBackInvokedCallback
.WindowOnBackInvokedDispatcher
, if there is a back-press enqueued while there is another message ahead of it which will causeWindowOnBackInvokedDispatcher
to update it's topCallback, it can run on a stale callback.This race condition ultimately means that
Activity.onBackPressed
is invoked instead ofActivity.navigateBack
, exposing the app to the crash in fragment manager'spopBackStackImmediate
.This is just speculation, but from our crash breadcrumbs it does seem that this crash is also proceeded by the destroy event of an activity 5-100ms prior.
It would be much appreciated to have the perspective of someone more familiar with the platform code. We are seeing a steady increase in this crash as more users adopt android 13.