12 February 2018
What happens to app usage and accessibility when people get new phones? The feedback we've had is that people want apps to work straight out of the box, just like on their old phones.
Developers of successful apps might also be used to thinking about user activation in a model borrowed straight from web. On the web, people register new accounts, activate by finding great features, then become retained when they experience value, and come back repeatedly to use your web page.
The story is much the same on mobile. People register to create new accounts, activate by using your great features, then become retained when they find value and repeatedly launch your app. However, there's one big difference. Android apps typically store more information compared to your average web session. You usually never have to re-enter your password for an Android app for years, post account creation, that is until the moment you get a new phone.
Getting a new phone can be a rare event for many people - some going years between upgrading devices. However, overall a large proportion of those who use your app will get a new phone every year. We have several tools to help you keep people logged in, engaged, and happy when they use your app on a new phone.
Auto Backup for apps should be configured for every application. This feature does exactly what it says - automatically backs up your app data. So when people get a new phone, their app data is automatically restored before your app launches.
To configure Auto Backup for your app you need to setup include/exclude rules:
AndroidManifest.xml
<application ... android:fullBackupContent="@xml/autobackup">
xml/autobackup.xml
<?xml version="1.0" encoding="utf-8"?> <full-backup-content> <include domain="sharedpref" path="."/> <exclude domain="sharedpref" path="device.xml"/> </full-backup-content>
When configuring include/exclude rules it's important to avoid storing sensitive user data in Auto Backup, although it's a great place to store user specific settings and other app content!
To implement tracking for Auto Backup register a BackupAgent and listen for onQuotaExceeded(long, long) callback. If your app exceeds the 25MB backup limit, this callback will be your notification of failure. In a well configured app this will never happen, so you can track it as a crash report.
Learn more about Auto Backup for apps.
When we talk to people about the experiences they want on their new phones they're very clear; they want your app to remember who they are, and they don't want to re-enter a password. There are several ways you can accomplish this as a developer:
<TextViewandroid:id="@+id/username" android:layout_width="wrap_content" android:layout_height="wrap_content" android:autofillHints="username" />
<TextView android:id="@+id/password" android:layout_width="wrap_content" android:layout_height="wrap_content" android:autofillHints="password" /> <TextView android:id="@+id/captcha" android:layout_width="wrap_content" android:layout_height="wrap_content" android:importantForAutofill="no" />
If you haven't already, try the Auto Backup for Android Codelab, and SmartLock Codelab.
Improving retention on Android for many people will involve trying to overcome the friction of device switches. With a rich toolbox at your disposal to transfer settings with Auto Backup, and to improve the login experience with Google Sign-In, Smart Lock for Passwords, Autofill, and Account Transfer API, you have the opportunity to deliver a great user story: your app works on people's new phones, just like it did on their old phones.
How useful did you find this blogpost?