在线 APK/AAB 分析与 Google Play 上架体检

Google Play 上大多数卡住发版的问题，其实都能直接从你准备提交的那个文件里读出来。targetSdkVersion 写在 AndroidManifest.xml 里；原生库是否满足 16 KB 对齐，写在 ELF 程序头里；是不是用调试密钥签的名，写在证书里。这些都不需要服务器，也不需要源码。

这个工具在浏览器里直接读取打包好的 APK 或 AAB 中的这些字段，对照 Google Play 上架和线下分发中最常导致发版受阻的规则逐项检查。每条结果都附上判断依据（证据）、修复方法，以及写明该规则的官方页面链接。

能检查什么

目前共有 34 条检查，覆盖 Google Play 上架要求、线下分发与安装问题、签名、隐私和应用防护。规则编号与本站使用的规则清单一致，报告里的 #PLAY-02 这类锚点始终指同一条规则。“触发条件”一列写明了具体条件，例如 SIGN-03 只有在 targetSdk ≥ 30 时才按拒审处理。如果你只关心 Google Play，可以用 Google Play 上架合规体检：同一个工具，默认选中 Play 场景。

体检前先选择分发场景：Google Play、Play 以外（线下分发或其他应用商店），或者两者都要。只在 Play 以外分发时，权限声明表这类 Play 专属规则会跳过；SIDE-01 这类安装层面的规则在任何场景下都适用。

你还可以选择“按哪一天生效的规则体检”，默认是今天。选一个以后的日期，就能提前看到哪些要求即将生效，例如 2027-02-01 之后的 16 KB 规则。

隐私是怎么保证的

文件不会被上传。这一点由页面的实现方式决定，而不只是一句承诺：

• 页面只把浏览器的 File 句柄交给一个 Web Worker。Worker 按需切片读取文件，用浏览器内置的 DecompressionStream 解压条目，代码里完全没有网络请求。
• 只读取需要的部分：ZIP 中央目录、AndroidManifest.xml、资源表（APK 的 resources.arsc，AAB 的 resources.pb）、启动图标、Manifest 指向的无障碍服务配置和网络安全配置 XML、每个 .so 和 React Native bundle 开头的一小段、很小的版本文件，以及签名数据。一个 200 MB 的 APK，实际只读几 MB。
• 报告显示之后，Worker 会按 4 MB 一段计算整个文件的 SHA-256，仍然在浏览器里完成。哈希显示在页面上，也会写进你自己导出的文件。旁边有一个在 VirusTotal 上搜索这个哈希的链接：它只是普通链接，你点击之前不会发出任何请求，点击后地址里也只有哈希。文件本身不会上传到任何地方。
• 分析结束后发送的统计事件只包含粗粒度的固定取值：文件类型、大小区间、耗时区间、成功或错误码、未通过的检查数量。绝不包含文件名、包名、哈希或任何文件内容。完整清单见隐私政策。
• 工具页不展示广告。

如何自己验证

你不必只听我们说。

1. 选择文件之前，打开浏览器开发者工具，切到 Network（网络） 面板。完成一次分析，逐条查看出现的请求：没有任何一条带着你的文件。除本站以外，你只会看到 Google Fonts 和 Google Analytics 两类域名。
2. 或者先加载本页，然后断开网络（关闭 Wi-Fi，或在 Network 面板勾选 Offline），再做分析。分析照样能完成，因为没有任何东西需要离开你的电脑。

结果怎么看

每条检查的结果是以下五种状态之一：

• 拒审：如果该规则适用于你选择的场景，Google Play 会阻止发布，或者 Android 会拒绝安装。
• 高风险：大概率触发权限声明审核、Play Protect 警告，或者是一项已公布生效日期、即将强制执行的要求。
• 建议：最佳实践或提前预警。
• 未知：工具无法判断。常见原因是某个值是工具暂时无法解析的资源引用，或者规则依赖的那部分文件解析失败。“未知”不等于通过，请手动核对。
• 通过：工具检查过，没有发现问题。

每条未通过的结果都会列出证据，例如 lib/arm64-v8a/libfoo.so: PT_LOAD p_align=0x1000，方便你在动手修改之前先用自己的工具复核。

报告全部通过也不等于审核通过。Google Play 还会审核权限声明、商店详情、Data safety 表单和运行时行为，这些都不是检查文件能看到的。本工具的结果不代表 Google 的审核结论。 如果想在 Android Studio 里检查源码层面的政策风险，Google 还提供了 Play Policy Insights。

常见问题怎么修

16 KB 页面大小（PLAY-02、PLAY-03）

