Solved How to figure out what's killing Android app after about a minute?
-
I have an old Android app built in Qt5.7 (QQuickView, QML plus some custom C++ & OpenGL components).
It works great on the HW it originally a targeted - a Galaxy Tab S2 (now up to OS 7.0) - but on a Galaxy Tab S4 (OS 8.1.0) something kills it after on the order of thirty seconds to a minute of starting it up, whether I'm actively using it or just letting it sit on its own "front page" doing absolutely nothing. There's nothing obvious (to me) in the logging (from the app's own qInfo() logging or in all the system spew) which informs me why it might have been shut down... but then I have to admit most of the Android logging is opaque to me and I've no idea what to look for or what most of it is.
A quick test on an OS 9 phone showed a similar issue there, so now I am slightly worried this is something which will affect all devices with OS8 or later... need to do some more testing though.
App has been more widely tested on iPads (works great on everything we've tried it on). On Android, in the early days we had some issues with rcc files being too big to be reliably memory mapped but this isn't that.
Any ideas what might have changed in the Android OS that Qt5.7 didn't anticipate and/or any pointers what to look for in the logs to understand why the system has decided to kill it? (Googling led to QTBUG-56648, but that's about services rather than apps, I think. I do wonder if more aggressive power management is something to do with it though).
-
Think I've got some insight into this one now. It really only seems to be on OS8... the app works absolutely fine on OS7, 9 & 10.
I added (to app's QML) a Timer spitting out a console.info message at a 10Hz rate. This let me identify what else the system was doing in a 0.1s window around the time the app died... and it invariably seemed to be some "dex2oat" thing on some bit of the app.
Apparently dex2oat is something which precompiles bytecode into native code (so-called "Ahead Of Time" compilation). There's obviously something about my Qt5.7 app which causes some trouble on OS8. It works fine on OS7, 9 & 10. A minimal Qt5.7 app also worked fine on OS8. But my app recompiled with other Qts up to 5.10 also broke on OS8.
However.... my understanding (after reading up on it) is that dex2oat only processes an app while it's running when the apk has been installed "developer style" (e.g over USB). If you install via an installer, all the dex2oat processing happens during the "Installing..." stage, before the app runs. However, for development, apparently the system allows apps to be run (presumably interpreting byte code) before having been fully dex2oat processed, in the name of developer productivity and not making people wait.
So, I tested the app installed by the appstore (we use Amazon's, due to a monstrous app size) on OS8. Sure enough, it worked fine. (Before that, all my OS8 testing had been via Amazon Device Farm where you just get to upload an apk to be tested, which is less hassle, and faster than jumping through appstore hoops on a fresh device).
Why the dex2oat thing should be toxic to my particular app when it's installed "developer style" on OS8 alone remains a mystery, but I can live with it when 9&10 are fine and normal users installing via the appstore should never see the issue.
Did find some mention of an app manifest attribute
android:vmSafeMode="true"
. It seemed to make some difference on OS7 (dex2oat command being applied the app changes to include--compiler-filter=interpret-only
)... but seems to make no difference on OS8 (the problem one) or later. (I'm going to interpret that as something significant changed in OS8, broke something enough to cause my app some trouble, and then got fixed in OS9+. But who knows really.)Be interested in any comments from someone who understands more about what's going on!
-
That might be silly to ask but have you tried deploying and debugging your app while running on the phone to see exactly which part of your code cause the crash and what is the exact error?
-
Ooops I should have added that I don't actually have any Android HW other than the OS7 Galaxy Tab S2 mentioned... all the other testing has been via AWS's "Device Farm" which lets you upload an apk and interact with it (or automated fuzz-test it) and capture videos/screenshots/logs... but not actually debug it!
Have been away from this issue for a couple of weeks but about to start looking at it again. Might indeed be easiest to just get hold of some more recent Android HW though!
-
Think I've got some insight into this one now. It really only seems to be on OS8... the app works absolutely fine on OS7, 9 & 10.
I added (to app's QML) a Timer spitting out a console.info message at a 10Hz rate. This let me identify what else the system was doing in a 0.1s window around the time the app died... and it invariably seemed to be some "dex2oat" thing on some bit of the app.
Apparently dex2oat is something which precompiles bytecode into native code (so-called "Ahead Of Time" compilation). There's obviously something about my Qt5.7 app which causes some trouble on OS8. It works fine on OS7, 9 & 10. A minimal Qt5.7 app also worked fine on OS8. But my app recompiled with other Qts up to 5.10 also broke on OS8.
However.... my understanding (after reading up on it) is that dex2oat only processes an app while it's running when the apk has been installed "developer style" (e.g over USB). If you install via an installer, all the dex2oat processing happens during the "Installing..." stage, before the app runs. However, for development, apparently the system allows apps to be run (presumably interpreting byte code) before having been fully dex2oat processed, in the name of developer productivity and not making people wait.
So, I tested the app installed by the appstore (we use Amazon's, due to a monstrous app size) on OS8. Sure enough, it worked fine. (Before that, all my OS8 testing had been via Amazon Device Farm where you just get to upload an apk to be tested, which is less hassle, and faster than jumping through appstore hoops on a fresh device).
Why the dex2oat thing should be toxic to my particular app when it's installed "developer style" on OS8 alone remains a mystery, but I can live with it when 9&10 are fine and normal users installing via the appstore should never see the issue.
Did find some mention of an app manifest attribute
android:vmSafeMode="true"
. It seemed to make some difference on OS7 (dex2oat command being applied the app changes to include--compiler-filter=interpret-only
)... but seems to make no difference on OS8 (the problem one) or later. (I'm going to interpret that as something significant changed in OS8, broke something enough to cause my app some trouble, and then got fixed in OS9+. But who knows really.)Be interested in any comments from someone who understands more about what's going on!