Publishing your app on Google Play

Android signing keystore

• Keystore file — .jks format only.
• Store password — protects the keystore file.
• Key password — protects the key inside it (often the same as the store password).
• Alias — the key's name inside the keystore, must match exactly.
• App build scheme — 64 bit for smaller, modern-device builds, or 32 & 64 bit for wider compatibility.
• SHA-1 / SHA-256 — shown automatically once the key exists; needed for Firebase and Google API setups.

Lost your keystore?

If your app uses Play App Signing, download the PEM certificate from your app's signing step, then in Play Console go to Test and release → App integrity → App signing and choose Request upload key reset, uploading that PEM file. Once Google approves, update the keystore details here and rebuild. This resets the upload key only — not the Google Play app signing key.

Native Google account picker

Under Native features you choose how sign-in behaves. The simplest option, Open the phone's browser, sends people to your normal website login in a Chrome tab and brings them back to the app afterwards — it works with any login and needs no setup. Keep sign-in inside the app runs the login in the app's own window, and Android account picker shows Android's account sheet. If any of them cannot finish, the app falls back to the normal web login so nobody gets stuck.

Only the account picker needs setup — these steps apply to that option:

1. In Google Cloud, create an OAuth Android client using the package name and SHA-1 fingerprint shown next to the switch, and an OAuth Web client in the same project.
2. Paste the Web client ID into the first field — that is the one the app signs in with. The Android client ID only has to exist in Google Cloud; the builder asks for it so you can confirm both belong to the same project.
3. The app finishes the sign-in itself: it hands the account to the website's own Google callback when there is one, otherwise it signs the person in against the website's backend and reloads the page. The backend address and public key are detected automatically on most sites; if the picker keeps returning people to the login page, fill those two optional fields in the Google panel.
4. If the app cannot complete the sign-in, it leaves the Google login alone entirely — the normal web login runs from start to finish, so you never get stuck in a loop.
5. If you prefer to handle it yourself, the token also arrives as window.AppForgeGoogleIdToken and as an appforge:google-token event, and you can trigger the sheet with await window.AppForgeGoogleSignIn().
6. Your website has to trust the same Web client. A site using the built-in Google sign-in that came with its hosting only trusts that built-in Google app and will reject the account the picker returns. In your website’s settings open Users → Auth Settings → Sign in methods → Google, switch to your own Google credentials, and paste the Web client ID and secret from the same project — plus your site’s sign-in callback address in that Web client’s authorised redirect URLs. If you would rather not change your site, leave the account picker off: the in-app Google login still works, it just shows the normal Google page.
7. Publishing on Google Play? Play re-signs your app, so also add the SHA-1 shown in Play Console under App integrity to the same Android client — otherwise the picker works on the file you download here but not on the Play install.

window.addEventListener('appforge:google-token', async (e) => {
  await supabase.auth.signInWithIdToken({
    provider: 'google',
    token: e.detail.idToken,
  });
});

How long your files are kept

We keep only the most recent APK or AAB for each app. When a new build of the same app finishes, the previous file is deleted automatically to save storage, and its download link stops working. Download anything you want to keep before starting another build — your app settings, signing key and store listing are never deleted.

Publishing to Google Play

Everything Google asks for at upload, in the order you will meet it.

1. Pick a permanent package name. It can never be changed once published, and com.example.* is rejected.
2. Target Android 16. Since 31 August 2026 Google Play only accepts apps targeting API level 36 or higher. Every build we make targets API 36 with a minimum of API 23, so you are covered.
3. Create your signing key on the Signing tab and keep the download safe. Play App Signing re-signs your app for distribution, but this upload key is how Google recognises your updates.
4. Choose AAB output and build. Play does not accept APKs for new apps — the APK is for your own testing.
5. Fill in the Store listing tab: title (30 characters), short description (80), full description (4000), category, a 512x512 icon, a 1024x500 feature graphic, and at least two phone screenshots between 320 and 3840 px on every side.
6. Add a privacy policy URL. Play requires a public https page for every app, and refuses release without it.
7. Answer the content rating and data safety questions in the builder, then copy them across in Play Console.
8. Export the listing pack — a zip with your images and all the text, ready to drag into Play Console — then upload the AAB under Test and release.

APK or AAB?

Use the .apk for direct installs and testing. Use the .aab for the Play Store — Google requires it for all new apps.