Hacking a tablet to force an Android update
For a while, the O/S-update negligence was little more than an annoyance ... some programs wouldn't install at all because Android was out of date, while others wouldn't upgrade to their latest versions ... and of course, I wasn't receiving ongoing security patches and bug fixes from Google. But recently, the situation became more critical. I started getting ongoing popup messages, one every few seconds, indicating that "Unfortunately, the process android.process.acore has stopped" and effectively rendering the system unusable. I also was no longer able to access my contacts database; application launch attempts would abruptly and rapidly terminate.
As it turns out, the issues were related. From my research, I learned that the issue seems to be a bug in this particular Android version related to third-party application (Microsoft Office apps, Facebook, etc) access to the contacts database. Sometimes, as with Facebook, I could get the problem to go away by deleting (and therefore no longer being able to use) the offending app. Other times, as with Microsoft Word, no amount of uninstalls, cache wipes, etc. would suffice; the only option was to wipe the tablet clean via a factory reset and start all over again (along with, as before, never again being able to install/use the offending app).
Clearly, this was an untenable situation. And if I had a conventional manufacturer- and/or carrier-locked handset, I'd be out of luck. Fortunately, though, in this particular Nexus-branded case, although Verizon conventionally controls the over-the-air delivery of firmware updates, they ultimately come directly from Google. So I decided to dispense with the Verizon intermediary and "sideload" the upgrade myself via a USB cable tether to my Mac.
While it's possible to "sideload" OTA updates via ADB (Android Debug Bridge), thereby preserving the already installed applications and data, doing so is tricky; each upgrade to the next Android iteration often needs to be done sequentially, for example, which is tedious at best (and I was many iterations behind at this point). Plus, I'd already factory-wiped the Nexus 7, anyway. So I instead decided to update straight to the latest v6.0.1 factory image. However, if you look at the list of images for the "razorg" Nexus 7  (Mobile) platform, which corresponds to my tablet, you'll see 14 different v6.0.1 builds offered. Which one was I supposed to use? Fortunately, Verizon's online documentation tipped me off that version "MMB30S" was the one for me. And the instructions at the top of the firmware image page took me from there.
After downloading and unzipping the firmware image into a unique directory, I then downloaded and installed the Android SDK Platform-Tools package into that same directory (I also could have used the Android Studio suite to accomplish the upgrade, but that full-blown IDE would have been overkill for my specific purpose in this particular case). After adding the new directory to my Mac OS X path variable, so that the "flash-all" script could find all the necessary utilities and data files located there, I tethered the shut-down tablet to the Mac via USB and powered up the Nexus 7 in Bootloader mode. The bootloader was already unlocked, since this is a Nexus-branded (versus OEM) device, so I went straight to running flash-all from a Terminal command prompt. The nice thing about running the script is that it iteratively erases and updates each of the core elements of Android—boot, bootloader, radio, recovery, system, and vendor—along with blanking out the data and cache partitions, versus you needing to manually execute each step yourself.
A couple of minutes later, the upgrade was complete and the Nexus 7 auto-rebooted into its brand new Android 6.0.1 form. After entering my Google account credentials, I was then able to restore the nearly full application suite from backup. I still subsequently needed to reinstall a few more programs I'd sourced from the Amazon App store, as well as recreate my homescreen icon layout and re-log into relevant online accounts, but all in all it wasn't too much trouble. Thankfully, I no longer receive any android.process.acore-related error messages. And the system seems much speedier now, as well, along with being fuller-featured: it's good to go for a while longer! I still don't know why it got stuck on Android 4.4.2 in the first place; as you can see, there are two variants of this particular image available, one explicitly labeled "Verizon," so I wonder if I initially got OTA-pushed the wrong one, and was stuck from that point. But thankfully, my hacking (which perhaps obviously isn't generally consumer-friendly) got me over the hump.
Brian Dipert is Editor-in-Chief of the Embedded Vision Alliance and a Senior Analyst at BDTI.
- How does flash memory storage impact tablet responsiveness?
- Android woes give iOS the upper hand
- Software upgrade exhaustion
- The basics of USB device development using the Android framework
- Teardown: Inside Google's Nexus 7 tablet