What the Play Store process looks like

The bit nobody puts in the tutorial

You have a signed release build. Getting it onto Google Play is not one step. It is roughly fifteen, spread over days, and about four of them have nothing to do with code at all.

This lesson is the honest version. Not to put you off — thousands of people do this every week — but because the single most demoralising thing in software is discovering a requirement you were never told about, three hours after you thought you had finished.

The checklist, in full

Every item below is required before a first app can go live. None of them can be skipped.

1. A Play developer account. A one-off registration fee of about 25 US dollars, paid once, ever — not per app and not per year.

2. Identity verification. For a personal account, Google checks you are a real named person, with an identity document and an address. This takes time and it happens before you can publish anything.

3. A signed release AAB. Not an APK. Play stopped accepting APKs for new apps some years ago. The Gradle task is bundleRelease.

4. An app icon. 512 by 512 pixels, PNG, with no transparency. Note that this is a separate file from the adaptive icon inside your app — Play does not extract one from your APK, you upload it.

5. A feature graphic. 1024 by 500 pixels. The banner across the top of your listing. Required even if you think it is ugly.

6. Screenshots. At least a couple of phone screenshots, and Play has minimum sizes. Take them on your own phone, running your own app.

7. A store listing. App name, a short description capped at 80 characters, and a full description up to 4,000. The short one is what people actually read.

8. A privacy policy URL. A real, public, permanently reachable web page. This catches almost everybody, because it is the one item that is not about the app at all. Even an app that collects nothing needs a page saying it collects nothing.

9. A content rating questionnaire. You answer questions about violence, language, gambling and so on, and Play issues the official rating from your answers.

10. A data safety form. What your app collects, whether it leaves the device, whether it is shared. "No data collected" is a completely valid answer, and for all three apps in this course it is the true one — but you still have to fill the form in.

11. Meeting the target API level rule. Play requires new apps to target a recent Android version, and that bar rises every year. See Lesson 2.7 for what targetSdk actually does; the point here is that an old value will simply block the upload.

12. A period of closed testing. New personal developer accounts have been required to run a closed test — a set number of testers, opted in for a continuous run of days — before a first public release is allowed.

13. Review. Partly automatic, partly a human being. Hours if you are lucky. Commonly a few days. A first app from a brand-new account can take considerably longer.

Why an AAB and not an APK

You spent Lesson 2.8 learning what an APK contains. Here is the twist: you do not upload one.

An APK has to contain everything for every phone — every screen density of every picture, every ABI of every native library, every translation. Most of that is dead weight on any one device.

An AAB is a package of everything needed to make APKs. You upload it once, and Play generates a tailored APK per device: that phone's screen density, that phone's chip, that phone's language. Users download less. You do nothing extra.

1:app:assembleRelease
2  -> app/build/outputs/apk/release/app-release.apk
3
4:app:bundleRelease
5  -> app/build/outputs/bundle/release/app-release.aab

An AAB is not installable. You cannot tap it on a phone and get an app. It is a shipping crate, not a product.

This is also why Play App Signing is not optional for new apps: Play has to build those per-device APKs itself, and something has to sign them. You sign the bundle with your upload key; Play signs each generated APK with the app signing key it holds.

The four numbers that matter at upload time

Everything Play cares about in your build file lives in one block.

The tracks, and why you should not start at the end

Play Console releases go down one of four release tracks. A build is promoted between them; you do not re-upload.

Start on internal testing. Always. It costs nothing, arrives in minutes, and catches the embarrassing category of problem — the wrong icon, a crash on first launch, a screen that only worked because your phone had test data on it.

When you do reach production, use a staged rollout: release to a small percentage first, watch the crash reports for a day, then widen. It converts "my app is broken for everyone" into "my app was briefly broken for a few people", which is an entirely different kind of morning.

What it actually feels like

A realistic first run, assuming nothing goes wrong:

The graphics and the writing take longer than the code. Everyone is surprised by that once.

You do not have to publish anything

Worth saying clearly, because Part 6 can read as though Play is the finish line. It is not.

An APK you build is a real app. You can send it to someone in a message, they can install it after allowing installs from that source, and it will run exactly as it runs on your phone. No account, no fee, no forms, no waiting. That is how every app you have built in this course already works.

Play is for reaching strangers. If the people you want to reach are your family, your class or your football team, the pavement table is genuinely the right answer.