How Pandao uses the In-App Updates flexible flow to speed up the app update process on Android
Guest authored by Sergey Smetanin, Android Developer at Pandao
Of the variety of new tools and features announced at Google I/O, one of the most exciting is the In-App Updates (IAU) API, which allows developers to deliver features, bug fixes, and performance improvements faster for active users. As a developer for Pandao, a marketplace platform for Chinese goods, my team and I have used the API to get more users to update. In this article, I’ll share what our team has learned about the IAU API, recommend some user flows, and let you see some of our code samples. I’ll also go over how we integrated IAU in the Pandao app.
The IAU API allows developers to initiate a new in-app update request flow to urge active users to update. In-app updates complement the existing Google Play auto-update mechanism, which may not always be enabled or capable of completing. An IAU request can be implemented in two ways with completely different user experiences:
- The flexible flow prompts users to download an update in the background and install it at their convenience. It is meant to be used in situations when it is still okay for a user to use an older version of the app even though a new one has been released.
- The immediate flow requires users to download and install an update before continuing using the app. It is meant to be used in situations when it is crucial for developers to prevent usage of the app before the update is applied.
Since the latter is less relevant to the Pandao app, we’ll focus on the former.
IAU Flexible Flow Integration: Use Case
The flexible IAU flow consists of the following steps:
- The app requests Google Play to check for available updates using the Play Core Library.
- If there is an available update, the app requests Google Play to show the IAU dialogue. Google Play shows the update request dialogue to the user.
- If the user accepts the update request, Google Play downloads an update in the background.
- If the process of downloading completes while the app is in the background, Google Play automatically completes the installation. In case the download completes while the app is in the foreground, we have to define custom logic for the update completion. Consider these best-practices for the implementation:
a. After the update has downloaded, display a dialogue or prompt to allow the user to confirm that they’re ready to relaunch and update the app. Once they’ve agreed to update, Google Play will display a screen showing the installation progress before restarting the app. This is the flow we recommend.
b. If the app does not prompt the user to apply the update, Play will attempt to update the next time the app goes to the background. On the one hand, this option is less invasive in terms of user experience. But on the other hand, it requires the developer to implement a tricky feature for detecting whenever the app goes to the background.
In exceptional situations, the completion of the update will be deferred automatically to the Google Play background task. This option is not recommended for the explicit use because it doesn’t guarantee when or if the update will be installed.
Basic Requirements for Manual Testing
In order to manually perform the full update flow on a test device, you should have at least two versions of the app with different version numbers: a source version and a target version.
- The source version with the higher version number should be published on Google Play. This is the version which will be identified by Google Play as an available update. The target version with the lower version number and integrated IAU feature should be installed on your device. This is the version which will be updated. When the app requests Google Play to check for available updates, it compares the version number of the installed app with the version number of the last available build in Google Play, so the IAU feature will only be triggered if the version number in Google Play is higher than the actual version of the app on the device.
- Both the source and the target versions need to have the same package name and should be signed with the same release certificate.
- Your test device needs to run Android API 21+. Pre-Lollipop devices are not supported.
Sample Code
To begin, let’s create an instance of the IAU manager and add callbacks to the AppUpdateInfo task. The result contains information about an update availability, an intent to start an update if available, and the current progress of the update download if it has already started.
To trigger the update request dialogue from Google Play in code, you can start the update flow by calling startUpdateFlowForResult, passing the AppUpdateInfo object you received before as a parameter. This dialogue requests the user to start the update.
To monitor the update state, you can add InstallStateUpdatedListener to the IAU manager. Please make sure your InstallStateUpdatedListener is lifecycle-aware.
As soon as the update is downloaded (DOWNLOADED status), the app needs to restart to complete the update. You can initiate the restart by calling appUpdateManager.completeUpdate(), but you might want to display a snackbar to allow the user to confirm explicitly that he or she is ready to relaunch the app right now.
“Update Is Not Available” Error
If you see this error, double-check the requirements in the “Basic Implementation Requirements” section. If you’ve completed the steps listed above and met all the requirements but the onSuccess callback says the update is still not available, the most likely reason is that Google Play does not know about the update yet due to the internal caching mechanism. To make sure you have a fresh cache when testing manually, refresh the cached version by going to the “My Apps & Games” screen in the Google Play app. As an alternative, you can simply clear the cache of the Google Play app in the settings. Note that this is just an issue for testing and does not affect end users, since the cache is updated daily.
IAU Flexible Flow in Pandao
As a part of an early access program, Pandao integrated the IAU flexible flow (recommended implementation) in the app. The IAU dialogue was shown on the main screen so the maximum number of users were able to interact with it. Initially, we decided to show the IAU dialogue no more than once a day in order to avoid annoying our users.
Since A/B testing is a pivotal step in every new feature lifecycle, we decided to evaluate the effect of IAU on the Pandao app. We randomly divided our users into two non-overlapping groups. The first one was a control group without IAU, representing the “no-change” baseline, and the second one was a test group with the IAU dialogue.
Over the past few releases, we measured the percentage of active users for each app version. We found out that among active users with the last available version, most were in Group B, the users who saw the IAU. As you can see from purple lines in Fig. 1, in the first days after the publication of version 1.29.1, the number of active users with the IAU feature exceeded the number of users without this feature. The opposite situation can be observed for the previous versions of the app — see the blue and red lines after the publication of version 1.29.1. Based on our test, it seems like users with IAU tend to update the app more quickly.
According to Pandao analytics data (see Fig. 2), conversions to click on the confirmation button in the IAU dialogue reach their peak on the first days of the release and then decrease steadily until the next app update. The same pattern can be observed in conversions to click on the install button in a snackbar, which initiates the installation of the downloaded update. Consequently, it seems like the average conversion rate in both cases is directly proportional to the release frequency. For Pandao, the average conversion rate over the course of one month exceeds 35% for clicks on the confirmation button and 7% for clicks on the install button.
After looking at the data, we suggested that the drop-off in the confirmation rate over time is a user experience problem, because people who are interested in the new app version will update pretty quickly, while those who aren’t will continue to ignore it. Based on this information, we decided to back off some users who weren’t interested in updating, rather than asking them every day. It seems to be a good practice to try different request logics based on “staleness,” e.g., how old their version is, how many times the user has already been asked to update, and so on, rather than risk annoying our users.
As a result of our testing, IAU demonstrated valuable results, so we rolled out this feature to all our users.
The In-App Updates API is now available to all developers. Check out the documentation to learn more.
Acknowledgments
I want to thank my colleagues for their contribution to this article. Thanks to Maryna Pliashkova, Alexander Chernyy, Ilia Nazarov, Gleb Bodyachevskiy, Daniil Polozov, Anastasia Kulik, Vladislav Breus and Vladislav Goldin.
