As mobile device makers roll out new models, users are replacing their devices more frequently. One of the biggest headaches for users is data migration. So what are the bad user experiences of incomplete data migration? Let’s take a look at the user’s annoyance from the following case.

Sally’s troubles

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

When she gets home after a hard day at the lab, she likes nothing more than playing casual games on her phone.

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

Sally goes to her local mobile phone store and Hakeem, an experienced shop assistant, recommends an excellent new Android phone to her.

As soon as She got home, Sally started setting up her new phone. She was happy that she could easily transfer all the apps, photos, messages and Settings from her old phone to her new phone.

After the transfer, she wanted to see some of her favorite games in action on the great new phone. Her favorite casual game is Super Soccer Goalie Catch 2. It took her months to reach level 123 and she couldn’t wait to get through it on her new phone.

Unfortunately, when she opened the game, all progress was gone. Sally felt frustrated that it took several days to get back to the original level. She thought it was not worth the time to get back to the original level. Uninstalled the game and installed the Soccer Goalie 3D app, the game’s main competitor.

Undaunted, Sally opened the Protein Shake Tracker app. Sally likes to drink protein powders, rate them and track how much nutrition she’s taking in. When Sally opened the app, the system prompted her to log in, but she did not remember her login information and did not use the password manager. She was also pretty sure she had changed her email address. She was at a loss.

As you’ve guessed, Sally has uninstalled the app and decided to try another brilliant new app called Protemate. The app was heavily advertised on her Instagram feed.

Sally likes her new phone and most of the apps on it, but she is disappointed that some apps can’t transfer the old data.

Javier’s confusion

This is Javier. Javier uses iPhone to send messages to his younger generation. He has many photos of his younger generation on his phone, which means everything to him.

Javier is an early adopter and always buys new mobile phones. He likes the look of his new foldable Android phone, which gives him more screen real estate to text and play games and show off to his friends.

Javier transfers all his apps, contacts and photos from the iPhone to the new foldable Android phone. As soon as the transfer was complete, he opened his instant messaging app, hoping to see photos of his younger generation on the big screen.

But he was dismayed to discover that the messaging app was not transmitting messages from the iPhone. He was thinking maybe he should switch to a messaging app.

Now, you might think all this is fear-mongering. But at Google, we’ve done a lot of research on the switching experience, and the results show that users aren’t happy with the switching experience.

This quote from a recent Article in the Guardian chimes with our findings.

Real user feedback

The user left his phone on the roof of his car and uninstalled the game when he realized it wasn’t being transferred to the new device. We hear that a lot in our research.

△ Summary of research results

This is a summary of our findings. To the frustration of users, apps don’t continue as they did on older phones. They are upset about the loss of their personal data, and users don’t blame Android or THE OEM, they blame the app or themselves.

Only 30% of devices are configured on the new device, and most users want to be able to transfer data from the old phone to the new device. Failure to do so will upset users, leading to lower app ratings in the Play Store and a direct loss of users.

Don’t be like this developer, who has no idea why they’re losing users. These are the users you’ve worked hard to get in the beginning, and keep them when they switch to a new device.

Fortunately, it’s easy to transfer your app data to a new device on Android, and you can even back it up to the cloud for free, helping you grow your user base and ultimately your revenue with high-quality apps that 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 you have an iOS phone, you can use a cable to connect the old phone to the new Android device and then perform device-to-device migration, or D2D for short. During D2D we will see what apps are available on the user’s iOS device and then try to find Android apps in the Play Store and install them automatically. For some applications, application data can also be transmitted. If you are interested in data transfer between iOS and Android apps, please contact us at this email address.

△ Backup and recovery by connecting the device with data cable

For the use case of switching from Android to Android, the user can also connect the device via a data cable. We will re-download all of your applications and transfer up to 2GB of data for each application that participates in backup and recovery.

△ Recovering data in cloud backup

If the user’s old device is not currently with them, data can be restored from a cloud backup created previously. This is because app data on Android devices is regularly backed up to the cloud. These app backups are protected by 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 related application on the device.

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

At this point you might be thinking, I’ve used some kind of solution to keep user data synchronized to the cloud. Like Firebase or custom backends, why backup and restore?

First, users need to be logged into your application in order to use the in-app cloud synchronization feature. The data processed by the backup and restore function was already available because we already identified users by their Google accounts.

Second, and perhaps more importantly, there is a lot of data that is unique to the device, not the account in the application. Apps often don’t synchronize this data to the cloud. For example, suppose you have a starter tutorial that displays once on each device rather than on each account. Or, suppose your app has a Settings screen that users can set to customize the look and behavior of the app on that particular device. The list goes on.

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

