Android 开发者验证：找出包名和签名证书 SHA-256，提前完成登记

结论先行：要在 Google Play 以外为应用做 Android 开发者验证登记，需要从你自己的构建里拿到两样东西：包名，以及签名证书的 SHA-256 指纹。对于已经存在的包名，还要证明你持有私钥：控制台会给你一段代码片段，放进 APK 后用同一把私钥签名再上传。这两个值都能用本站的 APK/AAB 分析与上架体检从成品 APK 或 AAB 里几秒钟读出来，文件留在浏览器里，不会上传；再用 apksigner 或 keytool 复核即可。

适合谁读：在 Google Play 以外分发 Android 应用的开发者（官网下载、其他应用商店、企业或社区渠道），以及同时在 Play 和其他渠道分发 APK 的开发者。

读完你会知道：

2026-09-30 起哪些情况开始执行，哪些暂时不受影响
该用哪个控制台，需要填什么
怎么从 APK、AAB 和 keystore 里读出包名和证书 SHA-256
用了 Play App Signing、做过密钥轮换或有多个签名者时，该登记哪把密钥
常见的坑：调试密钥、密钥丢失、包名已被别人使用

下面的政策信息来自 Google 的开发者验证页面，我在 2026-10-14 重新核对过。这些内容会变，涉及日期时请以链接页面为准。文中的指纹来自我用临时密钥构建并签名的 APK 和 AAB。

什么时候、对谁生效

根据 Google 的概览页和 FAQ：

2026-09-30 起，在巴西、印度尼西亚、新加坡、泰国，运行 Android 7 及以上的认证设备上，从参与商店安装的应用开始受到检查。参与商店包括 Google Play、荣耀应用市场、OPPO 软件商店、三星 Galaxy Store、传音 Palm Store、vivo 应用商店和小米 GetApps。
2027 年，Google 表示验证将“扩展到全球所有认证 Android 设备上的所有应用”，具体日期尚未公布。
侧载和其他商店暂不受影响。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.” 同时建议在 2027 年全球推行前完成验证。
ADB 不变。“As a developer, you are free to install apps without verification with ADB.” 本地开发测试流程照常可用。
对未验证开发者的应用，用户可以通过一次性设置开启“高级流程”（advanced flow）来安装。

所以，只要你不是通过上面那几家商店向这四个国家的用户分发，目前在 Play 以外分发的应用不会受影响。真正要提前准备的是 2027 年的全球推行。

用哪个控制台，要填什么

只在 Google Play 分发：Google 称 Play 已自动登记“99% 的应用”，使用 Play App Signing 的应用会被自动认领。到 Play Console 首页确认是否还有遗漏。
Play 和其他渠道都有：在 Play Console 里同时登记你在 Play 以外分发的应用。
只在 Play 以外分发：注册 Android Developer Console。按 Google 的说明，登记步骤是：
1. “Enter the package name”（填写包名）
2. “Enter the SHA-256 certificate fingerprint from your app’s signing key pair.”（填写签名密钥对的证书 SHA-256 指纹）
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.”（已存在的包名需要上传用私钥签名的 APK，控制台会提供一段放进 assets 目录的代码片段用于验证）

账号类型是另一回事。完整分发（Full distribution）账号需要身份验证：个人要提供政府签发的带照片证件和地址证明，组织还需要 D-U-N-S 编号，以及经 Search Console 验证的网站。面向学生和爱好者的有限分发（Limited distribution）账号不需要证件，最多分发到 20 台设备。费用请以官方指南为准。

第 1 步：从构建里读出包名和 SHA-256

打开 APK/AAB 分析与上架体检，拖入你的正式版 APK 或 AAB，也就是实际发出去的那个包，不是 debug 包。要看两处：

摘要 → 包名：Manifest 里的 package 属性，也就是用户在系统设置里看到的应用 ID。
签名：每个签名者、每种签名方案一块，包括主题、有效期和一行 SHA-256。这一行就是控制台要的证书指纹。

我的正式版 verifydemo.apk（versionCode 7）在工具里显示如下（有删节，每个签名者块里的 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

三种方案用的是同一张证书，所以只需登记一个指纹。工具显示的是 64 位小写十六进制，没有冒号。

用 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

要用的是证书的 SHA-256。加上 -v 时，apksigner 还会打印 “public key SHA-256 digest”，那是只对公钥算的哈希，不是证书指纹，数值也不一样。

从 AAB 读

Android App Bundle 用 jarsigner 签名，所以只有 META-INF/ 下的 v1 式签名。我用同一把密钥签了 verifydemo.aab。工具识别出这是 AAB，从 base 模块的 Manifest 读到 dev.example.verifydemo，并显示一个 v1 签名者，SHA-256 同样是 1b9aafb1…f4d0。keytool 的结果一致：

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

