Sauvegarde des données utilisateur avec Sauvegarde automatique
Sauvegarde automatique pour applications sauvegarde automatiquement les données d’un utilisateur à partir d’applications qui se chargent et s’exécutent sur Android 6.0 (niveau API 23) ou version ultérieure. Android préserve les données de l’application en les téléchargeant sur Google Drive de l’utilisateur — où elles sont protégées par les informations d’identification du compte Google de l’utilisateur. La quantité de données est limitée à 25 Mo par utilisateur de votre application et le stockage des données de sauvegarde est gratuit. Votre application peut personnaliser le processus de sauvegarde ou se désinscrire en désactivant les sauvegardes.
Pour un aperçu des options de sauvegarde d’Android et des conseils sur les données que vous devez sauvegarder et restaurer, consultez la vue d’ensemble de sauvegarde des données.
Fichiers sauvegardés
Par défaut, la sauvegarde automatique inclut les fichiers dans la plupart des répertoires attribués à votre application par le système :
- Fichiers de préférences partagées.
- Fichiers enregistrés dans la mémoire interne de votre application, accessibles par
getFilesDir()
ougetDir(String, int)
. - Fichiers dans le répertoire renvoyé par
getDatabasePath(String)
, qui inclut également les fichiers créés avec la classeSQLiteOpenHelper
. - Fichiers sur le stockage externe dans le répertoire renvoyé par
getExternalFilesDir(String)
.
La sauvegarde automatique exclut les fichiers dans les répertoires renvoyés par getCacheDir()
getCodeCacheDir()
, ou getNoBackupFilesDir()
. Les fichiers enregistrés dans ces emplacements ne sont nécessaires que temporairement ou sont intentionnellement exclus des opérations de sauvegarde.
Vous pouvez configurer votre application pour inclure et exclure des fichiers particuliers. Pour plus d’informations, consultez la section Inclure et exclure des fichiers.
Remarque : Android ne traite pas la configuration des composants comme des données utilisateur. Si votre application active ou désactive des composants spécifiques dans son manifeste pendant son exécution, ne vous attendez pas à ce qu’AutoBackup enregistre et restaure la configuration. Pour conserver l’état de configuration, enregistrez-le dans les Préférences partagées et récupérez les Préférences partagées lors de la restauration. Si vous souhaitez que votre application enregistre son état, stockez l’état dans les Préférences partagées et récupérez les Préférences partagées lors de la restauration.
Emplacement de sauvegarde
Les données de sauvegarde sont stockées dans un dossier privé du compte Google Drive de l’utilisateur, limité à 25 Mo par application. Les données enregistrées ne sont pas prises en compte dans le quota Google Drive personnel de l’utilisateur. Seule la sauvegarde la plus récente est stockée. Lorsque abackup est effectué, la sauvegarde précédente (si elle existe) est supprimée. Les données de sauvegarde ne peuvent pas être lues par l’utilisateur ou d’autres applications sur l’appareil.
Les utilisateurs peuvent voir une liste des applications qui ont été sauvegardées dans l’application Google DriveAndroid. Sur un appareil sous Android, les utilisateurs peuvent trouver cette liste dans le tiroir de navigation de Driveapp sous Paramètres >Sauvegarde et réinitialisation des données de l’application >.
Les sauvegardes de chaque périphérique-setup-lifetime sont stockées dans des jeux de données distincts, comme indiqué dans les exemples suivants :
- Si l’utilisateur possède deux périphériques, un jeu de données de sauvegarde existe pour chaque périphérique.
- Si l’usine utilisateur réinitialise un périphérique, puis configure le périphérique avec le même compte, la sauvegarde est stockée dans un nouvel ensemble de données. Les jeux de données obsolètes sont automatiquement supprimés après une période d’inactivité.
Programme de sauvegarde
Les sauvegardes se produisent automatiquement lorsque toutes les conditions suivantes sont remplies :
- L’utilisateur a activé la sauvegarde sur l’appareil. Dans Android 9, ce paramètre est la sauvegarde des paramètres >Système >.
- Au moins 24 heures se sont écoulées depuis la dernière sauvegarde.
- L’appareil est inactif.
- L’appareil est connecté à un réseau Wi-Fi (si l’utilisateur de l’appareil n’a pas opté pour des sauvegardes de données mobiles).
En pratique, ces conditions se produisent à peu près tous les soirs, mais un appareil peut ne jamais se réactiver (par exemple, s’il ne se connecte jamais à un réseau). Pour conserver networkbandwidth, le téléchargement n’a lieu que si les données de l’application ont changé.
Pendant la sauvegarde automatique, le système arrête l’application pour s’assurer qu’elle n’écrit plus dans le système de fichiers. Par défaut, le système de sauvegarde ignore les applications qui s’exécutent au premier plan car les utilisateurs remarqueraient que leurs applications sont arrêtées. Vous pouvez remplacer le comportement par défaut en définissant l’attribut backupInForeground
sur true.
Pour simplifier les tests, Android inclut des outils qui vous permettent d’initier manuellement une sauvegarde de votre application. Pour plus d’informations, consultez Tester la sauvegarde et la restauration.
Programme de restauration
Les données sont restaurées chaque fois que l’application est installée, soit depuis le Play Store, lors de la configuration de l’appareil (lorsque le système installe des applications précédemment installées), soit à partir de l’exécution d’adb install. L’opération de restauration se produit après l’installation de l’APK, mais avant que l’application ne soit disponible pour être lancée par l’utilisateur.
Pendant l’assistant de configuration initiale de l’appareil, une liste des jeux de données de sauvegarde disponibles s’affiche à l’utilisateur et on lui demande lequel restaurer les données. L’ensemble de données de sauvegarde sélectionné devient l’ensemble de données ancestral de l’appareil. L’appareil peut restaurer à partir de ses propres sauvegardes ou de l’ensemble de données ancestral. L’appareil donne la priorité à sa propre sauvegarde si des sauvegardes des deux sources sont disponibles. Si l’utilisateur n’a pas consulté l’assistant de configuration de l’appareil, l’appareil ne peut restaurer qu’à partir de ses propres sauvegardes.
Pour simplifier les tests, Android inclut des outils qui vous permettent d’initier manuellement une restauration de votre application. Pour plus d’informations, consultez Tester la sauvegarde et la restauration.
Activer et désactiver la sauvegarde
Les applications ciblant Android 6.0 (niveau API 23) ou supérieur participent automatiquement à la sauvegarde automatique. Dans le fichier manifeste de votre application, définissez la valeur booléenne android:allowBackup
pour activer ou désactiver la sauvegarde. La valeur par défaut est true
mais pour que vos intentions soient claires, nous vous recommandons de définir explicitement l’attribut dans vos manifestes indiqués ci-dessous:
<manifest ... > ... <application android:allowBackup="true" ... > ... </application></manifest>
Vous pouvez désactiver les sauvegardes en définissant android:allowBackup
sur false
. Vous pourriez vouloir le faire si votre application peut recréer son état via un autre mécanisme ou si votre application traite des informations sensibles qu’Android ne devrait pas sauvegarder.
Inclure et exclure des fichiers
Par défaut, le système sauvegarde presque toutes les données de l’application. Pour plus d’informations, consultez Fichiers sauvegardés. Cette section vous montre comment définir des règles XML personnalisées pour contrôler ce qui est sauvegardé.
- Dans
AndroidManifest.xml
, ajoutez l’attributandroid:fullBackupContent
à l’élément<application>
. Cet attribut pointe vers un fichier XML contenant des règles de sauvegarde. Par exemple :<application ... android:fullBackupContent="@xml/my_backup_rules"></application>
- Créez un fichier XML appelé
my_backup_rules.xml
dans le répertoireres/xml/
. Dans le fichier, ajoutez des règles avec les éléments<include>
et<exclude>
.L’exemple suivant sauvegarde toutes les préférences partagées saufdevice.xml
<?xml version="1.0" encoding="utf-8"?><full-backup-content> <include domain="sharedpref" path="."/> <exclude domain="sharedpref" path="device.xml"/></full-backup-content>
XML config syntax
The XML syntax for the configuration file is shown below:
<full-backup-content> <include domain= path="string" requireFlags= /> <exclude domain= path="string" /></full-backup-content>
Inside the <full-backup-content>
tag, you can define <include>
and <exclude>
elements:
-
<include>
– Specifies a file or folder to backup. By default, Auto Backup includes almost all app files. Si vous spécifiez un élément <include >, le système n’inclut plus aucun fichier par défaut et sauvegarde uniquement les fichiers spécifiés. Pour inclure plusieurs fichiers, utilisez plusieurs éléments <incluez >.Remarque : Les fichiers dans les répertoires renvoyés par
getCacheDir()
getCodeCacheDir()
, ougetNoBackupFilesDir()
sont toujours exclus même si vous essayez de les inclure. -
<exclude>
– Spécifie un fichier ou un dossier à exclure lors de la sauvegarde. Voici quelques fichiers qui sont généralement exclus de la sauvegarde :- Fichiers qui ont des identifiants spécifiques au périphérique, émis par un serveur ou générés sur le périphérique. Par exemple, Google Cloud Messaging (GCM) doit générer un jeton d’enregistrement chaque fois qu’un utilisateur installe votre application sur un nouvel appareil. Si l’ancien jeton d’enregistrement est restauré, l’application peut se comporter de manière inattendue.
- Informations d’identification du compte ou autres informations sensibles. Envisagez de demander à l’utilisateur de s’authentifier de nouveau la première fois qu’il lance une application restaurée plutôt que de permettre le stockage de ces informations dans la sauvegarde.
- Fichiers liés au débogage des applications.
- Fichiers volumineux qui font que l’application dépasse le quota de sauvegarde de 25 Mo.
Remarque : Si votre fichier de configuration spécifie les deux éléments, la sauvegarde contient tout ce qui est capturé par les éléments <include>
moins les ressources nommées dans les éléments <exclude>
. En d’autres termes, <exclude>
a priorité.
Chaque élément doit inclure les deux attributs suivants :
-
domain
– spécifie l’emplacement de la ressource. Les valeurs valides pour cet attribut sont les suivantes :-
root
– le répertoire du système de fichiers où sont stockés tous les fichiers privés appartenant à cette application. -
file
– répertoires renvoyés pargetFilesDir()
. -
database
– répertoires renvoyés pargetDatabasePath()
. Les bases de données créées avecSQLiteOpenHelper
sont stockées ici. -
sharedpref
– le répertoire oùSharedPreferences
sont stockés. -
external
le répertoire renvoyé pargetExternalFilesDir()
-
-
path
: Spécifie un fichier ou un dossier à inclure ou à exclure de la sauvegarde. Notez que :- Cet attribut ne prend pas en charge la syntaxe générique ou regex.
- Vous pouvez utiliser
.
pour référencer le répertoire courant, cependant, vous ne pouvez pas référencer le répertoire parent..
pour des raisons de sécurité. - Si vous spécifiez un répertoire, la règle s’applique à tous les fichiers du répertoire et aux sous-répertoires récursifs.
Remarque: Vous ne pouvez pas sauvegarder les fichiers en dehors de ces emplacements.
L’élément include
peut également contenir l’attribut requireFlags
, dont la section décrivant comment définir les exigences conditionnelles pour la section de sauvegarde discute plus en détail.
Définir les conditions de l’appareil requises pour la sauvegarde
Si votre application enregistre des informations sensibles sur l’appareil, vous pouvez spécifier les conditions dans lesquelles les données de votre application sont incluses dans la sauvegarde de l’utilisateur. Vous pouvez ajouter les conditions suivantes dans Android 9 (niveau API 28) ouplus haut:
-
clientSideEncryption
: La sauvegarde de l’utilisateur est cryptée avec un secret côté client. Cette forme de cryptage est activée sur les appareils fonctionnant sous Android 9 ou plus haut tant que l’utilisateur a activé la sauvegarde dans Android 9 ou plus haut et a défini un verrouillage d’écran (code PIN, motif ou mot de passe) pour son appareil. -
deviceToDeviceTransfer
: L’utilisateur transfère sa sauvegarde vers un autre appareil prenant en charge le transfert de périphérique à périphérique local (par exemple, Google Pixel).
Si vous avez mis à niveau vos périphériques de développement vers Android 9, vous devez désactiver et réactiver la sauvegarde des données après la mise à niveau. En effet, Android crypte uniquement les sauvegardes avec un secret côté client après avoir informé les utilisateurs dans les paramètres ou l’Assistant de configuration.
Pour déclarer les conditions d’inclusion, définissez l’attribut requireFlags
sur la ou les valeurs désirées dans vos éléments <include>
dans votre ensemble de règles de sauvegarde :
my_backup_rules.xml
<?xml version="1.0" encoding="utf-8"?><full-backup-content> <!-- App data isn't included in user's backup unless client-side encryption is enabled. --> <include domain="file" path="." requireFlags="clientSideEncryption" /><full-backup-content>
Si votre application implémente un système de sauvegarde clé-valeur, ou si vous implémentez vous-même Backupagent, vous pouvez également appliquer ces exigences conditionnelles à votre logique de sauvegarde en effectuant une comparaison bit à bit entre un BackupDataOutput
ensemble d’indicateurs de transport d’objets et le FLAG_CLIENT_SIDE_ENCRYPTION_ENABLED
FLAG_CLIENT_SIDE_ENCRYPTION_ENABLED
FLAG_CLIENT_SIDE_ENCRYPTION_ENABLED
FLAG_CLIENT_SIDE_ENCRYPTION_ENABLED
FLAG_CLIENT_SIDE_ENCRYPTION_ENABLED
FLAG_CLIENT_SIDE_ENCRYPTION_ENABLED
FLAG_CLIENT_SIDE_ENCRYPTION_ENABLED
drapeaux.
L’extrait de code suivant montre un exemple d’utilisation de cette méthode:
Kotlin
class MyCustomBackupAgent : BackupAgent() { override fun onBackup(oldState: ParcelFileDescriptor?, data: BackupDataOutput?, newState: ParcelFileDescriptor?) { if (data != null) { if ((data.transportFlags and FLAG_CLIENT_SIDE_ENCRYPTION_ENABLED) != 0) { // Client-side backup encryption is enabled. } if ((data.transportFlags and FLAG_DEVICE_TO_DEVICE_TRANSFER) != 0) { // Local device-to-device transfer is enabled. } } } // Implementation of onRestore() here.}
Java
public class MyCustomBackupAgent extends BackupAgent { @Override public void onBackup(ParcelFileDescriptor oldState, BackupDataOutput data, ParcelFileDescriptor newState) throws IOException { if ((data.getTransportFlags() & FLAG_CLIENT_SIDE_ENCRYPTION_ENABLED) != 0) { // Client-side backup encryption is enabled. } if ((data.getTransportFlags() & FLAG_DEVICE_TO_DEVICE_TRANSFER) != 0) { // Local device-to-device transfer is enabled. } } // Implementation of onRestore() here.}
Implémenter un agent de sauvegarde
Les applications qui implémentent une sauvegarde automatique n’ont pas besoin d’implémenter un BackupAgent
. Cependant, vous pouvez éventuellement implémenter un BackupAgent
personnalisé. En règle générale, il y a deux raisons à cela :
- Vous souhaitez recevoir une notification d’événements de sauvegarde tels que
onRestoreFinished()
ouonQuotaExceeded(long, long)
. Ces méthodes de rappel sont exécutées même si l’application n’est pas en cours d’exécution. - Vous ne pouvez pas exprimer facilement l’ensemble des fichiers que vous souhaitez sauvegarder avec des règles XML. Dans ces rares cas, vous pouvez implémenter un BackupAgent qui remplace
onFullBackup(FullBackupDataOutput)
pour stocker ce que vous voulez. Pour conserver l’implémentation par défaut du système, appelez la méthode correspondante sur la superclasse avecsuper.onFullBackup()
.
Si vous implémentez un BackupAgent, par défaut, le système s’attend à ce que votre application effectue une sauvegarde et une restauration de clé/valeur. Pour utiliser la sauvegarde automatique basée sur des fichiers à la place, définissez l’attribut android:fullBackupOnly
sur true
dans le manifeste de votre application.
Pendant les opérations de sauvegarde et de restauration automatiques, le système lance l’application en mode restreint pour empêcher l’application d’accéder aux fichiers susceptibles de provoquer des conflits et laisser l’application exécuter des méthodes de rappel dans son BackupAgent
. Dans ce mode restreint, l’activité principale de l’application n’est pas automatiquement lancée, ses fournisseurs de contenu ne sont pas initialisés et la classe de base Application
est instanciée au lieu de toute sous-classe déclarée dans le manifeste de l’application.
Attention : Pour éviter les erreurs, assurez-vous que les parties de votre application qui s’exécutent en mode restreint (principalement votre BackupAgent
) n’accèdent pas aux fournisseurs de contenu dans la même application ou ne tentent pas de lancer l’objet Application
. Si vous ne pouvez pas éviter ces modèles, envisagez d’implémenter une sauvegarde clé/valeur ou de désactiver entièrement la sauvegarde.
Votre BackupAgent
doit implémenter les méthodes abstraites onBackup()
et onRestore()
, qui sont utilisées pour la sauvegarde clé-valeur. Mais si vous ne souhaitez pas effectuer de sauvegarde clé-valeur, vous pouvez simplement laisser votre implémentation de ces méthodes vide.
Pour plus d’informations, consultez Extension de BackupAgent.