According to his LinkedIn profile, veteran Google engineer Dan Morrill “leads the team ensuring Android application compatibility, and administrating the Android Open-Source Project.”
In addition to knowing Android inside out, Morrill is a redditor and regularly contributes to r/Android answering questions that pertain to the inner workings of our favorite operating system. Here are his latest nuggets of Android wisdom:
As Dan Morrill explains here, updates roll out in batches, starting with 1 percent of all devices in the first 24-48 hours. The team checks for problems, and if everything goes to plan, proceeds to update the next batch, typically consisting of 25 percent of devices. So the percentage of updated devices goes from 1%, to 25%, to 50%, to 75%, to 100% over a period of 1-2 weeks.
And here’s the thing – the devices that go into each batch are randomly selected once for each batch. In other words, if you are turned down for the first batch, you have to wait for the next one, and no amount of tapping the Check now button will help.
The bottom line is there’s no point checking for updates more than a couple of times per day.
In a related thread, Dan Morrill also explains what happens when you clear the application data of the Google Service Framework, a trick that some users employ to get Android system updates faster. Morrill talks about the negative side effects of the procedure, which is not even guaranteed to work in all cases.
The issues occur because the procedure resets the Google Cloud Messenger ID, which is the service that Google’s apps and many other third-party apps use to transfer data to and from Android devices. Depending on your setup, clearing the Google Service Framework can cause all kinds of problems with your apps, which persist until all of them get a new GCM ID.
Instead of clearing GSF data, Morrill recommends the impatient to manually sideload the image file with ADB, a procedure that my colleague Adam Koueider walks you through here.
Like this post? Share it!
personally, I really don’t understand why google does NOT do more volunteer beta tests before the release. . . I’m sure many of the more tech savy would love to be in that program.
That’s what I asked myself. Apple does betas. Why not Google?
I think that apple´s betas are only for developers and some journalists, so whe would be out the same way
“Because if the sampling is not chosen at random, the sample population is a poor reflection of the entire population.”
This. Apple devices in general are much more standardized than Android, and they don’t need to worry too much about the variety of devices, hence they can assume a selective portion of a population will probably reflect the entire population.
Users are beta testers for Google :)
true. . .very true. . . I guess if you use a google product you ought to know you are a beta tester LOL
If you own a Nexus then you ARE a beta tester. It’s the whole point of the Nexus program. Google can get AOSP working as a X.X.1 release, and then we beta test so that Google can get the X.X.3 or so release for the OEM’s.
the “Nexus program”? lol…
I think you’re fantasizing a bit too much. It was never a ‘program’, the Nexus users were never chosen, they are consumers just like anyone else.
Because if the sampling is not chosen at random, the sample population is a poor reflection of the entire population. ie) By accepting volunteer betas, they might risk accepting majority of people with similar devices or setups. It’s not like beta testing for games where you are testing for a software written for standardized APIs and systems, Android devices vary a lot.
What about people that sideload updates? Case in point, sideloading KitKat to a Nexus 7 before an official rollout.
That’s exactly what he recommends doing…
“Instead of clearing GSF data, Morrill recommends the impatient to manually sideload the image file with ADB, a procedure that my colleague Adam Koueider walks you through here.”
LOL, I missed that last sentence…that’s what I get for reading too fast. :p I just happened to sideload KitKat to my Nexus 7…I do fall under that “impatient” segment. ;-)
What might happen to those peopel is that if the update has a serious bug like I don´t know, damages your hardware, these people would not be safe because they did not wait the first 1% and then the 5% and so on to test it first ;)
Maybe, but not as likely if the image file is coming from an official source. The risk of damaging the hardware is more on the user improperly installing it, so I don’t recommend sideloading, or going as far as rooting, unlocking the bootloader, etc. unless you feel you’re comfortable going that road.
Implying a software update will damage hardware. Worst thing that can happen is a brick, which is usually reversible. Its not like it will remove the restrictions from the kernel, overclock your gpu and melt the phone or anything.
I did not said that, I said maybe, just maybe you know? but software can mess with hardware like your phone might have problem to charge or not eve charge at all, we seen this happen a lot, so yes it can mess with the hardware, but even a brick would be something bad, so why not wait those 1% to test and so on?
Its been more than 2 weeks and still don’t have an update.
Nexus 7 2013 and 2012 WiFi only.
At least I have my Nexus 5 to enjoy kit Kat.
“there’s no point checking for updates more than a couple of times per day.”
We are already doing that.
Read my mind. I check updates like 3 times a day, JUST in case there’s anything hiding behind the curtains. Addicted to updates? Yes, yes I am!
I already knew that.
Mindreader much? :o hahaha
He is God… of course he knew everything
Jesus isn’t God. God is God, Jesus is his son. At least that’s what I remember from my religion classes in high school (although, to be fair, I’m not religious and I hardly paid any attention at all)
Will the ADB sideload methos described on the post of Adam Koueider work on another phone when using the correct OTA files?