Prepare the store application and credentials
Follow the current Android submission guide for Google Play prerequisites, service-account access and first-time submission options. Do not assume an older tutorial's first-upload restriction or Console path still applies unchanged.
Keep the service-account key out of app assets and public source. It is a privileged submission credential, not client configuration.
Submit the intended build
An illustrative command is:
eas submit --platform android
Select the correct build and submission profile. For automation, pin profile and environment deliberately rather than relying on the most recent build belonging to another branch.
Separate submission states
| State | Meaning |
|---|---|
| EAS build complete | Artifact was produced |
| Submission complete | Upload/API operation completed |
| Draft release | Further Console action may be required |
| In review | Google is evaluating the submitted changes |
| Rolled out | Release availability follows track and country settings |
The Play release documentation governs the store-side process. A successful API response is not a publishing guarantee.
Match upload and app-signing identities
Use the Expo credentials guidance and the app's Play signing setup. Do not generate a new keystore for an existing app merely because the current CI environment cannot find its credentials.
Complete declarations and test delivery
Review app access, Data safety, content rating, target API and account-specific requirements. Install the Play-delivered test build to verify sign-in, billing, native modules and update behavior.
APKLint's bundle and release tools can support pre-upload inspection. They cannot read your private release status or approve the submission. Retain the EAS build/submission identifiers and the actual Play track outcome as separate release evidence.
Name the build and submission profile
Keep build settings and submission settings distinct in eas.json. A build profile determines the artifact being produced; a submission profile determines where an existing artifact is sent. For example, an internal-test submission can explicitly target the internal track instead of inheriting a colleague's last selection. The service-account path below is illustrative and must refer to a locally available, untracked credential file when that authentication method is used.
{
"submit": {
"internal-test": {
"android": {
"serviceAccountKeyPath": "./private/play-submit.json",
"track": "internal"
}
}
}
}Read Expo's Android submission instructions for the current supported authentication setup and first-upload requirements. The example is a profile fragment: merge it with the existing project configuration rather than overwriting other build profiles. Keep the private directory excluded from version control and from packaged app assets.
Choose the exact completed EAS build by its identifier. An illustrative command is eas submit --platform android --profile internal-test --id BUILD_ID, replacing the final placeholder with the intended build ID. Before confirming, compare that build's application ID, version code, branch and creation time with the release record. A valid upload of the wrong branch is still the wrong submission.
Interpret a rejected upload by layer
If authentication is rejected, verify which service account the submission actually used and whether it can access the intended Play application. Changing the Android signing key will not repair an API authorization failure. If the error instead concerns package identity or signing, compare the uploaded artifact's package and upload certificate with the existing app's configuration. Do not create a new Play app entry as a shortcut for updating an existing application.
If the version code was already used, increment the app's release version code and produce a new artifact from source. Renaming an AAB file does not change the internal Android version code. If an initial manual upload or account requirement is outstanding, complete that identified prerequisite in the owner's Play Console workflow; repeating the same API request does not bypass it.
Prove that the chosen tester receives the build
After a successful submission, inspect the selected track and its release state. Use an eligible test account to install or update from Play, then verify the installed version code inside the app's diagnostic information or package inspection. This checks the delivery path as well as the upload operation. A screenshot of the EAS success page alone does not establish that an invited tester can obtain the build.
For an update test, start with the previous published test release and retain its data. Exercise sign-in and a native feature that depends on release signing, such as an integration configured with certificate fingerprints. Then repeat with a clean installation to separate migration defects from startup defects. Keep the EAS submission ID, Play track, version code and tester observation together; they answer different questions and make a failed release easier to diagnose.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
