Changes in backup and restorebookmark_border

There are changes to how backup and restore works in apps that run on and target Android 12. Android backup and restore has two forms:

• Cloud backups: User data is stored in a user’s Google Drive so that it can later be restored on that device or a new device.
• Device-to-device (D2D) transfers: User data is sent directly to the user's new device from their older device, such as by using a cable.

For more information on how data is backed up and restored, see Back up user data with Auto Backup and Back up key-value pairs with Android Backup Service.

D2D transfer functionality changes

For apps running on and targeting Android 12 and higher:

• Specifying android:allowBackup="false" does disable backups to Google Drive, but doesn’t disable D2D transfers for the app.

• Specifying include and exclude rules with the XML configuration mechanism no longer affects D2D transfers, though it still affects Google Drive backups. To specify rules for D2D transfers, you must use the new configuration covered in the next section.

New include and exclude format

Apps running on and targeting Android 12 and higher use a different format for the XML configuration. This format makes the difference between Google Drive backup and D2D transfer explicit by requiring you to specify include and exclude rules separately for cloud backups and for D2D transfer.

Optionally, you can also use it to specify rules for backup, in which case the old configuration is ignored.

Note: If you use the new configuration format your app will use the new behavior, even if you don't yet target Android 12.

XML format changes

The following is the format used for backup and restore configuration in Android 11 and lower:

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

The following shows the changes in the format in bold.

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

Each section of the configuration (<cloud-backup>, <device-transfer>) contains rules that apply only to that particular type of transfer. That allows you, for example, to exclude a file or directory from Google Drive backups while still transferring it during D2D transfers. This may be useful if you have files which would be too large to back up to the cloud, but which can be transferred between devices without issue.

If there are no rules for a particular backup mode, such as if the <device-transfer> section is missing, that mode is fully enabled for all content except for no-backup and cache directories, as described in Files that are backed up.

Your app can set the disableIfNoEncryptionCapabilities flag in the <cloud-backup> section to make sure the backup happens only if it can be encrypted, such as when the user has a lock screen. Setting this constraint stops backups from being sent to the cloud if the user’s device cannot support encryption, but because D2D transfers aren't sent to the server, they will continue to operate even on devices that don't support encryption.

Manifest flag for apps

Point your apps to the new XML configuration by using the android:dataExtractionRules attribute in your manifest file. When you point to the new XML configuration, the android:fullBackupContent attribute that points to the old config is ignored. The following code sample shows the new manifest file entries:

<application
    ...
    <!-- The below attribute is ignored. -->
    android:fullBackupContent="old_config.xml"
    <!-- You can point to your new configuration using the new
         dataExtractionRules attribute . -->
    android:dataExtractionRules="new_config.xml"
    ...>
</application>