Activity lifecycle issues. after onDestroy, application will become unusable #1844
Comments
|
Nice and comprehensive bug report! |
|
Interesting, I feel like this would have been noticed if it had always happened, but I don't know what could have changed about it. Maybe it could be related to:
|
|
My app is terminated in the background a lot and I use bleeding edge p4a with a bumped up SDL2 version and it seems to work fine. I don't think I ever saw this with the current SDL2 version (not bumped up) either, so it doesn't seem to be a universal breakage I am wondering, I could see this happen if the app actually exited on its own, but not all python threads terminated and it would therefore continue to hang around and not restart properly when launched next time. Could this possibly be the cause? (In that case it would likely be a bug in some associated library that Etheroll and electrum both happen to be using) |
How would the app "exit on its own"? Do you mean if the app overrides |
|
no just exit the main function or use sys.exit() or os._exit. if you do any of the these and other threads keep running you're in for all sorts of breakage (would also happen if the main loop /main function ever bails out with uncaught error with any other non-daemon threads not terminating themselves) |
|
I don't think there is any code in Electrum that directly interacts with the activity lifecycle. Note that this issue happens if and only if the activity onDestroy is called (as can be seen from the logs in OP). |
|
ondestroy will be called by android right after afaik, if you exit in any of the ways I described (or the sdl2 java wrapper, one of the two) |
|
Note the logs in OP:
|
|
I am having the same problem with another app. It's just barebones kivy app with one button that creates a foreground service (that just prints stuff every 5 seconds), so really no weird libraries. If onDestroy is called while the service is active, the application becomes unusable. |
|
Hello, I have had some similar troubles with a p4a/kivy application life cycle on Android. Basically, if I close the app through the "previous" button of the phone (OnePlus 3T), everything is fine. It disappears from the "cached background processes" list of developer tools panel. I can relaunch the app, it loads from start (with splashscreen) and works. But if I go to the "active applications list" via the other button, and kill the application by swiping it right, it enters a weird "zombie" state : is still present in the "cached background processes", but if I relaunch it, it immediately shows an unresponsive black/grey screen, which I must kill again to be able to properly relaunch (from start) the application. My investigations showed that it's indeed the presence of a FOREGROUND service (with mService.startForeground(...)) which leads to this weird zombie mode. If I let the service be only a background service, then swiping the app preview right in the "actice applications list" properly kills the whole application. The logcat (and the logs I've added to SDL onDestroy()) show that in the case of an app with a BACKGROUND service (the GOOD one):
Whereas in the case of an app with a FOREGROUND service (the ZOMBIE one):
I've found no other solution than to add a "Process.killProcess(Process.myPid());" at the beginning of SDL onDestroy()... but I dunno what the implications are for this brutal treatment of the problem. Does anybody understand why Android doesn't kill the whole app after suppressing its foreground service ? Below are logcats and example applications with and without foreground service, to reproduce the problem. I'm on the latest kivy and python-for-android commits, stable versions had the same problem. best_of_logcat_lifecycle_issues.zip p4a_app_cached_process_restoration_fails_full_logcat.zip WitnessAngelDemo__armeabi-v7a-0.1-debug_background_service.apk.zip WitnessAngelDemo__armeabi-v7a-0.1-debug_foreground_service.apk.zip |
Has anyone been able to make any progress on this, as I am seeing the exact same behaviour? If my app which is running a foreground process is killed by swiping it away, then when I try and relaunch it I just get an black/grey screen and the Python process never starts. I have to swiped this unresponsive app away again, and then it will start quite happily. The only difference I can see in the logs is when the app is swiped away for the first time I see:
When I swipe it away the second time I see:
I am very new to p4a, so any advice would be much appreciated |
|
Has anybody got the solution? I ran into the same issue and the app starts only if I go to the Developer options -> Running services -> Show cached processes and stop the process manually. |
|
I played around with killBackgroundProcesses() and got all the stuff working, I placed that code within onStartCommand() method just before |
I too have this problem, having a foreground service, and user swiping away while the app is in the background. Placing |
|
This appears to have been resolved as of Kivy 2.1.0 and Python for Android 2022.07.20. Valory Go 0.1.29 release is confirmed to work properly and no longer needs workaround for the black screen on app startup issue. |
|
Closing based on sunnyking's comment. If this problem persists, please let us know. |
Valory Go is closed source (as far as I can see, if google sent me to the right place), so it's hard to see what fix or workaround has been applied. The changelog mentions a service restart, which sounds like a crude workaround might have been applied. IMO this issue should be reopened. |
I am testing latest Electrum, which uses p4a ccb0f8e, buildozer kivy/buildozer@678b1bf, and kivy kivy/kivy@82d561d
(sdl2 bootstrap)
on both Android 8 and 9
If the application is in the background, and the OS destroys the activity to reclaim memory, the next time the user puts the app into foreground, the whole screen will be black/empty, and the app needs to be killed manually and restarted for it to become usable.
To test this, go to Android settings > Developer options > and enable
Don't keep activities.Then,
To make sure this is not an issue with Electrum, I've also reproduced using @AndreMiras' EtherollApp.
logcat 1, with activity left alone by OS, works as expected
logcat 2, with activity destroyed by OS, issue manifests
The text was updated successfully, but these errors were encountered: