Retain users with Android Backup and Restore

https://www.bilibili.com/video/BV1eL4y147we/?aid=850750786&cid=487532141&page=1

△ Use Android Backup and Restore to retain users

As mobile device manufacturers continue to introduce new models, users are replacing devices more frequently. When replacing a new machine, one of the biggest headaches for users is data migration. So what kind of bad experience does imperfect data migration bring to users? Let's take a look at the user's troubles from the following case.

Sally's Trouble

Her name is Sally, Sally is a food microbiologist, and she has a great job that keeps her busy, even exhausting.

Back home after a hard day's work in the lab, her favorite thing to do is play casual games on her phone.

Sally loves her phone, which she bought in 2017 so she can watch The Good Place on her commute. But now she mostly plays games on her phone. However, this phone is not as good as it used to be.

Sally goes to the local phone store, and Hakeem, an experienced clerk, recommends her a great new Android phone.

Sally started setting up her new phone as soon as she got home and was delighted that she easily transferred all the apps, photos, messages and settings from the old phone to the new phone.

After the transfer, she wanted to see how some of her favorite games would play on this awesome new phone. Her favorite casual game is Super Soccer Goalie Catch 2. It took her a few months to reach level 123 and can't wait to get through it on her new phone.

Unfortunately, when she opened the game, all game progress was lost. It took Sally a few days to get to her previous level, and she was frustrated that she didn't think it was worth the time to get back to her previous level. So I uninstalled the game and installed the game's main competitor, the Soccer Goalie 3D app.

Not discouraged, Sally opens the Protein Shake Tracker app. Sally loves protein powders, grades them, and keeps track of how many nutrients she's getting. When Sally opens the app, she is prompted to log in, but Sally doesn't remember her login information and doesn't use a password manager. She's also pretty sure she's changed her email address. She was a little overwhelmed.

As you may have guessed, Sally uninstalled the app and decided to try another great new app called ProteinMate. The app runs a lot of ads on her Instagram feed.

Sally loves her new phone and most of the apps on it, but she's disappointed that some apps can't transfer previous data.

Javier's confusion

This is Javier, Javier uses his iPhone to message his juniors. There are many pictures of juniors on his phone, which means everything to him.

Javier loves to experiment and buy new phones frequently. He loves the look of his new foldable Android phone, which gives him more screen real estate for texting and gaming, and showing off to friends.

Javier transfers all his apps, contacts and photos from his iPhone to his new foldable Android phone. After the transfer was completed, he immediately opened the instant messaging application he used, hoping to see the photos of the younger generation on the big screen.

But he was struck by the fact that the instant messaging app wasn't transferring messages from the iPhone. He's thinking, maybe it's time to switch to an instant-messaging app.

Now, you might think all of this is panic-mongering. But at Google we have done a lot of research on the switching experience, and the results show that users are not satisfied with the switching experience.

This is a quote from a recent article in the Guardian that matches our findings.

△ Real user feedback

The user left his phone on the roof of the car and uninstalled the game when he noticed that the game's progress was not being transferred to the new device. We hear a lot of that in our research.

△ Summary of research results

This is a summary of our findings. What makes users puzzled is that the application cannot continue the original state of the old phone. They are upset about their personal data being lost, and users don't blame Android or the OEM, but the app or themselves.

In the new phone configuration process, only 30% of the devices are set up with the new device, and the vast majority of users want to be able to transfer data from the old phone to the new device. Failure to do so will result in uneasy users, resulting in lower app ratings in the Play Store and direct churn.

Don't be like this developer who doesn't understand why users churn. These users are the ones you strive to acquire from the beginning, and when users switch to new devices, be sure to keep them.

Luckily, transferring app data to a new device on Android is easy, and you can even back up your data to the cloud for free, helping you grow your user base and ultimately your revenue with high-quality apps your users trust.

About Android Backup and Restore

Let's look at two use cases: switching from iOS to Android and switching from Android to Android.

If the user used an iOS phone before, they can connect the old phone to the new Android device with a data cable, and then perform device-to-device migration, referred to as D2D. During D2D we'll look at what apps are on the user's iOS device, then try to find the corresponding Android apps in the Play Store, and install them automatically. For some applications, application data can also be transferred. If you are interested in data transfer between apps for iOS and Android, please contact us at email address