以 Android 15 及以上为目标的应用，必须在 64 位设备上支持 16 KB 内存页。Google 开发者文档写明，自 2027-02-01 起，不合规的更新将无法发布。在那之前，工具把这两项标为“高风险”，而不是“拒审”。来源：Support 16 KB page sizes。

• ELF 段对齐（PLAY-02）：用 NDK r28 或更高版本编译原生代码，默认就是 16 KB 对齐。NDK r27 及以下，添加链接参数 -Wl,-z,max-page-size=16384。第三方 SDK 提供的预编译 .so，请向供应商索取支持 16 KB 的版本。
• ZIP 内对齐（PLAY-03）：升级到 Android Gradle Plugin 8.5.1 或更高版本，它会正确对齐未压缩的库。暂时无法升级的，设置 useLegacyPackaging = true 改为压缩存放（安装体积会变大）。修改后可以用 zipalign -c -P 16 -v 4 app.apk 复核。

targetSdk 36（PLAY-01）

自 2026-08-31 起，面向手机和平板的新应用和应用更新必须以 API 36（Android 16）为目标，可以在 Play Console 申请延期，最晚到 2026-11-01。Wear OS 和 Android Automotive OS 应用要求 35，TV 和 XR 应用要求 34；工具会读取 Manifest 中的 uses-feature 来判断设备形态并选用对应的门槛。来源：目标 API 级别要求。

提高 targetSdk 会改变应用的运行时行为，发布前请对照 Android 16 的行为变更逐项回归测试。反过来，SIDE-01 在 Play 以外同样重要：Android 14 拒绝安装 targetSdk 低于 23 的应用，Android 15 及以上拒绝安装低于 24 的应用（Android 15 行为变更）。

调试证书（SIGN-01）

主题为 CN=Android Debug,O=Android,C=US 的证书，是 Android Studio 为本地构建自动生成的调试密钥。Google Play 会拒绝它；而且它的私钥存在于每一台开发机上，任何人都能用它签出一个“更新”来替换你的应用。请生成专用的发布密钥（RSA 2048 位或以上），做好备份，用它签署发布版本。在 Play 上分发的，加入 Play 应用签名，由 Google 保管应用签名密钥，你自己保留上传密钥。来源：为应用签名、Play 应用签名。

只有 v1 签名（SIGN-03）

v1（JAR）签名只对 ZIP 中的各个条目签名，压缩包的其余部分不受保护。以 API 30 及以上为目标的应用必须使用 APK 签名方案 v2 或更高版本签名，否则无法安装。Android Gradle Plugin 默认启用 v2 和 v3，所以只有 v1 的 APK 通常来自自定义的签名步骤。请用 apksigner 签名并保持 v2/v3 开启；minSdk 达到 24 以后可以去掉 v1。注意顺序：先 zipalign，再 apksigner，不能反过来。来源：APK 签名、apksigner、zipalign。

权限类结果（PLAY-08、09、10、12、13、16）

这些结果并不意味着权限本身一定被拒，而是说明 Google Play 只允许这些权限用于特定的核心功能，并要求填写声明表。应用用不到的，就删除，包括由第三方库合并进 Manifest 的那些。确实需要的，优先换成范围更窄的替代方案：用 SMS Retriever API 代替短信权限，用 <queries> 代替 QUERY_ALL_PACKAGES，用存储访问框架（SAF）或 MediaStore 代替所有文件访问，用系统照片选择器代替 READ_MEDIA_IMAGES。另外，自 2027-01-27 起，“电话账户验证”不再是 READ_CALL_LOG 的允许用途（政策截止日期）。报告中的每条结果都会链接到对应的政策页面：短信和通话记录、软件包可见性、所有文件访问、REQUEST_INSTALL_PACKAGES、后台位置、照片和视频权限。

AAB 文件，以及如何用 bundletool 交叉核对

Android App Bundle 的 Manifest 和资源表用 protobuf 存储，而不是二进制 XML。工具会解码 base 模块的 manifest/AndroidManifest.xml、resources.pb 和 BundleConfig.pb，所以 AAB 和 APK 走同一套 Manifest 检查。@string/app_name、@mipmap/ic_launcher 这样的资源引用会解析成默认配置下的值，并与原始资源 ID 一起显示。报告还会列出 bundle 中的模块（base、功能模块和资源包，以及各自的分发方式），以及 BundleConfig.pb 中与 16 KB 适配相关的设置：原生库是否不压缩存放、按多大的页对齐。

启动图标是 PNG 或 WebP 位图时会显示出来，取密度最高的一张。自适应图标是矢量 XML，工具不做渲染，会明确标出；如果它的前景层是位图，就显示前景层。

想用 Google 自己的工具核对结果，可以在本地运行 bundletool：

