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.
Back up your app data
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.
Optimize log-in
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:
- Use Google Sign-In to make login frictionless. People can sign in with their Gmail account, or any email address. Most importantly, they don't need to remember a password. On top of improving registration and activation, enabling Google Sign-In will also help with retention as it allows those getting new phones to reactivate with a single button, or even automatically. Even better, you can use Google Sign-In for the same login experience for your iOS, Web, and Android applications. This seamless experience is also available if your app uses Firebase Auth to handle Google Sign-In.
- Make things simpler by using Google Smart Lock and Autofill. These two features work hand in hand to help people safely access their passwords. Autofill was introduced in Android O, and will offer to save your app user's passwords to the Smart Lock datastore, or their preferred password manager, automatically when they log in. To prepare your app, setup Autofill hints, and exclude fields that should not be filled by the Autofill framework.
<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" />
- Integrate the Smart Lock for Passwords API to safely store passwords. It's backwards compatible to API 9 and works great on devices with older versions of Android that don't work with Autofill. Similar to Autofill, Smart Lock API will offer a dialog to save people's passwords after they log in. But even better - it enables programmatic retrieval for automatic return to user sign-in, even across new devices and in Chrome. To support this Smart Lock functionality you will need to include some code in your app; check out the Codelab to learn how to integrate Smart Lock for Passwords to your app. Also, be sure to link your app and website, for a smooth experience across Chrome and Android with Autofill and Smart Lock.
- Consider using the Account Transfer API so your app can transfer credentials from an old phone to a new one. It does this using an encrypted bluetooth/cable, and you can transfer data from phones running API 14 or higher. Account transfer happens when your app user is setting up their new phone for the first time, though your app doesn't need to be installed from the Google Play Store. When your app re-installs from Google Play, the credentials will be available to your app on first launch. Watch more best practices to get started with the Account Transfer API, and read the API guide for Account Transfer.
Codelabs
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?
