So… we talked of “our” AndroidOne anomaly / bug to a friend who’s in Google.
thanks for reporting this. We will look into it and get back to you. However one thing I noticed was that the Android OS versions on the two phones were different – one was 5.0.0 and the Android one was 5.1 That could be the source of the difference but we’ll check.
Our response – it is definitely an AndroidOne anomaly! Here’s more on that…
It is definitely a bug or atleast an anomalous behavior- and happens even with Android 6 (running on the same Lava Pixel V1 phone running AndroidOne)–
video of same anomaly on AndroidOne phone updated to Android-6:
Here’s a somewhat longish explanation which I hope will help:
Also, I have a thought on why this happens:
In each of the cases we invoke an “intent” (Android jargon for invoking an external program or system call to do a task while a an app is running)- and many “intents” are different from say library function calls because invoked will typically an intent will often happen from the UI thread and a new activity or task with it’s own state will open- temporarily taking focus away and being visible on top of the app which invokes the intent– while the task which invoked the intent is one position behind in the “back stack”.
(the back stack is the list of activities currently running– such that each time we press back button to exit the current activity, the activity under it on the back stack will take focus, till there are no more actvities on the “back stack”).
If there are too many tasks on back stack OR if the depth of back stack is less– then the tasks deep in the back-stack are removed by the OS– and if the user comes back to them– then the activity is re-started.
But normally activities are almost never re-started when email client or web-browser or google-play games UI is invoked.
I believe that as per the original Android spec– the platform vendor– has the liberty to decide how deep or how shallow the back stack will be– and as per the original android specification– an activity should assume that if it invokes an intent– then it can be terminated and restarted when intent completes– and must be prepared to save it’s state while invoking an intent.
However, ever since Android Gingerbread, API-8 or 9– on all devices I’ve seen till now, the expected behavior is that depth of the back stack– even on low end phones– is such that 2 or 3 or even 5 or 6 back actvities can sit on back-stack without worrying about re-starting– and so almost nobody saves the state of an activity.
A lot of the way android apps are engineered– is that they assume on most android versions from 2.2 or 2.3 onwards– an intent can be invoked without worrying about the current activity being re-started.
All mobile video ad networks i know of– including Unity Ads and Google AdMob rewarded videos and others; as well as Google Play Game Services and also the built-in browser and email intents– assume that the invoking task will maintain it’s state when the intent invocation completes and will continue executing rather than be re-started.
Hence, in this case even though the behavior is as per Android Specification Ie: that the platform vendor– in this case– AndroidOne team decides how deep the back stack will be– and hence if the back-stack depth is just 1– and invoking any activity shuts and restarts current activity– it causes a whole bunch of normally programmed apps- to break down- and not function as expected.
Maybe it was chosen as a kind of trade-off to minimise memory footprint on an AndroidOne device.
However, This is especially bad on a phone like the Lava Pixel V1 I mentioned– which has 2x the RAM as an iphone 6 and comparable hardware– but cant run many standard apps as expected– and shop salesmen actually warn customers that due to the limitations of AndroidOne– the device will not function as expected and so a customer should beware before buying it.
That’s why we are talking of this– and I hope that in an upcoming update, the AndroidOne team will fix the behavior to be closer to standard android behavior because with the current thing, many users assume the behavior of AndroidOne to be anamalous and not as expected– and some developers even go as far as to set their apps to exclude AndroidOne devices from the list of targetted or test devices.