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

[moffatman]

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

#146499 (comment)

[lukehutch]

@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]

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.

[moffatman]

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.

[lukehutch]

@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]

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:

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

[moffatman]

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]

@AbdeMohlbi I can confirm that this suggestion you linked to (modifying MainActivity.kt) does not solve the problem: #139630 (comment)

[lukehutch]

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

[lukehutch]

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.

[AbdeMohlbi]

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

#146499 (comment)

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]

@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 #146499 (comment), 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]

@reidbaker i think u should take a look here

[AbdeMohlbi]

@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

[huycozy]

@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]

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

[AbdeMohlbi]

@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]

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]

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]

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]

@lukehutch
Check here

[lukehutch]

@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:

[moffatman]

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]

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

[lukehutch]

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]

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

[lukehutch]

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

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

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

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":

[lukehutch]

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]

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]

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

[lukehutch]

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.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.