Google Play
Use Google Play for MainSDK app updates on Android - Play In-App Updates, minimum versions enforced on the server, main.yaml, testing and swapping.
The Google Play driver serves updates for Android apps through Play In-App Updates. When a new version is ready, users get a flexible prompt that downloads in the background or an immediate, full-screen update; when a version is too old, they see an "Update required" screen and your server refuses requests from it. Pick it for any Android build you ship through Google Play, next to the App Store for iOS.
Interfaces it serves
Pick Google Play in main.yaml for any of these. Your calls stay the same, and you can swap later.
updatesBuilding for 0.7Driver google-play Google Play
1.1; wraps a Play In-App Updates bridge by shape
updates:
driver: google-playSwap to another provider
Before you start
You need a Google Play developer account and an app published in the Play Console.
- Publish through Google Play. In-App Updates only work for apps installed from Google Play, so test with a build from a Play testing track, not a sideloaded APK.
- Note your package name. It identifies the app on Google Play.
- Version consistently. Google Play orders builds by version code; keep the user-facing version in semantic versioning (2.4.1) so
updatescan compare versions.
Configure
Set the driver for your app's Android build:
updates:
driver: google-play
# [to be decided] how the minimum version and the flexible or immediate mode are declaredThe mobile target is one target with platforms: [ios, android]; how you give Android and iOS different updates drivers is not decided yet. How you declare the minimum version, the update mode, and staged rollout percentages and markets is not decided yet.
Use it
import { updates } from "mainsdk";
export async function onStartup() {
const u = await updates.check();
if (u.required) showUpdateScreen(u); // immediate update for blocked versions
}updates.minVersion() sets the oldest version you still accept. The change is audited and the server refuses older versions. Its arguments arrive with the spec.
Local development and testing
- Play testing tracks: use internal testing to try the flexible and immediate flows with a real Play install.
- Tests:
createTestApp()from@mainsdk/testingrunsupdateson an in-memory fake, so tests reach no app store, andchaos.on("updates", { outage: true })simulates the update check failing. Helpers to set a minimum version on the fake arrive with the spec.
What MainSDK adds on top
- Blocking enforced by the server as well as the app, so a modified client cannot skip it.
- Blocked users can still export their data.
- Every change to the minimum version audited.
- Version spread from
analyticsbefore you block.
See App updates and version blocking for the full contract.
Limits and notes
- Planned driver, not in a spec yet:
updatesis phase 2. - In-App Updates need the Google Play app on the device; builds from other stores need another driver.
- JavaScript-only changes can go over the air with Expo Updates.
- MainSDK Cloud Teams adds release dashboards; Fleet adds fleet-wide version rules.
Swap to or from it
updates:
driver: google-play # was expo-updatesYour updates.check() and updates.minVersion() calls stay the same.
FAQ
Flexible or immediate? Flexible suits ordinary releases: users keep working while the update downloads. Immediate suits versions you are blocking, such as after a security fix.
Why doesn't the prompt show on my test device? In-App Updates only apply to builds installed from Google Play. Install from a testing track.
Next
Open questions
Was this page helpful?