I have a Xamarin.Android app that has been in production and stable for several years, but is now exhibiting crashing, during startup, when running on a specific device type (Zebra TC21/TC26), but only after it has been unused for 3 or 4 days.
If the app is used regularly, it performs reliably, but when left idle for an extended period, it crashes, during restart, apparently because Android has recycled the Application object, perhaps as described here.
The strange thing is that neither a forced close of the app nor a reboot of the device resolves the problem. Only after uninstalling and reinstalling the app will it run again.
To make matters worse, I can't seem to get any useful log data from the app when it is running on Zebra devices. The app is extensively instrumented for logging (via Loggly) and it works reliably for all other Android device types that I have tested, but Zebra test runs yield no log events.
I apologize that this is a vague question, but I have spent a huge amount of time trying to diagnose this issue and I am at a loss for what to try next. Any suggestions would be very welcome and I am happy to post more details, if required.
UPDATE: As suggested by #Cheesebaron, I have examined the device log, retrieved from a Zebra, which shows that the crash is due to an NRE. I attribute this to a required dependency not being injected correctly, but I am not sure what that tells me about the root cause of the problem, which clearly doesn't occur during normal operation. I am not an expert in deciphering Android logs, and I am curious what I should be looking for to understand the specific OS event that tipped the app into a failing state. Just being able to reproduce the issue in real time would be a great step forward.
I am also puzzled why this issue is not cleared by restarting the device. Does this indicate a data/settings corruption or could there be some other explanation? Is there anything in the device log that I should be looking for to understand this?
I am happy to post the device logs (or excerpts) if anyone feels inclined to review them.
a colleague of mine is working on a legacy ReactNative app. There is quite a lot of code both in JavaScript and Java land, the latter being related to HERE Maps SDK.
Two of our clients experience multiple crashes every day and we cannot figure out why as we have no error reports.
Bugsnag was installed early last year (circa jan 2020) and we have nothing on there to help us. Nothing to be found in Google Console either. App just stops.
To help us debug we've added a logging system which sends debug info to our backend via dedicated API calls.
It roughly consists of logging "start of function A", "end of function A" etc so we know what the app is doing. We don't always enable it as it tends to make the app even more unstable.
In parallel to that we managed to get an idea of when the app crashes via login events that are sent by Firebase Auth when user re-launches the app.
Looking at our logs around the time of crash doesn't help us as 1) they look the same as when it all works and 2) we haven't covered all method calls as there are way too many (in JS and Java).
Our users run the app on a Samsung Galaxy Active Tab 2 mounted in the cabin of a tractor. Some use a Galaxy Active Tab 3 and also have the issue.
We have run through various theories :
Could it be too hot in the cabin so Android shuts down? No, tablet is always on according to clients.
Could it be related to a change in voltage? When WE try to plug and unplug everything continues to work fine.
Could it be Android that decides the app is consuming too much battery or CPU (GPS is needed for our app) so it shuts it down? We've let our app in the foreground for hours with no problem.
We logged in with customers' credentials (they are aware) and could not replicate the issue.
Customers interest in helping us find the issue is slowly fading away so we can't keep on asking them to install a patched version every week.
First there was just one client but now we have at least 3 more users complaining about mysterious crashes.
We're a bit stomped as to what to do.
Has anyone any idea of an ultimate catch all library? Or a syslog on the tablet where we could get more info?
Thanks in advance for your help!
After much testing my colleagues managed to easily reproduce the error and found the root cause: poor memory management in one method in Java land.
Said method was responsible for changing markers orientation on the map but it duplicated markers when their orientation changed. It resulted in a high memory consumption and when it reached a certain point Android would just kill all running apps.
My colleague fixed the leak and we're good! Onto the next bug now. :)
The below reasoning is based on hardware failure. If your software hasn't drastically changed (the app or the operating system), then this is a likely scenario:
The Tab 2 was released in 2012, so we're talking about a device that is up to 9 years old. If the users all use the same hardware, and the software hasn't been changed for a while, it could be some kind of hardware failure. It could be related to the vibrations of the tractor, moisture over time, or just because they used the tablet more intensively than you use yours. There could be something (semi-)loose or the memory (SSD or RAM) could start becoming faulty.
It can be a software error too of course, but it's unlikely if you haven't updated in a long time - assuming the tablets haven't been updated either.
Could you perhaps swap your tablet with one of a customer. Preferrably a customer that has the issue most often. Then observe if the issue is resolved.
This way, you'll be able figure out if it is related to the tablet (being broken) or the environment (tractor) it is being used in.
If the issue persists after a tablet swap, it's either the environment or the software, but you'd have ruled out the hardware.
If the issue is resolved, you'll know for sure it's the hardware at fault.
Devices such as Huawei, Xiaomi, some Samsung models, or most of the devices I know that has MIUI, EMUI in their system has by default turned on battery saver features and automatic "optimizations". Recently I've created an important worker but my device (Huawei P20 Lite) has this built-in feature which prevents the job from running (it even shows that the system blocked the execution), unless I go to that panel and let the app execute on background by myself.
On a production environment we can't tell the users to go to this menu and let us run on background (simply because we don't know how many variations of these battery saver features), the app itself doesn't run on background on most cases. However, this worker still should execute because the task is pretty important.
Two questions:
1) For a rough estimate, how much percentage of devices will prevent a work manager task to be executed?
2) Can any workarounds be applied for this situation?
Any help is appreciated, thanks.
Please, a file bug on Google issuetracker under this component:
Android Public Tracker -> Device-Specific App Issues.
This seem a CDD violations and the bug will help Google explaining to the OEMs what needs to be fixed.
I've seen that there's a library that tries to handle (Autostarter), across different devices, opening the right setting. This is just a workaround.
The best course of action is to report the issue, but this will probably request some time to be fixed and the user will need to update the OS.
I have written an android app that generates a strange exception on the LG-Phone I have just started testing on. In DDMS the tag is "ISP_LOG_MW_DEBUG" and the text is "AMI_IsWindowSearch()." It is generated about 10 times per second while the app is running. It doesn't seem to interfere with the program itself, but I would rather not have this error. but I can not find any information on this on the web.
If a click the home button (the app continues running in the background) and start the app again (new UI, with the old services) the amount of these messages increases each time. So it is reasonable to assume that they are generated by something in the UI.
Has anybody experienced this error or has any idea how to avoid it?
Real devices can sometimes make a lot of noise. Sometimes the vendors just leave a lot of debugging turned on. If your app is not crashing, or showing performance issues, I would say it's safe to ignore.
Also, try with another device, or try with the emulator. If you don't see those errors with another device or the emulator, I think it's safe to say the vendor developers of the the LG device are just lazy and didn't turn off all their debugging like a good developer should. :D
db
We are currently developing an Android app that is a fitness-tracker application. It runs constantly in the background, and it works fine on most devices, but we've been having issues with the application dying completely on some Samsung devices. After some investigation, it seems like some Samsung devices has a completely custom "App Optimisation" feature (http://forums.androidcentral.com/samsung-galaxy-s6/599408-app-optimisation-after-updating.html), which is basically a (very) primitive version of the Doze feature that exists in later versions of Android which basically just murders apps if they haven't been used for three days.
As this app is more or less only doing logging, and doesn't open the activity, it presents a big problem for us, because this feature is pre-enabled on many Samsung devices. The problem is solved by using a foreground service, but that is a sledgehammer of a solution that requires disturbing the user with a constant notification, and we really don't need the app to be in the foreground - we are fine with the normal power management of Android.
The Samsung App Optimisation feature clearly states that it will "optimise" apps if they have not been used for three days. Does anyone have insight in what Samsung considers to be "used" and can I somehow trigger that?
Side-rant: In my opinion, this is a badly implemented feature that makes development on Android more hostile. Besides our use case, it will any messenger applications break. If it were not for the fact that Facebook Messenger and Whatsapp are hard-wired to be exempt for the app, users would be going crazy because it would be breaking their experiences.
I've owned (and currently own) Samsung devices, so I know a little as to how it works from the user's point of view. The technical specifications and how it works on the inside is an entirely separate issue, and one I can't answer.
The system can detect if you open an app. Samsung uses that in their app optimization, and will save power on apps that haven't been used in over three days. It is a terrible system though.
It ignores background-processes that may be critical to apps, and even if it is an app you actively use, like a fitness tracker, it will have issues. To quote what it says inside the app optimization-list:
"To save battery power, apps that haven't been used for more than 3 days will be designated to save power. Apps designated to save power may not show notifications"
(Rough translation from Norwegian, originally taken from an S6 running Android 6)
Therefore, apps that have been manually, or automatically set (3 days of no use) may give various issues with background processes. But remember that the user can set any app to never save battery, and ignoring the automatic setting. So with this in mind, let's consider possible solutions.
There is one scenario where you do not need to worry about the app and app optimization: When app optimization is disabled entirely.
Looking aside that, there is really only two things you can do:
Ask users on Samsung to disable battery optimization for your app to prevent issues
As #MinaSamy suggested (in their now deleted answer), SyncAdapter and having a periodic synchronization. Note that I haven't tested this, so I don't know whether it works or not.
And there's also a third option, which really isn't a solution, but you can ignore it and gamble on app optimization being disabled, or just not care about it at all.
Does anyone have insight in what Samsung considers to be "used" and can I somehow trigger that?
As far as I know, unless Samsung added some safeguards against accidental opening or added some kind of minimum activity requirement, opening is enough. It appears to be a "stupid" feature, which runs on hard-coded rules rather than a dynamic system that actually detects app use and sets power saving relative to that. It's "easy to enable", but fortunately easy to disable as well.
Meaning you cannot trigger an event that will keep it alive (unless SyncAdapter does the trick)
And to make the facts clear, from #Neil's answer:
It does seem like the user can do this, so there must be some database or setting somewhere that controls it.
There kinda is. There are a total of four settings, three of which are app-specific, and it is stored in a database (or some other form of data storage). These four settings can be used, although extremely shallow, to alter the behavior of the app optimization:
Always optimize
Automatic optimization
Never optimize
Disable app optimization
The first three options are on a per-app basis, which means each app can have separate settings. Disabling app optimization is exactly what you'd expect: it disables the entire feature for all apps. If it's disabled entirely, nothing is optimized.
There's also a website listing ways of bypassing optimizations on a per-brand basis. The entry for Samsung is more or less what I've said: tell the user to manually disable optimization. There are no developer solutions.
In settings>device health>battery there's an option to "put unused apps to sleep". You can turn it off, or change the amount of time it takes, which is 3 days by default.
Sounds like that's your problem.
https://forums.androidcentral.com/samsung-galaxy-s10-s10-plus/964083-whats-disabling-some-my-apps-background.html
Is there a reason you can't add your service to the 'don't optimise' list?
It does seem like the user can do this, so there must be some database or setting somewhere that controls it.
Alternatively, if you detect you are installing on one of the devices, open the optimise activity page, and show a message saying "Don't optimise us!".
As a workaround, i implemented the SyncAdapter mechanism, using this link as a good starting point: https://github.com/bmeike/MiniSync
It doesn't work perfectly (for testing, in my app i write a log every 1h, and after 3 days, it starts not respecting this scheduling), but at least it doesn't stop after 3 days, without the need to put the app in ignored optimization mode.
UPDATE: After the update to android PIE, scheduling stopped again after 3 days.
On another device, same app with android Oreo, scheduling is working (even if not completely respected).
On Samsung phones, the culprit is this Sleep setting:
You have got to take your users to this system settings screen and ask them to turn the feature off.
In my opinion you should implement a 'Broadcast Receiver' that listens to a custom 'Intent' and this 'Intent' to be Broadcasted by the 'Service' from 'onDestroy()' method of the 'Service' because when the 'System' kill the 'Service' this method will be called definitely.
And when the 'Broadcast Receiver' receives the 'Intent' you should start the 'Service' again.
And to distinguish between you stopping the 'Service' or the 'System' stopping the 'Service' just use some 'booleans' stored in 'SharedPreferences' and then in the 'Broadcast Receiver' you decide whether to activate the 'Service' or not
we are fine with the normal power management of Android
Are you? From the Android docs
However, since the user is not directly aware of a background service, in that state it is considered a valid candidate to kill, and you should be prepared for this to happen. In particular, long-running services will be increasingly likely to kill and are guaranteed to be killed (and restarted if appropriate) if they remain started long enough.
Three days seems like it would fall under "long-running...guaranteed to be killed".
If the problem is not that your service is killed but that it isn't restarted, you could use the AlarmManager to regularly check the status of your service and restart, if necessary.