Anyone who has ever owned an Android-powered smartphone will probably tell you how frustrating it is to get OTA updates. Whether it’s security patches, bug fixes, or the much-coveted OS upgrades (for example: Lollipop to Marshmallow). Since each of these is different, the reasons for delays and the mechanism for getting updates are sometimes different as well.

Operating System Upgrades

Let’s start with the proverbial 800-pound gorilla, shall we?

First of all, Android and iOS are substantially different in how each approaches updates. Apple attempts to get every device up to the latest version of iOS (and touts those numbers widely). Unfortunately, that’s not the whole story.

Despite the version number being bumped to the latest revision, various features of the new OS are omitted on older devices, resulting in “feature fragmentation”. iOS 9 isn’t the same on every device. Google, on the other hand, keeps features either in apps distributed through the Play Store, or pigeonholed in a specific version of Android. New features specific to Gingerbread, for example, are available in that version, but not in previous versions. This helps keep feature-sets specific to versions of the OS, not specific to a particular OS running on a particular phone (as is the case with Apple).

There are pros and cons to each method, and although I’m probably biased, I think the Android way of doing this is easier for app developers than the iOS way.

Bug Fixes

No software is ever “bug-free”, especially considering the substantial amount of “moving parts” we have in today’s mobile devices. From operating systems, APIs, libraries, device drivers, apps, and even transport mechanisms (WiFi versus Bluetooth versus LTE versus EDGE, etc.), there are a significant number of layers through which data must traverse. Each step along the way may introduce bugs and hiccups that either weren’t found during development, or weren’t taken into consideration.

Bugs will surface, and as they do, they need to be patched. The way those patches are delivered can vary, and eventually a product will reach the end of its supported lifespan. Developers need to focus on new products rather than patching a decreasing number older devices.

Security Patches

Security holes are a form of bug, but they’re a particularly high-priority type of bug due to the damage they may cause. These types of bugs need to be identified and patched as quickly as possible. Need I say more?

How Do We Fix Them?

The first thing we need to accept is that the current method of checking for updates on Android-powered phones simply doesn’t work. When I go into Settings and check for system updates, most of the time I’m told that my devices software is up-to-date – even when that’s an outright lie. I’ve seen this on Nexus devices running Android KitKat when Android Marshmallow was available for the device. There’s no polite way around it, the current method just doesn’t work.

Now that we’ve got that out of the way, how could it work? First off, we’d have the device’s manufacturer host a web service that the device would query every time the “check for updates” button was pressed. The device would send its identity as part of the request and the OEM’s web server would check to see what the latest build was for that device. This would be generic to the type of device, not to a specific build of a device (The HTC One M9 versus “Verizon’s HTC One M9”).

Next, once that response is received, the device would check its version against the version that was just returned. If they don’t match, there should be two options given:

Update Now, or An explanation of why the update can’t be applied to (or isn’t available/approved for) your device, AND who to contact to make that happen.

The former is fairly self-explanatory, the latter is where we get down to business. If the phone has an update available but the carrier (or someone else) is holding it up, that’s what the message should say.

“There is an update available for your phone, but your Verizon Wireless has not yet approved it. For more information, call Verizon at +1-800-555-5555, x12345.”

This would put the pressure on whomever is holding back the updates, and give customers a phone number to the department who oversees the update – even better would be an the ability to call that number with one touch. With enough people calling, perhaps the bottlenecks can be solved and updates streamlined and made available in a more timely fashion. But it all starts with giving owners accurate information about what updates are really available for their devices – and giving them a conduit to contact a person who works for the company who holds the blame for being the bottleneck.

Your turn!

Will it happen? Probably not, but something has got to change. What about you? Do you think this idea could work? Do you have some ideas on how to improve it? Do you have a better solution? We’re all in this together, so head down to the comments and let us know how you think Google and OEMs can fix Android OTA updates!