-
Notifications
You must be signed in to change notification settings - Fork 2k
Description
This problem actually was noted by another reviewer in ticket #646, but I suspect they stopped seeing it because only certain situations seem to trigger it. Specifically, it appears that rotation and pause / resume can cause the PythonActivity to be destroyed and re-created, even if the app is still running in the background. The behavior is documented in the Android docs here:
https://developer.android.com/training/basics/activity-lifecycle/recreating.html
To avoid having a complete app restart, it appears that Android caches the app state using the Bundle instance and tries to restore the app state automatically on resume. This is why onCreate gets a Bundle object that sometimes is empty (new start), and sometimes is not (rotation change or resume).
Unfortunately, it appears the state saving behavior is "under the hood" and it would take a deep look into Android's code to know what state it saves and when. It does seem to differ from app to app, which is why the problem is not persistent and easily reproduced.
When it does happen, you get the crash noted in #646, and tracking that down, you find that the problem is that when onCreate is called with a non-empty Bundle, it causes mLayout and mImageView to be restored from cache, so the attempt in showLoadingScreen to add mImageView to mLayout gives a 'duplicate view' error.
I'm going to submit a pull request with a fix for this. I didn't discover a way to check if a view exists, and I wasn't sure if doing a try block with removeView would have any side-effects, so I went with the solution of only setting mImageView to mLayout if we don't have an existing mImageView. The potential side-effect is that resume may not show the splash screen, but resume startup won't have the potential unzip slowdown, and the Bundle resuming should reduce the loading time on resume at least somewhat.
Anyway, I'm open to a different or better approach if anyone knows of one. :)
Also, I think #730 and #732 are affected by recreating the PythonActivity based on their problem descriptions, but I do not know this for certain.