Mobile Echo_1

Android 14 adds new features to make third-party app stores work even better

Google Play is by far the most popular app store among Android users, but some might argue that it didn’t earn its top spot fairly. Google has been scrutinized by regulatory agencies and lawmaking bodies around the world because of how it maintains its app store dominance, and there are no signs this pressure will loosen up anytime soon. That’s perhaps why Google is taking the initiative to introduce new features in Android 14 that improve the experience for users of third-party app stores.

Most third-party app stores on Android aren’t really competitive with Google Play, and it’s not just because of their app selection. While first-party, preinstalled app stores have always had the ability to do automatic app updates, third-party app stores have only recently been able to do unattended updates. Google added an API in Android 12 that lets third-party app stores update apps without needing user action, reducing the friction of using a third-party app store.

However, this still left third-party app stores at a major disadvantage when it comes to functionality, because they couldn’t easily know when it would be safe to actually do an automatic update. That’s what Google is trying to solve in Android 14 with a new API that enables third-party app stores to perform “gentle updates”.

Gentle updates

Android 14 has added a new API that lets third-party app stores check whether certain conditions are met before they go ahead with automatically updating an app. The PackageInstaller.InstallConstraints API “can be used by app stores to deliver auto updates without disrupting the user experience (referred as gentle update) - for example, an app store might hold off updates when it find [sic] out the app to update is interacting with the user.”

This new API lets third-party app stores check whether an app they’re preparing to update has an active foreground service (isRequireAppNotForeground), is interacting with the user in some way (isRequireAppNotInteracting), or is on screen (isRequireAppNotTopVisible). Third-party app stores can also check whether the device is in doze mode (isRequireDeviceIdle) or in a phone call (isRequireNotInCall).

While the API allows for specifying what conditions to check, the documentation recommends using the preset constraints as the “system knows best how to do it.” This is logical given Google has had plenty of time to develop how best to handle automatic updates in its own app store. Using the preset is also beneficial, as noted by the documentation, since the accuracy and efficiency of gentle updates may be improved in future releases if Google adds more constraints to the API.

Every condition that the PackageInstaller.InstallConstaints API enables checking can already be checked through existing APIs, but having the system handle these checks is far easier and less intrusive. For example, third-party app stores that want to check whether an app they’re updating is actively being used by the user would currently have to use an API like UsageStats or AccessibilityService, both sensitive permissions. If they use this new Android 14 API, though, they wouldn’t need these permissions to do their job.

Update ownership

Enabling “gentle updates” isn’t the only improvement in Android 14 for third-party app stores. There’s also a new “update ownership” mechanism that lets third-party app stores become the exclusive source of future automatic updates to an app they first installed. This will mean that if you’re using a third-party app store because the apps available through it are vetted by the community, for example, then an unvetted update that’s available through other app stores won’t be automatically pushed to your device.

Right now, when you install an app through a third-party app store, there’s nothing preventing a first-party app store from updating that app. While Android 12’s unattended updates API only lets third-party app stores silently update apps that they first installed, first-party app stores are unaffected as they hold the privileged INSTALL_PACKAGES permission.

Third-party app stores on Android 14 can use the new setRequestUpdateOwnership method in PackageInstaller.SessionParams, however, to tell the system that they’re claiming update ownership over the app they’re about to install. Once update ownership enforcement is enabled for an app, all other app stores — even ones with the INSTALL_PACKAGES permission — need action from the user to update the app. Update ownership can only be enabled during the initial installation of an app, so another app store won’t be able to take over updates unless the app in question is uninstalled and reinstalled from that store. App stores can check if update ownership is enabled for an app, and if so, which app is the update owner, through the new InstallSourceInfo#getUpdateOwnerPackageName() API.

Third-party app stores must hold the new ENFORCE_UPDATE_OWNERSHIP permission to use the update ownership enforcement API, but seeing as this permission has a protection level of “normal”, it will be granted by the system at install time. However, it remains to be seen if Google Play will audit the use of this permission/API.

Install pre-approval

The last new Android 14 API I wanted to highlight is PackageInstaller.Session#requestUserPreapproval. This API lets third-party app stores request user approval before they commit an installation session. I imagine this will be useful for third-party app stores that intentionally want to prompt the user before updating an app in the background.

For example, imagine a security-focused app store wants to let its user know when an app update adds new permissions; instead of automatically updating that app, thereby automatically granting that permission if its protection level is “normal”, the app store could prompt the user before doing the update. Currently, if a user isn’t present during an automatic update, the third-party app store would have to keep track of the installation session and prompt them later. This API simplifies that process.

Android 14 will introduce loads of new features and APIs when it’s released to the public later this year. While these new APIs aren’t hidden like some of the other changes we spotted, there’s no guarantee these APIs will be available to developers in the stable release. That’s because the API freeze won’t happen until Android 14 hits “platform stability” with Beta 3 in June 2023, and we’re only on DP1 at the moment. We’ll keep an eye out on future Android 14 DP and Beta releases to see if these APIs stick around or if any new APIs relevant to third-party app stores are added.