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, które są przeznaczone na Androida 6.0 (poziom interfejsu API 23) lub nowszego i na nim działają. Android zachowuje dane aplikacji, przesyłając je na Dysk Google użytkownika, gdzie są chronione przez dane logowania do konta Google użytkownika. Kopia zapasowa jest 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 jest bezpłatne. Aplikacja może dostosować proces tworzenia kopii zapasowej lub z niego zrezygnować, wyłączając kopie zapasowe.

Omówienie opcji tworzenia kopii zapasowej na urządzeniach z Androidem oraz wskazówki dotyczące tego, jakie dane warto przywracać, znajdziesz w tym artykule.

Pliki, których kopia zapasowa jest tworzona

Domyślnie funkcja automatycznego tworzenia kopii zapasowych obejmuje pliki w większości katalogów przypisanych do aplikacji przez system:

Automatyczna kopia zapasowa nie obejmuje plików w katalogach zwracanych 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 i wykluczała określone pliki. Więcej informacji znajdziesz w sekcji Uwzględnianie i wykluczanie plików.

Lokalizacja kopii zapasowej

Dane kopii zapasowej są przechowywane w prywatnym folderze na koncie Google Drive użytkownika. Limit wynosi 25 MB na aplikację. Zapisane dane nie wliczają się do limitu miejsca na osobistym Dysku Google użytkownika. Przechowywana jest tylko najnowsza kopia zapasowa. Podczas tworzenia kopii zapasowej poprzednia kopia zapasowa jest usuwana. Danych kopii zapasowej nie może odczytać użytkownik ani inne aplikacje na urządzeniu.

Użytkownicy mogą wyświetlić listę aplikacji, których kopie zapasowe zostały utworzone w aplikacji Google Drive na Androida. Na urządzeniu z Androidem listę tę można znaleźć w szufladzie nawigacyjnej aplikacji Dysk w sekcji Ustawienia > Kopia zapasowa i resetowanie.

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

  • Jeśli użytkownik ma 2 urządzenia, dla każdego z nich istnieje zbiór danych kopii zapasowej.

  • Jeśli użytkownik przywróci urządzenie do ustawień fabrycznych, a następnie skonfiguruje je przy użyciu tego samego konta, kopia zapasowa zostanie zapisana w nowym zbiorze danych. Przestarzałe zbiory danych są automatycznie usuwane po okresie nieaktywności.

Harmonogram tworzenia kopii zapasowej

Kopie zapasowe są tworzone automatycznie, gdy spełnione są 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 minęło co najmniej 24 godziny.
  • Urządzenie jest nieaktywne.
  • Urządzenie jest połączone z siecią Wi-Fi (jeśli użytkownik urządzenia nie włączył kopii zapasowych danych mobilnych).

W praktyce te warunki są spełniane mniej więcej każdej nocy, ale urządzenie może nigdy nie utworzyć kopii zapasowej (np. jeśli nigdy nie połączy się z siecią). Aby oszczędzać przepustowość sieci, przesyłanie odbywa się tylko wtedy, gdy dane aplikacji uległy zmianie.

Podczas automatycznego tworzenia kopii zapasowej system zamyka aplikację, aby upewnić się, że nie zapisuje ona już danych w systemie plików. Domyślnie system kopii zapasowych ignoruje aplikacje działające na pierwszym planie, aby uniknąć pogorszenia komfortu użytkowania. Domyślne działanie możesz zastąpić, ustawiając atrybut android:backupInForeground na wartość true.

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

Przywracanie harmonogramu

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

Podczas wstępnej konfiguracji urządzenia użytkownikowi wyświetlana jest lista dostępnych zbiorów danych kopii zapasowych i jest on pytany, z którego z nich chce przywrócić dane. Wybrany zbiór danych kopii zapasowej staje się zbiorem danych przodków urządzenia. Urządzenie może przywrócić dane z własnych kopii zapasowych lub z zestawu danych przodków. Jeśli dostępne są kopie zapasowe z obu źródeł, urządzenie traktuje priorytetowo własną kopię zapasową. Jeśli użytkownik nie skorzystał z kreatora konfiguracji urządzenia, może przywrócić dane tylko z kopii zapasowych utworzonych na tym urządzeniu.

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

Włączanie i wyłączanie kopii zapasowej

Aplikacje kierowane na Androida 6.0 (poziom interfejsu API 23) lub nowszego automatycznie biorą udział 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 jawne ustawienie atrybutu w pliku manifestu, jak pokazano w tym przykładzie:

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

Kopie zapasowe możesz wyłączyć, ustawiając wartość android:allowBackup na false. Może to być przydatne, jeśli aplikacja może odtworzyć swój stan za pomocą innego mechanizmu lub jeśli przetwarza informacje poufne.

Uwzględnianie i wykluczanie plików

Domyślnie system tworzy kopie zapasowe niemal wszystkich danych aplikacji. Więcej informacji znajdziesz w sekcji Pliki, których kopie zapasowe są tworzone.

Możesz określić, które dane mają być uwzględniane w kopii zapasowej, w zależności od typu przenoszenia. Automatyczna kopia zapasowa obsługuje tworzenie kopii zapasowych w chmurze na Dysku Google oraz bezpośrednie przesyłanie danych między urządzeniami (D2D). Metody konfiguracji różnią się w zależności od wersji Androida i targetSdkVersion aplikacji.

Kontrolowanie kopii zapasowej na Androidzie 11 i starszych wersjach

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

  1. W pliku AndroidManifest.xml dodaj atrybut android:fullBackupContent do elementu <application>, jak pokazano w tym przykładzie. Ten atrybut wskazuje plik XML, który zawiera reguły tworzenia kopii zapasowej.

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

  2. Utwórz plik XML o nazwie @xml/backup_rules w katalogu res/xml/. W tym pliku dodaj reguły z elementami <include> i <exclude>. Ten przykład tworzy kopię zapasową wszystkich ustawień udostępnionych 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>

Określanie warunków dotyczących urządzenia, które muszą być spełnione, aby można było utworzyć kopię zapasową

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. W Androidzie 9 (API na poziomie 28) lub nowszym możesz dodać te warunki:

Jeśli urządzenia deweloperskie zostały uaktualnione do Androida 9, po uaktualnieniu musisz wyłączyć, a następnie ponownie włączyć tworzenie kopii zapasowych danych. Dzieje się tak, ponieważ Android szyfruje kopie zapasowe za pomocą klucza po stronie klienta dopiero po poinformowaniu użytkowników w Ustawieniach lub 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 Twoja aplikacja implementuje system kopii zapasowych klucz-wartość lub jeśli implementujesz go samodzielnie, możesz też zastosować te wymagania warunkowe do logiki kopii zapasowej, wykonując porównanie bitowe między zestawem flag transportu obiektu BackupDataOutput a flagami FLAG_CLIENT_SIDE_ENCRYPTION_ENABLED lub FLAG_DEVICE_TO_DEVICE_TRANSFER niestandardowego agenta kopii zapasowej.BackupAgent

Poniższy fragment kodu pokazuje przykładowe użycie 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.
}

Kontrolowanie kopii zapasowej na Androidzie 12 lub nowszym

Jeśli Twoja aplikacja jest kierowana na Androida 12 (API na poziomie 31) lub nowszego, wykonaj czynności opisane w tej sekcji, aby określić, które pliki mają być tworzone na urządzeniach z Androidem 12 lub nowszym.

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

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

  2. Utwórz plik XML o nazwie backup_rules.xml w katalogu res/xml/. W tym pliku dodaj reguły z elementami <include> i <exclude>. Ten przykład tworzy kopię zapasową wszystkich ustawień udostępnionych z wyjątkiem 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 aplikacja i w której działa.

Android 11 lub starszy

Użyj tej składni XML w pliku konfiguracji, który kontroluje tworzenie kopii zapasowych 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>

Androida 12 lub nowszą wersję,

Jeśli Twoja aplikacja jest kierowana na Androida 12 (API na poziomie 31) lub nowszego, użyj w pliku konfiguracyjnym, który kontroluje tworzenie kopii zapasowych na urządzeniach z Androidem 12 lub nowszym, poniższej składni XML.

<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>
  <cross-platform-transfer platform="ios">
    ...
    <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"/>
    ...
    <platform-specific-params bundleId="string" teamId="string" contentVersion="string"/>
    ...
  </cross-platform-transfer>
</data-extraction-rules>

Każda sekcja konfiguracji (<cloud-backup>, <device-transfer>, <cross-platform-transfer>) zawiera reguły, które mają zastosowanie tylko do tego typu transferu. Ten podział umożliwia na przykład wykluczenie pliku lub katalogu z kopii zapasowych Dysku Google, ale nadal przesyłanie go podczas przesyłania danych z urządzenia na urządzenie lub przesyłania między platformami. Jest to przydatne, jeśli masz pliki, które są zbyt duże, aby utworzyć ich kopię zapasową w chmurze, ale można je bez problemu przenosić między urządzeniami.

Jeśli dla danego trybu tworzenia kopii zapasowej nie ma reguł, np. brakuje sekcji <device-transfer>, tryb ten jest w pełni włączony w przypadku wszystkich treści z wyjątkiem katalogów no-backup i cache, zgodnie z opisem w sekcji Pliki, które są objęte kopią zapasową.

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 uniemożliwia wysyłanie kopii zapasowych do chmury, jeśli urządzenie użytkownika nie obsługuje szyfrowania. Jednak ponieważ transfery D2D nie są wysyłane na serwer, działają one nadal nawet na urządzeniach, które nie obsługują szyfrowania.

Składnia elementów uwzględniania i wykluczania

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

<include>

Określa plik lub folder, którego kopię zapasową chcesz utworzyć. Domyślnie automatyczna kopia zapasowa obejmuje prawie wszystkie pliki aplikacji. Jeśli określisz element <include>, system nie będzie już domyślnie uwzględniać żadnych plików i będzie tworzyć kopie zapasowe tylko określonych plików. Aby dołączyć wiele plików, użyj kilku elementów <include>.

Na Androidzie 11 i starszych wersjach ten element może też zawierać atrybutrequireFlags, który jest szczegółowo omówiony w sekcji opisującej, jak określać wymagania warunkowe dotyczące kopii zapasowej.

Pliki w katalogach zwracanych przez 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 z kopii zapasowej. Oto niektóre pliki, które są zwykle wykluczane z kopii zapasowej:

  • Pliki, które mają identyfikatory specyficzne dla urządzenia, wydane przez serwer lub wygenerowane na urządzeniu. Na przykład Komunikacja w chmurze Firebase (FCM) musi generować token rejestracyjny za każdym razem, gdy użytkownik zainstaluje aplikację na nowym urządzeniu. Jeśli stary token rejestracyjny zostanie przywrócony, aplikacja może działać w nieoczekiwany sposób.

  • Pliki związane z debugowaniem aplikacji.

  • Duże pliki, które powodują przekroczenie limitu kopii zapasowych wynoszącego 25 MB.

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 są przechowywane wszystkie pliki prywatne należące do tej aplikacji.
  • file: katalogi zwrócone przez getFilesDir().
  • database: katalogi zwrócone przez getDatabasePath(). Bazy danych utworzone za pomocą SQLiteOpenHelper są przechowywane tutaj.
  • sharedpref: katalog, w którym są przechowywane pliki SharedPreferences.
  • external: katalog zwrócony przez getExternalFilesDir().
  • device_root: podobne do root, ale w przypadku pamięci chronionej na urządzeniu.
  • device_file: podobne do file, ale w przypadku pamięci chronionej na urządzeniu.
  • device_database: podobne do database, ale w przypadku pamięci chronionej na urządzeniu.
  • device_sharedpref: podobne do sharedpref, ale w przypadku pamięci chronionej na urządzeniu.
path

Określa plik lub folder, który ma zostać uwzględniony w kopii zapasowej lub z niej wykluczony. Uwaga:

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

Konfigurowanie transferów między platformami

Od Androida 16 QPR2 (poziom interfejsu API 36.1) możesz skonfigurować automatyczną kopię zapasową do przesyłania danych na urządzenia inne niż Android i z nich. Aby to zrobić, dodaj element <cross-platform-transfer> w konfiguracji <data-extraction-rules>, jak pokazano w składni Androida 12 lub nowszego. Musisz określić platformę docelową za pomocą wymaganego atrybutu platform. Jedyną obsługiwaną wartością jest ios.

W tej sekcji możesz używać standardowych elementów <include> i <exclude>, zgodnie z opisem w artykule Składnia elementów include i exclude, aby określić, które dane mają być przesyłane.

Musisz też dodać element <platform-specific-params>, aby ułatwić systemowi dopasowanie aplikacji do odpowiedniej aplikacji na platformie docelowej. Ten element ma te wymagane atrybuty:

  • bundleId: identyfikator pakietu aplikacji na innej platformie (np. identyfikator pakietu aplikacji na iOS).
  • teamId: identyfikator zespołu aplikacji na innej platformie (np. identyfikator zespołu aplikacji na iOS).
  • contentVersion: zdefiniowany przez Ciebie ciąg znaków wersji powiązany z eksportowanym formatem danych.

Atrybuty bundleId i teamId służą do weryfikacji integralności danych i prawidłowego dopasowywania aplikacji do aplikacji. Gwarantują, że podczas eksportu dane są przesyłane do określonej aplikacji na innej platformie, a podczas importu ta aplikacja na Androida importuje dane z tej konkretnej aplikacji.

Aby uzyskać większą kontrolę nad procesem przekształcania i przenoszenia danych niż ta, którą zapewniają reguły XML, możesz wdrożyć niestandardowy BackupAgent i użyć interfejsów API do przenoszenia danych między platformami.

Mapowanie plików w przypadku przesyłania na iOS

Podczas przesyłania plików na iOS znaki domain i path określone w <include> regułach są mapowane na konkretną strukturę katalogów. W tabeli poniżej podano ścieżki docelowe w systemie iOS w odniesieniu do głównego folderu docelowego transferu na podstawie systemu Android domain:

Android domain Ścieżka w iOS (względem katalogu głównego przenoszenia)
root app/
file app/files/
database app/databases/
sharedpref app/shared_prefs/
external external/files/
device_root device/app/
device_file device/app/files/
device_database device/app/databases/
device_sharedpref device/app/shared_prefs/

Na przykład plik dołączony do <include domain="file" path="my_settings.txt"/> będzie dostępny na urządzeniu z iOS w lokalizacji app/files/my_settings.txt względem katalogu głównego miejsca docelowego transferu.

Implementowanie BackupAgent

Aplikacje, które implementują automatyczne tworzenie kopii zapasowych, nie muszą implementować BackupAgent. Możesz jednak opcjonalnie zaimplementować niestandardowy BackupAgent. Zwykle są 2 powody, dla których to robimy:

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

  • Nie możesz łatwo określić zestawu plików, których kopię zapasową chcesz utworzyć, za pomocą reguł XML. W rzadkich przypadkach możesz zaimplementować BackupAgent, która zastępujeonFullBackup(FullBackupDataOutput), aby przechowywać wybrane przez siebie dane. Aby zachować domyślną implementację systemu, wywołaj odpowiednią metodę w klasie nadrzędnej za pomocą super.onFullBackup().

Jeśli zaimplementujesz BackupAgent, system domyślnie oczekuje, że aplikacja będzie tworzyć kopie zapasowe par klucz-wartość i je przywracać. Aby zamiast tego używać automatycznej kopii zapasowej opartej na plikach, ustaw atrybut android:fullBackupOnly na true w pliku manifestu aplikacji.

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, i umożliwić jej wykonywanie metod wywołania zwrotnego w BackupAgent. W tym trybie ograniczonym główna aktywność aplikacji nie jest uruchamiana automatycznie, jej dostawcy treści nie są inicjowani, a zamiast dowolnej podklasy zadeklarowanej w manifeście aplikacji tworzona jest instancja klasy bazowej Application.

Klasa 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ć implementację tych metod pustą.

Więcej informacji znajdziesz w artykule Rozszerzanie klasy BackupAgent.

