Lessons Learned from Shattering my Phone

2022 03 29

I've had pretty good luck with mobile devices, all things considered. Having used them for the vast majority of my life, I've only broken them in a significant fashion a small handful of times. I've broken the digitizer (but not LCD panel) on a Nexus 7, I've had an iPhone 3GS get a serious battery bulge, but nothing ever too serious. I managed to recover my Nexus 7 by hooking a DualShock 3 up to it via USB-OTG. That was quite an adventure, but hey, it worked!

I also had my Gameboy Color get run over by my parents' minivan (my fault), but it was actually 100% fine aside from some cosmetic cracking and was fully functional. This was the same Gameboy I had dropped in the (unused) toilet previously. Nintendo has (had?) some solid hardware engineers, and I was quite a dumb kid.

Unfortunately, my Pixel 5a (3.5mm audio outputs will never die!) recently decided to slip from my grasp and fall in just the wrong way to land on a hard point and shatter both the screen and digitizer. No visual, no touch input. Truly a worst case scenario. I had backups, but I was not diligent in keeping them up to date and were a couple months old. I also had an older (non-broken) phone since I had upgraded semi-recently, so I was not phone-less for too long.

For fun and entertainment, let's go through some of my failed attempts to get data off the shattered device. These might have actually worked in different circumstances, but didn't for me:

1. Attempt to use one of those USB-C to everything docks to get video out. Pixel 5a does not support video out over the USB-C port, and it's apparently a super uncommon feature in Android devices. How annoying.
2. Attempt to enable + trust ADB by hooking up a keyboard via USB-C and blind-navigating the menus with the assistance of an Android simulator.
   1. I'm pretty sure that I got ADB actually enabled via the keyboard method, but the tricky part is getting the "Trust this computer?" prompt to appear and still have keyboard input. I couldn't get both the keyboard input and my computer's connection to go at the same time, and the "Trust?" prompt disappears almost immediately after being disconnected from the computer. I couldn't manage to pit-crew the USB cables in and out fast enough.
      1. I tried to enable Bluetooth and use a Bluetooth keyboard I already had paired with my phone. For whatever reason (likely me failing to enable Bluetooth via blind keyboard inputs) I couldn't get the BT keyboard to pair.
3. Largely the same as above, but via blind touch. This was before I realized that the digitizer was 100% gone.

My options exhausted, I bit the bullet and bought a new phone. With the replacement device in hand, I've learned some important lessons on operational diligence and the weird quirks of Android.

These tips are written with some assumptions already set:

• Your phone is Android based.
• Your phone is rooted. Some of these tips may still apply to non-root users, but no promises.
• This is based on Android 12. Future (or past) versions of Android may deviate.
• You have the Android Platform Tools downloaded and installed.

First and foremost, the Android Debugging Bridge is a godsend for so many reasons. ADB, as it's commonly known, is a USB (or network if you're feeling fancy) protocol for interfacing in all kinds of fun ways with an Android device. First and foremost, the adb push and adb pull commands are significantly easier than whatever MTP or other "automatic" file transfer malarkey Google decides is the latest default in Android this given week. There are also tools like scrcpy which leverage ADB to provide a VNC-like interface to your phone from a computer running a major operating system. If you're on Android 12, make sure to compile it from source rather than using your distro-packaged version, it probably won't work.

The main issue with ADB is that since it provides great and powerful capabilities, Google tries very hard to make it difficult to use in what they declare to be an insecure fashion. I'm not here to make claims that the workflow I have isn't technically less secure than defaults, but I'm willing to accept the tradeoffs for "I can get data out of my phone if it breaks."

ADB operates similar to SSH, where a host computer will have an RSA keypair that must be trusted by the target device. (Yes, this is a gross simplification of SSH but let's run with it.) As of Android 12, by default, will pop a "Trust this computer?" prompt on the touch screen. That's all well and good, but not super helpful when the touch screen is all kinds of broken. Thankfully, there is a solution! In Settings -> System -> Developer Options (once enabled as described here) there is a "Disable adb authorization timeout." This option will, as it says on the tin, disable the default trust revocation after 7 days for a trusted computer, even if the "always trust this machine" checkbox is enabled. With this toggle set, I plugged my replacement, non-shattered phone into my workstation and, with the "always trust" checkbox checked, trusted my computer.

After establishing this new (hopefully?) long-lived trust, I figured it would be prudent to backup the keys that are trusted. On Linux, those files will live in ~/.android/adbkey(.pub). I backed them up as attachments into my KeepassXC store, and have that squirreled away in various non-mobile backup solutions. This way, even if I'm at a separate computer, I can re-fetch those keys, install them, and my phone will trust them.

With the access portion of the equation more or less solved, the question comes down to how actual backups are done. Titanium Backup is, as far as I know, the gold standard for rooted Android backup and has been for a heck of a long time. It's a little strange on Android 12, and will sometimes require some fiddling to get apps and data to restore. I haven't run into any cases where backup files are completely unrestorable, but it can take some doing. On my new phone, I've set scheduled tasks to run daily with data and config changes. Titanium Backup supports straight-to-cloud uploads of your backups (and encryption) but I'm not a huge fan of trusting cloud storage with that raw data, and I haven't vetted the encryption too terribly much.

As a quick side note, Signal does not play nicely with TitaniumBackup (and rightly so.) Signal does provide native backup support which works a treat in my experience. I slap it into /sdcard/TitaniumBackup so I can pull it along with the Titanium Backup data files.

So, what to do with these backup packages once they exist on the phone storage? Google offers a tool called adb-sync intended to have rsync-like behavior for ADB. However, I've been extremely pleased with SelfAdjointOperator's fork, the cleverly named better-adb-sync. I set up a quick and dirty Bash script to run a sync on both the /sdcard/DCIM folder (for photos) and the /sdcard/TitaniumBackup folder to pull my backup packages. Once on my local workstation, there are further backups and redundancy solutions in place, but that's perhaps out of scope for this writeup.

The final piece is to add an entry to my to-do list to remind myself daily to pull backups. Since the steps are "plug it in and run a script" I have very little excuse to not keep up to date on them. Next time I shatter my phone into a non-functional state, I will be far more prepared. Learning and growing!

In summary:

1. Enable ADB, disable the "Disable adb authorization timeout" toggle, and leave it on!
2. Backup your computer's ADB RSA keypair!
3. Use Signal! Also, its native backup feature!
4. Get better-adb-sync for easy transfers to and from your device!
5. If at all possible, don't shatter your phone to begin with!