In my kotlin project, google play console one Warning issue in Performance is - "Your app took 5,793ms to launch for the first time, after being installed on this device model". Type is Cold start time. Can anyone help me to fix this issue.
It can be a variety of reasons, causing a slow startup. You should use a profiler to measure where the time is spent.
https://developer.android.com/studio/profile/android-profiler
Very general there could be a lot of time spent on the CPU.
You could wait for a lot of network traffic to be received.
Or you initiate a very complex rendering, maybe requiring a lot of data to be loaded into memory.
One way of workaround would be to offload the initialisation into a background task, which is executed while the user is already a first screen presented, so they get a first visual feedback earlier.
Related
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.
I'm using location & activity recognition features of android. Used for realtime location tracking. Currently using the latest ConnectionLess APIs. I have encountered the following problem:
After starting the location, activity services, once in a while, the battery starts to get drained. The behavior is pretty strange as the entire drain is showed under Google Play Services. The drain persists even if the app is stopped, killed, etc. To my surprise, the drain persisted even when the app was uninstalled and it took a couple of full battery re-charges to come out of the situation.
I'm more or less sure that the drain is triggered by my app as multiple devices have recorded the issue and these devices are from different manufacturers and across multiple android OS versions. In ADB shell, I find com.google.android.gms taking up 126% CPU permanently as seen below:
Next, I listed all the threads under that process. Result attached below:
As seen there's one thread, CastSocketMulti running. All other threads are sleeping.Didn't get much on castSocketMulti other than some basic information like it is related to casting in android, etc. We aren't using anything related to casting in our app.
After, killing the process, the drain stops.
Note: I found same question here, however unanswered.
Edit: Every time the battery drain happens, as above, com.google.android.gmsis listed as the number one process taking 100%+ CPU and the castSocketMulti, the only thread of that process in R status
Update: I have opened an issue here.
Pls leave a star so that it may go high on priority
I have found the exact same thing here on a OnePlus 3. I'm not rooted and can't kill the process, but using adb to clear the cache of com.google.android.gms makes the process crash and alleviates the problem for a few days.
Do you use Android Auto or Android Pay? It seems to happen more frequently when I use those two apps in particular.
OK, Google claims to have fixed the issue and they have marked the issue as 'Fixed'. Details here
Just out of curiosity. Logically thinking, does Android debugging mode slows down the performance of Android devices?
How can I prove to users that Android debugging does or does not slow down the Android?
P.S.: I need specific answer and reliable source to how can I prove it?
Yes. Attaching a debugger almost always slows down the performance. The best way to prove any performance related argument is always to run some tests. Set some timers in your code and gather the data empirically. Then you'll know not only which way is faster but by exactly how much.
For a 'specific answer' - measure and your tests will be the 'reliable source'
Run the application with and without debugging and show the execution time difference. It's best to use an app that simply opens, does some calculations or something then exits that way there's no user error in interacting with it.
I have been battling an ANR happening in one of my services for a while now. It is very hard to reproduce and the UI seems to have full functionality right before it happens 100% of the time there is never any noticeable lag or freezing. My service has a TimerTask and a few AsyncTask's that it runs and that is it.
The stack traces I get when you report it with the Android Market in 2.2 are hard to read, there doesn't seem to be a reference to any of my code directly but only from classes in the SDK. Can anyone take a look at the stacktrace and see if you can tell what is going on.
The print out is so large I opted to post it to pastebin, I hope that isn't against the rules.
http://pastebin.com/KHUD0UHW
Here is the Logcat log as well
http://pastebin.com/V5xSey36
It's possible that it's not your apps fault. An ANR shows up for whatever the 'current' app is. However if another app on the system was really taking out your CPU and forcing your app to starve, your app will get the ANR because it has the user's focus. If that is the situation, there is nothing you can do. Perhaps the best way to test for this is watch for or force the system to do a sync. Syncs are usually quite heavy on the phone and can cause bad lag on less powerful phones.
Another way to test if you have a slower phone is to install a big app from the market. Once it goes in to the 'Installing' phase after downloading, do something just a little bit intensive in your app. If the installing phase takes longer than 5 seconds or so, it has quite a decent chance to make your app get the ANR. This is because of bad IO speeds while installing the app. IO blocks other apps from getting CPU time. Android thinks that means that you are stealing it.