You publish an app to Google Play by releasing it to a track, not by submitting it.
To publish an app to Google Play you create a release, attach an app bundle to it, write the notes and start the rollout. There is no single submit button anywhere in Play Console. Four tracks run side by side. The difference between a build a colleague opens today and a listing strangers can find is only the track you chose. If you have done publishing to the App Store, the pieces will feel familiar, with the waiting moved elsewhere.
This page goes in order: which track to pick, what the file has to be, the declarations that quietly hold a rollout, and the one gate on production.
See which track you actually needThe short version
Building the upload is the easy half, the forms are the half that stalls.
A Google Play submission is not one action. A signed app bundle is the solved part. Then Play Console wants a data safety declaration, a content rating questionnaire, a target age group, a privacy policy that actually loads, and a 1024 by 500 feature graphic. None of it lives in your code, and any of it can hold the rollout.
The second surprise is that production is gated on its own. A new personal developer account cannot go straight to the public, however finished the app is. That is a date in the calendar rather than a checkbox.
Four tracks, and the one you want first
Play Console lists four places a release can go. Internal testing, available to up to 100 chosen testers. Closed testing, available to a limited number of chosen testers. Open testing, available to testers on Google Play. Production, available to all Google Play users in your chosen countries. The same app bundle is valid on any of them.
Internal testing is where almost everyone should start. It takes the bundle production would take and puts it on the phones of people you name by email. Nothing about the listing becomes public. You find out the app crashes on a Pixel before a stranger does.
A Play Console release then follows the same steps on every track. Create a new release, upload the bundle or add one from your library, name it for your own reference, write localized release notes of up to 500 characters per language, then save the draft. Review it, pick a rollout percentage if you are updating an existing app, and start the rollout.
One rule catches people out. You cannot create a new release while an earlier one is still outstanding. Roll the staged release out to 100 percent, or remove the changes, and then the next one is possible.
Google Play Console Help, prepare and roll out a release
Try it
Which track you actually need
Most people asking how to publish do not need production yet. Pick who has to open the app.
Internal testing
Who can install it: Up to 100 testers you name
What it needs: An app bundle uploaded in Play Console, and a list of tester email addresses.
What Google Play will accept as the file
Uploading an app to the Play Store starts with the format, and the format is not negotiable. Since August 2021 new apps have to publish with the Android App Bundle, the .aab file. It is a publishing format, not an install format: it carries your compiled code and resources and defers APK generation and signing to Google Play.
That splits signing into two keys. You sign the bundle you upload with your upload key. Google signs the APKs users receive with the app signing key it holds. Updates have to come from the same key lineage, so the keystore behind your first release is the one file you cannot afford to lose.
The other rejection you will meet is the version code. It has to increase on every upload, and Play refuses a bundle whose version code it has already seen. Put that bump in whatever builds your releases.
The APK still has a job, just a different one. An .aab cannot be installed on a phone. For the app in your own hand this afternoon, with no tester list involved, you want a signed release APK with the JavaScript bundled in. Newly builds both from the same project, which is why its Android row carries an APK button and an AAB button side by side.
The declarations that hold a rollout
Most stalled first releases are not stalled on code. Play Console keeps a list of tasks that have to be complete before an app can go out, and nearly all of them are forms. A data safety declaration covering what the app collects and why, including when the answer is nothing. A content rating from the IARC questionnaire. A target audience and age group. Whether the app shows ads. Whether a reviewer needs a login to see anything at all.
Then the assets, which have fixed sizes and short limits. The app icon is a 512 by 512 32 bit PNG. The feature graphic at the top of your listing is 1024 by 500, as JPEG or 24 bit PNG with no alpha. The short description is capped at 80 characters.
Apple asks for an overlapping but different set, and the gaps are where teams shipping to both stores lose a week. The app store requirements cover the iOS half. Answer all of it before the app is finished. These are decisions rather than engineering, and each one blocks the rollout instead of warning you early.
What production asks for that testing does not
This is the requirement that surprises people who read only the upload documentation. Google asks personal Play Console accounts created after November 13, 2023 to run a closed test before they can apply for production access. At least 12 testers must be opted in to that closed test when you apply, and they must have been opted in continuously for the preceding 14 days. Organization accounts are not asked for this.
Read it as a date in the calendar. Twelve real people who install the app and leave it installed for two weeks is a recruiting job. It only starts once the app is worth installing, so the closed test has to open two weeks or more before any launch date.
Production then adds the review, the countries you select and the staged rollout. After that, every change takes the same road: new version code, new bundle, new release, new rollout. How much of that a small fix can skip has a narrower answer than people hope: auto update android app.
Google Play Console Help, app testing requirements for new personal developer accounts
What each route actually gets you
| Route | Who can install it | Needs an app bundle | Reaches the public | Updates arrive on their own |
|---|---|---|---|---|
| Signed release APK you send | Anyone you hand the file to | No | No | No |
| Internal testing | Up to 100 testers you name | Yes | No | Yes |
| Closed testing | A tester list or group you control | Yes | No | Yes |
| Open testing | Anyone who opts in on Google Play | Yes | opt in only | Yes |
| Production | Everyone in the countries you pick | Yes | Yes | Yes |
Doing this without living in Play Console
Every step above can be done by hand, and for one app that is fine. What wears people down is the repetition: version code, bundle, upload, release name, notes, rollout, then all of it again on Thursday. Google publishes a developer API for that reason.
Newly is an AI app builder: you describe an app in plain English and it writes a real React Native and Expo project you own, running it on a cloud iPhone or Android simulator while it builds. It is $25 a month and there is no free plan. The Deploy tab's Android row has four options: Simulator, APK, AAB and Play Store. APK produces a standalone release build with the JavaScript bundled in, which you install on a phone directly. Play Store connects your Google Play account and uploads the bundle to the internal testing track. Moving that same build to production is a separate step you confirm, and the review and the closed test gate still sit behind it. iOS goes out through TestFlight and App Store Connect with your own Apple Developer account.
Whatever ships it, something has to produce the artifact first, and the queue times and credentials of that step are their own subject: building the binary first. Get that reliable and the Play side becomes paperwork you have already done once.
Questions people ask about publishing to Google Play
Create a developer account, create the app in Play Console, build a signed Android App Bundle, then create a release on a track and upload the bundle to it. Name the release, write release notes, save the draft and start the rollout. Internal testing is the fastest first target. Production also needs the full store listing, every declaration and Google's review.
Describe the app, then take it through the tracks
Get a build onto a real phone first and onto internal testing second. The listing and the declarations are easier to finish once the app already exists.
Start building