Guide summary
Place an Android developer verification preflight before Fastlane upload or promotion lanes.
For: Mobile release teams using Fastlane supply, gradle or custom lanes.
Release sequence
- Read the release application ID from the same configuration used by the lane.
- Extract the certificate fingerprint from the signed APK produced by the lane.
- Call a protected checker endpoint and parse the stable state field.
- Stop the lane on NOT_REGISTERED or certificate mismatch and link remediation.
Quick facts
Use retries only for network or quota errors. A stable registration mismatch needs human remediation, not repeated calls.
Detailed guidance
Put the check after signing
A Fastlane lane should extract identity from the artifact it is about to promote. Running earlier can check the wrong flavor, package suffix or certificate.
Use sh or a small Ruby action to call the official API, parse JSON and raise a clear UI.user_error! for stable registration failures. Keep transient network handling separate so repeated calls do not hide a real mismatch.
- Build and sign first.
- Check the production application ID.
- Link the failure message to a remediation guide.
status = sh("curl --fail --silent -H 'X-Goog-Api-Key: #{ENV.fetch('ANDROID_DEVELOPER_ID_API_KEY')}' '#{endpoint}' | jq -r .state").strip
UI.user_error!("Android package is #{status}") unless status == "REGISTERED"Frequently asked questions
Should the lane retry a certificate mismatch?
No. That is a stable identity result requiring investigation.
Can the public fingerprint appear in logs?
It is not the private key, but teams can still minimize logs and retain it only in controlled release evidence.
Sources and review
Last reviewed: