MainSDK
Search⌘K
Integrations

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.

1 interface1 driverWritten guide
Updated 2026-10-28

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.

Before you start

You need a Google Play developer account and an app published in the Play Console.

  1. 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.
  2. Note your package name. It identifies the app on Google Play.
  3. Version consistently. Google Play orders builds by version code; keep the user-facing version in semantic versioning (2.4.1) so updates can compare versions.

Configure

Set the driver for your app's Android build:

main.yaml
updates:
  driver: google-play
  # [to be decided] how the minimum version and the flexible or immediate mode are declared

The 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

app/startup.ts
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/testing runs updates on an in-memory fake, so tests reach no app store, and chaos.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 analytics before you block.

See App updates and version blocking for the full contract.

Limits and notes

  • Planned driver, not in a spec yet: updates is 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

main.yaml
updates:
  driver: google-play   # was expo-updates

Your 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?

↑↓ moveEnter openEsc close

Not decided yet