java -jar bundletool.jar dump manifest --bundle=app.aab
java -jar bundletool.jar dump resources --bundle=app.aab --values
java -jar bundletool.jar dump config --bundle=app.aab

包名、versionCode、versionName、min/target SDK、权限、debuggable、应用名称和图标都应与报告一致。bundletool 按名称打印引用（如 @string/app_name），资源转储会给出这个名称对应的资源 ID（即报告里显示的 ID）和它的取值。

做不到的事

• 不做病毒判定：不扫描病毒，也不判断应用是否安全可装。
• 不反编译 DEX：不会把 classes.dex 还原成 Java 或 Kotlin 代码。需要的话，请在本地使用 JADX 等反编译工具（见下方相关教程）。
• 不转换 AAB：无法在浏览器里把 AAB 转成可安装的 APK，请使用 bundletool。工具按 bundle 原样读取，不会生成拆分 APK，所以 ZIP 内对齐（PLAY-03）和“只有 v1 签名”（SIGN-03）两项只对 APK 检查。
• 按名称识别，不读代码：框架、SDK 和应用防护都根据文件名、Manifest 和很小的版本文件识别。改过名的库、没有 Manifest 组件的 SDK 识别不到；只有包里写明了版本才显示版本号。基于 DEX 代码的指纹，以及依赖它的检查（自更新、动态加载代码、R8、Play Integrity、Data safety 提示），在后续版本提供。
• 加壳只识别，不处理：加壳和加固是正当的防护手段。PROT-01 只说明识别到了什么，并解释误报和 Play App Signing 方面的风险。工具不会脱壳、修改、重签名或重新打包任何文件，也不提供任何向审核或安全扫描隐藏行为的方法。
• 不做完整签名校验：会读取并检查证书，但还没有对 v1/v2/v3 签名做密码学校验；需要时请用 apksigner verify -v。
• 不代表审核结论：结果不代表 Google 的审核结论，报告全部通过也不保证能上架。

常见问答

文件真的不上传吗？ 是的。分析在当前标签页的 Web Worker 中完成。你可以按照如何自己验证中的方法，用 Network 面板或断网来确认。

支持哪些文件？ 最大 1 GiB 的 .apk 和 .aab。第一版不支持拆分 APK 集合（.apks、.xapk）。

为什么会出现“未知”？ 检查所依赖的某个值读不出来，例如 targetSdkVersion 写成了资源引用，或者签名块已损坏。请把“未知”理解为“需要你自己核对”，而不是通过。

报告全部通过，是不是就一定能上架？ 不是。Play 还会审核权限声明、商店详情、Data safety 和运行时行为，工具只覆盖能从文件中读出来的部分。

规则多久更新一次？ 每条规则都记录了最近一次对照官方来源核实的日期，每月复核一次。超过 90 天未复核的规则，会在报告中标注“待复核”。

相关教程

• Android 16 KB 页面大小适配：在线检查 APK 的 .so 对齐：用示例 APK 逐条讲解 PLAY-02 和 PLAY-03，并用 zipalign、llvm-readelf 复核。
• 用 REA 分析 Android APK：JADX、Apktool、ADB 与 Flutter 快照：从体检报告出发，找到导致问题的那段代码。
• AAB 转 APK 与 APK 解包：用 REA 盘点并提取资源和脚本：用 bundletool 转换 AAB，并盘点包内的每一个条目。
• 安装包与现有包冲突怎么解决：排查自己 App 的签名不一致：对比两个构建的签名证书 SHA-256，修好签名不一致。
• 安装包似乎无效怎么解决：查出自己的 APK 到底哪里坏了：把笼统的安装提示还原成真实的 INSTALL_PARSE_FAILED 代码，再按签名（SIGN-03）、resources.arsc（SIGN-08）或拆分包（SIDE-08）逐项修好。
• 应用与你的手机不兼容：检查 targetSdk、ABI 和 minSdk：结合真实的 INSTALL_FAILED 代码，读懂 SIDE-01、PLAY-04 和原生库表格。
• Android 开发者验证：找出包名和签名证书 SHA-256，提前完成登记：从自己的 APK 或 AAB 里拿到登记需要的信息。
• 自己的 App 被 Play Protect 拦截？开发者视角的原因排查与正当处理：读懂 SIDE-02、SIDE-03、SIDE-06 和 PROT-01，修好构建，再走官方申诉。
• 用 REA 读 logcat 和 bugreport，排查自己 App 的崩溃：安装包能装上却会崩溃时，读崩溃日志和原生 tombstone。
• REA MCP 安装指南：接入 Claude Code、Cursor 与 Codex：在本地装好 REA，做更深入的分析。
• REA 安全吗？如何确认装的是真正的 Reverse Engineer Anything：确认你安装的是正版的 REA 软件包。