△ Connect the device through the data cable for backup and recovery

For the use case of switching from Android to Android, the user can also connect the device via a data cable. We will redownload all of the user's apps and transfer up to 2GB of data for each app participating in backup and restore.

△ Data recovery from cloud backup

If the user's old device is not currently around, data can be restored from a previously created cloud backup. This is because app data on Android devices is regularly backed up to the cloud. These app data backups are protected with end-to-end encryption on devices running Android Pie and higher, provided the user has set a PIN, pattern, or password to unlock the screen. In this mode, we will back up up to 25MB of data for each associated app on the device.

All apps on Android M and higher have backup and restore enabled unless you explicitly choose to disable the feature. You can easily control and customize the behavior you want, and we'll show you how to do that later.

Here you might be thinking, I've used some kind of solution to keep user data synced to the cloud. Like Firebase or a custom backend, why do you need backup and restore?

First, users need to be logged into your app in order to use the in-app cloud sync feature. The data processed by the backup and restore function is already available before that, because we already identify the user through the user's Google account.

Second, and perhaps more importantly, there's a lot of data that's unique to the device and doesn't belong to the account in the app. Apps typically don't sync this data to the cloud. For example, let's say you have a getting started tutorial that appears once per device instead of per account. Alternatively, let's say your app has a settings screen where the user can customize the app's appearance and behavior on this particular device. There are many more such examples.

But the point is that when users launch the app for the first time on a new phone, they really want all of these preferences already configured correctly. Now, let's see how to configure backup and restore for Android applications.

Auto Backup

By default, all apps participate in automatic backups. This means that most of your app data will be included in cloud backups and D2D transfers. We'll only exclude cache directories and special non-backup folders where you can put things you don't want backed up or transferred.

Custom Auto Backup

This is the configuration that can be customized in automatic backup:

• Set up rules that dictate which files or directories should be included in cloud backups or device transfers
• Specifies that cloud backup is required only if the device supports end-to-end (E2E) encryption
• Set different rules for cloud and D2D

To accomplish all these tasks, simply create an XML file containing the desired configuration.

<data-extraction-rules>
    <cloud-backup disableIfNoEncryptionCapabilities=”true”>
        <exclude path=”my_prefs/device_specific_prefs”/>
        <exclude path=”downloaded/temp” />
    </cloud_backup>
    <device-transfer>
        <exclude path=”my_prefs/device_specific_prefs” />
    </device-transfer>
</data-extraction-rules>

As shown in the code above, the configuration consists of two parts: one for cloud backup and one for device transfer. Within each section, you can set rules for which files or directories to exclude or include.

<data-extraction-rules>
    <cloud-backup disableIfNoEncryptionCapabilities=”true”>
        <exclude path=”files/my_firebase_token”/>
        <exclude path=”files/downloaded” />
    </cloud_backup>
    <device-transfer>
        <exclude path=”my_prefs/device_specific_prefs” />
    </device-transfer>
</data-extraction-rules>

In this example, we're excluding the Firebase Push Token from the cloud backup, as it won't work on any other device. It is very reasonable to exclude data that cannot be reused outside of a specific device. We've also excluded a larger downloadable file, which makes no sense to include in a cloud backup if it's easy to re-download specific data from a location.

Additionally, for cloud backups, we have set the disableIfNoEncryptionCapabilities flag to "true". This means that data will not be backed up to the cloud unless end-to-end encryption is provided.

Finally, we define a more relaxed configuration for device-to-device transfers, as no cloud storage is involved in the process.

<uses-sdk android:targetSdkVersion=”31” />
<application
        ... 
        android:dataExtractionRules=”my_rules.xml”>

Once the configuration is complete, you need to point to the configuration in the AndroidManifest file using the dataExtractionRules property. Also, don't forget to target Android 12 as the attribute was only introduced from this version.

For more detailed instructions on configuring automatic backups, see the official documentation .

Key/Value Backup

Next, let's briefly look at another method I mentioned earlier, namely key-value backup (K/V backup).

