Utilisez android:allowBackup uniquement en connaissance de cause !

TLDR : Depuis Android 4.0, il est possible de récupérer les données d’une application (base de données, préférences…) sans être root.
Mettez android:allowBackup à true uniquement lorsque les données stockées par votre application ne sont pas critiques (pas de notion d’utilisateur par exemple).

Si vous utilisez Android Studio comme IDE pour développer vos applications Android, les templates pré-embarqués mettent désormais l’attribut android:allowBackup à true dans l’AndroidManifest.xml. Il faut toutefois bien réfléchir à sa valeur.

Qu’est-ce que le BackupManager ?

Avant de s’intéresser réellement à android:allowBackup, regardons plus précisément la classe qui le définit. Disponible depuis Android 2.2 (FroYo), le BackupManager sert à sauvegarder et restaurer l’état d’une application. L’idée est de pouvoir synchroniser ses données dans le cloud pour les retrouver sur un nouveau terminal. Alors que cette fonctionnalité existe depuis plusieurs années (FroYo étant sorti en 2010), rares sont les applications qui l’utilisent aujourd’hui.

Concrètement, le mécanisme est séparé en deux entités :

• un Backup Transport qui s’occupe d’envoyer et recevoir les données sauvegardées
• un BackupAgent qui se charge de donner les données au Backup Transport et de restaurer son application à partir de celles reçues

Si vous avez un téléphone avec les GMS, les données seront alors envoyées vers le cloud de Google. La documentation à ce sujet est très complète, mais montre que rien n’est fait automatiquement, car c’est à vous de dire ce qu’elles données doivent être conservées avec un BackupAgent.

L’attribut allowBackup permet de dire si une application peut être « backupée », même si elle définit un BackupAgent :

Whether to allow the application to participate in the backup and restore infrastructure. If this attribute is set to false, no backup or restore of the application will ever be performed, even by a full-system backup that would otherwise cause all application data to be saved via adb. The default value of this attribute is true.

A première vue, on se dit que cet élément ne peut-être qu’utile pour l’utilisateur final, car il pourra sauvegarder et restaurer les paramètres de son application sans se prendre la tête pour autant. Il est à noter que par défaut sa valeur est à true. Si elle n’est pas définie dans le code, une erreur Lint sera automatiquement levée afin d’éviter toute ambiguité.

Le changement apporté avec Android 4.0

Mais depuis Android 4.0, les choses ont changé, puisqu’outre la synchronisation dans le cloud, il est possible d’effectuer le processus à travers son ordinateur grâce à la commande adb.

L’allowBackup permet maintenant de dire à la fois si la synchronisation est activée dans le cloud et si elle peut être faite depuis adb.

Comment fonctionne un backup avec adb ?

1) La sauvegarde

Sauvegarder une application en particulier (par nom de paquet) :

adb backup com.example.app

Sauvegarder le système dans son ensemble :

adb backup -all -apk -shared

Le terminal demandera alors confirmation à l’utilisateur avant de procéder à la sauvegarde. Un mot de passe vous sera alors demandé (facultatif si le téléphone n’est pas crypté).

Vous obtiendrez alors un fichier backup.ab, qui n’est, ni plus ni moins, qu’un tar avec un header spécifique. Il vous faudra tout de même un outil dédié pour extraire les données : Android Backup Extractor, où vous n’avez qu’à compiler le projet à la main :

./gradlew

Vous obtiendrez alors dans le répertoire build/libs, un fichier abe-all.jar. Pour convertir le backup.ab en fichier tar standard :

java -jar abe-all.jar unpack backup.ab backup.tar

Si toutefois votre archive est protégée par un mot de passe et que vous obtenez une exception « Illegal key size », il faut télécharger les Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files et relancer la commande.

Vous voilà désormais avec un fichier tar valide, que n’importe quelle application pourra extraire.

2) La restauration

A partir d’un fichier ab, vous n’avez qu’à lancer la commande :

adb restore backup.ab

Un mot de passe pourra vous être demandé sur le terminal si l’archive est cryptée.

Si vous avez extrait le contenu et l’avez ensuite modifié, il ne reste plus qu’à générer un fichier tar, puis un fichier ab :

java -jar abe-all.jar pack backup.tar backup.ab

Le contenu des fichiers ab

Les archives qui arrivent sur votre ordinateur ont une arborescence assez simple à comprendre.

Premier niveau :

• apps : vos applications
• shared : le contenu de la « sdcard »

En regardant de plus près dans apps, vous retrouvez l’ensemble des applications dans des dossiers spécifiques aux couleurs de leur nom de paquet. Elles peuvent ensuite contenir :

• _manifest : fichier manifest (rien à voir avec l’AndroidManifest.xml)
• a : apk(s)
• db : base(s) de donnée(s)
• f : fichier(s)
• r : ressources (ex : WebView)
• s : préférence(s)

Un potentiel risque de sécurité ?

Si on prend l’exemple de l’application Email disponible sur AOSP (com.android.email), on va alors tomber sur les différentes bases de données SQLite, les préférences et un fichier.

Vous comprenez donc qu’il y a de quoi prendre peur, car l’intégralité des données stockées dans le dossier d’une application (/data/data/com.example.app) sont visibles. Cela peut donc présenter un réel danger pour la sécurité des informations. Il n’y a absolument pas besoin d’être root pour avoir cet accès. Certes les manipulations ne sont pas simples et un écran s’affiche devant l’utilisateur, mais le risque est présent.

En revanche, vous remarquez que certaines applications ne contiennent que le fichier _manifest, car elles ont tout simplement désactivé le allowBackup.

Que faut-il faire ?

Tout dépend de votre application ! Si les informations placées dans le dossier ne sont pas critiques, laisser la possibilité aux utilisateurs de faire une sauvegarde et une restauration de leurs données ne pourra être qu’un point positif.

En revanche dès que des informations sensibles sont stockées, mettre android:allowBackup="false" s’impose.

En ayant rajouté la fonction à travers adb, Google a encore plus enterré sa synchronisation dans le cloud, qui était déjà peu populaire. Dommage !