CI integration

Android package registration CI: GitHub Actions

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.

Guide summary

Add a privacy-conscious Android package registration preflight to GitHub Actions without exposing the Google API key.

For: Teams using GitHub Actions for Android build, signing and release automation.

Release sequence

  1. Resolve the production application ID from the release variant.
  2. Extract the public SHA-256 fingerprint from the signed artifact.
  3. Call the official status API through a protected job or team endpoint.
  4. Fail promotion on unresolved or mismatched status, with a manual override policy.

Quick facts

SecretGoogle API key
Safe build outputPublic certificate SHA-256
Recommended gateBefore store promotion
Field note

Never print the API key, keystore password or private signing key in Actions logs. A public certificate fingerprint is not the private key.

Detailed guidance

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.
GitHub Actions step
- 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

Last reviewed: