What is Android "optimising" during restarts? - android

First question, appreciate some guidance. I am currently teaching myself to develop for Android and have installed my app (via Studio after builds) onto my own phone.
Every now and then my phone will restart itself (not querying that - these things happen).
During these (occasional) restarts I will get a message that Android is "Optimising App 1 of 1". I am pretty sure it is my app being "optimised".
I have searched here and the Web. Most of the questions seem to be users that have recently upgraded OS Version and that is causing the issue. There seems to be anecdotal evidence that wiping the cache cures this and that it only does it while the device is being charged.
However, if it is my app, I don't want users of my to go through this. I suspect it relates to the Target SDK I am using but it might be something different?
So, what is Android optimising? How can I make best efforts to stop my app being the cause of this?
Many thanks.

Earlier Android OS used to run on Dalvik Runtime which means apps used to compile at the time of execution. But now, Android has switched to ART with Lollipop version. It means all the apps will be compiled beforehand making them launch faster. So "Optimizing the Apps" basically means Android is compiling all the apps.

From Android 5.0, Android uses ART instead of DVM So every time your mobile OS upgraded This will happen. Also “Optimizing app” should happen only once after OS upgrade. If it’s happening every time then there is some issue in your mobile.
A factory reset should be probably solving this. (You have to go
through the pains of redownloading all your apps etc).

Related

ReactNative app crashes occasionally on production with no Bugsnag report

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.

Automated deployment of unity3d builds to lots of android devices

I have a lot of Android devices that all want to run the same unity app, but the refresh cycle is long to test on all of them... I have to manually update each one when a minor change is made. Currently I'm manually downloading an apk (via http) on each device.
Is there a way to deploy a unity app to lots of Android devices? I have seen reference to this being possible in Android Studio, but I don't see a way to push from Unity to Android Studio for deployment, and it's not as elegant as I would like because I will need to have about 50 devices plugged in to USB. Something over the network would be way better.
I know this can be done with (expensive) enterprise deployment systems, but it's a little impractical when I'm making a change every few minutes.
Is there a way to do this without Android Studio? My build system is OSX, but any other operating system is available. Something like a Jenkins deployment would be pretty awesome.
Anyone have an idea? I was thinking that the app itself could check via http for updates, and it could update itself. It's a bit to code, but maybe is do-able. In that case, you have to manually install the app once per device, but after that it would detect if an update is available.
Once you deploy your app to the Google Play Store via your Google Developer Console you can set up automatic updates on your devices. Every time you deploy new apk your devices will get the newest version automatically.
You can of course deploy development version so only your test users can download it.

Faking android version for a specific app

I recently upgraded my Android phone to have Android 8.1 (LineageOS 15.1) only to realize that my office mail client does not work with it. When I consulted with the concerned team in the office, the only options I was given is to either wait till the issue is resolved (which will be late this year) or roll back to previous Android version. Now, I don't want to roll back my Phone to the previous version.
Now I am not sure if it's possible/feasible, but I was wondering if there is any way to simulate Android version for a specific app. There are application which can make your device to appear as a completely different device (I tried Market Helper), but couldn't find any option to simulate prior version.
If Android API is backward compatible, shouldn't it be possible to simulate version to specific apps? (I understand that this may not work completely, but it should be worth a shot).
Thanks in advance.
Not sure about specific app, but you can edit your device build.prop and change OS version to one, you want.
Еdit Android Version by locating ro.build.version.release= and changing the current Build Version.

Debug App in Galaxy S5

