[TIMOB-24962] Android - App Crashes on Resume

GitHub Issue	n/a
Type	Bug
Priority	Critical
Status	Closed
Resolution	Duplicate
Resolution Date	2017-07-26T19:06:13.000+0000
Affected Version/s	Release 6.0.4, Release 6.1.1
Fix Version/s	Release 6.1.2
Components	Android
Labels	android, crash, defect
Reporter	Rene Pot
Assignee	Gary Mathews
Created	2017-07-14T15:23:12.000+0000
Updated	2017-07-27T15:57:19.000+0000

Description

When resuming the app from background the app crashes most of the times on device SM-G928G. To replicate this install the default app when creating a new project (also attached) on the android device. To trigger the app to go to background go to developer settings and put the option "limit background process" to "at most 1 process". Open the just installed app, go through multitasking to another app, then again through multitasking go back to the just installed app. The app will now crash. A log we found around the crash:

07-14 15:59:56.166 21434-21434/? E/Zygote: v2
07-14 15:59:56.167 21434-21434/? E/Zygote: accessInfo : 0
07-14 15:59:56.167 21434-21434/? W/SELinux: SELinux selinux_android_compute_policy_index : Policy Index[2],  Con:u:r:zygote:s0 RAM:SEPF_SECMOBILE_7.0_0005, [-1 -1 -1 -1 0 1]
07-14 15:59:56.197 3642-3666/? W/WindowManager: Failed looking up window
                                                java.lang.IllegalArgumentException: Requested window android.view.ViewRootImpl$W@c68471b does not exist
                                                    at com.android.server.wm.WindowManagerService.windowForClientLocked(WindowManagerService.java:10431)
                                                    at com.android.server.wm.WindowManagerService.windowForClientLocked(WindowManagerService.java:10422)
                                                    at com.android.server.wm.WindowManagerService.removeWindow(WindowManagerService.java:2674)
                                                    at com.android.server.wm.Session.remove(Session.java:208)
                                                    at android.view.ViewRootImpl.dispatchDetachedFromWindow(ViewRootImpl.java:3699)
                                                    at android.view.ViewRootImpl.doDie(ViewRootImpl.java:6612)
                                                    at android.view.ViewRootImpl$ViewRootHandler.handleMessage(ViewRootImpl.java:4117)
                                                    at android.os.Handler.dispatchMessage(Handler.java:102)
                                                    at android.os.Looper.loop(Looper.java:154)
                                                    at android.os.HandlerThread.run(HandlerThread.java:61)
                                                    at com.android.server.ServiceThread.run(ServiceThread.java:46)
07-14 15:59:56.202 21434-21434/? W/System: ClassLoader referenced unknown path: /system/priv-app/CMHProvider/lib/arm64

Attachments

File	Date	Size
Crash on Resume.zip	2017-07-14T15:20:06.000+0000	7870176

Comments

Rene Pot 2017-07-14

I should add it doesn't only happen on device specified, but I know for certain it does happen on that one.
Joshua Quick 2017-07-17

Setting the "limit background process" to 1 will force quit apps that were put in the background (ie: suspended). This is normal. You can tell when this is happening when you see "WINDEATH" in the Android log. You can see the full log via the Android SDK's "adb logcat" command line tool. You can see this happening with Google's apps as well. Tap on the Calendar app and then create/tap on an event to display an event activity window. Press the home button and go to a different app. And then switch back to the Calendar app. Notice that the Calendar app is restarting (you can see its splashscreen). You would also see that it was forced-quit by the Android OS in the background as well (WINDEATH in adb logcat). The difference here is that Google's app keeps track of the last state it was in so that it can restore its previous state. Also, the Android OS can force-quit your app when it is running low on memory as well. This is likely to happen if your app consumes a lot of memory such as images.
Michael Gangolf 2017-07-17
Caio Iglesias 2017-07-18

Hi, I work with Rene and I saw this issue happening too. Setting the limit of background processes to 1 is just the quick way to create the scenario for the crash to occur faster. I used Joshua's calendar example for this video: https://drive.google.com/file/d/0B4q2Tzi3o3rydGtla2ZrbTVOQjQ/view Google calendar relaunches, Titanium based app attempts to relaunch and then crashes.
Rene Pot 2017-07-18

It indeed seems to have relation with the crash mentioned above. To me this issue seems quite urgent as we get floaded with crashreports in the vitals dashboard and through other channels.
Joshua Quick 2017-07-18

