Operational summary
A release workflow can check the production application ID and certificate fingerprint before promotion. The API key should remain an encrypted CI secret or behind a controlled internal proxy.
Recommended sequence
- Resolve the production application ID from the release variant.
- Extract the public SHA-256 fingerprint from the signed artifact.
- Call the official status API through a protected job or team endpoint.
- Fail promotion on unresolved or mismatched status, with a manual override policy.
A release-gate job
Run the check after the release APK is signed and before store promotion. Put the Google API key in GitHub Actions secrets, restrict it to the Android Developer ID Status API and avoid pull-request contexts where untrusted code can access release credentials.
Parse the state field with jq. Fail immediately on stable unresolved states, but use bounded exponential backoff for RESOURCE_EXHAUSTED, INTERNAL and UNAVAILABLE responses.
- Never echo the API key.
- Pin third-party Actions used in the release job.
- Store the status artifact without signing secrets.
- name: Check Android registration
env:
API_KEY: ${{ secrets.ANDROID_DEVELOPER_ID_API_KEY }}
PACKAGE_NAME: com.example.app
run: |
curl --fail --silent --show-error \
-H "X-Goog-Api-Key: $API_KEY" \
"https://androiddeveloperidstatus.googleapis.com/v1/packages/$PACKAGE_NAME/packageRegistrationStatus:check" \
| tee status.json
test "$(jq -r .state status.json)" = "REGISTERED"Frequently asked questions
Should CI call PkgReady's browser endpoint?
No. CI should call the official server-to-server API with a protected key owned by your organization.
What should fail the release?
Fail on NOT_REGISTERED or a certificate mismatch. Treat quota and service errors as infrastructure failures with bounded retries.
Sources and review
PkgReady summarizes operational implications but does not replace an official console or Android documentation. Reviewed 2026-08-14.