From native release to signed update.

1. Create your workspace and application

Sign in, verify your email, and create a workspace. Add your Android application ID. The service prepares separate staging and production deployments. Open an application to find its SDK repository, deployment identity, public control key, and Gradle configuration.

2. Establish the native contract

Apply the Code Push Gradle plugin to the app. Choose the patch entry point and expose only the host capabilities that code needs. Keep Android permissions, platform integrations, dependencies, and signing identities in the native build.

Generate a patch signing key locally and store its private part outside the source repository. Pin the corresponding public key and the deployment’s public control key in the APK. The service never needs your patch private key.

3. Build and preserve the release

Build the native release and archive its exact baseline, toolchain identity, and APK. Register that baseline with the deployment using the authenticated CLI. Native release IDs are immutable: use a new ID for a new baseline.

Keep the baseline as a build artifact. Patches must be compiled against the baseline embedded in the installed APK, including the same host API and native inputs.

4. Connect the application lifecycle

Install the runtime before calling the patch entry point. Load and verify the selected baseline or patch from app-private storage. Check for updates after the first usable frame, and confirm a launch only once the relevant application flow is healthy.

A failed startup is rejected on the next launch. Recovery selects a previous healthy patch when available, then the baseline. The runtime does not replace guest code in a running process.

5. Publish and observe

Change code inside the supported guest boundary, compile against the preserved baseline, and sign the patch locally. The CLI uploads the original signed envelope and immutable artifact. Start with staging and a small production rollout.

Use the release page to choose a patch and rollout percentage. Tester installation hashes can receive an offer independently of the percentage. Device reports show observed checks and launches; offline devices appear after they reconnect.

6. Pause or recover

Pause a rollout to stop new activations while retaining previously healthy patches. Permanently revoke an artifact when it must be rejected. Devices apply the new signed policy on a successful update check; revocation cannot take effect immediately on an offline device.

Keep distribution requirements in your release process

Code push does not replace app-store review or grant permission to distribute every possible change. Review the current policies for the store that distributes your app and keep native updates available.