近两年做安卓的团队大多遇到过同一件事：商店后台上传的是 .aab，而内测群里发出去的必须是能直接安装的 APK。两种格式同时在用，谁负责哪个环节，经常说不清楚。这篇把 AAB 与 APK 的关系讲明白，并给出内测阶段该发什么、手上只有 AAB 时怎么处理。
AAB 与 APK 分别是什么
APK是安卓应用的安装包格式，文件本身就是一个完整的、可以直接安装到设备的程序AAB（Android App Bundle）是面向应用商店的发布格式，它把代码、资源以及不同分辨率与架构的产物分开存放，本身不是可直接安装的包- 用户从商店安装时，商店会按设备配置从 AAB 生成一份只包含该设备所需内容的
APK，再下发给设备 - 一句话概括：AAB 解决的是上传与下发体积的优化，APK 解决的是设备上能不能装上
AAB 和 APK 的关键差异
| 对比项 | APK | AAB |
|---|---|---|
| 能否直接安装 | 可以，传到设备上即可安装 | 不可以，需先转换成 APK |
| 主要使用场景 | 内测分发、官网下载、第三方渠道 | 上架应用商店 |
| 体积处理方式 | 一个包包含全部资源 | 商店按设备拆分后下发 |
| 内测阶段适用性 | 适合 | 不适合直接发给测试用户 |
表格里说的只是格式本身的差异，具体到各家商店的要求与限制，以对应平台的最新说明为准。
为什么内测阶段通常还是发 APK
- 内测设备往往不走商店的下发链路。测试机可能没装商店，或者登录的是无法访问商店的账号，拿不到按设备生成的那份包
- 分发平台的上传入口面向的是可安装文件。虾分发支持上传
APK与IPA，上传后自动解析并生成分发链接与二维码 - 双端合并下载依赖同一种产物形态。安卓
APK与 iOSIPA合并成一个二维码后，用户扫码按机型自动匹配，流程才不会中途断掉 - 内测追求的是「拿到就能装」，而 AAB 需要先经历一次转换，环节越多越容易出错
手上只有 AAB，内测包怎么出
如果你手上只有构建产出的 .aab，可以按下面的顺序处理：
- 先回到构建环节，让打包流程同时产出
APK与AAB两个产物，同一份代码配置两套输出，是长期最省事的做法 - 确实只能拿到 AAB 时，用安卓官方的命令行工具从 AAB 生成本地可安装的
APK，注意区分为单一设备生成的包与通用包 - 生成后的
APK先在真机上安装一遍，确认能正常启动，再进入分发环节 - 打开虾分发官网（https://xiafenfa.com），上传该
APK，等待系统自动解析 - 解析完成后核对应用名称、版本号与图标是否正确，再生成分发二维码
- 把二维码或链接发给测试用户，并按需配置下载密码、IP 白名单等安全设置
建议：在发布流程里固定一条约定——上架用 AAB，内测分发用 APK，两者由同一次构建产出并各自留档。这样既不会出现商店包与内测包版本对不上的情况，也不用在发版当天临时补包。
常见问题
| 问题 | 说明 |
|---|---|
| AAB 能直接发给测试用户吗 | 不能，设备无法直接安装，需先转换成 APK |
| 内测包与商店包的版本号要一致吗 | 建议一致，便于按 versionCode 对应到同一份代码 |
| 从 AAB 生成的 APK 和商店下发的一样吗 | 商店会按设备拆分，本地生成的按你的配置产出，以真机实测为准 |
| iOS 端有类似的格式问题吗 | iOS 侧对应的是 IPA，分发前需确认证书与描述文件正常 |
总结
AAB 与 APK 不是替代关系，而是分工关系：一个面向商店上传，一个面向设备安装。内测阶段的判断标准很简单——测试用户能不能拿到一个点了就装的包。把 AAB 留在构建与上架环节，把 APK 交给内测分发，流程自然就顺了。文中涉及的产品能力与边界，以虾分发官网的最新说明为准。