Nie jest niczym nowym, że można używać wielu urządzeń z Androidem za pomocą jednego konta Google . Po włączeniu nowego urządzenia po raz pierwszy pojawia się pytanie, czy chce się przechowywać dane w Google, który wtedy zawsze synchronizuje „niektóre rzeczy” z serwerami Google, w zasadzie

• niektóre dane aplikacji (jeśli aplikacje obsługują je jawnie)
• Hasła Wi-Fi
• zakładki przeglądarki
• lista aplikacji zainstalowanych z Google Play
• słowa dodane do słownika używanego przez klawiaturę ekranową
• większość spersonalizowanych ustawień

Szczegóły można znaleźć w Panelu Google . Odpowiednie pytania dotyczące tych zagadnień obejmują:

• Jakie informacje tworzy kopia zapasowa Google?
• Co dokładnie jest synchronizowane z Google?
• W jaki sposób Android synchronizuje profile WiFi?

Deweloperzy API Google kopii zapasowej daje pewne dalsze wgląd w jaki sposób rzeczy zapasowa ma pracować (i kilka pytań tutaj pokazać, jak to naprawdę działa - to znaczy, czasami tak, czasami tylko częściowo, a czasem wcale). Oprócz niezawodności i faktu, że nie każdy chce, aby jego prywatne dane były w chmurze (a nawet wspomniane odniesienie API ² ostrzega: Android nie daje żadnych gwarancji bezpieczeństwa danych podczas korzystania z kopii zapasowej. Zawsze należy zachować ostrożność przy korzystaniu z kopii zapasowej do przechowywania poufnych danych dane, takie jak nazwy użytkowników i hasła. ), moje główne pytanie brzmi:

Po utworzeniu kopii zapasowej danych z wielu urządzeń przy użyciu tego samego konta:

• co by się stało z wcześniej używanym w ten sposób urządzeniem przywracającym ustawienia fabryczne? Czy zostanie to rozpoznane i czy przywrócone zostaną tylko te rzeczy, które były wcześniej na nim używane?
  ^{(identyfikacja urządzenia może np. odbywać się np. przez IMEI (ale nie przez Android_ID, ponieważ może to zostać usunięte po przywróceniu ustawień fabrycznych ) - i może to być przyczyną zachowania opisanego w odpowiedzi Nalum )}
• co zostanie przywrócone na (nowym / przywróconym do ustawień fabrycznych) urządzeniu, które właśnie zainicjowałeś za pomocą tego konta Google?
  ^{(jeśli urządzenia zostaną zidentyfikowane za pomocą kopii zapasowych na używanym koncie Google, może to wywołać specjalną akcję dla „nowego urządzenia”, np. „przywróć wszystko, urządzenie zmienione!” - lub „przywróć wszystko z nie podłączonego urządzenia X, ponieważ prawdopodobnie został wymieniony! ”- ale trzymaj się, aby„ przywrócić tylko to, co było na tym urządzeniu ”w przypadku przywrócenia ustawień fabrycznych)}

Umowa jest taka: jeśli jeden ma wiele urządzeń, są one często używane do określonych problemów, więc nie chce się wszystkiego na wszystkich urządzeniach. Ponieważ nie widziałem sposobu, aby wybrać dane do utworzenia kopii zapasowej (np. Aby wykluczyć te „wrażliwe dane”, o których nas ostrzegano: hasła WiFi należałyby do tej kategorii), zakładam, że nie ma też możliwości przywrócenia? Jak więc się tym zajmuje?

Porozmawiajmy o zestawach, kochanie

Usługa tworzenia kopii zapasowych w Androidzie ma koncepcję zwaną zestawem : zestawem wszystkich danych, których kopie zapasowe wykonano z jednego urządzenia (na jednym transporcie , ale to szczegół). Każdy zestaw jest identyfikowany unikalnym ciągiem, takim jak IMEI na urządzeniu. Podczas tworzenia kopii zapasowej aplikacji (lub listy zainstalowanych aplikacji) jej dane kopii zapasowej trafiają do zestawu powiązanego z urządzeniem, z którego jest tworzona kopia zapasowa. Wszystkie zestawy są nadal specyficzne dla konta Google użytkownika. Jeśli wyczyścisz urządzenie i sprzedasz je komuś innemu, nie będzie on mógł uzyskać dostępu do zestawu tego urządzenia, chyba że będzie mógł zalogować się na Twoje konto Google.

Domyślne zachowanie