I am building an Android app for my company, using Android Studio 1.5.1 . I've discovered that the app won't work on some Galaxy S5 phones.
These phones just show a white screen when the app runs.
This error happens on Galaxy S5 devices with Android version 5.1.1 But not on an Galaxy S5 Device running Android version 5.0
I'm focusing on the Android Version as a clue to solving this bug.
I can't actually get one of the devices so I've created several Virtual Devices. There are 6 Downloadable system images of Android 5.1.1 in Android Studio's Virtual Device Configuration wizard. I've installed all of them. none replicate this white screen error.
What else can I do to uncover this bug?
If it helps answer my question, my app relies heavily on server communication. The whole app is just one Webview with a few html & JS files.
The problem with emulators is that they are not reproducing actual device behaviour(especially, once many OEMs like Samsung tend to customise Android based on their needs), so I'm afraid the only options you have are:
Get Samsung Galaxy S5 with 5.1.1
Apart from obvious ideas "go to shop and buy", I can recommend you:
to take a look at Open Device Lab. It operates around the world and there's an arguably good chance to find the device you need there;
build a pool of alpha-beta users you can talk to and share new builds. Google Play has quite rich functionality in this area. Samsung S5 is quite common model, so it shouldn't be a problem to find people with it. If your product is "public", you can try to find beta-users on services like BetaBound or just among your social media network;
Use Analytics tools to collect more data from affected devices and act based on the information you get
There're dozens of different frameworks for accomplishing it. I can suggest Crittercism as a super powerful and comprehensive tool. In particular, I'd definitely log:
All handled exceptions
Add breadcrumbs (short string to capture app run-time information) to all Activity/Fragment lifecycle methods, to Application's methods (as white screen on start might mean some issues there), to all meaningful async tasks, etc.
If app gets into suspicion state - log it as a handled exception, so you can see the whole trail of breadcrumbs and track history of exceptions for the user. Unfortunately, you won't get trail of breadcrumbs, before something has been logged as an issue (crash or exception). There're frameworks, which log everything, like MixPanel, for example, but I honestly think that Crittercism suits much more here)
Crittercism will also catch & report all crashes happen in the app and
The Get Started Guide is here and it's pretty straightforward: http://docs.crittercism.com/android/android.html
Saying that, I'd suggest you to integrate some analytics anyway, as it'll help you in the future and to try to get affected phone in hands for test.
I guess the culprit is webview. Can you check the webview version on which the issue is reproducible.
To check the version you need to go to settings->Application Manager-> Downloaded Apps-> check "Android System Webview"version
We had a similar issue when the screen used to go blank and it used to happen only on particular version of webview. The issue was fixed by Google later.
The chromium webview layer is now updatable from Google Play.
For more details refer-http://developer.android.com/about/versions/lollipop.html#WebView
I assume you are building a hybrid app.
If the webview is the culprit, you could try crosswalk.
It adds Mb's to your app but it makes sure every device uses the same webview (latest chromium). Moreover rendering differences etc are also minimized.
if you are using cordova run: cordova plugin add cordova-plugin-crosswalk-webview and that's it.
If you implement this and the whitescreen problem is gone, you debugged it in a sherlock holmish deduction way...
The problem is not with emulator. It is with WebView in Android versions 5.1 onward.
Try
uninstalling the updates for "Android system webview" app (go to
settings and look for it under "downloaded") it works just fine!
Source - similar question

Nexus One - Android 2.1 release, WHERE is the SDK for 2.1?

The Nexus android phone went on sale today with 2.1 Os on them. My friend
just ordered two with overnight shipping. I assume that means it will be in his hands tomorrow or the next day.
How is it even remotely acceptable that people will have 2.1 in their
hands before developers even get to touch the SDK? I already have
users using the Nexis-Droid 2.1 rom saying that my highly used widget
doesn't work. How am I supposed to test this out in advance without
hacking our phone all up?
All this does is frustrate users when apps don't work and further
degrades the market with 1 stars because developers don't have a
chance to update their code.
Thanks google....
You can expect the SDK in a few days. Google said it would be "open-sourced" in the next couple of days. It does suck that we don't have it yet. If I remember correctly, we received 2.0 about a week before the DROID was released, and we got 2.0.1 about the same time frame before it was pushed down to the DROID.
People using an OS that isn't available should not be complaining about apps not working. It's their choice to be an adopter of an OS that isn't even released yet. They can deal with the consequences. (which has nothing to do with you)
The part I hate about the market is our inability to respond to ratings. I have more than 2500 ratings for my app, yet I constantly get 1-stars because the users are morons and can't read. Yet I only have 325 characters for my app desciption. I have started writing my own comments and updating it to respond to ratings.
I haven't developed anything yet for Android but have looked into the SDK a bit.
I saw is possible to specify a maxSdkVersion in the manifest.
I'd say developers should put there the max version of the SDK that they've been able to test.
So if no SDK 2.1 is available yet and you put 2.0 or 2.0.1 there, it will prevent Nexus One users to download your application (I'm guessing here it works that way).
It would be in the interest of Google to release the SDK if Nexus One users cannot download and install any application at all. The users will be blaming Google then instead of you.
Edit: Oops, somebody commented it before.
Android 2.1, Release 1 SDK
The SDK has been released; this is the first time that an Android SDK has followed the release of a device running that version.

Categories

Resources