BackupManager: Unsafe At Any Speed

I had planned on writing a chapter on the new BackupManager system in Android 2.2. That is on indefinite hold, in part because I can’t get it to work, even with the tools refresh and a new AVD.

But, beyond that, using it seems pointless at best and damaging at worst. Simply put, you have no idea if it will actually ever work for a given user, or even who will have access to the backed-up data.

First, it only works on Android 2.2+ devices. That’s not a bad limitation, but it certainly limits usefulness in the near-term.

Second, it only works on devices that have enabled backups and automatic restores. While these are in the Privacy area of the Settings application, there do not appear to be any corresponding values in the Settings.Secure provider, nor any methods on the BackupManager class, to see whether or not these options are enabled. While they appear to be enabled by default for the Nexus One receiving the 2.2 upgrade, it remains to be seen what happens with other devices. It is unlikely that all will have it enabled by default. Since you cannot tell from your code whether or not it is enabled, you have no good way of hinting to the user to go in and enable them, short of telling everybody that, even if most already do have it enabled.

Third, you need to agree to a rather extensive separate Terms of Service for Google’s cloud, getting another API key, much like the Maps API key. This goes in your manifest. Fortunately, it only varies by package, not by developer, so it is not quite the version control nightmare that the Maps API key is. But the legal terms are, as usual, interesting. IANAL, but you will want qualified legal counsel to review those terms to see their impact on your application. Among the terms you may wish to ponder:

• You cannot easily have an open source application that supports BackupManager, because “You agree that only you are authorized to use the Backup Service Key(s) assigned to you”, and that implies a closed-source application, lest somebody else use the key and your package name for some other app (perhaps beating you to the Market).

• “You agree that you and your Applications will not transmit or store sensitive user information, such as user names, passwords, or credit card numbers, through the Service”, which will defeat the purpose of the backups for many apps.

• “You agree that you will not transmit any Content through the Service that is copyrighted, protected by trade secret or otherwise subject to third party proprietary rights, including patent, privacy and publicity rights, unless you are the owner of such rights or have permission from their rightful owner to transmit the Content through the Service”, which means you probably need a EULA or some other means of getting permission from the users to back up their data.

Fourth, there is no guarantee that every 2.2+ device will have the backup system. And, you have no API to determine whether or not it is available for any given user.

Fifth — and closely related to the previous point — is that some devices may have a different backup service provider, other than Google. You have no idea who it might be. You have no guarantees on what that provider might do with the data. It may be simply that your app will not back up with that provider, because you do not have an API key for their service. Or, all the data could be sent straight to some government intelligence agency, because that’s what the government told that device manufacturer and carrier to do.

Sixth, it is not a complete backup solution. It only really handles the case where the user’s phone is factory-reset or replaced. You still need your own separate backup system — perhaps lightly integrated with BackupManager — to handle more common scenarios, like “oops, I shouldn’t have deleted that entry”.

The net?

• You gain no marketing advantages for having this feature, since you can’t promote it, since you can’t be sure it will work for any of your users, let alone a significant number of them. You can’t even tell a given user whether or not it will work — you can tell them it won’t work in certain cases (e.g., 2.1 or earlier), but you can never know if it will definitely be available. Advertising it, then failing to deliver, will only harm you.

• The privacy implications of undefined and unknowable backup cloud providers means many applications just cannot use the service. Reviewing the applications installed on my personal phone, I see none for whom the backups would be relevant that I would actually want to be using this backup solution.

• Adding a cloud component to the backup logic you need to implement for common backup scenarios (e.g., “oops”) is not terribly hard. Then, you and the user get to make the decisions on who gets the data — not Google, not the device manufacturer, and not the carrier.

I may wind up completing this chapter someday, just for completeness, and to put these concerns down in a more lasting medium. And I sincerely hope that some of the easily-solved limitations (e.g., APIs for seeing if backups are enabled and possible) will get addressed in upcoming releases. However, I would really have preferred it if Google would have created an open source framework for cloud-based backups, with Google being a candidate provider but controllable by developers and users.

If you feel that some of my criticisms are flawed or unwarranted, please join the cw-android Google Group and let me know!