[jinghero]

预装 android-36 被运行机更新或移除时，CI 和发版核对原来会直接失败。两个 workflow 现在先核对预装 android.jar；缺失或 SHA-256 不符时，从 Google 下载固定的 Android 36 r2，依次校验压缩包和解压后的 android.jar，再用原有 build-tools 36.1.0 和构建参数编译。finally 清理临时目录，构建进程的非零退出码也会终止流程。

Refs ModAVD/ModAVD#83。宿主输入法及这两个 workflow 已在本仓库，ModAVD 主仓库没有对应文件。

Google 官方依据：

• repository2-3.xml：platforms;android-36，revision 2，platform-36_r02.zip，65,878,410 字节，SHA-1 2c1a80dd4d9f7d0e6dd336ec603d9b5c55a6f576。
• 官方压缩包：先按官方 SHA-1 校验，再计算 SHA-256 37607369a28c5b640b3a7998868d45898ebcb777565a0e85f9acf36f29631d2e，固定在两个 workflow。XML 只公布 SHA-1，没有 SHA-256；此处没有把计算值冒称为 Google 公布值。
• android.jar SHA-256 仍为 d9eb9da824d9e247a352f570f01e1169e725b2954bca9e283a71786c59b59f9a。

备用逻辑留在 workflow 内，使 verify-release 检出旧 tag（如 v1.0.0）时也能运行，不要求旧 tag 包含新增脚本。新增测试提取并执行 workflow 代码，要求两份代码一致；只替换测试 ZIP/jar 的哈希并拦截网络和构建调用，实际执行文件校验、解压、分支和清理。中英文 README 补充了不依赖 Actions 的获取和双重校验步骤。

本地验证：

• pwsh -NoProfile -File scripts/test_android_sdk_fallback.ps1：9/9，通过正确预装、预装缺失、预装错误、下载哈希错误、解压后 jar 错误、解压后缺失 jar、下载失败、解压失败、构建失败。错误内容无法进入构建，坏压缩包无法进入解压，临时目录均清理。
• Windows 实际执行 workflow 构建代码，使用 Temurin 25.0.4.1+1、build-tools 36.1.0、TZ=CET-1。A 使用正确预装 jar，并将任何下载调用设为报错；B 预装路径不存在，从 Google 实际下载；C 预装 jar 错误，实际执行 verify-release 的备用代码。三次均通过协议自测并编出两个 APK。
• A/B/C 的产品 APK、测试 APK、aligned.apk 全部逐字节一致。同一开发密钥下，产品 APK SHA-256 为 ebff38996f8fc448f785d69e7fb65aad1c9c832fe76940d2fc5bc9cdc866a6c5，测试 APK 为 9c2552a69fb980b69711445cd6b592244caee01338be4dcebbfff9359362daed。
• YAML 解析、actionlint 1.7.12、git diff --check、隐私扫描、提交作者检查通过；repo_checks 3 项、verify_release_apk 5 项测试通过。

v1.0.0 一致性：

• 实际发布 APK 同时通过仓库 release/1.0.0.SHA256SUMS.txt 和 Release 附件 SHA256SUMS.txt 校验，SHA-256 均为 912c9c9724e63fa606fa5d4e4212cef0e24148b013923ba49d1ebf8cfd38e0e2。
• B 的 aligned.apk 用一次性 RSA-4096 密钥签名后，现有 verify_release_apk.py 核对通过，发布证书验证通过。额外逐字节比较确认：签名块前的全部字节和签名块后的全部字节（含中央目录及未经归一化的 EOCD）完全一致。唯一差异是偏移 12288 处、长 8192 字节的签名块。
• 仅放回已发布的原签名块后，B 的整个 APK 与发布文件逐字节一致，SHA-256 严格等于上述基准；apksigner 验证 v3、唯一签名者和正式证书摘要均通过。没有源码、SDK 或时区差异，没有放宽任何比较。
• 一次性密钥直接签出的 APK 整文件不等于正式发布文件。整文件复现复用了公开 APK 的原签名块，没有取得或使用正式私钥，也没有声称独立重签能得到同一签名。 原有发版核对逻辑保持不变。

GitHub Actions：

• 最终 PR 提交的 fork CI：4/4 job 成功，提交为 8ec0ec03e8b3247f47bc6fdafe7faaef1539e319。
• 隐藏预装 jar 后的 fork CI：4/4 job 成功，实际走官方备用下载并编出两个 APK。
• 强制备用下载及 v1.0.0 一致性核对：4/4 job 成功。Windows runner 日志确认预装 jar 不存在、备用下载及编译成功、现有发版核对通过；签名块以外的全部字节完全一致，复用原签名块后整文件逐字节相同，SHA-256 严格等于 912c9c9724e63fa606fa5d4e4212cef0e24148b013923ba49d1ebf8cfd38e0e2。临时验证步骤只在 verify/83-force-sdk-download 分支，没有进入本 PR。
• 上游 PR CI 当前为 action_required，需要维护者批准外部贡献者运行；未将其标为通过。