Android 13: Crash in WindowOnBackInvokedDispatcher / OnBackPressedDispatcher [291869278]

Fixed

Bug

androidx-activity-1.8.0-alpha07

Status Update

No update yet.

Description

be...@airbnb.com

created issue #1

Jul 19, 2023 06:45PM

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).

java.lang.NullPointerException: Attempt to invoke virtual method 'android.os.Handler android.app.FragmentHostCallback.getHandler()' on a null object reference
        at android.app.FragmentManagerImpl.ensureExecReady(FragmentManager.java:2008)
        at android.app.FragmentManagerImpl.execPendingActions(FragmentManager.java:2061)
        at android.app.FragmentManagerImpl.popBackStackImmediate(FragmentManager.java:874)
        at android.app.FragmentManagerImpl.popBackStackImmediate(FragmentManager.java:835)
        at android.app.Activity.onBackPressed(Activity.java:4083)
        at androidx.activity.ComponentActivity.access$001(ComponentActivity.java:121)
        at androidx.activity.ComponentActivity$1.run(ComponentActivity.java:165)
        at androidx.activity.OnBackPressedDispatcher.onBackPressed(OnBackPressedDispatcher.kt:216)
        at androidx.activity.OnBackPressedDispatcher$2.invoke(OnBackPressedDispatcher.kt:102)
        at androidx.activity.OnBackPressedDispatcher$2.invoke(OnBackPressedDispatcher.kt:102)
        at androidx.activity.OnBackPressedDispatcher$Api33Impl.createOnBackInvokedCallback$lambda$0(OnBackPressedDispatcher:286)
        at androidx.activity.OnBackPressedDispatcher$Api33Impl$$InternalSyntheticLambda$1$5dea06066ea46437e84a2264f31c2ea84a3652ee19c7688a4a1451cf132e3013$0.onBackInvoked(OnBackPressedDispatcher:3)
        at android.window.WindowOnBackInvokedDispatcher$OnBackInvokedCallbackWrapper.lambda$onBackInvoked$3$android-window-WindowOnBackInvokedDispatcher$OnBackInvokedCallbackWrapper(WindowOnBackInvokedDispatcher.java:287)
        at android.window.WindowOnBackInvokedDispatcher$OnBackInvokedCallbackWrapper$$ExternalSyntheticLambda0.run(Unknown:2)
        at android.os.Handler.handleCallback(Handler.java:942)
        at android.os.Handler.dispatchMessage(Handler.java:99)
        at android.os.Looper.loopOnce(Looper.java:226)
        at android.os.Looper.loop(Looper.java:313)
        at android.app.ActivityThread.main(ActivityThread.java:8757)
        at java.lang.reflect.Method.invoke(Method.java:-2)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:571)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1067)

I have not been able to create a reliable reproduction, however, have a hypothesis from reading through the source code.

The nature of the crash invoking the fallbackHandler implies that WindowOnBackInvokedDispatcher is invoking an OnBackPressedDispatcher with no enabled OnBackPressedCallbacks. The crash itself seems to imply the FragmentManager has been destroyed.
This appears somewhat unexpected from the platform, as in OnBackPressedDispatcher, there is logic to ensure when there are no active callbacks the window dispatcher is updated to not have the OnBackPressedDispatcher as the "topCallback". Instead the Activity's navigateBack is used. Notably, navigateBack does not perform a popBackStackImmediate which is different from the OnBackPressedDispatchers fallback which ultimately invokes onBackPress and popBackStackImmediate
The WindowOnBackInvokedDispatcher uses a weak reference to the proper back callback which is created via setTopOnBackInvokedCallback.
Since back presses are enqueued on a handler in WindowOnBackInvokedDispatcher, if there is a back-press enqueued while there is another message ahead of it which will cause WindowOnBackInvokedDispatcher to update it's topCallback, it can run on a stale callback.

This race condition ultimately means that Activity.onBackPressed is invoked instead of Activity.navigateBack, exposing the app to the crash in fragment manager's popBackStackImmediate.

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.

Comments

su...@google.com <su...@google.com> Jul 20, 2023 07:37AM

Assigned to su...@google.com.

su...@google.com <su...@google.com> #2Jul 20, 2023 09:02AM

Thank you for reporting this issue. For us to further investigate this issue, please provide the following additional information:

Android build
Which Android build are you using? (e.g. OPP1.170223.012)

Device used
Which device did you use to reproduce this issue?

Steps to reproduce
What steps are needed to reproduce this issue?

Please provide sample project or apk to reproduce the issue. Also mention the steps to be followed for reproducing the issue with the given sample project or apk.

Android bug report capturing
After reproducing the issue, press the volume up, volume down, and power button simultaneously. This will capture a bug report on your device in the “bug reports” directory. Attach the bug report file to this issue.

Alternate method
After reproducing the issue, navigate to “developer settings”, ensure “USB debugging” is enabled, then enable “Bug report shortcut”. Capture bug report by holding the power button and selecting the “Take bug report” option.

Screen capture of the issue
Press the volume down and power buttons simultaneously. The image will appear in your gallery. Attach the screenshot file to this issue.

NOTE : To avoid leaking private information, please share screenshots and bugreports only in Google Drive. Share files with android-bugreport@google.com and include only Google drive links in your bug. Bug report attachments should not be included directly in issue reports.

kj...@gmail.com <kj...@gmail.com> #3Jul 20, 2023 06:59PM

Can you please address

comment#2

?
Unfortunately the issue would be closed within 7 days if there is no further update.

lo...@gmail.com <lo...@gmail.com> #4Jul 23, 2023 07:16PM

Attached is a sample project that demonstrates the issue in two ways:
- when long pressing text (e.g. the headline)
- when opening a select
Both will ultimately load an alert dialog with a list adapter that has the layout ids for the content set to 0.

https://drive.google.com/file/d/1Fe2ym2F0o4XWEDHvKY8-UzpvSJq4wbWq/view?usp=drive_web (WebViewAppCompatBug.zip)

This is reproducible on an API 21 emulator (Nexus 5 configuration, no Chrome installed).

NB There is a second issue when loading the web view in the first place which in this sample project is worked around by using a resource wrapper. This is already reported under

https://issuetracker.google.com/issues/140884278 and the attached project will also display this error when commenting out lines 13-15 in MainActivity.kt.

be...@airbnb.com <be...@airbnb.com> #5Jul 24, 2023 04:46PM

Please take a look at this issue and provide your inputs.

fe...@gmail.com <fe...@gmail.com> #6Jul 26, 2023 05:08PM

Wrapping Resources is not supported by the framework and you must not create your own instances of Resources at all (the APIs to do so are now marked deprecated after they were accidentally exposed).

We can't do anything to fix this - you need to solve the underlying problem with appcompat and stop wrapping it like this, and then resources will work.

su...@google.com <su...@google.com> Aug 3, 2023 02:34PM

Status: New

il...@google.com <il...@google.com> #7Aug 4, 2023 10:00PM

Assigned to sa...@google.com.

While I agree this is WontFIx from WebView's perspective (the WebView APK in question already shipped), it seems like this should still be considered a regression from appcompat's perspective, given the community can no longer test on lower-level emulators. We've received several unique user reports of this issue, not to mention the internal reports which led to filing

issue 139710458

.

Surprisingly,

issue 142086375

claims this bug repros on Marshmallow, which is something we haven't observed so far and doesn't fit into the current hypothesis:

> in Android 6.0 (API 23) it crashes on tapping the <select> element.

---

From

issue 141132133

:

> This change is the root cause:

https://android.googlesource.com/platform/frameworks/support/+/26079d87c79a64829f036236353fac1dae4e0613%5E%21/#F2
>
> sAlwaysOverrideConfiguration forces updating the Resources configuration and therby messing up the webview inflation on older devices.

Chis, any chance this checks out? I didn't look too closely into this, so I'm not sure if there are consequences to not overriding the configuration on L-M only, or perhaps further limited old WebView versions only.

il...@google.com <il...@google.com> Aug 16, 2023 11:23PM

Reassigned to jb...@google.com.

ap...@google.com <ap...@google.com> #8Aug 17, 2023 12:49AM

Same problem appear simply by using a WebView on Android 5 / 5.1 (on actual devices, no emulator) with appcompat:1.1.0 directly causing a crash (on display, no interaction needed).

jb...@google.com <jb...@google.com> #9Aug 17, 2023 12:57AM

Marked as fixed.

Dropping the priority of this, since there's no feasible fix for this.