flutter / flutter

Flutter makes it easy and fast to build beautiful apps for mobile and beyond
https://flutter.dev
BSD 3-Clause "New" or "Revised" License
162.28k stars 26.66k forks source link

"Black screen of death" when resuming Flutter app on Android after several minutes in background #147849

Closed lukehutch closed 1 week ago

lukehutch commented 1 week ago

Steps to reproduce

When I switch away from my Android Flutter app, and switch back to the app a few minutes later, the app comes up with a completely black screen, which does not respond to touch events. In VS Code, there is an action "Debug: Attach to Flutter on Device", which just sits there spinning (it never attaches), so the Flutter process is no longer responding at that point.

I recently upgraded my Android project to build with minSdk = 34 (which may or may not be related to the problem), and I am using:

Flutter 3.22.0-0.3.pre • channel beta • https://github.com/flutter/flutter.git Framework • revision 87b652410d (12 days ago) • 2024-04-23 21:41:18 -0500 Engine • revision b4bfd45986 Tools • Dart 3.4.0 (build 3.4.0-282.3.beta) • DevTools 2.34.3

This happens on a physical Google Pixel 4 (Android 13) and a physical Google Pixel 7 Pro (Android 14), with close to 100% reproducibility.

Issue #139630 looks similar, but it is claimed to be Samsung-specific. So either this has an unrelated cause, or this problem is not Samsung-specific.

Expected results

App should restart

Actual results

App locks up with a "black screen of death"

Code sample

N/A

Screenshots or Video

N/A

Logs

N/A

Flutter Doctor output

Doctor output ```console $ flutter doctor -v [✓] Flutter (Channel beta, 3.22.0-0.3.pre, on Fedora Linux 39 (Workstation Edition) 6.7.7-200.fc39.x86_64, locale en_US.utf8) • Flutter version 3.22.0-0.3.pre on channel beta at /opt/flutter • Upstream repository https://github.com/flutter/flutter.git • Framework revision 87b652410d (12 days ago), 2024-04-23 21:41:18 -0500 • Engine revision b4bfd45986 • Dart version 3.4.0 (build 3.4.0-282.3.beta) • DevTools version 2.34.3 [✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0) • Android SDK at /home/luke/Android/Sdk • Platform android-34, build-tools 34.0.0 • Java binary at: /opt/android-studio/jbr/bin/java • Java version OpenJDK Runtime Environment (build 17.0.10+0-17.0.10b1087.21-11572160) • All Android licenses accepted. [✓] Chrome - develop for the web • Chrome at google-chrome [✓] Linux toolchain - develop for Linux desktop • clang version 17.0.6 (Fedora 17.0.6-2.fc39) • cmake version 3.27.7 • ninja version 1.11.1 • pkg-config version 1.9.5 [✓] Android Studio (version 2023.3) • Android Studio at /opt/android-studio • Flutter plugin version 79.0.2 • Dart plugin can be installed from: 🔨 https://plugins.jetbrains.com/plugin/6351-dart • Java version OpenJDK Runtime Environment (build 17.0.10+0-17.0.10b1087.21-11572160) [✓] VS Code (version 1.89.0) • VS Code at /usr/share/code • Flutter extension version 3.89.20240501 [✓] VS Code (version 1.88.0-insider) • VS Code at /usr/share/code-insiders • Flutter extension version 3.79.20231130 [✓] Connected device (3 available) • Pixel 4 (mobile) • 99121FFAZ005NP • android-arm64 • Android 13 (API 33) • Linux (desktop) • linux • linux-x64 • Fedora Linux 39 (Workstation Edition) 6.7.7-200.fc39.x86_64 • Chrome (web) • chrome • web-javascript • Google Chrome 122.0.6261.94 [✓] Network resources • All expected network resources are available. • No issues found! ```
lukehutch commented 1 week ago

The issue is still present after switching to the Flutter master channel, 3.22.0-23.0.pre.43.

lukehutch commented 1 week ago

Actually if I set the screen lock timeout to 30 minutes and then leave the screen on with the app in the foreground, the app locks up after 5-ish minutes, then does not respond to touch events. Switching away from the app and switching back brings the black screen. Then after killing the app and restarting it, occasionally it just sits there on the Android splash screen, and never starts Flutter.

moffatman commented 1 week ago

Not sure what Android version your devices are running. I think the samsung-specific thing got more complicated, turns out to be a bug in all vendors Android 14 implementation

https://github.com/flutter/flutter/issues/146499#issuecomment-2082873125

AbdeMohlbi commented 1 week ago

Not sure what Android version your devices are running. I think the samsung-specific thing got more complicated, turns out to be a bug in all vendors Android 14 implementation

https://github.com/flutter/flutter/issues/146499#issuecomment-2082873125

Well from the doctor output the pixel 4 uses Android 13 and as far as i know the issue is only with Android 14 and a workaround has been merged to the engine if i still remember ,so if this problem also occurs in Android 13 i think it's worth investigation.

lukehutch commented 1 week ago

@AbdeMohlbi good catch, you're right, the Pixel 4 is on Android 13. The Pixel 7 Pro is on Android 14. Both have the issue. I put a comment on https://github.com/flutter/flutter/issues/146499#issuecomment-2095539350, but maybe this is not the same issue:

I see this problem on both Pixel 4 and Pixel 7 Pro. However, my symptoms are somewhat different than this description.

  1. I get a "black screen of death" when backgrounding the app for some period of time, e.g. 5 minutes (presumably under memory pressure, but not always in any obvious way), then switching back to the app.
  2. The app is not responsive in any way, but I don't get an ANR unless I attach the debugger and pause the running process for long enough.
  3. I cannot connect a debugger to the running Flutter instance, which confirms that the app is not responsive under the black screen.
  4. Rotating the screen does not clear the condition in my case.
  5. The Back button pops the whole app, rather than what would be the current view in the app, which is another indication that the app is unresponsive.
AbdeMohlbi commented 1 week ago

@reidbaker i think u should take a look here

AbdeMohlbi commented 1 week ago

@lukehutch If u can i suggest u provide the pixel 4 And the 8 ui system version maybe this could make the investigation shorter and ty

lukehutch commented 1 week ago

@AbdeMohlbi well the versions are different enough that I don't think this will help (because it spans a wide range of builds), but the Pixel 4 is on build TP1A.221005.002.B2, and the Pixel 7 Pro is on AP1A.240405.002.B1.

lukehutch commented 1 week ago

Here's another finding: if I leave the app running on the phone, without backgrounding the app, with the screen on, sometimes it will freeze with the app still showing on the screen, but it is completely unresponsive (the on-screen keyboard is responsive, but if you minimize the keyboard, the app does not redraw under the keyboard, and nothing else on the screen is responsive). Switching to another app and back brings the black screen of death immediately.

huycozy commented 1 week ago

@lukehutch Do you integrate platform views or use any plugins using platform views under the hood? For us to further investigate this issue, please provide a completed and minimal reproducible code sample that doesn’t include 3rd party plugins or complex production code. Thanks!

lukehutch commented 1 week ago

I don't use any plugins that use platform views, AFAIK. There are a few plugins that use platform functionality, such as for decoding JPEGs, but all the rendering should be in pure Dart/Flutter. Here is my pub deps output though:

deps.txt

