Ick!

If you’ve got a sensitive stomach, you might want to stop reading this post now.

Still here? The subtitle of this post is “How do you disinfect a tablet?”

The short answer appears to be “You don’t.” But let’s back up a bit.

A few weeks ago, I dropped my Nexus 9 (poor Kei-kun!). It landed on edge (wince) in the litter box (double-wince). Fortunately, I had just emptied the box, so there weren’t any, ah, chunks of ickiness. That also meant the top layer of litter was about as clean as it gets. And, since the tablet was in its case, the only part to come in contact with the contents of the box was the screen.

Have I mentioned that there are many good reasons to keep your tablet in a case that provides full coverage? No? Consider it mentioned.

Step One was to get the tablet out of the case. Easily done. I set the tablet and case on newspaper* and moved on.

* I have one thing to say to my friends who tease me about still reading the newspaper instead of getting all my news online: “Nya, nya!”

Step Two was to wash my hands. Thoroughly. Several times.

Step Three: Research!

I couldn’t find any reputable sites that gave instructions for decontaminating tablets or phones–though quite a few warned against spraying Apple screens with any kind of cleaning fluid. Apparently the coating Apple uses to minimize fingerprint smudges is very vulnerable to cleaners. Since, as far as I can tell, Nexus devices don’t have a similar coating–a quick look at all the smudges on my poor tablet made that obvious–I moved on.

OK, I can’t sterilize Kei-kun. What about disinfection? There are quite a few click-bait articles referencing a somewhat questionable study that claim phones are covered with something like 18 times as many bacteria as toilet seats. Most of the articles take great pleasure in telling you there’s nothing you can do about it; A few suggest using alcohol, though it’s unclear whether you’re supposed to use it to disinfect the device or just drink enough that you don’t care how disgusting your phone is. sigh

How about benign neglect? I tried to figure out how long bacteria live on glass and plastic. Turns out it depends on the specific bacteria, the kind of plastic, the humidity, and probably several thousand other factors. The range is from “a couple of hours” to “months”.

At this point, it had been a couple of hours, and I was suffering from tablet withdrawal. No way was I going to make it for months. I sprayed the tablet and case with an alcohol-based screen cleaning solution–carefully avoiding the buttons, camera, and speakers–and went to bed.

Step Four: Ignore the case. I figured that most of the bacteria on it would either die or get bored and go in search of a more interesting habitat within a couple of days. And, as long as I washed my hands, using the tablet was no more of a health risk than cleaning the darn box. I went through an unusually large amount of soap over the next couple of days.

I also noticed that the tablet was running hot. Mostly just warm, but when installing app updates, it got uncomfortably hot on a couple of points. Since I’d been using in the case, I had no idea whether the amount of heat I was feeling was normal.

Step Five: Return table to case. I was figuring another couple of days of excessive handwashing, and life would be back to normal. A couple of hours after I started using the case, the Nexus rebooted. And again forty-five minutes later. Back out of the case and back to the Internet.

Interestingly, overheating Nexus 9s seem to be a thing. The consensus is that it could be caused by a hardware problem or a corrupted system file, and either condition can be caused by dropping the tablet.

Step Six: Use tablet without a case and switch to a “smart cover” to protect the screen without allowing heat to build up. I figured that would hold me until the Android Marshmallow rollout. Upgrading the OS would then replace the entire system, and–hopefully–resolve the overheating problem. And it does seem to have helped. The tablet is definitely running cooler. I’m just not sure it’s running cool enough to risk putting it back in the case.

Which, of course, means that it could give out on me at any moment, case or not. I had some hope that Marshmallow’s auto-backup system would give me some peace of mind. Early reports were that it would back up all apps unless developers specifically opted out. However, it turns out that’s only true if the app has been targeted for API 23*. Older apps won’t be backed up.

* That is, the app needs to be compiled with the Marshmallow SDK and have the Marshmallow feature-set turned on. This is easy to do, but good software practices require app testing before making such a change. As of this writing, approximately a week after I got the upgrade, exactly two non-Google apps are being backed up: my alarm clock app and Yelp.

So I’m back to using the command line backup tool I talked about back in January. And running with the less-secure smart cover instead of the case. Pray for me and poor Kei-kun.

Google, can we please get a backup system that Just Works?

Interesting Times, Part 2

Welcome back. Last time, I implied that Google had made a big mistake in designing Android. Today, I’ll explain.

I can summarize the problem in one simple sentence. It’s impossible to back up your Android device.

Really.

There are some partial methods:

  • Turn on “Back up my data”. (Android prompts you to turn it on when you’re setting up the device, but if you declined, you can find it in the “Backup & reset” section of the Settings app.) This sounds good. According to the menu in Lollipop, it will back up “app data, Wi-Fi passwords, and other settings to Google servers”. Unfortunately, the description is somewhat misleading. Your Android settings will be backed up. So will a list of all of the apps you’ve installed. What won’t be backed up is the settings of all those apps. Game progress? Not backed up. List of websites in your RSS reader? Not backed up. Configuration of your e-book reader, social network apps, and weather app? Not backed up–unless you’re using Google’s own apps. The problem is that Google has made the APIs for saving configuration and app state optional. The number of developers who actually use them is miniscule.
  • Install a backup app. There are some. Some of them even work–but only for data the individual apps have marked as public. As part of Android’s security model, apps are largely prevented from accessing any data but their own. In order to do a full backup, you need to root the device. That requires a user to gather instructions and software from several places around the Internet and risk bricking the device. In many cases, it will void the warranty and prevent automatic installation of OS updates–and configuring the device to allow rooting will wipe all of the data on the phone. Yeah, the same data you were trying to back up.
  • Use the backup tool from the developer’s kit. Uh-huh. The average user isn’t going to use any tool that requires them to type commands. Heck, never mind the fact that the average user doesn’t back up their computer and wouldn’t see the point in backing up their phone; the portion of users who would even install a command line program is too small to count. Not that it would help much if they did. Google warns that backing up app data isn’t fully supported, and may not work.

The bottom line here is that as soon as you install one non-Google app, you have almost certainly lost the ability to move your electronic life from one device to another.

That’s not just a problem for people whose devices suddenly drop dead. It affects anyone who wants to upgrade to a new phone (Gotta have that larger screen, right?); anyone who needs to change carriers; and, of course, anyone who doesn’t trust Google to keep their data safe when the NSA comes calling.

Unfortunately, there isn’t much Google can do to repair the problem at this point. Google doesn’t review apps at a level of detail that would allow them to require apps to use their backup APIs. Future versions of the OS could introduce a limited form of root access (similar to Windows’ “Administrator mode”), but that wouldn’t help anyone using a device with an older OS–which is most users*.

* As of January 5, Google’s own numbers show that less than 0.1% of users have picked up Lollipop since its November launch. Less than 40% have even gotten as far as last year’s KitKat release. Hell, nearly 8% are still using Gingerbread, which hasn’t received any updates since 2011.

Security is a spectrum. Every vendor has to strike a balance between user freedom and protecting users from themselves. In this case, Google put the balance point in the wrong place. How many would-be phone upgraders, faced with the task of re-entering all their app settings have changed their minds? A little more freedom, and we might not have all of those Gingerbread and Honeycomb users still clutching their aging hardware and praying that it won’t die on them.