Posts Tagged Android

I’m doing some Android app development, and as part of it, I hit some issues with the database.

My first plan was to download the database and open it in SQLite, but having to re-establish my ADB debug session each time I downoaded the file got annoying, so I decided to write a short snippet which dumps the name & CREATE TABLE schema of each table to the log:

I have a Galaxy Nexus, and have been pretty happy with it. Then Google said it wouldn’t update the Galaxy Nexus to 4.4, and 4.4 is all swanky and new and most importantly, supports low memory devices better. So I want it. And guess what? CyanogenMod is pushing out 4.4 in CM11.

The real push for me to flash it is the fact that it has started dying on me – most annoyingly, the screen lit up to maximum brightness (while I was using it), then turned off. I suspect the screen just went dead, because I mashed the power button and tapped the blank screen and it vibrated at my touch, but the screen would only come back on after I pulled the battery and replaced it. Happening once is OK, I’ll chalk it up to cosmic ray events/random glitches. Having it happen 3 times in a single night is a bit much.

So it’s off to CyanogenMod!

First off, backups: I found a full backup method in an XDA thread. Reading through the thread pointed out that SMSes weren’t backed up, so first SMS Backups were handled by SMS Backup+.

Then I tried to get ADB setup. First roadblock: The Google USB Driver wasn’t in the SDK that I downloaded – had to use the SDK Manager to download it. Unfortunately, that still didn’t work, so I had to install the Samsung driver instead. I ended up with a “Samsung Android ADB Interface” entry in the Device Manager, so that was good.

However, adb seemed to have completely crashed, and it was weirdly even resistant to ending the process through Task Manager. adb.exe, java.exe and powershell.exe are all stubbornly refusing to close. This, however, was because Avast was restricting access to it, annoyingly enough. I disabled the Avast shields, and added the SDK folder as exempt from scanning.

One adb pull /sdcard/ and I had a backup of the contents of the internal SD card. Because I had the shared stuff (I’m assuming that’s what the SD card stuff is), the next thing is adb backup -all -apk backup.ab. However, Google Music threw this for a loop here because the backup includes the cached music, so the final size of the backup was 5.11GB… which is excessively large.

Next step was actually unlocking the bootloader. fastboot required a different driver, so I ended up using the “Universal Driver” from XDA. After running fastboot oem unlock. I booted back into stock 4.2 (hadn’t flashed CM11 yet), and tried to restore my data using adb restore. It worked through ~half the apps, then died on restoring the google play store. Instead of retrying the restore, I forged ahead and flashed CM11.

Now that I had CM11 installed, I then tried to restore my data. Which is where the weird part hit – The restore ran for a second or two, and then said “Restore completed”. After retrying a few times and getting the exact same thing, I hooked up adb logcat to monitor the restore and see what was happening.

Now I’m not too sure what was wrong, but BackupManagerService was consistently reporting “Incorrect password”. I tracked down the source, which I eventually decided that either it meant I was truly using the wrong password (I deemed this unlikely because the failed restore partially worked) or comparing the calculated key checksum with the stored key checksum failed. I heard stuff about Android’s encryption being weak, so they might have changed something, but a quick glance over the 4.2.1 and 4.4.2 BackupServiceManager files showed no obvious difference.

Whatever the case, my full adb backup was well and truly dead. So I just reverted to reloading my apps from the Play Store (ran through the list in My Apps) and waiting for the backup manager to restore whatever data Google had backed up. After installing everything, I restored Whatsapp from the database I backed up, and ran SMS Backup+ to restore all my SMS messages/call log from the backup.

So I had pretty much everything back where I wanted it, so the next thing in the list was to install a new kernel that would give me more RAM (since apparently TI ION maps a whole bunch of stuff into the RAM range, so the full 1GB wasn’t usable). That was a download and reboot into recovery mode to flash it, but straight forward since I’d already been poking around CWM.

And that was pretty much that. A shiny new (clean) install of Android 4.4.2 on an older phone, that actually revitalized it.

Future stuff:

Use ClockWorkMod Touch instead of the standard ClockWorkMod (since my volume up button is broken, and scrolling through the list is tedious)

Fix in short: switch Google Play to a different Google Account, and switch back to the original account. It can be a new Google account, or one that already exists on your phone.
I hope that helps, and if you want screenshots & more details, read on. 🙂

(Short version because, apparently, this post is #3 on Google for “Google Play RPC:S-5”, and variations thereof, and putting the fix in the description that Google will show seems like a Good Thing to Do.)
==
If you’re unlucky, like me, you’re getting an error like this when you try to update stuff on your shiny Android 4.1(.1) device: (Edit: Apparently, not just Android 4.1.1, I’ve seen reports of 4.2 breaking too.)

The most common ‘solution’ I’ve seen is to completely remove your Google account, and re-add it.

Which seemed a bit extreme, given that it’d (supposedly) wipe all your stuff off the phone. A solution that I stumbled upon is to simply switch to a different Google account in Google Play (Tap the options button at the top right), install an update, then switch back to your original account, and install the rest of the updates.

Yes, the third option on the list that appears. (I’m not showing my accounts screen because that has my email addresses.)

That got it working for me. It’s possible that you don’t even need to install an app in the other account – just switching back and forth might be enough to get Google Play to update whatever cached file is breaking. (I’m assuming it’s a cached file, that is.)

Apparently, this is an unexpected result of flushing and restarting the Google Services Framework in an attempt to force Android to detect/receive the update to Android 4.2. (Which, sadly, didn’t work for me, possibly because I’m on Wind in Canada. Oh well.)