I'll try to create a repro, but it may take some time, and I don't know if it will even be possible to trigger this situation with a simpler app (the app I have built is enormous and complex, and it is proprietary, so I can't share it...).

moffatman commented 1 week ago

Upon rereading I missed that the whole app is unresponsive to debugger too. The linked issue was just about graphics presentation, tapping still worked AFAIK. So this sounds like you have some deadlock/freeze somewhere in native code. I would try to attach android native profiler during this situation. Then you can find what stack trace it's frozen in.

AbdeMohlbi commented 1 week ago

@lukehutch hold up I recently upgraded my Android project to build with minSdk = 34 (which may or may not be related to the problem), and I am using: have u tried mkaing it back into 33 and see if the issue still in the pixel 4 also find something but not sure of it here(for the pixel 7 ) also try this

lukehutch commented 1 week ago

@AbdeMohlbi I don't see the point of flashing an update to my Pixel 4 when the problem is also present on the Pixel 7 Pro with Android 14...

I will try the other workaround if I can get this to reproduce reliably, so I can test with and without this change. Thanks. Right now it's hit-or-miss.

lukehutch commented 1 week ago

I have a working theory, based on some bad behavior I have seen in VS Code builds recently (especially with hot reload): I start these sessions in the debugger, then will often unplug the phone and walk away with the app backgrounded. When it's brought back from background, I think something in the hot reload state of the app is mis-aligned with the compiled state of the app (e.g. I have had issues recently with the VS Code debugger seeing one view of the code and the source having a totally different version of the code, due to stale files in the incremental build). Then the phone still thinks it is running in the debugger (even though I unplugged the cable -- I think there is some stale state there too), and Flutter "stops in the debugger" with a runtime exception, even though the debugger is no longer connected.

AbdeMohlbi commented 1 week ago

The hot reload and hot restart is not only with vs code there is a problem with the engine if i remember correctly a fix is not landed yet

lukehutch commented 1 week ago

Why my comment disappeard ?

No idea, I didn't delete it...

The hot reload and hot restart is not only with vs code there is a problem with the engine if i remember correctly a fix is not landed yet

Do you have a link, please?

AbdeMohlbi commented 1 week ago

@lukehutch Check here

lukehutch commented 1 week ago

Upon rereading I missed that the whole app is unresponsive to debugger too. The linked issue was just about graphics presentation, tapping still worked AFAIK. So this sounds like you have some deadlock/freeze somewhere in native code. I would try to attach android native profiler during this situation. Then you can find what stack trace it's frozen in.

Thanks for this tip, it didn't occur to me to try attaching the Android Studio debugger (the VS Code Flutter debugger is unable to attach in this state).

The Android debugger is able to attach, and if I pause execution while in the "black screen of death" state, I see this:

image

So it looks to me like the event loop is still operational.

moffatman commented 1 week ago

That's the main thread stack trace, what about io.flutter.ui thread? That would be the most important one, may need to use some sort of NDK tools to attach and get it?

lukehutch commented 1 week ago

@moffatman I don't have any thread io.flutter.ui in the thread list -- main is the only one I can pause on. Which I assume means that the Flutter renderer process has died (or was shut down when the app was backgrounded for long enough)?

Here are the threads I can see:

image

image

image

image

moffatman commented 1 week ago

Sorry I didn't do this on Android before. On my iPhone the thread is called io.flutter.ui. I believe from your screenshots you should look at 1.ui then.

lukehutch commented 1 week ago

@moffatman I looked at 1.ui and I can neither pause it nor therefore view the stacktrace within it.

lukehutch commented 1 week ago

I did catch this in logcat -- a segfault in libflutter.so -- but I don't know if it is related to the lockup, because I wasn't watching the phone to know when the lockup happened exactly:

--------- beginning of system
2024-05-06 15:11:35.483  8719-8844  libc                    pid-8719                             A  Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x200000c67 in tid 8844 (1.ui), pid 8719 (app.clicksocial)
2024-05-06 15:11:36.299 20254-20254 DEBUG                   pid-20254                            A  Cmdline: app.clicksocial
2024-05-06 15:11:36.299 20254-20254 DEBUG                   pid-20254                            A  pid: 8719, tid: 8844, name: 1.ui  >>> app.clicksocial <<<
2024-05-06 15:11:36.299 20254-20254 DEBUG                   pid-20254                            A        #00 pc 000000000226ecf8  /data/app/~~_LatxRCcVRHcjPJSEgbUmA==/app.clicksocial-mgJ3rSbsI_sP5x3qAxEgPQ==/lib/arm64/libflutter.so (BuildId: f062ddda7530d5698d7860a32e8e8d7088526de3)
2024-05-06 15:11:36.299 20254-20254 DEBUG                   pid-20254                            A        #01 pc 00000000021e975c  /data/app/~~_LatxRCcVRHcjPJSEgbUmA==/app.clicksocial-mgJ3rSbsI_sP5x3qAxEgPQ==/lib/arm64/libflutter.so (BuildId: f062ddda7530d5698d7860a32e8e8d7088526de3)
2024-05-06 15:11:36.299 20254-20254 DEBUG                   pid-20254                            A        #02 pc 00000000021e9940  /data/app/~~_LatxRCcVRHcjPJSEgbUmA==/app.clicksocial-mgJ3rSbsI_sP5x3qAxEgPQ==/lib/arm64/libflutter.so (BuildId: f062ddda7530d5698d7860a32e8e8d7088526de3)
2024-05-06 15:11:36.300 20254-20254 DEBUG                   pid-20254                            A        #03 pc 00000000021ea72c  /data/app/~~_LatxRCcVRHcjPJSEgbUmA==/app.clicksocial-mgJ3rSbsI_sP5x3qAxEgPQ==/lib/arm64/libflutter.so (BuildId: f062ddda7530d5698d7860a32e8e8d7088526de3)
2024-05-06 15:11:36.300 20254-20254 DEBUG                   pid-20254                            A        #04 pc 00000000021eb3d8  /data/app/~~_LatxRCcVRHcjPJSEgbUmA==/app.clicksocial-mgJ3rSbsI_sP5x3qAxEgPQ==/lib/arm64/libflutter.so (BuildId: f062ddda7530d5698d7860a32e8e8d7088526de3)
2024-05-06 15:11:36.300 20254-20254 DEBUG                   pid-20254                            A        #05 pc 00000000022fcaf4  /data/app/~~_LatxRCcVRHcjPJSEgbUmA==/app.clicksocial-mgJ3rSbsI_sP5x3qAxEgPQ==/lib/arm64/libflutter.so (BuildId: f062ddda7530d5698d7860a32e8e8d7088526de3)
2024-05-06 15:11:36.300 20254-20254 DEBUG                   pid-20254                            A        #06 pc 00000000022f4a40  /data/app/~~_LatxRCcVRHcjPJSEgbUmA==/app.clicksocial-mgJ3rSbsI_sP5x3qAxEgPQ==/lib/arm64/libflutter.so (BuildId: f062ddda7530d5698d7860a32e8e8d7088526de3)
2024-05-06 15:11:36.300 20254-20254 DEBUG                   pid-20254                            A        #07 pc 00000000022f4f20  /data/app/~~_LatxRCcVRHcjPJSEgbUmA==/app.clicksocial-mgJ3rSbsI_sP5x3qAxEgPQ==/lib/arm64/libflutter.so (BuildId: f062ddda7530d5698d7860a32e8e8d7088526de3)
2024-05-06 15:11:36.300 20254-20254 DEBUG                   pid-20254                            A        #08 pc 00000000022033b0  /data/app/~~_LatxRCcVRHcjPJSEgbUmA==/app.clicksocial-mgJ3rSbsI_sP5x3qAxEgPQ==/lib/arm64/libflutter.so (BuildId: f062ddda7530d5698d7860a32e8e8d7088526de3)
2024-05-06 15:11:36.300 20254-20254 DEBUG                   pid-20254                            A        #09 pc 00000000022269b4  /data/app/~~_LatxRCcVRHcjPJSEgbUmA==/app.clicksocial-mgJ3rSbsI_sP5x3qAxEgPQ==/lib/arm64/libflutter.so (BuildId: f062ddda7530d5698d7860a32e8e8d7088526de3)
2024-05-06 15:11:36.300 20254-20254 DEBUG                   pid-20254                            A        #10 pc 0000000002226b84  /data/app/~~_LatxRCcVRHcjPJSEgbUmA==/app.clicksocial-mgJ3rSbsI_sP5x3qAxEgPQ==/lib/arm64/libflutter.so (BuildId: f062ddda7530d5698d7860a32e8e8d7088526de3)
2024-05-06 15:11:36.300 20254-20254 DEBUG                   pid-20254                            A        #11 pc 00000000023195ec  /data/app/~~_LatxRCcVRHcjPJSEgbUmA==/app.clicksocial-mgJ3rSbsI_sP5x3qAxEgPQ==/lib/arm64/libflutter.so (BuildId: f062ddda7530d5698d7860a32e8e8d7088526de3)
2024-05-06 15:11:36.300 20254-20254 DEBUG                   pid-20254                            A        #12 pc 00000000022ecedc  /data/app/~~_LatxRCcVRHcjPJSEgbUmA==/app.clicksocial-mgJ3rSbsI_sP5x3qAxEgPQ==/lib/arm64/libflutter.so (BuildId: f062ddda7530d5698d7860a32e8e8d7088526de3)
moffatman commented 1 week ago

May be a way with profiling tools to at least record generally what the 1.ui thread is doing?

lukehutch commented 1 week ago

@AbdeMohlbi I can confirm that this suggestion you linked to (modifying MainActivity.kt) does not solve the problem: https://github.com/flutter/flutter/issues/139630#issuecomment-1858465706

lukehutch commented 1 week ago

@moffatman Profiling tells me that 1.ui is sleeping:

image

However, now if I tap on the screen, I can wake up the main thread, and see what at least that thread is doing:

image

image

So basically it looks like ActivityThread.main is just sitting in its event loop as normal. Also, it looks like touch events are in fact being delivered (although they are not presumably being picked up by Flutter, since it seems that Flutter is not running.)

image

In the profiler, there is no option to profile the 1.ui thread using the method trace or callstack methods, and it shows as "No data available" in "System trace":

image

lukehutch commented 1 week ago

Upon rereading I missed that the whole app is unresponsive to debugger too.

To clarify, the app is unresponsive to the Flutter debugger, but responds to the Android debugger.

moffatman commented 1 week ago

OK not sure where to go next. Only clue left is the segfault? If you run with --split-debug-info=/path/to/dir, you could symbolicate that native stack libflutter.so and find what segfaulted. Is the segfault shown in every reproduction?

lukehutch commented 1 week ago

@moffatman I have only seen that segfault once, but I'll try that if I see it again.

lukehutch commented 1 week ago

I have been having significant issues with the binary and source of my app getting out of sync (e.g. the running program trying to call a method that doesn't exist anymore in the source, i.e. something in the app assembly process has been depending upon stale state), so went and deleted all the state I could find for VS Code, killed all the running processes to do with Dart and VS Code, and restarted. For now, this issue seems to have disappeared, so I'll close this issue for now, and I'll reopen if it comes back.