rea-reverse

Android Developer Verification: Package Name and SHA-256 Cert

Written for REA 6.4.0Updated 7 min read
On this page

Short answer: to register an app for Android developer verification outside Google Play, you need two values from your own build: the package name and the SHA-256 fingerprint of the certificate that signs it. For packages that already exist, you also prove that you hold the private key by signing an APK that contains a snippet the console gives you. Both values can be read from the finished APK or AAB in a few seconds with this site’s APK & AAB analyzer, in your browser and without uploading the file, and cross-checked with apksigner or keytool.

Who this is for: developers who distribute Android apps outside Google Play (their own website, other stores, enterprise or community channels), and Play developers who also ship APKs elsewhere.

What you will learn:

  • What applies from 2026-09-30, and what does not apply yet
  • Which console to use and what it asks for
  • How to read the package name and certificate SHA-256 from an APK, an AAB and a keystore
  • Which key to register with Play App Signing, key rotation or several signers
  • Common mistakes: debug keys, lost keys, package names you don’t own

The policy facts below come from Google’s developer verification pages, which I re-read on 2026-10-14. They change, so check the linked pages before you rely on a date. The fingerprints come from APKs and an AAB I built and signed with my own throwaway keys.

What applies and when

From Google’s overview and FAQ:

  • From 2026-09-30, protections apply to users in Brazil, Indonesia, Singapore and Thailand on certified devices running Android 7+, for apps installed from the participating stores: Google Play, HONOR App Market, OPPO App Market, Samsung Galaxy Store, Transsion Palm Store, vivo V-Appstore and Xiaomi GetApps.
  • In 2027, Google says verification “will be expanded globally for all apps on certified Android devices”. No exact date is published.
  • Sideloading and other stores are not covered yet. The FAQ: “If you distribute your app through other stores, or if users sideload your app directly, these new verification requirements won’t apply to your app yet.” It still recommends verifying before the 2027 rollout.
  • ADB is unchanged. “As a developer, you are free to install apps without verification with ADB.” Your local test workflow keeps working.
  • For apps from unverified developers, users can turn on an “advanced flow” with a one-time setup.

So if you distribute outside Play, nothing breaks today unless you ship through one of the listed stores to users in those four countries. The 2027 rollout is the deadline to plan for.

Which console, and what it asks for

  • Only on Google Play: Google says Play registers “99% of apps” automatically, and apps that use Play App Signing are claimed automatically. Check the Play Console home page for anything left over.
  • On Play and elsewhere: use Play Console to register the apps you distribute outside Play as well.
  • Only outside Play: sign up for the Android Developer Console. Its registration steps are, in Google’s words:
    1. “Enter the package name”
    2. “Enter the SHA-256 certificate fingerprint from your app’s signing key pair.”
    3. “For existing package names, you must sign an APK with your private key and upload it. The Android Developer Console provides a snippet to add to the APK’s asset folder for this challenge.”

Account types are a separate step. Full distribution requires identity verification (government ID and proof of address for individuals; organizations add a D-U-N-S number and a website verified in Search Console). Limited distribution, for students and hobbyists, needs no ID and reaches up to 20 devices. Check the guides for current fees.

Step 1: Read the package name and SHA-256 from your build

Open the APK & AAB analyzer and drop your release APK or AAB, the build you actually ship, not a debug build. Two places matter:

  • Summary → Package. This is the package attribute of the manifest, the application ID users see in settings.
  • Signing. One block per signer and scheme, each with subject, validity and a SHA-256 line. That line is the certificate fingerprint the console asks for.

For my release APK verifydemo.apk (versionCode 7), the analyzer showed (trimmed; each signer block repeats the same SHA-256):

Package:   dev.example.verifydemo
Signature schemes: v1, v2, v3
Signer 1 · v1  CN=Example Release,O=Example,C=US
Signer 2 · v2  CN=Example Release,O=Example,C=US
Signer 3 · v3  CN=Example Release,O=Example,C=US
SHA-256    1b9aafb13d527001813e0c2d212ff035c57c003434ceeaf705be8cc736b3f4d0

All three schemes carry the same certificate, so there is one fingerprint to register. The analyzer prints it as 64 lower-case hex digits, without colons.

Cross-check with apksigner

apksigner verify --print-certs verifydemo.apk
Signer #1 certificate DN: CN=Example Release, O=Example, C=US
Signer #1 certificate SHA-256 digest: 1b9aafb13d527001813e0c2d212ff035c57c003434ceeaf705be8cc736b3f4d0
Signer #1 certificate SHA-1 digest: 97f43bd7b7c773453c8c44d18255f914d0ea2690