Auto Backup

By default, all applications participate in automatic backup. This means that most of your application data will be contained in cloud backups and D2D transfers. We will exclude only cache directories and special non-backup folders where you can put content that you do not wish to back up or transfer.

Custom automatic backup

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

  • Setting rules specify which files or directories should be included in cloud backup or device transfer
  • 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 of these tasks, you simply create an XML file containing the required 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>
Copy the code

As shown in the code above, this configuration consists of two parts: one for cloud backup and the other for device transport. In 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>
Copy the code

In this case, we exclude the Firebase push token from cloud backup because it is not available on any other device. It makes perfect sense to exclude data that cannot be reused outside a particular device. We also excluded a large downloadable file, which makes no sense to include in a cloud backup if specific data can be easily redownloaded from a location.

In addition, for cloud backup, we have set disableIfNoEncryptionCapabilities logo to “true”. This means that data will not be backed up to the cloud unless end-to-end encryption is provided.

Finally, we defined a looser configuration for device-to-device transfers, because there was no cloud storage involved in the process.

<uses-sdk Android :targetSdkVersion= "31" /> <application... Android: dataExtractionRules my_rules. = "XML" >Copy the code

Once the configuration is complete, you need to point to it in the AndroidManifest file using the dataExtractionRules property. Also, don’t forget to include Android 12 as the target platform, as this attribute was introduced from that release.

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

Key/Value Backup

Next, let’s take a quick look at another method I mentioned earlier, called 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) {
              // Include the data that needs to be backed up here: either use end-to-end encryption or do not upload any data to the cloud}}Copy the code

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

<application
        . 
        android:backupAgent="MyBackupAgent">
Copy the code

Also, when the backup proxy is in place, don’t forget to point to it in AndroidManifest. If you are interested in key-value backup, see the distribution guide for implementing key-value backup.

Use BlockStore to transfer user credentials

Let’s look at a specific category of application data. One of the biggest hurdles users face when launching an app on a new device is logging in again. Users may not even remember their login name and password. Wouldn’t it be nice if your app could automatically recognize users and allow them to continue from where the app was on the old device?

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

val client = Blockstore.getClient(this)
val data = StoreBytesData.Builder()
        .setBytes(/* Binary array */)
        .build()
client.storeBytes(data).addOnSuccessListener{result -> log. d(TAG, "Stored: ${result.getBytesstored ()}")}Copy the code

Every time a user logs into your application and generates an authentication token or any other login credentials, simply save the data to BlockStore, which encrypts and stores the data securely.

val client = Blockstore.getClient(this) client.retrieveBytes().addonSuccessListener {result -> log.d (TAG, "Spectrum: ${String(result)}")}Copy the code

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

For more information about BlockStore, see.

test

After you have done all the configuration you need, whether using automatic or key-value backup, it is important to do some testing to ensure that you have the desired state when you first start your application after recovery.

Testing is very simple, and you can simulate cloud backup and device-to-device transfers for applications using a single device or emulator with a special workflow.

For detailed instructions on testing, please refer to the official documentation.

Keep updating your implementation

Finally, it is equally important to keep your configuration up to date. As applications evolve and add new features, make sure that backup and recovery cover the new content. You may not need to do anything if you are using an automatic backup, and all new data is included by default. If you are using key-value pair backup, update BackupAgent to include any relevant information.

Important updates for Android 12

Application developers have reported to us that they are concerned that ADB backups could lead to application data being easily extracted. To address this issue, we have turned off ADB backups for all applications. Therefore, enabling backup and restore does not affect your application with ADB backup. However, 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 older methods, namely the allowBackup flag and fullBackupContent configuration. It is recommended that you use dataExtractionRules for Android 12 and later. Also preserve the fullBackupContent configuration for earlier operating system versions.

For a full explanation of the above updates, please refer to the official documentation.

conclusion

I believe it is very exciting when your application data is synced to the new device. The good news is that more than 2 billion Android devices now support free backup to the cloud. Wi-fi and data lines will be extended to all new Android devices from January 2022. All of these will take effect by default, and it is recommended that you ensure that these features are enabled. If you have a lot of data or sensitive data, you can fine-tune what you export. Don’t forget the new BlockStore API, which you can use to securely handle passwords.

  • For more information
  • Contact us

Hopefully you found this helpful, and hopefully you can use backup and restore to provide a better experience for your users.

Please click here to submit your feedback to us, or share your favorite content or questions. Your feedback is very important to us, thank you for your support!