Codemagic Google Play "Package not found": the first upload rule
· 5 min read
The first time a new Android app is published to Google Play from Codemagic, there is a good chance it fails with "Package not found". Codemagic has a help center article about it, and the same question shows up on Stack Overflow. The cause is almost always on the Google Play side, not in your codemagic.yaml. This guide explains the rule, the other usual causes, and how Play tracks work, since that is the next question. Codemagic facts are as read on docs.codemagic.io and help.codemagic.io on November 5, 2026.
The first upload rule
The Google Play Developer API, which Codemagic and every other CI use, can only work with an app that Play already knows by its package name. Creating the app in Play Console is not enough. Codemagic's help article on this error says the first upload has to be done by hand, and its common Google Play errors page lists it too.
So the order for a new app is:
- Create the app in Play Console.
- Build a signed .aab (Codemagic can do this; download the artifact).
- Upload that .aab by hand in Play Console to a testing track, for example internal testing, and save the release.
- Run the Codemagic workflow with Google Play publishing from then on.
A related rule for brand new apps
We hit a second rule ourselves on November 5, 2026, while sending our own Android app to Google Play through the API. Until an app has been published once, Google Play refuses API releases that are not drafts, with the message "Only releases with status draft may be created on draft app". We had to send the first production release for review from Play Console.
Codemagic's Google Play publishing has a submit_as_draft option, which fits this case. If you see that message, publish as a draft and finish the release in Play Console.
Other causes of "Package not found"
| Cause | What to check |
|---|---|
| No build was ever uploaded | The first upload rule above |
| Package name differs | applicationId in android/app/build.gradle.kts (including flavor suffixes) against the app in Play Console |
| Service account has no access to the app | Play Console, Users and permissions: the service account email must be invited, with access to this app |
| Wrong service account JSON | The key in the Codemagic variable belongs to the Google Cloud project you linked, and to the account you invited |
| Wrong Play developer account | Agencies with several accounts: the app lives in the account the service account was invited to |
The publishing block in codemagic.yaml
Codemagic's Google Play publishing docs list these options: track (internal, alpha, beta, production or a custom track), rollout_fraction, in_app_update_priority (0 to 5), release_name, changes_not_sent_for_review, submit_as_draft, and release_promotion to move a release to another track. A minimal block:
publishing:
google_play:
credentials: $GCLOUD_SERVICE_ACCOUNT_CREDENTIALS
track: internal
submit_as_draft: trueGoogle Play tracks, explained plainly
A Codemagic docs issue asks for "more detailed documentation on how Google Tracks work", so here is the short version:
| Track | Who gets it | Review |
|---|---|---|
| Internal testing | Up to 100 testers you add by email list in Play Console | Fast; meant for quick checks |
| Closed testing (alpha, or custom) | Testers in email lists or Google Groups | Reviewed by Google |
| Open testing (beta) | Anyone who joins from the Play listing | Reviewed by Google |
| Production | Everyone, or a percentage during a staged rollout | Reviewed by Google |
Testers on Play tracks install from the Play Store app. That needs a Google account on the phone and an opt in. For quick test builds to clients, many teams use an install link for an APK instead and keep Play tracks for release candidates.
A staged rollout in Codemagic is a fixed rollout_fraction per publish. Raising it later means another publish or a change in Play Console. We did not find an automatic rollout ramp in Codemagic's docs.
Sending the .aab from AppForShare instead
If your team already uploads Codemagic builds to AppForShare for testers, the same .aab can go to Google Play from there. On Pro, an Admin sends an uploaded .aab to an internal, closed or open testing track with a confirm tick, with an optional release name (up to 50 characters) and in-app update priority 0 to 5. On Team, it can also be saved as a production release draft, and the Google Play releases page handles staged rollouts, halts and rollout plans an Admin sets once.
It uses the same Google Play API, so the first upload rule and the draft app rule apply here too: make the first upload by hand. Nothing is sent to Google Play unless a person asks for it.
Common questions
I uploaded by hand and it still fails. Why?
Check the service account's access to that specific app in Play Console and the package name, including flavor suffixes. Those two cover most remaining cases.
Can testers install the .aab directly?
No. Phones cannot install an .aab. Google Play builds APKs from it for each device. For a test link, upload the .aab to AppForShare and testers get one APK made from it, or build an APK in Codemagic.
Does Codemagic or AppForShare send my app for review?
Every release on a reviewed track goes to Google's review. Neither tool can skip it.
For the iOS side of store publishing, see Codemagic TestFlight publishing errors. For the full picture of what to keep in Codemagic, read Use AppForShare with Codemagic, and create a free account to try an .aab upload.