Use the certificate SHA-256. With -v, apksigner also prints a “public key SHA-256 digest”. That is a hash of the key alone, not of the certificate, and it is a different value.

From an AAB

An Android App Bundle is signed with jarsigner, so it has only a v1-style signature under META-INF/. I signed verifydemo.aab with the same key. The analyzer recognized it as an AAB, read dev.example.verifydemo from the base module’s manifest, and showed one v1 signer with the same SHA-256, 1b9aafb1…f4d0. keytool agrees:

keytool -printcert -jarfile verifydemo.aab
Signer #1:
Owner: CN=Example Release, O=Example, C=US
	 SHA256: 1B:9A:AF:B1:3D:52:70:01:81:3E:0C:2D:21:2F:F0:35:C5:7C:00:34:34:CE:EA:F7:05:BE:8C:C7:36:B3:F4:D0

Same value, upper case with colons. Normalize the format the console expects before you paste it.

From the keystore

If you have the keystore but no build at hand:

keytool -list -v -keystore release.jks -alias release

It printed the same SHA256: 1B:9A:AF:…:F4:D0 for my key. This is also the quickest way to confirm that the keystore in your CI secret store is the one that signed the shipped builds.

Step 2: Pick the right key

Play App Signing. Google re-signs the APKs it delivers with the app signing key it holds, and those apps are claimed automatically. The certificate in an AAB you upload is your upload key, not the key users’ devices see. If you also publish APKs outside Play that you sign yourself, those carry a different certificate from the Play copies. Register the apps you distribute outside Play through Play Console, as Google recommends for that case. The app signing page in Play Console lists the SHA-256 of both keys, so you can compare them with the analyzer.

Several signers or key rotation. The Android Developer Console “lets you add and verify multiple signing keys for a single package”. A rotated APK carries more than one certificate. I signed one with a lineage from my old key to a new one, and the analyzer showed the old certificate (1b9aafb1…) for v1, v2 and v3 (SDK 24–32) and the new one, CN=Example Release 2026 (b39a1c85…), for v3.1 (SDK 33 and up). The pages I read don’t say which certificate the console expects for a rotated app. Since multiple keys are allowed, add every certificate that signs builds your users install. Rotation itself is covered in the package conflict guide.

Debug builds. Don’t register a debug certificate. If the analyzer shows check SIGN-01 (“Signed with the Android debug certificate”), the build is signed with Android Studio’s debug key (CN=Android Debug, O=Android, C=US). That key differs per machine, and it is not a key you can protect. Create a release key and sign with it first.

Step 3: Prove ownership and keep it working

For an existing package name, the console gives you a snippet to add to your APK’s assets/ folder. Build an APK containing it, sign it with the same release key, and upload it. Sign with your normal release pipeline: if the fingerprint of the challenge APK differs from the one you entered, you used the wrong keystore. Run it through the analyzer before you upload.

After registration:

  • Keep the key safe. The FAQ is blunt: “If you lose your signing key you won’t be able to register your packages.” Store it in a secrets manager with an offline backup.
  • Keep the package name. Registration ties the name to your keys. If a name is already in use by another developer’s key, Google may tell you that your key is not eligible, and suggests a different package name, or a review if that is not possible. Avoid generic prefixes such as com.example (Play also rejects them, check PLAY-07 in the analyzer).
  • Record the fingerprint in your release checklist and compare it on each build. Shipping a build signed with the wrong key now fails in two places: updates on users’ devices, and verification.

Where REA fits

REA 6.4.0, the open-source project by morluto, has no developer verification feature. It does not read or verify signing certificates: rea inspect-android-package reports signature_verification: "not_performed". One thing it can do here is fetch an installed copy back from a test device you control, so you can confirm which key the build in testers’ hands carries:

rea pull-adb-package <serial> <package> --output-directory /tmp/pulls --format json

Then open the pulled base.apk in the analyzer. The REA setup is in Install REA MCP.

FAQ

Do I need to do anything if I only publish on Google Play? Check the Play Console home page. Google says most Play apps are registered automatically, including those with Play App Signing.

My users sideload the APK from my website. Are they blocked today? Not by this program yet: the FAQ says sideloaded apps are not covered “yet”. Plan for 2027.

Is the SHA-1 fingerprint enough? The console asks for the SHA-256 certificate fingerprint. The analyzer and apksigner print both values. Copy the SHA-256 one.

I lost the keystore. Then you cannot prove ownership of that key. For Play apps, Play App Signing lets you reset the upload key. Outside Play, plan a new package name with a new, backed-up key.

Next steps

Use these steps only for apps you own or are authorized to register.