Auto Backup for Apps säkerhetskopierar automatiskt användardata från appar som är avsedda för och körs på Android 6.0 (API-nivå 23) eller senare. Android bevarar appdata genom att ladda upp dem till användarens Google Drive – där de skyddas av användarens inloggningsuppgifter för Google-kontot. Datamängden är begränsad till 25 MB per användare av din app och det finns ingen avgift för lagring av backupdata. Din app kan anpassa säkerhetskopieringsprocessen eller välja bort den genom att inaktivera säkerhetskopiering.
För en översikt över Androids säkerhetskopieringsalternativ och vägledning om vilka data du bör säkerhetskopiera och återställa, se översikten över säkerhetskopiering av data.
Filer som säkerhetskopieras
Som standard inkluderar automatisk säkerhetskopiering filer i de flesta av de kataloger som systemet tilldelar din app:
- Filer för delade preferenser.
- Filer som sparats i appens interna lagringsutrymme och som nås med
getFilesDir()
ellergetDir(String, int)
. - Filer i katalogen som returneras av
getDatabasePath(String)
, vilket även inkluderar filer som skapats med klassenSQLiteOpenHelper
. - Filer på extern lagring i katalogen som returneras av
getExternalFilesDir(String)
.
Auto Backup utesluter filer i kataloger som returneras av getCacheDir()
getCodeCacheDir()
eller getNoBackupFilesDir()
. De filer som sparas på dessa platser behövs bara tillfälligt eller utesluts avsiktligt från säkerhetskopiering.
Du kan konfigurera din app så att vissa filer inkluderas och utesluts. Mer information finns i avsnittet Inkludera och utesluta filer.
Observera: Android behandlar inte konfigurationen av komponenter som användardata. Om din app aktiverar eller inaktiverar specifika komponenter i sitt manifest medan den körs ska du inte förvänta dig att AutoBackup ska spara och återställa konfigurationen. Om du vill bevara konfigurationstillståndet sparar du det i Delade inställningar och återställer Delade inställningar vid återställning. Om du vill att din app ska spara sitt tillstånd ska du spara tillståndet i Delade inställningar och återställa Delade inställningar vid återställning.
Säkringsplats för säkerhetskopiering
Säkringsdata sparas i en privat mapp i användarens Google Drive-konto,begränsad till 25 MB per app. De sparade uppgifterna räknas inte in i användarens personliga Google Drive-kvot. Endast den senaste säkerhetskopian lagras. När en säkerhetskopiering görs raderas den föregående säkerhetskopian (om en sådan finns). Säkerhetskopieringsdata kan inte läsas av användaren eller andra appar på enheten.
Användare kan se en lista över appar som har säkerhetskopierats i appen Google DriveAndroid. På en Android-driven enhet hittar användaren den här listan i Driveappens navigeringslåda under Inställningar > Säkerhetskopiering och återställning > Appdata.
Säkerhetskopior från varje enhetsuppsättningsliv sparas i separata datamängder, vilket framgår av följande exempel:
- Om användaren äger två enheter finns det en säkerhetskopieringsdatamängd för varje enhet.
- Om användaren fabriksåterställer en enhet och sedan konfigurerar enheten med samma konto lagras säkerhetskopian i ett nytt dataset. Föråldrade dataset raderas automatiskt efter en period av inaktivitet.
Säkringsschema
Säkringar sker automatiskt när alla följande villkor är uppfyllda:
- Användaren har aktiverat säkerhetskopiering på enheten. I Android 9 finns den här inställningen iInställningar > System > Säkerhetskopiering.
- Minst 24 timmar har förflutit sedan den senaste säkerhetskopieringen.
- Enheten är inaktiv.
- Enheten är ansluten till ett Wi-Fi-nätverk (om enhetsanvändaren inte har valt att ta säkerhetskopiering av mobildata).
I praktiken inträffar dessa villkor ungefär varje natt, men det kan hända att en enhet aldrig gör någon säkerhetskopiering (t.ex. om den aldrig ansluter till ett nätverk). För att spara nätverksbandbredd sker uppladdningen endast om appdata har ändrats.
Under automatisk säkerhetskopiering stänger systemet av appen för att se till att den inte längre skriver till filsystemet. Som standard ignorerar säkerhetskopieringssystemet appar som körs i förgrunden eftersom användarna skulle märka att deras appar stängs ner. Du kan åsidosätta standardbeteendet genom att ställa in attributet backupInForeground
till true.
För att förenkla testningen innehåller Android verktyg som låter dig initiera en säkerhetskopiering av din app manuellt. Mer information finns i Testa säkerhetskopiering och återställning.
Skema för återställning
Data återställs när appen installeras, antingen från Play-butiken, under enhetsinstallationen (när systemet installerar tidigare installerade appar) eller genom att köra adb install. Återställningsoperationen sker efter att APK:n har installerats, men innan appen är tillgänglig för att startas av användaren.
Under den första guiden för enhetsinstallation visas användaren en lista över tillgängliga säkerhetskopieringsdatamängder och tillfrågas om vilken som ska användas för att återställa data. Det backup-dataset som väljs blir det ursprungliga datasetetet för enheten. Enheten kan återställa från antingen sina egna säkerhetskopior eller det ursprungliga datasetet. Enheten prioriterar sin egen säkerhetskopia om säkerhetskopior från båda källorna är tillgängliga. Om användaren inte gick igenom guiden för enhetsinstallation kan enheten endast återställa från sina egna säkerhetskopior.
För att förenkla testningen innehåller Android verktyg som gör att du manuellt kan initiera en återställning av din app. Mer information finns i Testa säkerhetskopiering och återställning.
Aktivera och inaktivera säkerhetskopiering
Appar som är inriktade på Android 6.0 (API-nivå 23) eller högre deltar automatiskt i automatisk säkerhetskopiering. I manifestfilen för din app ställer du in det booleska värdetandroid:allowBackup
för att aktivera eller inaktivera säkerhetskopiering. Standardvärdet är true
, men för att klargöra dina intentioner rekommenderar vi att du uttryckligen ställer in attributet i ditt manifest enligt nedan:
<manifest ... > ... <application android:allowBackup="true" ... > ... </application></manifest>
Du kan inaktivera säkerhetskopiering genom att ställa in android:allowBackup
till false
. Du kanske vill göra detta om din app kan återskapa sitt tillstånd genom någon annan mekanism eller om din app innehåller känslig information som Android inte bör säkerhetskopiera.
Inkludera och exkludera filer
Som standard säkerhetskopierar systemet nästan alla appdata. Mer information finns i Filer som säkerhetskopieras. Det här avsnittet visar hur du definierar anpassade XML-regler för att styra vad som säkerhetskopieras.
- I
AndroidManifest.xml
lägger du till attributetandroid:fullBackupContent
till elementet<application>
. Det här attributet pekar på en XML-fil som innehåller regler för säkerhetskopiering. For example:<application ... android:fullBackupContent="@xml/my_backup_rules"></application>
- Create an XML file called
my_backup_rules.xml
in theres/xml/
directory. Inside the file, add rules with the<include>
and<exclude>
elements.The following sample backs up all shared preferences exceptdevice.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. If you specify an <include> element, the system no longer includes any files by default and backs up only the files specified. Om du vill inkludera flera filer använder du flera <include>-element.Observera: Filer i kataloger som returneras av
getCacheDir()
getCodeCacheDir()
ellergetNoBackupFilesDir()
utesluts alltid även om du försöker inkludera dem. -
<exclude>
– Anger en fil eller mapp som ska uteslutas under säkerhetskopieringen. Här är några filer som vanligtvis utesluts från säkerhetskopiering:- Filer som har enhetsspecifika identifierare, antingen utfärdade av en server eller genererade på enheten. Google Cloud Messaging (GCM) måste till exempel generera en registreringstoken varje gång en användare installerar din app på en ny enhet. Om den gamla registreringstoken återställs kan appen bete sig oväntat.
- Kontouppgifter eller annan känslig information. Överväg att be användaren att återigen autentisera sig första gången han/hon startar en återställd app i stället för att tillåta lagring av sådan information i säkerhetskopian.
- Filer som rör felsökning av appar.
- Large files that cause the app to exceed the 25MB backup quota.
Note: If your configuration file specifies both elements, then the backup contains everything captured by the <include>
elements minus the resources named in the <exclude>
elements. In other words, <exclude>
takes precedence.
Each element must include the following two attributes:
-
domain
– specifies the location of resource. Valid values for this attribute include the following:-
root
– the directory on the filesystem where all private files belonging to this app are stored. -
file
– directories returned bygetFilesDir()
. -
database
– directories returned bygetDatabasePath()
. Databases created withSQLiteOpenHelper
are stored here. -
sharedpref
– the directory whereSharedPreferences
are stored. -
external
the directory returned bygetExternalFilesDir()
-
-
path
: Specifies a file or folder to include in or exclude from backup. Note that:- This attribute does not support wildcard or regex syntax.
- You can use
.
to reference the current directory, however, you cannot reference the parent directory..
for security reasons. - If you specify a directory, then the rule applies to all files in the directory and recursive sub-directories.
Note: You cannot back up files outside of these locations.
The include
element can also contain the requireFlags
attribute, which thesection describing how to define conditional requirements forbackup section discusses in more detail.
Definiera enhetsvillkor som krävs för säkerhetskopiering
Om din app sparar känslig information på enheten kan du ange villkor för att appens data ska ingå i användarens säkerhetskopiering. Du kan lägga till följande villkor i Android 9 (API-nivå 28) eller högre:
-
clientSideEncryption
: Användarens säkerhetskopia krypteras med en klienthemlighet. Denna form av kryptering är möjlig på enheter som kör Android 9 eller högre så länge användaren har aktiverat säkerhetskopiering i Android 9 eller högre och har ställt in ett skärmlås (PIN-kod, mönster eller lösenord) för sin enhet. -
deviceToDeviceTransfer
: Användaren överför sin säkerhetskopiering till en annan enhet som har stöd för lokal överföring från enhet till enhet (t.ex. Google Pixel).
Om du har uppgraderat dina utvecklingsenheter till Android 9 måste du inaktivera och sedan aktivera säkerhetskopiering av data igen efter uppgraderingen. Detta beror på att Android endast krypterar säkerhetskopior med en hemlighet på klientsidan efter att ha informerat användarna i Inställningar eller i installationsguiden.
För att deklarera inklusionsvillkoren ställer du in attributet requireFlags
till önskat värde eller önskade värden i dina <include>
-element i din uppsättning av säkerhetskopieringsregler:
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>
Om din app implementerar ett backupsystem med nyckelvärden, eller om du själv implementerarBackupAgent,kan du också tillämpa dessa villkorliga krav på din säkerhetskopieringslogik genom att utföra en bitvis jämförelse mellan ettBackupDataOutput
objekts uppsättning transportflaggor och din anpassade säkerhetskopieringsagentensFLAG_CLIENT_SIDE_ENCRYPTION_ENABLED
eller FLAG_DEVICE_TO_DEVICE_TRANSFER
flaggor.
Följande kodutdrag visar ett exempel på användning av den här metoden:
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.}
Implement BackupAgent
Apps that implement Auto Backup do not need to implement a BackupAgent
. However, you can optionally implement a custom BackupAgent
. Typically, there are two reasons for doing this:
- You want to receive notification of backup events such as,
onRestoreFinished()
oronQuotaExceeded(long, long)
. These callback methods are executed even if the app is not running. - You can’t easily express the set of files you want to backup with XML rules. In these rare cases, you can implement a BackupAgent that overrides
onFullBackup(FullBackupDataOutput)
to store what you want. To retain the system’s default implementation, call the corresponding method on the superclass withsuper.onFullBackup()
.
If you implement a BackupAgent, by default the system expects your app to perform key/value backup and restore. Om du istället vill använda den filbaserade automatiska säkerhetskopieringen ställer du in attributet android:fullBackupOnly
till true
i appens manifest.
Under automatiska säkerhetskopierings- och återställningsoperationer startar systemet appen i ett begränsat läge för att både hindra appen från att få åtkomst till filer som skulle kunna orsaka konflikter och för att låta appen exekvera callback-metoder i sin BackupAgent
. I det här begränsade läget startas inte appens huvudaktivitet automatiskt, dess innehållsleverantörer initialiseras inte och basklassen Application
instansieras i stället för en underklass som deklareras i appens manifest.
Försiktighet: För att undvika fel bör du se till att de delar av appen som körs i det begränsade läget (främst din BackupAgent
) inte får tillgång till innehållsleverantörer i samma app eller försöker kasta Application
-objektet. Om du inte kan undvika dessa mönster bör du överväga att implementera nyckel/värde-backup eller inaktivera backup helt och hållet.
Din BackupAgent
måste implementera de abstrakta metoderna onBackup()
och onRestore()
, som används för nyckel/värde-backup. Men om du inte vill utföra säkerhetskopiering av nyckelvärden kan du bara lämna din implementering av dessa metoder tom.
För mer information, se Utöka BackupAgent.