Identify each credential's role
The Expo credentials guide explains managed app-signing material. Play App Signing distinguishes the upload key from the key used for APKs delivered to users.
| Credential | Role |
|---|---|
| Upload keystore | Signs the artifact submitted to Play |
| Play app-signing certificate | Identifies the installed Play-distributed app |
| Google service-account key | Authorizes submission API operations |
| Expo access token | Authenticates the EAS/Expo workflow |
These are not interchangeable and should not all be stored in client configuration.
Compare fingerprints before changing anything
Inspect the current EAS credential and the upload certificate expected by Play. Keep a controlled backup and record who owns credential recovery.
Do not delete a working credential to troubleshoot a package-name or version-code error.
Recover through the correct process
For a lost upload key on an eligible Play App Signing app, use the documented upload-key reset process. Resetting the upload key is different from rotating the app-signing key and should not be described as changing the installed app's identity.
Restrict automation access
Store service-account and Expo tokens in controlled CI secrets. Grant only the permissions needed for the release workflow and revoke obsolete access.
Avoid displaying private key material in support screenshots or attaching it to an APK analysis request.
Test the next real submission
Build with the intended credential, inspect the artifact and submit to the appropriate test track. APKLint's signing tools can display certificate information, but they cannot access EAS credentials or verify Play's private account configuration. Retain fingerprint comparisons and the successful accepted upload as distinct evidence.
Identify which credential the rejected step used
Suppose an EAS build succeeds but submission fails. Separate an upload-certificate mismatch from a submission service-account authorization failure. The keystore signs the Android artifact; the service account authorizes the submission operation. Replacing the keystore will not grant a service account access to the app, and changing an API role will not make a wrongly signed artifact match Play's expected upload certificate.
The Expo credentials guide describes signing material, while the local-credentials guide explains that alternative workflow. Record which source the selected build profile actually uses. A protected local credentials file and remotely managed credentials need different recovery and CI handling.
Compare public fingerprints without exposing private files
Inspect the authorized credential's certificate fingerprint and compare it with Play's upload-certificate record for the same application ID. Keep a separate app-signing-certificate record for APIs used by the installed Play application. Do not place private keystores, service-account keys or Expo tokens into client configuration or a public support attachment merely to make that comparison easier.
For a lost upload credential on an eligible app, follow the documented reset workflow and wait for the expected certificate state to be confirmed before building the next submission. Deleting a working credential to troubleshoot a reused version code or wrong package name creates an unrelated problem. Check profile inheritance too: a production profile may select a different credential source from the preview profile that just succeeded. Preserve the resolved profile and public fingerprint as evidence instead of assuming every build in the same Expo project signs identically.
After correction, produce a new traceable test candidate and inspect its identity before submission. Record EAS build ID, profile, source revision, application ID, version code and artifact digest. Keep successful artifact signing, accepted submission and installed test-track behavior as separate observations. Verify that certificate-bound authentication still works under the app-signing identity users receive. Restrict automation tokens to their authorized scope and remove obsolete access through the account's normal process. A credential repair is complete when the intended build and submission path works with the correct public identities, while recovery information and private material remain under controlled ownership.
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
