Build integration

Android package registration check with Gradle

The Android Gradle Plugin can report signing information for each variant, but the final signed APK is the artifact-level check. Resolve the selected release variant, inspect its package name and certificate, then call the status API from a protected release workflow rather than every local build.

Guide summary

Use Gradle's signing report to identify a release variant, then verify the final signed APK's package and certificate before a registration check.

For: Android engineers maintaining variant-heavy applications or multiple product flavors.

Release sequence

  1. Run the Android Gradle Plugin signingReport task and select the production variant, not a debug or staging variant.
  2. Build that release variant and inspect the exact APK with apksigner verify --print-certs.
  3. Use the final application ID and APK certificate as the package-and-fingerprint inputs.
  4. Call the status API in a protected release job and stop on a stable registration mismatch; retry only eligible service or quota errors.

Quick facts

Variant overviewGradle signingReport task
Artifact checkSHA-256 on the final signed APK
ExecutionProtected release preflight
Field note

Flavors and applicationIdSuffix can produce a different final application ID. The signing report describes configured variants; if its certificate differs from apksigner output on the release APK, investigate the artifact and build configuration before querying the API.

Detailed guidance

Inspect the variant and then the built APK

The signingReport task lists signing information for the Android project's variants. Select the production flavor and build type; a debug or staging row can have a different application ID and key. The report helps identify configured signing values, but it does not prove which certificate landed in a particular output file.

Build the selected release artifact and run apksigner against that exact APK. If its package name or SHA-256 differs from the variant details you expected, stop before the API call and resolve the artifact path or signing configuration. Once the inputs match, let a protected CI job make the status request; do not make normal local builds depend on an API key.

  • Use the final application ID after flavor and applicationIdSuffix rules are applied.
  • Compare the full SHA-256 from the output APK with the intended release certificate.
  • Do not copy keystore passwords, private keys or API credentials into build logs.
  • Treat NOT_REGISTERED or a certificate mismatch as remediation work, not as a reason to retry the same inputs.
Illustrative commands; replace module and variant names
./gradlew :app:signingReport
./gradlew :app:assembleRelease
apksigner verify --print-certs app/build/outputs/apk/release/app-release.apk

Have the production package name and signing certificate ready? Query the official registration state, then use the result to choose your next step.

Run status check →

Frequently asked questions

Why not call the API directly from every Gradle build?

That can waste quota, slow local builds and spread a credential into more environments. Run the request in a controlled release preflight after signing, with the API key protected by the CI platform or an internal service.

How should flavors be represented?

Select the production variant, including its flavor and build-type suffixes. Use that variant's final application ID and verify the certificate on its signed output APK before checking registration.

Does signingReport prove the final APK uses that certificate?

It reports configured signing information for project variants. Inspect the built release APK with apksigner as a second check, especially when multiple variants or custom signing tasks write artifacts to different paths.

Sources and review

Last reviewed: