54 votes

Milner avatar

Google Backup: Plusieurs appareils utilisant le même compte - que se passe-t-il lors de la restauration ?

Demandé el 24 de Mars, 2013
Quand la question a-t-elle été
81285 affichage
Nombre de visites la question a
5 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

Il n'est pas nouveau que on peut utiliser plusieurs appareils Android avec un seul compte Google. Lorsqu'on allume un nouvel appareil pour la première fois, on demande si on veut stocker ses données avec Google, ce qui permettrait de synchroniser "certaines choses" avec les serveurs Google, en gros :

  • certains données d'application (si les applications le supportent explicitement)
  • mots de passe Wi-Fi
  • favoris de navigateur
  • une liste des applications installées depuis Google Play
  • mots ajoutés au dictionnaire utilisé par le clavier virtuel
  • la plupart de vos paramètres personnalisés

Des détails peuvent être trouvés dans le Google Dashboard. Les questions pertinentes couvrant ces sujets ici incluent :

Le API des développeurs sur la sauvegarde Google donne un aperçu supplémentaire de la façon dont la sauvegarde est censée fonctionner (et plusieurs questions ici montrent comment ça fonctionne réellement -- c'est-à-dire, parfois ça fonctionne, parfois seulement en partie, et parfois pas du tout). Outre la fiabilité et le fait que tout le monde ne veut pas ses données privées dans le cloud (et même la référence de l'API mentionnée2 avertisse : Android ne garantit pas la sécurité de vos données lors de l'utilisation de la sauvegarde. Soyez toujours prudent en utilisant la sauvegarde pour stocker des données sensibles, telles que les noms d'utilisateur et les mots de passe.), ma principale question est :

Avoir sauvegardé des données à partir de plusieurs appareils en utilisant le même compte :

  • qu'arriverait-il à un appareil réinitialisé en usine utilisé de cette manière auparavant ? Serait-il reconnu et uniquement les choses restaurées qui ont été utilisées auparavant ?
    (l'identification de l'appareil pourrait par exemple se faire via l'IMEI (mais pas via l'Android_ID, car cela pourrait être supprimé avec une réinitialisation aux paramètres d'usine) -- et ceci pourrait être la raison du comportement décrit dans la réponse de Nalum)
  • qu'est-ce qui serait restauré sur un appareil (nouveau/réinitialisé en usine) que vous initialisez pour la première fois avec ce compte Google ?
    (si les appareils étaient identifiés avec des sauvegardes dans le compte Google utilisé, cela pourrait déclencher une action spéciale pour "nouvel appareil", par exemple "restaurer tout, appareil changé !" -- ou "restaurer tout depuis l'appareil X non connecté, car il a probablement été remplacé !" -- mais se limiter à "restaurer seulement ce qui était sur cet appareil" en cas de réinitialisation aux paramètres d'usine)

Le problème est le suivant : Si on a plusieurs appareils, ils sont souvent utilisés pour des problèmes spécifiques, donc on ne veut pas tout sur tous les appareils. Comme je n'ai vu aucun moyen de choisir quelles données sauvegarder (par exemple, exclure ces données "sensibles" dont on nous a avertis : les mots de passe Wi-Fi appartiendraient à cette catégorie), je suppose qu'il n'y a pas non plus de choix sur la restauration ? Alors comment cela est-il géré ?

Demandé el 24 de Mars, 2013 par Milner

0 votes

Avatar de Milner

Deux autres sources qui pourraient être intéressantes à lire à ce sujet sont : Google backup and restore for Android is device specific? (qui décrit le "bazar" d'au moins les versions d'Android avant 4.x), et Android's automatic backup and restore service is great ... when it works. Les deux reflètent en partie ma question, mais aucune n'y répond. Voilà pour la recherche sur le sujet.

Commenté el 25 de Mars, 2013 par Milner

3 votes

Avatar de crdx

La seule entrée que je peux donner, c'est qu'elle est si peu fiable. J'aimerais qu'il y ait un bouton de sauvegarde/restauration manuel que je pourrais utiliser. J'ai réinitialisé ma tablette l'autre jour et elle n'a pas restauré toutes mes applications et réglages, alors que les fois précédentes où cela a été fait, elle l'a fait. Je n'aime pas que je ne puisse pas compter dessus.

Commenté el 28 de Mars, 2013 par crdx

0 votes

Avatar de Milner

Même avec une prime, les détails ne semblent pas pouvoir être révélés, alors les chances de trouver une "réponse complète" sont plutôt faibles. Nous en savons donc autant qu'avant : cela pourrait fonctionner "d'une façon ou d'une autre", il faudra essayer de comprendre, et on pourrait être chanceux ou non. Merci, Google, pour un outil peu fiable sans aucune documentation utilisateur :( La prime va donc à Nalum : même si la réponse précède la prime, c'est la meilleure que nous ayons :)

Commenté el 9 de Mai, 2013 par Milner
Afficher 2 autres commentaires

Réponses

Trop de publicités?

45voto

Andy Brudtkuhl avatar
Andy Brudtkuhl Points 1714

Parlons des ensembles, bébé

Le service de sauvegarde Android a un concept appelé un ensemble : l'ensemble de toutes les données sauvegardées à partir d'un appareil (sur un transport, mais c'est un détail). Chaque ensemble est identifié par une chaîne unique, comme l'IMEI sur l'appareil. Lorsqu'une application (ou la liste des applications installées) est sauvegardée, ses données de sauvegarde vont dans l'ensemble associé à l'appareil à partir duquel elle est sauvegardée. Tous les ensembles sont toujours spécifiques au compte Google de l'utilisateur. Si vous réinitialisez votre appareil et le vendez à quelqu'un d'autre, il ne pourra pas accéder à l'ensemble de cet appareil à moins qu'il ne puisse se connecter à votre compte Google.

Comportement par défaut

Lorsqu'une application est installée, ou qu'un appareil restaure sa liste d'applications, le système de sauvegarde recherche d'abord dans l'ensemble de cet appareil les données de sauvegarde pour ce package. S'il n'en trouve pas (soit parce qu'il s'agit d'un appareil complètement nouveau sans données sauvegardées, soit parce que ce package n'a jamais été installé sur cet appareil), il étendra la recherche à d'autres ensembles. (S'il y a un choix, il utilisera le dernier ensemble qui a été utilisé pour une restauration complète de l'appareil.)

Ainsi, lorsque vous configurez un nouvel appareil, il restaurera la liste des applications à partir de la sauvegarde d'un ancien appareil, et restaurera chaque application à partir de la sauvegarde de l'ancien appareil. Si vous aviez une application installée sur un appareil et que vous l'installez sur un autre appareil, l'application sera restaurée avec ses données de l'ancien appareil. Dans les deux cas, les données sont désormais sauvegardées dans l'ensemble du nouveau appareil, ce qui signifie que les données de sauvegarde des deux appareils sont désormais séparées.

Après avoir réinitialisé un appareil, il restaurera à partir de la dernière sauvegarde de cet appareil s'il y en a une, et à défaut, à partir de la sauvegarde d'un autre appareil s'il y en a une, mais il commencera à créer son propre ensemble à partir de ce moment-là. C'est pourquoi les deux appareils de Nalum ne voient pas les applications sauvegardées l'un de l'autre : ils restaurent chacun à partir de leur propre dernière sauvegarde.

Source

Ce mécanisme n'a pas de documentation visible par les utilisateurs, car il est censé faire automatiquement ce qu'il faut, mais le code est disponible.

bmgr : utilisation de base

Comme l'a découvert Izzy, l'outil bmgr vous donne un certain contrôle sur ce processus. Il est destiné à aider les programmeurs à tester et à déboguer l'intégration de sauvegarde dans leurs applications. Vous pouvez utiliser cet outil dans un shell adb pour déclencher des sauvegardes et des restaurations de packages choisis, effacer les données sauvegardées des packages, voire une restauration complète de l'appareil.

Ne pas essayer de l'utiliser dans un shell sur l'appareil sauf en tant que root : vous avez besoin de l'autorisation système android.permission.BACKUP pour faire quelque chose d'intéressant avec.

Vous pouvez faire mettre à jour immédiatement les données sauvegardées d'une application :

bmgr backup com.shadowburst.showr
bmgr run

(ou quel que soit le nom de package de l'application). Normalement, il n'est pas nécessaire de le faire, car les applications demandent leurs propres sauvegardes lorsque leurs données changent, mais cela vous permet de contourner une application mal conçue. Pour restaurer un package à partir des données sauvegardées qu'il choisirait par défaut :

bmgr restore com.shadowburst.showr

mais encore une fois, cela fera seulement ce que l'appareil ferait de lui-même, donc vous ne devriez pas avoir besoin de l'utiliser. Notez également que l'application doit déjà être installée pour que cela fonctionne.

Plus de contrôle

Maintenant, passons aux choses que le système de sauvegarde ne fera pas de lui-même. Pour voir quels ensembles de données sauvegardées sont disponibles :

bmgr list sets

et vous obtiendrez une sortie comme ceci :

  3ff7800e963f25c5 : manta
  3f0e5c90a412cca7 : manta
  3dd65924a70e14c8 : TF101
  3baa67e9ce029355 : m0

Le nombre hexadécimal sur la gauche est un jeton. Vous en aurez besoin dans une minute. La chose à droite est un nom (relativement) convivial pour l'appareil propriétaire de l'ensemble. Par exemple, manta est le nom de code du nexus-10 ; TF-101 fait référence à l'original asus-eee-pad-transformer. Une fois que vous avez déterminé quel ensemble vous voulez, vous pouvez restaurer une application à partir de cet ensemble en utilisant son jeton :

bmgr restore 3ff7800e963f25c5 com.shadowburst.showr

Vous pouvez ajouter plus de noms de packages à la fin de la commande pour restaurer plusieurs packages à la fois, ou vous pouvez ne spécifier aucun nom de package (juste le jeton) pour restaurer chaque application avec des données dans cet ensemble (c'est-à-dire qu'il effectue une restauration complète du système).

Enfin, vous pouvez effacer les données d'une application de l'ensemble actuel :

bmgr wipe com.shadowburst.showr

Cela fera que sa prochaine opération de sauvegarde commence à zéro. Cela peut être utile après la désinstallation d'une application, si une erreur dans l'application a corrompu ses données de sauvegarde et que vous ne voulez pas les restaurer.

Vous ne pouvez pas faire en sorte qu'un appareil commence à écrire dans un ensemble différent, ni pouvez-vous effacer un ensemble entier.

Répondu el 19 de Juillet, 2013 par Andy Brudtkuhl (1714 Points )

0 votes

Avatar de Milner

Réponse très détaillée, merci, Dan! Le "contrôle manuel" (où restaurer à partir de) est un plus que je cherchais. J'aimerais qu'il y ait un choix pour tout cela, comme un pop-up lorsque la restauration démarre : "Voulez-vous restaurer?" -> "À partir de quoi?" -> "Sélectionner les détails (restauration complète, xxx...)". Bien qu'il puisse être agréable qu'une application sache "faire automatiquement ce qu'il faut", j'aime être en contrôle, et parfois c'est même nécessaire. De plus, une restauration peut être nécessaire dans des cas autres que les réinitialisations d'usine et les nouveaux appareils, il devrait donc y avoir un moyen pour l'utilisateur de la déclencher...

Commenté el 19 de Juillet, 2013 par Milner

7voto

Milner avatar
Milner Points 533

Il s'agit sans conteste d'une réponse à la question, mais cela pourrait éclairer certains détails :

Quelques éléments extraits de l'API de sauvegarde

Bien que l'API soit principalement destinée aux développeurs, il y a quelques faits que nous pourrions extraire pour notre cas. Dans la liste suivante, les citations de la documentation de l'API sont en italique.

  • Android effectue automatiquement une opération de restauration lorsque votre application est installée et qu'il existe des données de sauvegarde associées à l'utilisateur.
    → cela peut signifier deux choses :
    • si une application prend en charge l'API de sauvegarde Google, et que l'utilisateur a activé la sauvegarde Google, les données de sauvegarde disponibles seront automatiquement restaurées lors de l'installation. C'est pratique lorsque vous installez une application utilisée sur un seul appareil sur un deuxième appareil pour la première fois.
    • les sauvegardes sont uniquement associées au compte Google, pas à l'appareil (et il existe des données de sauvegarde associées à l'utilisateur) -- ou l'autre fait a simplement été ignoré comme étant sans importance pour ce cas particulier ("l'application est installée")
  • Le transport de sauvegarde est le composant côté client du framework de sauvegarde Android, qui est personnalisable par le fabricant de l'appareil et le fournisseur de services. Le transport de sauvegarde peut différer d'un appareil à l'autre [...]
    → cela pourrait expliquer l'instabilité lorsque l'on passe à des appareils différents (ou des versions d'Android différentes).
    (soulignement de ma part)
  • La sauvegarde des données n'est pas garantie sur tous les appareils alimentés par Android.
    (sans commentaire)
  • Google fournit un transport de sauvegarde avec le service de sauvegarde Android pour la plupart des appareils Android fonctionnant sous Android 2.2 ou supérieur.
    → ici, nous avons la version Android minimale requise pour que la sauvegarde Google soit disponible : Froyo, alias Android 2.2
  • Pour obtenir votre clé de service de sauvegarde, inscrivez-vous au service de sauvegarde Android. [...]
    → chaque application doit avoir sa propre clé. Il n'est pas expliqué "pourquoi", mais une bonne supposition serait : isoler les sauvegardes afin qu'aucune application ne puisse lire les sauvegardes d'une autre application (clé incorrecte ; quant aux sauvegardes d'un autre utilisateur : mauvais compte)
  • Pendant le développement de votre application, vous pouvez démarrer une opération de sauvegarde immédiate depuis le Gestionnaire de sauvegarde avec l'outil bmgr.
    → il semble qu'il y ait un moyen de déclencher manuellement des sauvegardes ? Nous creuserons cela plus tard. ↓
  • Lorsqu'il est temps de restaurer les données de votre application, le Gestionnaire de sauvegarde appelle la méthode onRestore() de votre agent de sauvegarde.
    → cela souligne à nouveau le premier élément de cette liste : d'abord l'application doit être installée, puis ses propres implémentations sont utilisées pour restaurer ses données. À y regarder de plus près: si la restauration de l'application échoue, il n'y aura pas de restauration des données pour les applications échouées -- jusqu'à ce que vous les installiez manuellement via Google Play. Ensuite, comme le premier élément l'a montré, les données devraient être automatiquement restaurées via Google Backup dans les conditions expliquées (doit avoir été sauvegardé avec lui, même compte, etc.)
  • Sauvegarde d'autres fichiers
    → pardonnez-moi de ne pas citer le contenu (technique) de ce chapitre, mais en bref : seuls les fichiers du stockage interne peuvent être sauvegardés selon cela.

Quelques éléments extraits de l'API bmgr

  • Il fournit des commandes pour induire des opérations de sauvegarde et de restauration [...]
    → il semble qu'il y ait un moyen de déclencher manuellement des actions si l'automatisme échoue
  • Ces commandes sont accessibles via le shell adb.
    → cela ne nécessite aucune explication :)
  • adb shell bmgr backup
    → OK, donc cette action est liée aux applications. Si vous connaissez le nom du package du fournisseur de données, cela devrait fonctionner également (par exemple com.android.providers.settings pour les paramètres système, ou com.android.providers.telephony pour les SMS/MMS etc ?)
  • vous pouvez forcer l'exécution immédiate de toutes les opérations de sauvegarde en attente en utilisant la commande bmgr run
    → la première commande planifie simplement les sauvegardes. Après avoir déclenché tous les packages, cela peut être utilisé pour les exécuter immédiatement.
  • adb shell bmgr restore
    → cela semble trop beau pour être vrai, n'est-ce pas ? Exactement, car : Le Gestionnaire de sauvegarde instanciera immédiatement l'agent de sauvegarde de l'application et l'invoquera pour la restauration. Seulement les données, car l'application doit déjà être présente (car ses routines sont appelées).

En résumé : bmgr peut être utilisé pour déclencher des sauvegardes pour les applications prenant en charge la sauvegarde Google, que vous avez installées -- et il peut déclencher la restauration des données pour les mêmes. Il ne peut pas être utilisé pour déclencher une restauration complète -- du moins, cela n'est pas documenté ici.

Répondu el 29 de Mars, 2013 par Milner (533 Points )

0 votes

Avatar de Soundfx4

Je sais que c'est ancien, et quelqu'un pourrait m'attaquer pour avoir commenté une question aussi ancienne, mais c'est le résultat le plus pertinent que j'ai pu trouver, peu importe à quel point j'ai googlé. Je viens d'acheter un nouveau téléphone et quand le processus de configuration du périphérique commence, il ne montre PAS mon ancien Nexus 5x comme périphérique à restaurer, et je SAIS que la sauvegarde et la restauration étaient activées sur le 5x. Le 5x est complètement mort donc je ne peux rien faire dessus pour aider. Et en faisant bmgr list sets, il montre exactement le mauvais appareil qu'il a montré pendant la configuration... tout conseil sera grandement apprécié.

Commenté el 7 de Août, 2017 par Soundfx4

1 votes

Avatar de Milner

@Soundfx4 Puis-je vous suggérer de poser une question distincte et dédiée ? N'hésitez pas à mettre un lien ici pour référence. De toute façon, je ne pourrai pas vous aider avec ce problème spécifique car je n'utilise pas Google Backup.

Commenté el 7 de Août, 2017 par Milner

1 votes

Avatar de Soundfx4

C'est une bien meilleure idée, merci. Internet ne peut jamais avoir assez d'informations utiles! Je taperai un message quand j'aurai un peu de temps. Merci pour la réponse!

Commenté el 9 de Août, 2017 par Soundfx4

6voto

lapis avatar
lapis Points 169

Quelques informations supplémentaires sur la sauvegarde de Google. Lorsque j'ai flashé un firmware personnalisé, cela n'a pas restauré les applications comme je m'y attendais. Dans Paramètres -> Sauvegarde et réinitialisation, il affichait "Sauvegarde dans le cache privé de débogage uniquement", et bmgr list sets ne donnait aucun résultat.
J'ai résolu mon problème en suivant ces étapes dans adb shell:
$ bmgr transport com.google.android.backup/.BackupTransportService
$ bmgr list sets 3a0a00a516a1daf1 : LT22i
Cela n'était cependant pas suffisant. Il n'a pas commencé à installer les applications. Cela a montré la raison pour laquelle :
$ bmgr list sets 3179e4ab08d74930 : LT22i 3a0a00a516a1daf1 : LT22i
Il avait créé un nouvel ensemble, bien que l'IMEI soit évidemment le même. Quoi qu'il en soit, voici la solution :
$ bmgr restore 3a0a00a516a1daf1 (l'ID qu'il a montré la première fois)
$ bmgr run (pour être sûr)
Ensuite, il a commencé à télécharger les applications.

Répondu el 16 de Novembre, 2014 par lapis (169 Points )

3voto

lindelof avatar
lindelof Points 9802

Mon expérience avec cela a été que chaque appareil a sa propre sauvegarde. Je le sais en expérimentant avec mon Nexus 7 et mon Galaxy S II. Mis à part cela, je ne sais pas.

Applications :

Mon Nexus 7 a ces applications Caustic, DC Comics et 20 Minute Meals qui, après la réinitialisation d'usine de mon Galaxy S II, ne sont pas installées sur le Galaxy S II.

Mon Galaxy S II a ces applications DriveDroid et Human Japanese qui, après la réinitialisation d'usine de mon Nexus 7, ne sont pas installées sur le Nexus 7.

Les applications sont compatibles avec les deux appareils, donc l'incompatibilité ne peut pas être la raison pour lesquelles elles ne sont pas installées sur l'autre appareil respectif.

Données :

Quant au Wifi et aux autres données, je ne suis pas sûr, car chaque fois j'ai configuré le Wifi sur chaque appareil lors de la configuration initiale d'Android. En ce qui concerne les autres comptes Google que vous pourriez avoir, ils ne semblent pas être copiés sur chaque appareil et il en va de même pour les comptes Skype et GitHub sur chaque appareil.

Répondu el 26 de Mars, 2013 par lindelof (9802 Points )

1 votes

Avatar de lindelof

Seules les applications qui ont été installées sur cet appareil sont réinstallées à partir de la sauvegarde. Par exemple, l'application DriveDroid est installée sur mon téléphone et ne se télécharge pas sur le Nexus 7 après une réinitialisation aux paramètres d'usine. J'ai Caustic sur le Nexus 7 qui ne se télécharge pas sur le Galaxy S II parmi d'autres applications.

Commenté el 26 de Mars, 2013 par lindelof

0 votes

Avatar de Milner

Merci -- j'ai intégré cela avec la réponse. Comme il y a des rapports assez controversés : seriez-vous si aimable de mettre à jour votre réponse avec les versions Android des appareils utilisés ? Merci d'avance ! Pour ne pas encombrer notre conversation, je vais également supprimer certains de mes commentaires (n'hésitez pas à faire de même pour ceux déjà intégrés dans la réponse elle-même).

Commenté el 26 de Mars, 2013 par Milner

0 votes

Avatar de Milner

Alors vient maintenant l'affaire : si rien n'est croisé-restauré, que faire si l'un des appareils "casse" (ou si vous voulez remplacer les deux par un nouvel appareil) et que vous voulez "fusionner" ? Je suppose que je ne suis pas le seul à vraiment regretter un bon manuel...

Commenté el 29 de Mars, 2013 par Milner

1voto

kaepora avatar
kaepora Points 11

J'ai sauvegardé des données en utilisant à la fois la sauvegarde Google intégrée et la sauvegarde Helium avant d'effacer et d'installer la ROM personnalisée Carbon sur un Nexus 4 (à partir de KitKat stock). J'attendais de Google qu'il restaure les applications, les paramètres, etc. comme il l'a fait auparavant lorsque j'ai restauré ce téléphone mais sans succès.

J'ai également essayé Helium, mais sans succès, même avec les restaurations manuelles 'PC Download' - il indiquait 'restauré', mais le Wifi et les données des applications n'étaient toujours pas là.

En exécutant bmgr restore pour une restauration complète et bmgr run comme détaillé ci-dessus, j'ai déclenché une restauration complète de Google et cela a parfaitement fonctionné - un sauveur pour moi!

Google pourrait faire un meilleur effort, surtout s'ils veulent rivaliser avec l'idée d'Apple selon laquelle les choses 'fonctionnent simplement'... Malgré ses inconvénients, j'adore la capacité de piratage d'Android!

Répondu el 12 de Mars, 2014 par kaepora (11 Points )

Questions connexes

Questions en vedette

Top Tags

Dans notre réseau

androidalle.com

AndroidAlle est une communauté de androiders où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X