I release a new version of my app , already tested by some htc phones.
but recent days, users report that in some moto phone (espically moto defy) ,don't like normal app freeze which system will show alert dialog,my app cause phone freeze(the system is not reponsing,people have to plug out the battery then restart). but most of users I asked told the new version is quick smooth~~ bad performance could make system freezing?
Do you know any possible reason may cause my problem?
or any related system log I can checked?
Are you using threads? If not, then you are blocking the UI thread. You can use Traceview to find performance problems.
Related
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.
Recently I have discovered that about 2 months ago there was released Android 11 update for Samsung devices.
Samsung has in this version of OS decided to really strictly suspend the apps/services running in the background (more info)
So e.g. when app I am working on goes to background and phone is locked, all BT communication is almost immediately suspended. When I unlock the screen, in that exact moment all threads are not suspended anymore and execution continues.
OS therefore completely ignores the foreground service mechanism.
Official documentation
Also when I try to add my app to the list of "Never sleeping apps" (some alternative to battery optimization whitelist on Android 11) - app is still getting suspended + this whitelisting mechanism appears to be unstable and even when I add my app to the whitelist, app disappears from the list after few hours.
My questions:
Have you seen similar issues on Android 11 too ? What helped to resolve the issue?
Is this only Samsung specific issue or even Pixel devices do the same optimization (ignoring foreground service and whitelist)?
Thanks for any input.
sadly this is a huge and common problem and my repsonse will probably not fix it for you, but give you some more insights and possible work-arounds. Have a look at dontkillmyapp.com.
Especially dontkillmyapp.com/samsung:
On Android 11 Samsung will prevent apps work in background by default unless you exclude apps from battery optimizations. This is a severe divergence from standard Android process management policies.
Yes, this is a long way to go! Devs cannot ask for it automatically as they risk being kicked out from Play Store due to policy violations.
Also I can highly recommend very insightful the fun talk fron Droidcon Berlin 2021.
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
I hope you're all good. I am working on an android application project and I mostly use android emulator for testing the application. Android Emulator takes too much time for application loading and since I am working on the design I have to run the application after a few seconds again and again. Because of slow emulator I think my time is wasted and I can't focus on the work.
I recently tried my Galaxy Note for running application and its quite fast and running experience is much better. What I wanted to know is.. Does running eclipse project on my Phone will harm my mobile phone in any way?
Because moments back while using the phone the screen got stuck and the icons changed to different green, red and blue color. I restarted the phone and its acting normal now. But I wanted to know if it happened because of the eclipse project running on the phone? Is it safe ?
It is possible to harm your phone.
Apart from the wear and tear (YMMV) of repeatedly flashing your app to memory you may unwittingly (or otherwise) create a virus.
I've been in a situation where a thread has run amok after the app terminated and hogged the processor slowing things down. It did eventually quit though (possibly after elective rebooting). I've often had my phone restart when debugging on it. I wouldn't worry too much about that (although my domain was Samsung's bada, a lot less robust platform).
I don't see too many risks with Java apps as the language is so well managed. Native code is a risk in that, at least, a buffer overflow could place unwanted code outside of the process address space and so escape being cleaned up when the app quits. A shut down and/or force close may result from such errors.