how to fix fastlane supply failed with error "package not found" on Play upload

TL;DR

Fix the package name mismatch between the Fastfile supply configuration and the app in Play Console. supply looks up the app by package name, and a wrong, renamed or environment-specific package name returns package not found even though the app exists. Copy the exact applicationId from the built bundle or Console, set it in the supply call, and confirm the service account has access to that app.

package not found - fastlane supply Play upload

Use this when

• fastlane supply fails with package not found while other lanes or manual uploads work.
• The app has separate package names per flavour or environment.
• A new service account was granted access recently.

Not for this skill when

• The service account lacks release permissions entirely. That surfaces as a permissions error once the package resolves.
• The app is unpublished under a different developer account. Package lookup is scoped to the account.

Steps

1. Read the package name from the built AAB manifest or the applicationId in Gradle, not from memory or the app name. Verify: the exact applicationId string is captured
2. Compare it character by character with the package_name value in the Fastfile or supply options file. Verify: any difference in suffix, underscores or environment segment is found
3. Check Play Console under the developer account the service account belongs to and confirm the app with that package is listed. Verify: the app appears in that accounts app list
4. Confirm the service account is invited to that specific app with at least release access in Users and permissions. Verify: the service account shows active with release permissions for the app
5. Run supply with the corrected package name, ideally with a metadata-only or validate-only change first. Verify: supply finds the app and completes the validation run
6. Run the full supply upload. Verify: the release appears in Console on the intended track
7. Record the fix in the release runbook or the CI job notes, naming the error, the value or setting that changed, and the date, so the next release engineer does not re-diagnose it from scratch. Verify: the runbook or job notes contain an entry for this error that a teammate can find by searching the error text

Why it happens

supply addresses apps purely by package name through the Play Developer API. Flavoured builds, renamed applications and multi-account setups make it easy to point at a package the API account cannot see, and the APIs answer for an invisible app is the same as for a nonexistent one: package not found. The error is about lookup, not about the artefact.

In practice this failure is rarely a one-off. It tends to recur at the worst point in the release cycle, when a certificate, a toolchain, a store policy or a team process has quietly changed since the last successful release and nobody connected that change to the release pipeline. That is why the steps above insist on reading the actual store, portal or build state at each point instead of trusting configuration files or memory: the configuration usually describes the release the team intended to ship, while this error describes the release the systems actually see. Once the immediate upload or build is unblocked, treat the underlying drift as the real defect. Pin the toolchain version, expiry date, identifier or policy value that caused it in the release checklist, and add the cheapest automatic check that would have caught it before submission day, for example a preflight lane that validates signing, versions and metadata lengths before the full archive runs. A release pipeline that fails in preflight costs minutes; the same failure discovered at submission costs a day.

Variants and edge cases

supply package not found fastlane fix

Fastlane phrasing; compare applicationId against the Fastfile value. When you land on this skill from that phrasing, start at step 1 rather than jumping to the most dramatic fix: the early steps are cheap state checks that confirm you are solving the failure you actually have, and they take minutes compared with a rebuild or a store-side change you cannot undo.

googleplaytrack package not found service account

Service account phrasing; check app-level invitation as well as the name. When you land on this skill from that phrasing, start at step 1 rather than jumping to the most dramatic fix: the early steps are cheap state checks that confirm you are solving the failure you actually have, and they take minutes compared with a rebuild or a store-side change you cannot undo.

Edge case: staged package renames

Old store listings under a retired package name stay in the account. Make sure you target the live package, not the retired one. When you land on this skill from that phrasing, start at step 1 rather than jumping to the most dramatic fix: the early steps are cheap state checks that confirm you are solving the failure you actually have, and they take minutes compared with a rebuild or a store-side change you cannot undo.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstrA0b7pl7w27qn8Mi3ofVg