It's not crashing on resume. It's being force quit in the background after switching apps. That's my point. For example, try adding this code snippet to your app: setInterval(function() { Ti.API.info("@@@ Timer elapsed. " + (new Date()).toString()); }, 1000); The above will log a message every 1 second, even while the app is in the background (this isn't iOS; your app doesn't really suspend). When switching to another app with this setting on (or if the device is running low on memory), your app can be force-quit by the OS. When this happens, you'll notice that the above stops logging a message every 1 second and the last logged message will be followed by another message such as... ActivityManager: Killing <YourProcessId>:<YourPackageName> ...along with a message like this... WindowManager: WIN DEATH: Window{228b981 u0 <YourPackageName>/<YourPackageName>.<YourActivityName>} You can't catch this event. This is like a Windows Ctrl+Alt+Delete equivalent that's happening to your app. And unfortunately, Android won't automatically restore the last state of your app. It's up to you keep track of where it was last left off. Also, I don't think the "IllegalArgumentException" stack trace you gave us is related. We actually see this exception when launching an app from a "cold start" from Appcelerator Studio. And it's an exception from the OS, not the Titanium app. Note that there is no Titanium/Appcelerator related things in the stack trace (although I'd like to know what triggers this).
Gary Mathews 2017-07-26

This will be fixed by https://github.com/appcelerator/titanium_mobile/pull/9256
Gary Mathews 2017-07-26

Resolving as duplicate of TIMOB-24710 This issue has been addressed in 6_1_X by [PR-#9256](https://github.com/appcelerator/titanium_mobile/pull/9256)
Abir Mukherjee 2017-07-26

Closing this as TIMOB-24710 is confirmed to have the fix.
Caio Iglesias 2017-07-27

Cool! Just tested it with the PR too. Works! Nice job!

Michael Gangolf 2017-07-27

While this is working fine on my Android 7 device (HTC A9) I have problems with the default Alloy app on a Moto G2 (5.1.1): [Video](http://migaweb.de/restart2.mp4) App background limit is set to 1, so after starting the Play Store the test_start2 app is destroyed in the background. Here is the log:

    I/TiApplication(12729): (main) [0,0] checkpoint, app created.
    I/TiApplication(12729): (main) [105,105] Titanium 6.1.2 (2017/07/27 01:49 undefined)
    E/Vold(319): Failed to find mounted volume for /storage/sdcard1/Android/data/com.miga.test2/cache/
    W/Vold(319): Returning OperationFailed - no handler for errno 0
    I/TiApplication(12729): (main) [778,883] Titanium Javascript runtime: v8
    W/TiBaseActivity(12729): (main) [20,903] Runtime has been disposed or app has been killed. Finishing.
    W/TiApplication(12729): (main) [11,914] Scheduling application restart
    D/TiLaunchActivity(12729): (main) [149,1063] willFinishFalseRootActivity: TiApplication.forceFinishRoot = true
    W/InputMethodManagerService(921): Window already focused, ignoring focus gain of: com.android.internal.view.IInputMethodClient$Stub$Proxy@24c68dbf attribute=null, token = android.os.BinderProxy@235129e5
    W/libprocessgroup(921): failed to open /acct/uid_10214/pid_12729/cgroup.procs: No such file or directory
    V/WindowManager(921): removeAppToken make exiting: AppWindowToken{d7a672 token=Token{bb8f77d ActivityRecord{36f609d4 u0 com.miga.test2/org.appcelerator.titanium.TiActivity t993}}}
    W/WindowManager(921): Failed looking up window
    W/WindowManager(921): java.lang.IllegalArgumentException: Requested window android.view.ViewRootImpl$W@52c1492 does not exist
    W/WindowManager(921): 	at com.android.server.wm.WindowManagerService.windowForClientLocked(WindowManagerService.java:8464)
    W/WindowManager(921): 	at com.android.server.wm.WindowManagerService.windowForClientLocked(WindowManagerService.java:8455)
    W/WindowManager(921): 	at com.android.server.wm.WindowManagerService.removeWindow(WindowManagerService.java:2575)
    W/WindowManager(921): 	at com.android.server.wm.Session.remove(Session.java:186)
    W/WindowManager(921): 	at android.view.ViewRootImpl.dispatchDetachedFromWindow(ViewRootImpl.java:2959)
    W/WindowManager(921): 	at android.view.ViewRootImpl.doDie(ViewRootImpl.java:5460)
    W/WindowManager(921): 	at android.view.ViewRootImpl$ViewRootHandler.handleMessage(ViewRootImpl.java:3283)
    W/WindowManager(921): 	at android.os.Handler.dispatchMessage(Handler.java:102)
    W/WindowManager(921): 	at android.os.Looper.loop(Looper.java:135)
    W/WindowManager(921): 	at android.os.HandlerThread.run(HandlerThread.java:61)
    W/WindowManager(921): 	at com.android.server.ServiceThread.run(ServiceThread.java:46)

A different (more complex) app restarts fine on the HTC device! Just the default currently makes problems on the old device.

JSON Source