Tworzenie kopii zapasowej danych użytkowników przy użyciu Automatycznej kopii zapasowej

Automatyczna kopia zapasowa aplikacji automatycznie tworzy kopie zapasowe danych użytkownika z aplikacji, i działać na Androidzie 6.0 (poziom interfejsu API 23) lub nowszym. Android zachowuje dane aplikacji, przesyłając je na Dysk Google użytkownika, gdzie są chronione przez jego dane logowania do konta Google. Kopia zapasowa jest w pełni szyfrowana na urządzeniach z Androidem 9 lub nowszym przy użyciu kodu PIN, wzoru lub hasła urządzenia. Każda aplikacja może przydzielić do 25 MB danych kopii zapasowej na użytkownika. Przechowywanie danych kopii zapasowej nie wiąże się z żadnymi opłatami. Aplikacja może dostosować proces tworzenia kopii zapasowej lub zrezygnować z niego, wyłączając tworzenie kopii zapasowych.

Omówienie opcji tworzenia kopii zapasowych w Androidzie i wskazówki dotyczące tego, które dane tworzenia i przywracania kopii zapasowych znajdziesz w omówieniu tworzenia kopii zapasowych danych.

Pliki z kopią zapasową

Domyślnie Automatyczna kopia zapasowa uwzględnia pliki z większości katalogów, przypisane do aplikacji przez system:

Automatyczna kopia zapasowa wyklucza pliki w katalogach zwróconych przez getCacheDir(), getCodeCacheDir() i getNoBackupFilesDir(). Pliki zapisane w tych lokalizacjach są potrzebne tylko tymczasowo i są celowo wykluczone z operacji tworzenia kopii zapasowych.

Możesz skonfigurować aplikację tak, aby uwzględniała lub wykluczała określone pliki. Więcej informacje można znaleźć w sekcji Uwzględnianie i wykluczanie plików.

Lokalizacja kopii zapasowej

Dane kopii zapasowej są przechowywane w prywatnym folderze na koncie Dysku Google użytkownika. rozmiar jest ograniczony do 25 MB na aplikację. Zapisane dane nie wliczają się do limitu limitu osobistego miejsca na Dysku Google. Przechowywana jest tylko najnowsza kopia zapasowa. Gdy zostanie utworzona kopia zapasowa, zostanie usunięta poprzednia kopia zapasowa. Danych kopii zapasowej nie można odczytać użytkownika lub innych aplikacji na urządzeniu.

Użytkownicy mogą zobaczyć listę aplikacji, których dane zostały zarchiwizowane w aplikacji Dysk Google na Androida. Na urządzeniu z Androidem mogą znaleźć tę listę w drawerze aplikacji Dysk w sekcji Ustawienia > Kopia zapasowa i resetowanie.

Kopie zapasowe z każdego okresu konfiguracji urządzenia są przechowywane w osobnych zbiorach danych, opisane w tych przykładach:

  • Jeśli użytkownik ma 2 urządzenia, dla każdego z nich istnieje kopia zapasowa zbioru danych.

  • Jeśli użytkownik przywróci urządzenie do ustawień fabrycznych, a następnie skonfiguruje na nim na tym samym koncie, kopia zapasowa zostanie zapisana w nowym zbiorze danych. Nieaktualne zbiory danych to są automatycznie usuwane po okresie braku aktywności.

.

Harmonogram tworzenia kopii zapasowej

Kopie zapasowe są tworzone automatycznie, gdy są spełnione wszystkie te warunki:

  • Użytkownik włączył kopię zapasową na urządzeniu. W Androidzie 9 to ustawienie znajduje się w sekcji Ustawienia > System > Kopia zapasowa.
  • od ostatniej kopii zapasowej upłynęło co najmniej 24 godziny.
  • Urządzenie jest nieaktywne.
  • Urządzenie jest połączone z siecią Wi-Fi (jeśli użytkownik nie zdecydował się na tworzenie kopii zapasowych za pomocą danych komórkowych).

W praktyce te warunki występują mniej więcej co noc, ale urządzenie może nigdy nie wykonać kopii zapasowej (na przykład, jeśli nigdy nie łączy się z siecią). Aby oszczędzać przepustowość sieci, przesyłanie odbywa się tylko wtedy, gdy dane aplikacji ulegną zmianie.

Podczas automatycznego tworzenia kopii zapasowej system zamyka aplikację, aby mieć pewność, że nie będzie ona już zapisywać w systemie plików. Domyślnie system kopii zapasowej ignoruje aplikacje, które działać na pierwszym planie, aby zadbać o wygodę użytkowników. Możesz zastąpić zachowanie domyślnego działania, ustawiając atrybut android:backupInForeground na true (prawda).

Aby uprościć testowanie, Android zawiera narzędzia, które umożliwiają ręczne utworzenie kopii zapasowej aplikacji. Więcej informacji znajdziesz w artykule Testowanie kopii zapasowej i jej przywracania.

Przywracanie harmonogramu

Dane są przywracane za każdym razem, gdy aplikacja jest instalowana ze Sklepu Play, podczas konfiguracji urządzenia (gdy system instaluje wcześniej zainstalowane aplikacje) lub przez uruchomienie adb. Operacja przywracania jest wykonywana po zainstalowaniu pliku APK, ale zanim użytkownik będzie mógł uruchomić aplikację.

W kreatorze wstępnej konfiguracji urządzenia użytkownik widzi listę dostępnych tworzenie kopii zapasowych zbiorów danych i pytanie, z którego mają zostać przywrócone dane. Wybrany zbiór danych kopii zapasowej stanie się zbiorem danych przodków na urządzeniu. Urządzenie może lub z własnych kopii zapasowych albo z nadrzędnego zbioru danych. Jeśli kopie zapasowe są tworzone z: gdy dostępne są oba źródła, urządzenie nadaje priorytet własnej kopii zapasowej. Jeśli użytkownik nie przeszedł przez kreatora konfiguracji urządzenia, urządzenie może przywrócić dane tylko z własnych kopii zapasowych.

Aby ułatwić testowanie, Android zawiera narzędzia, które umożliwiają ręczne inicjowanie przywracania aplikacji. Więcej informacji znajdziesz w artykule Testowanie kopii zapasowej i przywracania.

Włączanie i wyłączanie kopii zapasowej

Aplikacje kierowane na Androida 6.0 (poziom interfejsu API 23) lub nowszego automatycznie uczestniczą w programie w Automatycznej kopii zapasowej. W pliku manifestu aplikacji ustaw wartość logiczną android:allowBackup, aby włączyć lub wyłączyć tworzenie kopii zapasowej. Wartość domyślna to true, ale zalecamy jednoznaczne ustawienie tego atrybutu w pliku manifestu, w tym przykładzie:

<manifest ... >
    ...
    <application android:allowBackup="true" ... >
        ...
    </application>
</manifest>

Możesz wyłączyć tworzenie kopii zapasowych, ustawiając wartość android:allowBackup na false. Możesz chcą to zrobić, jeśli aplikacja może odtworzyć swój stan za pomocą innego mechanizmu. lub jeśli aplikacja ma dostęp do informacji poufnych.

Uwzględnianie i wykluczanie plików

Domyślnie system tworzy kopię zapasową niemal wszystkich danych aplikacji. Więcej informacji: sekcji poświęconej plikom, które mają kopie zapasowe.

Ta sekcja pokazuje, jak definiować niestandardowe reguły XML, aby kontrolować, jakie dane mają być obsługiwane w górę. Jeśli Twoja aplikacja jest kierowana na Androida 12 (API na poziomie 31) lub nowszego, musisz określić dodatkowy zestaw reguł XML kopii zapasowej zgodnie z opisem w tej sekcji, aby obsługiwać zmiany w przywracaniu kopii zapasowej wprowadzone na urządzeniach z tymi wersjami Androida.

Zarządzanie kopiami zapasowymi na Androidzie 11 i starszych

Aby określić, które pliki mają być kopiowane na urządzeniach z Androidem 11 (poziom interfejsu API 30) lub starszym, wykonaj czynności opisane w tej sekcji.

  1. W pliku AndroidManifest.xml dodaj atrybut android:fullBackupContent do elementu <application>, jak w tym przykładzie. Ten atrybut wskazuje plik XML zawierający reguły kopii zapasowej.

    <application ...
 android:fullBackupContent="@xml/backup_rules">