数值相同，只是大写、带冒号。粘贴前按控制台要求的格式整理一下。

从 keystore 读

手头有 keystore 但没有构建产物时：

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

对我的密钥，它打印出同一个 SHA256: 1B:9A:AF:…:F4:D0。这也是确认 CI 密钥库里那把 keystore 就是签发正式包那把的最快办法。

第 2 步：选对要登记的密钥

Play App Signing。Google 会用它保管的应用签名密钥重新签名分发给用户的 APK，这类应用会被自动认领。你上传的 AAB 里的证书是上传密钥，不是用户设备上看到的那把。如果你还在 Play 以外分发自己签名的 APK，这些包的证书和 Play 分发的不一样。按 Google 对这种情况的建议，在 Play Console 里登记你在 Play 以外分发的应用。Play Console 的应用签名页面会列出两把密钥的 SHA-256，可以和工具里的结果对照。

多个签名者或密钥轮换。Android Developer Console “lets you add and verify multiple signing keys for a single package”（同一个包名可以添加并验证多把签名密钥）。轮换过的 APK 会带不止一张证书。我用从旧密钥到新密钥的谱系签了一个包，工具显示：v1、v2、v3（SDK 24–32）是旧证书（1b9aafb1…），v3.1（SDK 33 及以上）是新证书 CN=Example Release 2026（b39a1c85…）。我查阅的官方页面没有说明轮换后的应用应该登记哪一张。既然允许多把密钥，就把所有给用户实际安装的构建签过名的证书都加上。轮换的具体做法见安装包冲突那篇。

debug 构建。不要登记调试证书。如果工具报出 SIGN-01（使用了 Android 调试证书签名），说明包是用 Android Studio 的调试密钥（CN=Android Debug, O=Android, C=US）签的。这把密钥每台电脑都不一样，也谈不上妥善保管。先生成正式的发布密钥，用它签名。

第 3 步：证明所有权，并长期保持有效

对已存在的包名，控制台会给你一段代码片段，放进 APK 的 assets/ 目录。构建一个包含它的 APK，用同一把发布密钥签名后上传。请走你平时的正式签名流程：如果这个验证用 APK 的指纹和你填写的不一致，说明用错了 keystore。上传前先拖进工具里看一眼。

登记之后：

保管好密钥。FAQ 说得很直接：“If you lose your signing key you won’t be able to register your packages.”（签名密钥丢失后将无法登记包名。）放进密钥管理服务，并做离线备份。
不要换包名。登记会把包名和你的密钥绑定。如果包名已被其他开发者的密钥使用，Google 可能会告诉你你的密钥没有资格直接认领，并建议换一个包名；实在不能换，可以申请登记，但要经过额外审核。不要用 com.example 这类通用前缀（Play 也会拒审，工具里的 PLAY-07 会检查）。
把指纹写进发布检查清单，每次构建都比对。签错密钥的包现在会在两个地方出问题：用户设备上的更新，以及开发者验证。

REA 能帮什么

REA 6.4.0（morluto 的开源项目）没有开发者验证相关功能，也不读取、不校验签名证书：rea inspect-android-package 的结果里写着 signature_verification: "not_performed"。它在这里能做的一件事，是从你自己控制的测试设备上把已装的那份取回来，确认测试人员手里的构建带的是哪把密钥：

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

然后把拉回的 base.apk 拖进工具查看。REA 的安装方法见 REA MCP 安装指南。

常见问题

只在 Google Play 上架，需要做什么吗？ 去 Play Console 首页确认一下。Google 表示大多数 Play 应用已经自动登记，包括使用 Play App Signing 的应用。

用户从我官网下载 APK 侧载，现在会被拦吗？ 目前不会因为这项要求被拦：FAQ 写明侧载的应用“暂不适用”。请按 2027 年来做准备。

填 SHA-1 指纹行不行？ 控制台要的是证书的 SHA-256 指纹。工具和 apksigner 两个值都会打印，复制 SHA-256 那一行。

keystore 丢了怎么办？ 那就无法证明你持有那把密钥。Play 上的应用可以借助 Play App Signing 重置上传密钥；Play 以外，只能规划一个新包名，配一把新的、有备份的密钥。

下一步

从构建里读出包名和指纹：APK/AAB 分析与上架体检
安装时签名不一致：安装包与现有包冲突
把 AAB 转成 APK 再检查：AAB 转 APK 与 APK 解包
参考资料：Developer verification、FAQ、Sign your app、REA 的 DISCLAIMER.md

以上步骤只适用于你拥有或已获授权登记的应用。