Obsługa przesyłania danych między platformami w agencie kopii zapasowych

Od Androida 16 QPR2 (API na poziomie 36.1) w BackupAgent dostępnych jest kilka nowych interfejsów API, które lepiej obsługują przesyłanie danych między platformami.

Nowy rodzaj transportu:

  • FLAG_CROSS_PLATFORM_TRANSFER_IOS: ta flaga jest dodawana do transportFlags przekazywanego do BackupAgent.
    • W onFullBackup ta flaga jest ustawiana, jeśli bieżąca operacja tworzenia kopii zapasowej jest częścią eksportu danych na urządzenie z iOS.
    • W nowym przeciążeniu onRestoreFile ta flaga jest ustawiana, jeśli dane są importowane z urządzenia z iOS.

Nowa metoda onRestoreFile:

Wprowadzono nowe przeciążenie funkcji onRestoreFile, które przyjmuje jeden parametr FullRestoreDataInput. Ten obiekt dostarcza więcej informacji o operacji przywracania:

  • FullRestoreDataInput.getTransportFlags(): zwraca flagi transportu dla bieżącej operacji przywracania, które mogą obejmować FLAG_CROSS_PLATFORM_TRANSFER_IOS.
  • FullRestoreDataInput.getContentVersion(): zwraca ciąg tekstowy wersji treści podany przez aplikację źródłową na innej platformie podczas przenoszenia między platformami. Jeśli źródło nie podaje tej wartości, jest ona pustym ciągiem znaków.

Nowa metoda szacowania rozmiaru:

  • onEstimateFullBackupBytes(): ta metoda umożliwia podanie szacowanego rozmiaru danych, których kopia zapasowa ma zostać utworzona. Wdrożenie jest zdecydowanie zalecane, jeśli aplikacja wykonuje znaczące przekształcenia danych podczas tworzenia kopii zapasowej lub obsługuje dużą ilość danych, ponieważ może zwiększyć wydajność, unikając domyślnego testu systemu. W przypadku aplikacji z małymi, prostymi kopiami zapasowymi ta metoda zwykle nie jest konieczna.

Przykład użycia:

Kotlin

// In your custom BackupAgent class

override fun onFullBackup(out: FullBackupDataOutput) {
    // Check if this is a cross-platform export to iOS
    if ((out.transportFlags and FLAG_CROSS_PLATFORM_TRANSFER_IOS) != 0) {
        Log.d(TAG, "onFullBackup for iOS transfer")
        // Your custom export logic here
        // Call fullBackupFile() for files to include
    }
}

override fun onRestoreFile(input: FullRestoreDataInput) {
    if ((input.transportFlags and FLAG_CROSS_PLATFORM_TRANSFER_IOS) != 0) {
        val sourceContentVersion = input.contentVersion
        Log.d(TAG, "onRestoreFile from iOS, content version: $sourceContentVersion")
        // Your custom import logic here, using input.data, input.destination, etc.
    }
}

// Optional: Provide an estimate of the backup size
override fun onEstimateFullBackupBytes(): Long {
    return calculateEstimatedBackupSize()
}

Java

// In your custom BackupAgent class

@Override
public void onFullBackup(FullBackupDataOutput out) throws IOException {
    // Check if this is a cross-platform export to iOS
    if ((out.getTransportFlags() & FLAG_CROSS_PLATFORM_TRANSFER_IOS) != 0) {
        Log.d(TAG, "onFullBackup for iOS transfer");
        // Your custom export logic here
        // Call fullBackupFile() for files to include
    }
}

@Override
public void onRestoreFile(FullRestoreDataInput input) {
    if ((input.getTransportFlags() & FLAG_CROSS_PLATFORM_TRANSFER_IOS) != 0) {
        String sourceContentVersion = input.getContentVersion();
        Log.d(TAG, "onRestoreFile from iOS, content version: " + sourceContentVersion);
        // Your custom import logic here, using input.getData(), input.getDestination(), etc.
    }
}

// Optional: Provide an estimate of the backup size
@Override
public long onEstimateFullBackupBytes() {
    return calculateEstimatedBackupSize();
}