</application>

  2. Utwórz plik XML o nazwie @xml/backup_rules w w katalogu res/xml/. W tym pliku dodaj reguły z atrybutami <include> oraz <exclude> elementów. Ten przykładowy skrypt tworzy kopie zapasowe wszystkich udostępnionych ustawień z wyjątkiem device.xml:

    <?xml version="1.0" encoding="utf-8"?>
<full-backup-content>
 <include domain="sharedpref" path="."/>
 <exclude domain="sharedpref" path="device.xml"/>
</full-backup-content>

Definiowanie warunków wymaganych na urządzeniu do tworzenia kopii zapasowej

Jeśli aplikacja zapisuje na urządzeniu informacje poufne, możesz określić, warunki, w których dane aplikacji są uwzględniane w kopii zapasowej użytkownika. Dostępne opcje w Androidzie 9 (poziom interfejsu API 28) lub nowszym dodaj te warunki:

Jeśli urządzenia, na których tworzysz aplikacje zostały uaktualnione do Androida 9, musisz wyłączyć a następnie, po przejściu na nową wersję, ponownie włączyć tworzenie kopii zapasowej danych. Dzieje się tak, ponieważ Android szyfruje kopie zapasowe za pomocą tajnego klucza po stronie klienta dopiero po poinformowaniu użytkowników w ustawieniach lub w kreatorze konfiguracji.

Aby zadeklarować warunki uwzględniania, ustaw atrybut requireFlags na wybraną wartość lub wybrane wartości w elementach <include> w zestawie reguł zapasowych:

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>

Jeśli w aplikacji jest wdrożony system kopii zapasowej pary klucz-wartość lub zaimplementujesz BackupAgent, możesz również zastosować te wymagania warunkowe z logiką tworzenia kopii zapasowych, przeprowadzając bitowe porównanie Zbiór flag transportu i niestandardowej kopii zapasowej obiektu BackupDataOutput FLAG_CLIENT_SIDE_ENCRYPTION_ENABLED agenta lub FLAG_DEVICE_TO_DEVICE_TRANSFER.

Fragment kodu ilustruje przykład użycia tej metody:

Kotlin

class CustomBackupAgent : 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 CustomBackupAgent 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.
}

Zarządzanie kopią zapasową na Androidzie 12 lub nowszym

Jeśli Twoja aplikacja jest kierowana na Androida 12 (poziom interfejsu API 31) lub nowszego, wykonaj czynności opisane w artykule W tej sekcji możesz określić, które pliki są tworzone na podstawie kopii zapasowych na uruchomionych urządzeniach Androida 12 lub nowszego,

  1. W pliku AndroidManifest.xml dodaj Atrybut android:dataExtractionRules do elementu <application> Jak widać w przykładzie poniżej. Ten atrybut wskazuje kod XML który zawiera reguły tworzenia kopii zapasowych.

    <application ...
 android:dataExtractionRules="backup_rules.xml">
</application>

  2. Utwórz plik XML o nazwie backup_rules.xml w w katalogu res/xml/. W tym pliku dodaj reguły za pomocą elementów <include> i <exclude>. Poniższy przykład tworzy kopię zapasową wszystkich udostępnionych preferencji oprócz device.xml:

    <?xml version="1.0" encoding="utf-8"?>
<data-extraction-rules>
 <cloud-backup [disableIfNoEncryptionCapabilities="true|false"]>
   <include domain="sharedpref" path="."/>
   <exclude domain="sharedpref" path="device.xml"/>
 </cloud-backup>
</data-extraction-rules>

Składnia konfiguracji XML

Składnia XML pliku konfiguracyjnego różni się w zależności od wersji Androida, na którą jest kierowana i na której działa Twoja aplikacja.

Android 11 lub starszy

Użyj tej składni XML w pliku konfiguracji, który steruje kopią zapasową na urządzeniach z Androidem 11 lub starszym.

<full-backup-content>
    <include domain=["file" | "database" | "sharedpref" | "external" |
                     "root" | "device_file" | "device_database" |
                     "device_sharedpref" | "device_root" ] path="string"
    requireFlags=["clientSideEncryption" | "deviceToDeviceTransfer"] />
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                     "root" | "device_file" | "device_database" |
                     "device_sharedpref" | "device_root" ] path="string" />
</full-backup-content>

Android 12 lub nowszy.

Jeśli Twoja aplikacja jest kierowana na Androida 12 (poziom interfejsu API 31) lub nowszego, użyj tego kodu XML składni pliku konfiguracji, która steruje tworzeniem kopii zapasowych urządzeń z Androida w wersji 12 lub nowszej.

<data-extraction-rules>
  <cloud-backup [disableIfNoEncryptionCapabilities="true|false"]>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                     "root" | "device_file" | "device_database" |
                     "device_sharedpref" | "device_root" ] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                     "root" | "device_file" | "device_database" |
                     "device_sharedpref" | "device_root" ] path="string"/>
    ...
  </cloud-backup>
  <device-transfer>
    ...
    <include domain=["file" | "database" | "sharedpref" | "external" |
                     "root" | "device_file" | "device_database" |
                     "device_sharedpref" | "device_root" ] path="string"/>
    ...
    <exclude domain=["file" | "database" | "sharedpref" | "external" |
                     "root" | "device_file" | "device_database" |
                     "device_sharedpref" | "device_root" ] path="string"/>
    ...
  </device-transfer>
</data-extraction-rules>

Każda sekcja konfiguracji (<cloud-backup>, <device-transfer>) zawiera reguły, które dotyczą tylko tego typu przenoszenia. Taki podział pozwala na przykład wykluczyć plik lub katalog z kopii zapasowych na Dysku Google, i nadal przesyłam go podczas przenoszenia między urządzeniami (D2D). Jest to przydatne, jeśli masz pliki, które są zbyt duże, aby tworzyć ich kopie zapasowe w chmurze, ale można je bez problemu przenosić między urządzeniami.

Jeśli nie ma żadnych reguł dotyczących danego trybu tworzenia kopii zapasowej, np. brakuje sekcji <device-transfer>, ten tryb jest w pełni włączony dla wszystkich treści z wyjątkiem katalogów no-backup i cache, zgodnie z opisem w sekcji Pliki, których kopie zapasowe są tworzone.

Aplikacja może ustawić flagę disableIfNoEncryptionCapabilities w sekcji <cloud-backup>, aby kopia zapasowa była tworzona tylko wtedy, gdy można ją zaszyfrować, np. gdy użytkownik ma ekran blokady. Ustawienie tego ograniczenia Zatrzymuje wysyłanie kopii zapasowych do chmury, jeśli urządzenie użytkownika nie obsługuje jest szyfrowany, ale ponieważ transfery D2D nie są wysyłane do serwera, aby działać nawet na urządzeniach, które nie obsługują szyfrowania.

Składnia elementów uwzględniających i wykluczonych

W tagach <full-backup-content>, <cloud-backup> i <device-transfer> (w zależności od wersji Androida na urządzeniu i wersji aplikacji targetSDKVersion) możesz zdefiniować elementy <include> i <exclude>:

<include>

Określa plik lub folder, którego kopię zapasową chcesz utworzyć. Domyślnie automatyczne tworzenie kopii zapasowych obejmuje prawie wszystkie pliki aplikacji. Jeśli podasz element <include>, system nie będzie już domyślnie uwzględniać żadnych plików i będzie tworzyć kopie zapasowe tylko podanych plików. Aby uwzględnić kilka plików, użyj wielu elementów <include>.

Na Androidzie 11 i starszych ten element może też zawierać atrybut requireFlags, który jest bardziej szczegółowo omówiony w sekcji dotyczącej definiowania wymagań warunkowych dotyczących kopii zapasowej.

Pliki w katalogach zwracanych przez polecenie getCacheDir(), getCodeCacheDir() lub getNoBackupFilesDir() są zawsze wykluczane, nawet jeśli spróbujesz je uwzględnić.

<exclude>

Określa plik lub folder, który ma zostać wykluczony podczas tworzenia kopii zapasowej. Oto kilka pliki, które zwykle są wykluczone z kopii zapasowej:

  • Pliki z identyfikatorami specyficznymi dla urządzenia, które zostały wydane przez serwer lub wygenerowane na urządzeniu. Na przykład Komunikacja w chmurze Firebase (FCM) musi generować token rejestracji za każdym razem, gdy użytkownik instaluje Twoją aplikację na nowym urządzeniu. Jeśli przywrócisz stary token rejestracji, aplikacja może działać w nieoczekiwany sposób.

  • pliki związane z debugowaniem aplikacji.

  • duże pliki, które powodują przekroczenie przez aplikację limitu 25 MB na kopię zapasową;

.

Każdy element <include> i <exclude> musi zawierać te 2 atrybuty:

domain

Określa lokalizację zasobu. Prawidłowe wartości tego atrybutu to:

  • root: katalog w systemie plików, w którym znajdują się wszystkie prywatne pliki należące do tej aplikacji.
  • file: katalogi zwrócone przez getFilesDir().
  • database: katalogi zwrócone przez getDatabasePath(). Bazy danych utworzone za pomocą funkcji SQLiteOpenHelper są przechowywane tutaj.
  • sharedpref: katalog, w którym znajduje się SharedPreferences.
  • external: katalog zwrócony przez funkcję getExternalFilesDir().
  • device_root: jak root, ale dla pamięci chronionej przez urządzenie.
  • device_file: podobnie jak file, ale dotyczy pamięci chronionej na urządzeniu.
  • device_database: podobnie jak database, ale dotyczy pamięci chronionej na urządzeniu.
  • device_sharedpref: podobnie jak sharedpref, ale dotyczy pamięci chronionej przez urządzenie.
path

Wskazuje plik lub folder, który ma zostać uwzględniony w kopii zapasowej lub z niej wykluczony. Pamiętaj:

  • Ten atrybut nie obsługuje składni symboli wieloznacznych ani wyrażeń regularnych.
  • Możesz odwoływać się do bieżącego katalogu za pomocą ./, ale ze względów bezpieczeństwa nie możesz odwoływać się do katalogu nadrzędnego, na przykład za pomocą ...
  • Jeśli określisz katalog, reguła będzie obowiązywać w przypadku wszystkich plików w tym katalogu i w podkatalogach.

Implementacja BackupAgent

W aplikacjach, które mają włączoną Automatyczną kopię zapasową, nie trzeba stosować BackupAgent. Możesz jednak zaimplementować niestandardowy BackupAgent. Zazwyczaj są dwa powody, dla których warto to zrobić:

  • Chcesz otrzymywać powiadomienia o zdarzeniach związanych z kopią zapasową, takich jak onRestoreFinished() i onQuotaExceeded(long, long). Te metody wywołania są wykonywane nawet wtedy, gdy aplikacja jest wyłączona.

  • Nie da się w prosty sposób wyrazić zestawu plików, których kopię zapasową chcesz utworzyć, za pomocą kodu XML reguł. W takich rzadkich przypadkach możesz zaimplementować BackupAgent, który zastąpi onFullBackup(FullBackupDataOutput), aby przechowywać to, co chcesz. Aby zachować do domyślnej implementacji systemu, wywołaj odpowiednią metodę na superklasa z funkcją super.onFullBackup().

Jeśli zaimplementujesz BackupAgent, system domyślnie oczekuje, że aplikacja wykonywania tworzenia i przywracania par klucz-wartość. Aby zamiast tego korzystać z automatycznej kopii zapasowej opartej na plikach, w pliku manifestu aplikacji ustaw atrybut android:fullBackupOnly na true.

Podczas automatycznego tworzenia kopii zapasowej i przywracania system uruchamia aplikację w trybie ograniczonym, aby uniemożliwić jej dostęp do plików, które mogą powodować konflikty, oraz umożliwić jej wykonywanie metod wywołania w sposób BackupAgent. W tym w trybie ograniczonego dostępu główne działania aplikacji nie są uruchamiane automatycznie, dostawcy treści nie zostaną zainicjowane, a klasa bazowa, Tworzona jest instancja Application zamiast dowolnej podklasy zadeklarowanej w manifest aplikacji.

BackupAgent musi implementować metody abstrakcyjne onBackup() i onRestore(), które są używane do tworzenia kopii zapasowych par klucz-wartość. Jeśli nie chcesz tworzyć kopii zapasowej par klucz-wartość, możesz pozostawić te metody puste.

Więcej informacji znajdziesz w artykule Przedłużanie agenta BackupAgent.