Publishing to Google Play
🚀 Publishing to Google Play
🔑 App Signing — Every Release Build Needs a Key
An unsigned APK can't be installed on a real (non-debug) device at all — every release build must be signed with a private key that cryptographically proves subsequent updates genuinely come from the same developer. Android Studio's Build → Generate Signed Bundle/APK wizard creates a new keystore (a .jks file) on first use, or reuses an existing one:
Upload Key
The key used to sign the build actually uploaded to Play Console — kept by the developer, but if lost, Google Play's account recovery process can help re-establish a new one (this wasn't always true historically, which is why the next concept matters).
App Signing Key (Play App Signing)
Google Play itself holds the real signing key used for the final distributed APK, re-signing the uploaded bundle with it — this is now the default and strongly recommended, since Google securely manages the key that would otherwise be an unrecoverable single point of failure if lost.
Before Play App Signing existed, losing the signing keystore meant permanently losing the ability to publish updates to an already-published app — a new app (a new listing, zero existing installs or reviews) was the only option. Play App Signing genuinely solves this, but it's worth understanding why signing keys were treated with such extreme care historically, and still deserve real care today (the upload key itself still matters).
📦 Android App Bundle (AAB) — The Modern Format
Google Play requires uploads in AAB format (.aab), not a traditional universal APK — a bundle contains everything for every device configuration, and Play itself generates and serves an optimized, smaller APK tailored to each specific installing device (screen density, CPU architecture, language) rather than shipping resources for every configuration to every user:
Universal APK vs App Bundle
| Universal APK | App Bundle (AAB) | |
|---|---|---|
| Contains | Every resource, for every device config, in one file | Everything, but split and served per-device by Google Play |
| Download size for the user | Larger — includes unused configs | Smaller — only what that specific device needs |
| Where it's built | Locally, ready to install directly | Google Play's servers generate the final APK from the bundle |
| Google Play requirement | No longer accepted for new apps | Required |
🖥️ Play Console — Setting Up the Listing
A new app in Play Console requires several pieces of information beyond just the build itself before it can go live:
- Privacy policy URL — required for essentially every app, hosted somewhere the developer controls.
- Content rating questionnaire — a series of questions (violence, user-generated content, etc.) that determines the age rating shown on the store listing.
- Data safety form — a declaration of exactly what data the app collects and how it's used/shared, shown to users before install — this maps directly onto whatever Course 2's networking and DataStore chapters actually collect and store, and must be accurate, not just filled in generically.
🖼️ Store Listing — What Users See Before Installing
Required Assets
A title (30 characters), a short description (80 characters), a full description, at least 2 screenshots, a feature graphic (1024×500), and an app icon — all directly visible on the store page before anyone taps Install.
App Store Optimization (ASO)
Choosing title/description wording that matches how people actually search, similar in spirit to SEO for a website (HTML course territory) — genuinely affects discoverability, not just aesthetics.
🛤️ Release Tracks — Reaching Users Gradually
A build doesn't have to go straight to every user — Play Console offers several tracks, each reaching a progressively wider audience:
Release Tracks, in Order of Reach
| Track | Who Sees It |
|---|---|
| Internal testing | A small, manually-specified list (e.g. the dev team) — near-instant availability, no review delay |
| Closed testing (alpha) | A larger, invite-only group (an email list, a Google Group) |
| Open testing (beta) | Anyone who opts in via a public opt-in link — real, wider feedback before full release |
| Production | Everyone on Google Play — can itself be a staged rollout, e.g. 10% of users first |
A staged production rollout (say, 10% → 50% → 100% over several days) lets a serious bug affect only a fraction of users before it's caught and halted — genuinely valuable given how much slower a store release is to "roll back" compared to redeploying a web server.
Publishing to Google Play vs Deploying a Web App
| Web (Node Course 3 deployment) | Google Play | |
|---|---|---|
| Deploy speed | Minutes — push to a server/container | Hours to days — Google review process |
| Rollback | Redeploy the previous version immediately | Publish a new version and wait for review again |
| Gradual rollout | Feature flags, canary deploys, load balancer weighting | Staged rollout percentage, built into Play Console |
| User control over updates | None — the server just changes | User can delay/decline updating an installed app |
That last row is the most consequential practical difference: unlike a web deploy where every user is instantly on the new version, an Android update only reaches users who actually update — which is why backward compatibility (a client from months ago still calling a live API) matters more here than it typically does for a tightly-coupled web frontend/backend pair.
💻 Coding Challenges
Challenge 1: Configuring Release Signing in Gradle
Write the signingConfigs and buildTypes blocks in app/build.gradle.kts for a release build referencing a keystore file, storePassword, keyAlias, and keyPassword (using placeholder values, sourced from local.properties or environment variables rather than hardcoded — explain why in a comment).
Goal: Practice the Gradle-side signing configuration, and the reasoning for keeping credentials out of source control.
Challenge 2: A Release Checklist
Write a checklist (as comments) of everything that must be true before a build can go live in production on Play Console, referencing specific requirements from this chapter (signing, AAB format, privacy policy, content rating, data safety form, store listing assets).
Goal: Practice recalling the full set of prerequisites, not just the technical build step.
Challenge 3: Choosing a Release Track
For each scenario, name the appropriate release track and why: (a) the very first build, wanting only the two-person dev team to try it, (b) a build ready for broader feedback from 500 opted-in volunteers, (c) a routine update to an already-live app, being cautious about a risky change.
Goal: Practice matching a release scenario to the correct track and rollout strategy.
Everything through Chapter 6 makes a genuinely good app; this chapter is what actually gets it in front of real users. In practice, the non-technical pieces (privacy policy, content rating, store assets, waiting for review) often take longer than producing the signed AAB itself — worth planning for as real project time, not an afterthought squeezed in after "the code is done."
🎯 What's Next
Next chapter — the final chapter of this course: Firebase Integration — Crashlytics, Analytics, Remote Config, and FCM push notifications.