void onBackup(ParcelFileDescriptor oldState, BackupDataOutput data,
                ParcelFileDescriptor newState) {
       boolean isEncrypted = data.getTransportFlags
             & BackupAgent.FLAG_CLIENT_SIDE_ENCRYPTION_ENABLED
       boolean isD2d = data.getTransportFlags
             & BackupAgent.FLAG_IS_DEVICE_TO_DEVICE_TRANSFER
       if (isEncrypted || isD2d) {
              //在这里包含需要备份的数据:要么使用端到端加密，要么不上传任何数据到云端
       }
}

Here, you need to extend a class called BackupAgent and implement the backup and restore behavior you want. As part of a backup event you can check for the same conditions, such as whether end-to-end encryption is provided and whether the operation currently in progress is a cloud backup or a device transfer, to better determine which key-value pairs should be included.

<application
        ... 
        android:backupAgent=”MyBackupAgent”>

Also, when the backup proxy is in place, don't forget to point to that proxy in the AndroidManifest. If you are interested in key-value backups, see Distribution Guide for Implementing Key-value Backups .

Use BlockStore to transfer user credentials

Next we introduce a specific category of application data. One of the biggest hurdles a user faces when launching an app on a new device is logging in again. Users may not even remember their login and password. Wouldn't it be great if your app could automatically recognize users and allow them to pick up where they left off on the old device?

To achieve this a BlockStore can be used. It allows you to transfer any login credentials needed to identify the user to the new device as part of a device-to-device migration. BlockStore does not rely on features like automatic backups and key-value backups. Even if you don't use backup and restore for anything else, you can still use BlockStore to transfer authentication tokens. Let's take a quick look at how it works.

val client = Blockstore.getClient(this)
val data = StoreBytesData.Builder()
        .setBytes(/* 二进制数组 */)
        .build()
client.storeBytes(data)
        .addOnSuccessListener{ result ->
            Log.d(TAG, “Stored: ${result.getBytesStored()}”)
        }

Whenever a user logs into your app and generates an authentication token or any other login credentials, just save this data to BlockStore, which will encrypt and store it securely.

val client = Blockstore.getClient(this)
client.retrieveBytes()
        .addOnSuccessListener{ result ->
            Log.d(TAG, “Retrieved: ${String(result)}”)
}

After a device-to-device migration is complete, when your app is launched on a new device, you can request previously saved credentials from BlockStore and log in to the app without requiring the user to enter a login and password.

For more information on BlockStore , see.

test

After you've done all the configuration as needed, whether using automatic or key-value backups, it's important to do some testing to make sure you get the desired state the first time you start your app after a restore.

Testing is simple, and you can use a single device or emulator to specifically simulate cloud backups and device-to-device transfers of your app through special workflows.

For detailed instructions on testing, see official documentation .

Keep updating your implementation

Finally, it is also important to keep your configuration up to date. As your app evolves and adds new features, make sure backups and restores cover what's new. If you're using automatic backups, you may not need to do anything, all new data will be included by default. If you are using key-value backups, update BackupAgent to include any relevant information.

Important update for Android 12

App developers have reported to us that they are concerned about adb backups that allow app data to be easily extracted. To fix this, we've turned off adb backups for all apps. So enabling backup and restore will not make your app affected by adb backups. But you can still use adb backups for testing and development purposes as needed.

Second, we introduced the dataExtractionRules configuration as a new way to control automatic backups. We are phasing out the old methods, the allowBackup flag and the fullBackupContent configuration. It is recommended that you use dataExtractionRules on Android 12 and higher. Also keep the fullBackupContent configuration for earlier OS versions.

For detailed instructions on obtaining the above updates, please refer to the official documentation .

summary

I believe it's very exciting when your app's data is synced to a new device. The good news is that over 2 billion Android devices now support free backup to the cloud. Wi-Fi and cable delivery will be extended to all new Android devices from January 2022. All of these will be in effect by default, and it is recommended that you ensure these features are turned on. If you have a lot of data or sensitive data, you can fine-tune what is exported. Don't forget the new BlockStore API with which you can securely handle passwords.

• info
• us

I hope these are helpful, and I hope you provide a better experience for your users with backup and restore.

You are welcome Click here to submit feedback to us, or share your favorite content and found problems. Your feedback is very important to us, thank you for your support!