Android Monthly Security Update - Timeline, What to Expect on Nexus and Non Nexus devices

[Aquila]

The process here is something to the effect of the following:

Week 1-2: Cycle starts. Any issues identified in the past four weeks are included in this patch.
Week 3-4: Google Patch is complete, OTA's begin for NEXUS devices.
Week 4: AOSP is updated.
Week 4-6: OEM's can now retrieve the code and begin testing.
Week 7-8: OTA's go out to "PURE" devices (devices that are not sold through carriers)
Week 7-10: Carriers get Code, start testing
Week 11-12: OTA's ready to roll for "CARRIER" devices.

Meanwhile, in Week 4 Google is starting another patch, and again in Week 8 and again in Week 12 and OTA's for nexus devices are rolling in Weeks 7-8, 11-12, etc.

So, depending on how your phone is sold and whether or not carrier certification is needed for their security updates and whether or not the OEM (as opposed to carriers) are rolling the OTA, the security updates should begin to arrive on the your phone within 7 to 12 weeks of when the cycle starts, or 4 to 9 weeks after Nexus devices begin receiving an OTA.

Added a graphic to help illustrate.

 

[B. Diddy]

This is freakin' awesome.

 

[Aquila]

http://www.androidcentral.com/android-security-nexus-matters. This too.

 

[B. Diddy]

Nexus all the way, baby.

 

[Aquila]

While this is good that security is being addressed, keep in mind updates are not without risk. There will be an increased potential of an update borking a device. Unfortunately, Android isn't like a Windows PC where you can un-install the update or use system recovery to roll back to a known good state. Or a more direct comparison, it doesn't have a user-friendly option/setup like Apple where you can use iTunes to perform a reload/recovery of the OS. So these updates could leave more people with messed up devices where they have to resort to a master factory reset to try to get things back in order (a major pain point for many). Sometimes that works, other times it doesn't and the user is left with the unfriendly option of trying to re-flash the device's firmware, assuming it's even an option for their device AND they're comfortable doing it (even if it's a Nexus which has factory images one can flash), or attempt to get a device replacement or worse just having to deal with it.

So there is an inherent risk to benefit ratio here. Are these security updates really going to be worth the increased risk of possibly borking your device (especially considering there hasn't been a single report of a device being compromised from these "exploits" that these updates are supposed to fix)? Could this turn people off from Nexus or even Android? Possibly, it did for me with Nexus devices back when I had an OG Nexus 7. The frequent OS updates alone left me feeling like a Google beta tester where I ended up spending more time fussing around with the device than I actually got to use it. Thus why I now disable the OTA updater when at all possible on my devices to keep them stable with their current software build.

I've never personally had a device get bjorkeded by an update, but the LG and Samsung forums have legions of users with that issue and I know it can happen to a Nexus device too. I hadn't thought of the trade off in this way or updating as an inconvenience. The layers of security in Android are many and your method is probably getting 80% of the job done and keeping it real... savvy users are nearly immune to most attacks anyways because they don't just click "ok" on everything.

 

[Aquila]

On further reflection, just want to add that my thoughts on this come from my experience with Microsoft's update process that has evolved over the years (18+ years now in IT). Granted this isn't a direct comparison considering the platforms, but early on Microsoft was like Google attempting to address vulnerabilities with monthly patches. Many times the quality of those patches were suspect that caused issues making the community at large have reservation and hold off on applying patches until further testing validated it was OK to proceed or not. Over time Microsoft improved their patch process that instilled confidence in applying them without much reservation. Even so, today it's still best practice to test patches on a subset of non-critical systems before deploying to all so as to detect any issues that may crop up. The point being, Google is still early on in this whole process, like Microsoft was, so they really need time to mature their patch process where it can be reliable and stable and not cause greater harm to the ecosystem than is unnecessary (of which a recovery mechanism needs to be a part of).

That's a good point. Another thing you mentioned earlier ... we are very much beta testers for Google's products. It seems like they're trying to correct the user-facing front a bit and add some more polish, but most products seem to be in a perpetual state of testing and evolution.

 

[B. Diddy]

But even with Microsoft's long experience with patching their products, they still manage to release some doozies. There were a couple of patches this past year that caused significant problems, and another that borked Windows's ability to see Nexus phones when plugged in (instead causing them to be recognized as Acer ADB devices, I think).

 

[anon(9072051)]

But even with Microsoft's long experience with patching their products, they still manage to release some doozies. There were a couple of patches this past year that caused significant problems

Not to mention at least 1 "cumulative security update' released this month that refuses to install on Windows 10 machines and a squadron of support reps who seem to have their heads and hands crammed up you know where when it comes to diagnosing and fixing whatever the problem is.