Android Developer Console API 接入 CI/CD：Package 与 Signing Key 自动注册｜御盾
Android Developer Console API面向应用分发商和开发者，支持以程序化方式注册Package Name、关联Signing Key并处理已有包的所有权证明；Android Developer ID Status API则负责只读查询。CI/CD必须把两者拆开：普通发布阶段先检查最终签名身份，只有确需新增或变更登记时才进入由客户授权的Console API管理流程。御盾输出加固产物，不接管生产私钥或开发者账号。
摘要
Android Developer Verification进入首批执行阶段后，团队需要把开发者主体、Package Name、签名证书和渠道发布物纳入发布管理。Google提供两类容易混淆的程序化接口：Android Developer ID Status API能查询Package或Package+公开证书SHA-256指纹是否已注册；Android Developer Console API则用于授权后查看、注册和管理Developer Account下的Package与Key。前者适合只读预检，后者会改变身份登记状态，因此认证方式、授权主体和失败处置都不同。Google Status API指南；Google Console API指南
本文聚焦API实施与流水线分层，不是第五篇ADV入门介绍，也不是某个开发者账号、Package或签名证书的状态报告。本文没有执行真实OAuth授权、Google API请求、Package注册、Key所有权证明、商店操作或客户流水线接入；这些项目状态保持NOT_TESTED。
读者对象
本文面向负责Android构建和多渠道发布的研发、DevOps、移动安全及发行团队，特别适合需要在发布流水线里区分“检查当前身份”与“申请改变登记关系”的组织。如果团队只是想确认某个Package或公开证书指纹当前是否登记，可以使用Developer Verification Preflight与状态检查工具了解本地格式核对和用户自有API Key直连Google状态查询；如果需要理解多渠道Package与Signing Key如何对应，参见APP加固后的Package Name与Signing Key发布身份页。
核心结论
- **Status API查状态，Console API管注册。**两者都是Google的公开接口，但不能把查询API Key、Developer Console OAuth授权和商店审核状态混成一个PASS。
- Status API接受API Key，可检查Package Name或Package+公开证书SHA-256指纹；它本身不创建Package、不注册Key，也不证明应用已通过商店审核。
- Developer Console API通过OAuth 2.0 Web Server Flow访问与Google用户账号相关的开发者数据；Google明确说明Service Account、Workload Identity Federation和API Key不能代替该账号授权。
- 新Package可提供签名证书公钥；历史Package可能需要证明已知Private Signing Key的控制权，并可能需要提交注册理由。
- Key Eligibility会参考已知安装关系：多数Key、50次安装门槛以及低安装量时的先到先得规则会影响直注册资格；需要理由的申请可能需要最长约24小时审核。
adi-registration.properties用于承载API提供的验证字符串以完成特定的Key所有权流程；它不是御盾的加固配置文件，验证材料与生产私钥应留在责任主体控制的环境。- 建议让CI/CD日常构建仅做只读身份预检；注册、转移、所有权证明及Justification作为单独的受控操作，不能因为一个流水线凭据可读就自动放行变更。
- 本文没有执行真实API调用、账号授权或包名注册，所有项目级状态均为
NOT_TESTED。
事实依据与脱敏证据
| 编号 | 官方或已发布来源 | 可确认事实 | 对流水线设计的意义 | 不能推出的结论 |
|---|---|---|---|---|
| 1 | Android Developer Console API | API可程序化管理Package Name注册，服务于分发商、开发者及CI/CD场景 | 明确管理API的写入/变更责任 | 御盾已替客户接入或注册 |
| 2 | Console API OAuth说明 | API需要OAuth 2.0 Web Server Flow和androiddeveloperconsole范围 |
由客户账号所有者完成授权与令牌治理 | API Key或Service Account可管理Console账号 |
| 3 | Status API | 可检查Package与公开证书SHA-256指纹组合 | 最终签名后可执行只读检查 | 注册状态等于商店上架通过 |
| 4 | Status API配额与错误处理 | 状态查询默认配额为每项目每天1,000次；超额返回RESOURCE_EXHAUSTED |
需要调用限速和对可重试错误做分层处理 | 任意项目都能无限查询或异常等于未注册 |
| 5 | Console API状态说明 | Developer、Package、Key分别具有注册或验证状态 | 状态模型应保留资源类型，避免压成单布尔 | 某一状态代表发布物全部合格 |
| 6 | Console API Key Eligibility | 多Key资格可能由多数安装量、50次安装门槛或先到先得规则决定 | 历史Key盘点要早于注册写入 | 团队可任意换成新Key |
| 7 | Console API所有权证明 | 指定历史Key时，流程可能需要带verificationToken的签名APK来证明Key所有权 |
证明步骤必须归客户签名责任人控制 | 加固平台需要客户Private Key |
| 8 | 御盾Package / Signing身份页 | 发布身份由Package、证书、开发者和最终签名对象共同核对 | 加固候选与最终签名应分离 | 一次格式检查等同真实状态查询 |
| 9 | 本页核验范围 | 未授权任何Google账号或客户流水线 | 所有集成结果以NOT_TESTED标记 |
页面中的示例就是实际项目结果 |
技术拆解：Status API 与 Console API 的职责边界
Status API：只读检查发布身份关系
Android Developer ID Status API提供CheckPackageRegistrationStatus检查。只传Package Name时，回答该Package是否已关联至经过验证的开发者；添加certificateFingerprint后，回答该Package与给定的公开证书SHA-256指纹是否匹配。响应状态包括REGISTERED、NOT_REGISTERED和REGISTERED_WITH_ANOTHER_CERTIFICATE_FINGERPRINT。Google文档建议根据稳定的错误状态字段处理API错误，不应解析可能变化的人类可读错误文本。
Status API使用Google Cloud项目启用的API Key，调用默认限额为每个项目每天1,000次。RESOURCE_EXHAUSTED表示项目超额，需要按配额规则退避并检查Google Cloud配额；UNAVAILABLE或INTERNAL是服务可用性问题，可按官方建议重试；PERMISSION_DENIED应检查API是否启用及项目权限。流水线不得把所有非200响应都记成NOT_REGISTERED，也不能在查询服务暂时不可用时把UNKNOWN伪装成PASS。
如需核对自有Package与公开证书指纹格式，并可选地从浏览器直接查询Google官方状态，可使用御盾 Android Developer Verification 状态检查工具。工具不接收APK、私钥或API Key；仅在用户主动查询时，浏览器才使用用户自有API Key调用Google。查询结果也不代表商店审核或项目兼容性通过。
Console API：授权后管理开发者身份资源
Android Developer Console API处理的是开发者账号下的Package和Key数据，可以用来列出资源、获取注册策略、创建Package、关联Key、证明Key所有权及提交理由。由于这些数据与用户Google账号关联，API使用OAuth 2.0 Web Server Flow和https://www.googleapis.com/auth/androiddeveloperconsole范围。Google明确排除Service Account、Workload Identity Federation和普通API Key作为该API的账号授权方式。
OAuth不是把一份账号凭据复制进每个CI任务。若团队使用离线自动化流程，Google文档描述了用户一次性同意、获得刷新令牌并在受控部署环境保存的方式；另一种是每次运行时交互授权、使用短时访问令牌后丢弃。选择哪种流程应由账户所有者和安全团队决定，并需要将令牌保存在授权方管理的Secret Manager中。御盾不代管Google账号授权、刷新令牌或商店凭据。
| 能力 | Developer ID Status API | Android Developer Console API |
|---|---|---|
| 读取Package注册状态 | 支持 | 支持资源管理查询 |
| 检查Package与证书SHA-256配对 | 支持 | 管理流程也会涉及Key |
| 创建或管理Package / Key | 不支持 | 支持，按授权账号资源执行 |
| 身份授权方式 | Google Cloud API Key | OAuth 2.0 Web Server Flow |
| 适合的发布流水线职责 | 每次正式签名后的只读Preflight | 明确授权的身份注册、证明或转移操作 |
| 运行结果含义 | 当前查询所得注册关系 | 当前账号下管理操作的资源状态 |
| 不代表 | 商店审核、设备安装与业务兼容 | 最终产物已通过所有渠道门禁 |
Package注册：新Package与历史Package的流程不同
新Package Name
对于Android上从未出现过的新Package，开发者可向Console API提供其签名Key对应的公开证书。建议在身份登记之前先确定长期维护主体、正式分发渠道和生产签名责任，避免在非生产环境、临时签名或多个外包团队之间制造互相冲突的登记记录。Package状态应作为独立状态保存，不应跟Key状态或平台安装状态合并。
状态表还应保存更新时间和来源。一个已登记的Package可能对应不止一种历史Key，不同Key也可能处于待验证、审核中或转移处理中；若发布面板只显示“包名已登记”，操作者可能看不到某个证书仍未关联或迁移尚未完成。保存资源类型、原始枚举、上次读取时间和责任账号，有助于区分“登记成功”“登记处理中”与“目前没有足够信息”。
已存在的Package Name
对已有Package，Google可能返回已知的证书指纹和可选的Key Selection Strategy。若流程要求从已知Key列表中选择，即SELECT_KEY_FROM_LIST，开发者要证明掌握相应Private Signing Key；若策略为USE_ANY_KEY，流程允许提供Key，所有权证明步骤不同。团队应以Console API当前返回的策略和资源状态为准，不要用固定脚本把所有历史包一律走同一分支。
Google公开的多Key资格规则描述了三类情况：一个Key占已知安装量超过50%时，该Key优先直注册；无Key超过半数时，达到50次或以上安装的Key可进入直注册资格；如果所有Key都低于50次安装，可能适用先到先得，后续开发者则需要理由。被标注为需要理由的Key仍可能提交申请，但Google说明理由审核可最长约24小时。具体项目是否符合资格，需要依当前API响应与账号后台判断。
Key所有权证明与adi-registration.properties
当选择的策略要求Key所有权证明时，Console API会生成verificationToken。官方指南说明该字符串需要写入应用assets中的adi-registration.properties，再使用对应Private Signing Key签署APK并提交给所有权验证流程。这里的敏感点不只是文件名，而是完整签名责任：谁获得token、谁构建验证用产物、谁接触私钥、谁执行上传、谁确认返回状态，都需要由客户或其授权组织明确。
加固平台可以维护原始Release与加固输出物之间的受控关联，帮助记录公开证书指纹和版本摘要；它不应替客户生成或持有生产私钥，也不能在没有授权的情况下替客户提交Google身份变更。若项目要为既有Key进行验证，应单独由客户控制的签名系统和Developer Console授权流程执行。本文不包含token、真实Package、证书指纹或可直接提交的APK。
状态枚举应以当前API响应和schema为准
Google指南的概览术语表将Key注册状态列出为DRAFT、OWNERSHIP_VERIFIED、IN_REVIEW、REGISTERED、PENDING_TRANSFER；而同一指南的Key管理界面建议部分列出REGISTERED_ACTIVE。这说明页面的概览术语与具体管理界面用词存在差异。集成方应核对当前API参考文档和真实授权响应，保存原始规范状态字符串及资源类型，不要自行把未知状态折叠成REGISTERED或把REGISTERED_ACTIVE误解为另一个产品的通用状态。
工程落地：让查询与身份变更分开进入流水线
建议的阶段顺序
Repository Revision / Release Intent
↓
Original Build Artifact
↓
Yudun Protected Output
↓
Customer-controlled Production Signing
↓
Extract Package + Public Certificate SHA-256
↓
Status API Read-only Preflight
↓
Optional: Owner-authorized Console API Registration Flow
↓
Store-specific Review + Install / Upgrade Release Gate
该顺序的重点不是强制某种构建工具，而是确保检查发生在能够代表最终发布身份的对象上。若在正式签名前用非生产证书查询，结果并不能证明最终分发物的Certificate匹配；若加固平台先用临时证书签名再将该对象当成正式包，也会混淆签名责任和升级身份。正式签名后的Package、公开证书SHA-256、版本与产物摘要应绑定在同一条发布记录里。
日常Read-only Gate与例外管理
日常CI可在客户正式签名完成后执行Status API查询，字段包括Package、可选证书指纹、Google返回状态、HTTP/API错误类别、查询时间、Release摘要和目标渠道。REGISTERED可继续进入后续商店特定步骤；NOT_REGISTERED应转到登记责任人；REGISTERED_WITH_ANOTHER_CERTIFICATE_FINGERPRINT应阻断分发并核对签名链、历史Key与渠道，不要自动更换Key；API服务错误则保存为UNKNOWN并按策略重试或暂停，不应伪造成注册失败。
若确实需要创建Package、增加Key、证明所有权或提交理由，应该进入独立的身份管理流程。其授权上下文应说明将访问哪个开发者账号、执行什么注册动作、影响哪些Package，以及谁有权批准。将这类写入型动作放在一个只读预检的同一服务账号或同一构建步骤里，会增加错误授权、重复更改和审计缺失的风险。
Release Identity Record最小字段
| 字段 | 建议含义 | 是否能单独放行 |
|---|---|---|
packageName |
最终产物的逻辑Package Name | 否 |
versionCode |
当前发布版本标识 | 否 |
certificateSha256 |
正式签名证书公钥指纹 | 与Package联合核对 |
certificateRole |
Upload、App Signing、OEM或其他渠道证书角色 | 否 |
statusApiState |
Google只读查询原始状态 | 否，仍要看渠道和发行物 |
consolePackageState |
Developer Console返回的Package状态 | 否 |
consoleKeyState |
Key状态原值，避免映射损失 | 否 |
ownershipProofState |
所有权证明状态，不含验证材料 | 否 |
originalDigest |
原始构建物摘要 | 关联追踪 |
yudunOutputDigest |
加固输出物摘要 | 关联追踪 |
finalSignedDigest |
客户正式签名后产物摘要 | 关键发布对象 |
targetStore / country |
目标渠道与地区 | 分渠道判断 |
checkedAt / owner |
查询时间和责任人/系统 | 审计与过期判断 |
正式发布状态不应只有PASS=true。应保留Status API原值、Console资源原值和渠道自己的状态，UNKNOWN、IN_REVIEW、PENDING_TRANSFER都不能被改写成一个模糊“已完成”。Release Gate可以根据客户发布策略选择阻断、等待人工复核或回退，但必须能说明是哪个事实触发了决定。
攻防视角：身份管理接口不是客户端防护接口
Developer Console API管理的是开发者、Package与Key登记关系；它不是Android客户端反篡改机制，也不替代御盾保护App代码、Native资源、运行时关键路径和完整性。反过来，客户端加固也不会自动完成Package注册或证明客户掌握历史Private Signing Key。将两个安全面合并成“加固后ADV自动PASS”会造成错误的责任期待。
在防守设计里，API Key、OAuth访问令牌、刷新令牌、verificationToken与Private Signing Key属于不同类别的授权材料，应分别设置最小权限、存储位置、生命周期与审计。公开证书SHA-256可以用于状态配对核对，但完整签名私钥和OAuth长期凭据绝不能放进普通源代码、公开记录或加固平台交付包。对账户风险而言，异常状态要触发复核而非自动进行密钥轮换；密钥更换可能影响覆盖更新和历史用户迁移，应遵照Google与各商店当前流程。
御盾与客户的责任边界
| 工作项 | Google Developer ID Status API | Android Developer Console API | 客户/签名管理员 | 御盾 |
|---|---|---|---|---|
| 查询Package及证书关系 | 提供只读状态 | 可访问管理资源 | 决定检查对象 | 可关联发布记录；本文未声称已集成 |
| 注册Package或Key | 不负责创建 | 在OAuth授权后管理 | 拥有账号并批准变更 | 不代客户授权或登记 |
| 历史Key所有权证明 | 不执行管理流程 | 提供验证流程 | 使用受控私钥签名并提交 | 不持有生产私钥 |
| 客户端保护 | 不提供 | 不提供 | 授权保护范围 | 输出加固产物与受控摘要 |
| 商店审核及发行 | 不等同审核结果 | 不代替商店审核 | 负责渠道发布与账号运营 | 不承诺上架或曝光 |
| 业务交易与账号放行 | 不负责 | 不负责 | 后端策略最终裁决 | 不替代服务端业务策略 |
风险边界
- Status API返回
REGISTERED，只能说明当前查询的Package或Package+证书对符合对应登记条件，不说明Google Play或OEM商店已完成内容审核。 - Console API资源状态表示登记流程状态，不等同于该版本的安装、覆盖更新、启动、业务路径或运行时兼容结果。
- OAuth授权有账号管理权限边界；离线流程保存刷新令牌需要客户进行独立威胁建模和密钥管理。
- 已有Package的Eligibility和Key Ownership需要依账号当前状态判断；文章中的公开规则不替代该账号的Console响应。
- API默认配额为每项目每日1,000次，但项目可用额度和错误状态应在对应Google Cloud项目内确认；不能把配额耗尽误判为Package未注册。
- 本文没有执行真实API、Console账号授权、Key Ownership、商店审核、安装或升级验证；所有项目状态为
NOT_TESTED。
常见误区与常见问题 FAQ
Status API与Console API是不是同一个接口的不同认证方式？
不是。Status API面向Package注册状态只读查询，使用Google Cloud API Key；Console API管理开发者账号下的Package与Key，需要OAuth 2.0 Web Server Flow。二者的资源权限和副作用不同。
能不能用Service Account自动注册Package Name？
Google当前Console API指南明确说明，开发者账号数据关联Google用户账号，该API不接受Service Account、Workload Identity Federation或普通API Key作为账号授权。应遵循官方OAuth流程并由账号所有者授权。
REGISTERED是不是说明加固后的APK可直接发布？
不是。先确认查询对象是最终签名后的正式产物、所用证书角色正确，再按目标商店继续检查发行状态和升级链。注册关系与加固兼容、商店审核是不同门禁。
证明历史Key所有权是否需要把生产私钥交给御盾？
不需要。证明动作应由客户或授权签名系统在受控环境使用对应私钥完成。御盾可以保留候选摘要与发布对象之间的受控关联，但不需要接收或长期保存私钥。
哪些Package注册场景可能需要说明理由？
Google会根据历史安装量和Key资格规则决定哪些Key可以直接登记；不符合当前直接资格的Key可能要求提交业务理由。是否触发取决于API当前返回的资格结果，不能仅凭包名或团队历史经验推断。
这篇文章是否证明御盾已经接入Console API？
没有。本文描述Google公开接口和建议的职责划分；没有执行御盾侧Console API开发、OAuth授权、API调用或客户流水线联调。相应状态为NOT_TESTED。
下一步
团队可先盘点现有Package、证书角色、正式签名责任和目标渠道，再决定是否只需要Status API只读预检，还是确实要建立Developer Console API授权管理流程。对加固发布而言，建议把保护产物与客户最终签名分开，并在最终签名后进行身份核对。更多Package与Signing原则见APP加固后的Package Name与Signing Key发布身份页；更宏观的渠道分工见Android Developer Verification多商店状态核验；需要了解御盾保护边界时可阅读御盾APP加固产品页。