Gdy aplikacja jest zainstalowana lub urządzenie ma przywróconą listę aplikacji, system kopii zapasowych najpierw szuka w zestawie tego urządzenia danych kopii zapasowej dla tego pakietu. Jeśli nie znajdzie żadnego (albo dlatego, że jest to całkowicie nowe urządzenie bez kopii zapasowej danych, albo ponieważ pakiet ten nigdy nie został zainstalowany na tym urządzeniu), rozszerzy wyszukiwanie do innych zestawów. (Jeśli istnieje wybór, użyje ostatniego zestawu, który został użyty do przywrócenia pełnego urządzenia).

Tak więc, kiedy skonfigurujesz nowe urządzenie, przywróci ono listę aplikacji z kopii zapasowej starego urządzenia i przywróci każdą aplikację z kopii zapasowej starego urządzenia. Jeśli aplikacja została zainstalowana na jednym urządzeniu i zainstalujesz ją na innym urządzeniu, aplikacja zostanie przywrócona z danymi ze starego urządzenia. W obu przypadkach dane są teraz archiwizowane w zestawie nowego urządzenia, co oznacza, że ​​dane kopii zapasowej z dwóch urządzeń są odtąd odrębne.

Po przywróceniu ustawień fabrycznych urządzenie przywróci go z ostatniej kopii zapasowej tego urządzenia, jeśli taka istnieje, a jeśli to nie nastąpi, z kopii zapasowej innego urządzenia, jeśli istnieje, ale od tej chwili zacznie tworzyć własny zestaw. Właśnie dlatego dwa urządzenia Nalum nie widzą nawzajem swoich kopii zapasowych: każde z nich przywraca z własnych ostatnich kopii zapasowych.

Źródło

Ten mechanizm nie ma żadnej dokumentacji skierowanej do użytkownika, ponieważ ma on automatycznie robić właściwe rzeczy, ale kod jest dostępny .

bmgr: podstawowe zastosowanie

Jak odkrył Izzy, bmgrnarzędzie daje ci pewną kontrolę nad tym procesem. Ma to na celu pomóc programistom w testowaniu i debugowaniu integracji tworzenia kopii zapasowych w ich aplikacjach. Możesz użyć tego narzędzia adb shelldo wyzwalania kopii zapasowych i przywracania wybranych pakietów, czyszczenia danych z kopii zapasowej pakietów, a nawet przywracania całego urządzenia.

Nie próbuj używać go w powłoce na urządzeniu, z wyjątkiem rootowania : potrzebujesz poziomu systemu, android.permission.BACKUPaby zrobić z nim coś interesującego.

Możesz natychmiast zaktualizować kopię zapasową danych aplikacji:

bmgr backup com.shadowburst.showr
bmgr run

(lub jakakolwiek jest nazwa pakietu aplikacji). Zwykle nie ma takiej potrzeby, ponieważ aplikacje żądają własnych kopii zapasowych przy każdej zmianie danych, ale pozwala to obejść źle napisaną aplikację. Aby przywrócić jeden pakiet z danych z kopii zapasowej, domyślnie wybrałby:

bmgr restore com.shadowburst.showr

ale znowu zrobi to tylko to, co urządzenie zrobi samo, więc nie powinieneś go używać. Należy również pamiętać, że urządzenie musi już zostać zainstalowane, aby działało.

Większa kontrola

Teraz rzeczy, których system kopii zapasowych nie będzie w stanie wykonać. Aby zobaczyć, jakie zestawy danych z kopii zapasowej są dostępne:

bmgr list sets

a otrzymasz trochę takich wyników:

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

64-bitowa liczba szesnastkowa po lewej to token . Będziesz tego potrzebował za minutę. Rzecz po prawej to (względnie) przyjazna nazwa urządzenia, które jest właścicielem zestawu. Na przykład manta to nazwa kodowa nexusa-10 ; TF-101 odnosi się do oryginalnego transformatora pad-eee-eee-pad . Po ustaleniu, który zestaw chcesz, możesz przywrócić aplikację z tego zestawu, używając jego tokena:

bmgr restore 3ff7800e963f25c5 com.shadowburst.showr

Możesz dodać więcej nazw pakietów na końcu polecenia, aby przywrócić kilka pakietów na raz, lub możesz podać żadną nazwę pakietu (tylko token), aby przywrócić każdą aplikację z danymi w tym zestawie (to znaczy, że działa w pełnym systemie przywracać).

Na koniec możesz usunąć dane aplikacji z bieżącego zestawu:

bmgr wipe com.shadowburst.showr

Spowoduje to, że kolejna operacja tworzenia kopii zapasowej rozpocznie się od zera. Może to być przydatne po odinstalowaniu aplikacji, jeśli błąd w aplikacji uszkodził jej dane kopii zapasowej i nie chcesz, aby została przywrócona.

Nie możesz zmusić urządzenia do pisania w innym zestawie, ani nie możesz wyczyścić całego zestawu.

Poniższa odpowiedź nie jest zdecydowanie odpowiedzią na pytanie, ale może rzucić nieco światła na niektóre szczegóły:

Niektóre elementy wyodrębnione z Backup API

Chociaż interfejs API jest skierowany głównie do programistów, istnieje kilka faktów, które moglibyśmy wyciągnąć dla naszej sprawy. Na poniższej liście kursywą zaznaczono cudzysłowy z dokumentacji interfejsu API.

• Android automatycznie wykonuje operację przywracania, gdy aplikacja jest zainstalowana i istnieją dane kopii zapasowej powiązane z użytkownikiem.
  → może to oznaczać dwie rzeczy:
  • jeśli aplikacja obsługuje interfejs Google Backup API, a użytkownik ma włączoną funkcję Google Backup, dostępne dane kopii zapasowej zostaną automatycznie przywrócone podczas instalacji. Dobrze, gdy po raz pierwszy instalujesz aplikację używaną na jednym urządzeniu na drugim urządzeniu.
  • kopie zapasowe są powiązane tylko z kontem Google, a nie z urządzeniem ( i istnieją dane kopii zapasowej powiązane z użytkownikiem ) - lub inny fakt został po prostu zignorowany jako nieistotny w tym specjalnym przypadku („aplikacja jest zainstalowana”)
• Transport kopii zapasowych jest składnikiem systemu kopii zapasowych systemu Android po stronie klienta, który może być dostosowywany przez producenta urządzenia i usługodawcę. Transport kopii zapasowej może się różnić w zależności od urządzenia [...]
  → może to tłumaczyć zawodność różnych urządzeń (lub różnych wersji Androida).
  ^{(moje podkreślenie)}
• Kopia zapasowa danych nie jest gwarantowana na wszystkich urządzeniach z Androidem.
  (bez komentarza)
• Google zapewnia transport kopii zapasowej za pomocą usługi Android Backup Service dla większości urządzeń z Androidem 2.2 lub nowszych.
  → tutaj dostępna jest minimalna wersja Androida wymagana do Google Backup w ogóle: Froyo, AKA Android 2.2
• Aby uzyskać klucz usługi kopii zapasowej, zarejestruj się w usłudze Android Backup. [...]
  → każda aplikacja musi mieć własny klucz. Nie opisano „dlaczego”, ale należy zgadywać: aby wyizolować kopie zapasowe, aby żadna aplikacja nie mogła odczytać kopii innej aplikacji (zły klucz; jak w przypadku kopii zapasowych innego użytkownika: złe konto)
• Podczas opracowywania aplikacji możesz zainicjować natychmiastową operację tworzenia kopii zapasowej za pomocą narzędzia Backup Manager za pomocą narzędzia bmgr.
  → wygląda na to, że istnieje sposób ręcznego uruchamiania kopii zapasowych? Zajmijmy się tym później. ↓
• Kiedy nadszedł czas na przywrócenie danych aplikacji, Menedżer kopii zapasowej wywołuje onRestore()metodę agenta kopii zapasowej .
  → to ponownie podkreśla pierwszy element tej listy: najpierw aplikacja musi zostać zainstalowana, a następnie do przywrócenia danych wykorzystywane są jej własne implementacje. Po drugie: jeśli przywracanie aplikacji nie powiedzie się, nie będzie przywracania danych dla nieudanych aplikacji - dopóki nie zainstalujesz ich ręcznie za pośrednictwem Google Play. Następnie, jak pokazał pierwszy element, dane powinny zostać automatycznie przywrócone za pomocą Google Backup w objaśnionych warunkach (należy wykonać kopię zapasową przy użyciu tego samego konta itp.)
• Tworzenie kopii zapasowych innych plików
  → wybacz mi nie cytowanie z (technicznej) zawartości tego rozdziału, ale w skrócie: zgodnie z nim można tworzyć kopie zapasowe tylko plików z pamięci wewnętrznej.

Niektóre elementy wyodrębnione z bmgr API

• Udostępnia polecenia wywoływania operacji tworzenia kopii zapasowych i przywracania [...]
  → wygląda na to, że tutaj jest sposób ręcznego wyzwalania akcji w przypadku awarii „automatyzmu”
• Te polecenia są dostępne za pośrednictwem powłoki adb.
  → to nie wymaga żadnego wyjaśnienia :)
• adb shell bmgr backup <package>
  → OK, więc ta czynność jest powiązana z aplikacjami. Zgadnij, jeśli znasz nazwę pakietu dostawcy danych, to również powinno działać (np. W com.android.providers.settingsprzypadku ustawień systemowych lub com.android.providers.telephonySMS / MMS itp.)
• możesz zmusić wszystkie oczekujące operacje tworzenia kopii zapasowych do natychmiastowego uruchomienia za pomocą bmgr runpolecenia
  → pierwsze polecenie po prostu „planuje” tworzenie kopii zapasowych. Po uruchomieniu wszystkich pakietów można tego użyć do ich natychmiastowego wykonania.
• adb shell bmgr restore <package>
  → to wygląda na fajne, prawda? Dokładnie, ponieważ: Menedżer kopii zapasowych natychmiast utworzy kopię zapasową agenta kopii zapasowej aplikacji i wywoła go w celu przywrócenia. Tylko dane, ponieważ aplikacja musi już tam być (jak nazywają się jej procedury).

Krótko mówiąc: bmgrmoże służyć do wyzwalania kopii zapasowych aplikacji obsługujących Google Backup, które masz zainstalowane - i może przywracać dane w tym samym celu. Nie można go użyć do uruchomienia pełnego przywracania - przynajmniej nie jest to tutaj udokumentowane.

Więcej informacji na temat kopii zapasowej Google. Kiedy sflashowałem niestandardowe oprogramowanie, nie przywróciło aplikacji zgodnie z oczekiwaniami. W Ustawieniach -> Kopia zapasowa i resetowanie pokazywał „Tworzenie kopii zapasowej w prywatnej pamięci podręcznej tylko do debugowania” i bmgr list setsnie dawał żadnych wyników.
Rozwiązałem swój problem, wykonując następujące kroki adb shell:
$ bmgr transport com.google.android.backup/.BackupTransportService
$ bmgr list sets 3a0a00a516a1daf1 : LT22i
To jednak nie wystarczyło. Nie rozpoczęło się instalowanie aplikacji. To pokazało powód:
$ bmgr list sets 3179e4ab08d74930 : LT22i 3a0a00a516a1daf1 : LT22i
Stworzył nowy zestaw, chociaż IMEI oczywiście był taki sam. Tak czy
$ bmgr restore 3a0a00a516a1daf1inaczej , to była poprawka: (identyfikator, który pokazał za pierwszym razem)
$ bmgr run(dla pewności)
Potem zaczął pobierać aplikacje.

Z moich doświadczeń wynika, że ​​każde urządzenie ma własną kopię zapasową. Czerpię to z bałaganu z moim Nexusem 7 i Galaxy S II. Poza tym nie wiem.

Aplikacje:

Mój Nexus 7 ma te aplikacje Caustic , DC Comics i 20 Minute Meals, które po przywróceniu ustawień fabrycznych mojego Galaxy S II nie są instalowane na Galaxy S II.

My Galaxy S II ma te aplikacje DriveDroid i Human Japanese, które po przywróceniu ustawień fabrycznych mojego Nexusa 7 nie są instalowane na Nexusie 7.

Aplikacje są kompatybilne z obydwoma urządzeniami, więc niekompatybilność nie może być przyczyną, dla której nie zostaną zainstalowane na odpowiednim innym urządzeniu.

Dane:

Jeśli chodzi o Wi-Fi i inne dane, nie jestem pewien, ponieważ za każdym razem konfiguruję Wi-Fi na każdym urządzeniu podczas początkowej konfiguracji Androida. Jeśli chodzi o inne konta Google, które możesz mieć, wydaje się, że nie są one kopiowane na każde urządzenie i to samo dotyczy kont Skype i GitHub na każdym urządzeniu.

Utworzyłem kopie zapasowe przy użyciu zarówno wbudowanej kopii zapasowej Google, jak i kopii zapasowej Helu, zanim wyczyściłem i zainstalowałem niestandardową pamięć ROM Carbon na Nexusie 4 (z zasobów KitKat). Oczekiwałem, że Google przywróci aplikacje, ustawienia itp., Tak jak miało to miejsce wcześniej, gdy przywróciłem ten telefon, ale nie mam radości.

Próbowałem również helu, również bez radości, nawet przy ręcznym przywracaniu „PC Download” - powiedział „przywrócono”, ale danych Wi-Fi i aplikacji nadal nie ma.

Uruchomienie bmgr restore <xxx>pełnego przywracania i bmgr runzgodnie z powyższym opisem uruchomiło pełne przywracanie Google i działało dla mnie jako ratownik!

Google może podjąć większy wysiłek, zwłaszcza jeśli chce konkurować z pomysłem Apple „po prostu działa” ... Mimo to uwielbiam hackowalność Androida pomimo jego pułapek!