先说说google play上架为什么要用AAB格式
相比于 APK，Google 主推的 APP 打包格式 AAB 在很多方面都更为优越，主要体现为如下几点：
1.1. 动态分发
一个 APK 中往往包含各国的语言资源、ABI、屏幕密度等资源。然而，对于单个用户来说，往往只需要这些资源中的部分。
目前，国内的开发者将所有资源统一放在单个 APK 中，这样就会导致 APK 特别庞大，而AAB在压缩APK体积方面具有优势。
而为了缩小体积，部分开发者会有意缩减 APK 中的 ABI 目录。例如，将 arm64-v8a 的 SO 从 APK 中去除，只留下 armeabi-v7a 的 SO。但这种做法使得64位 CPU 的手机无法发挥出其64位的运算优势，降低程序运行速度。还有语言的问题,如果手机系统语言没有设置支持英语,那下载的AAB包也是不包含英语语言包的,这个时候添加英语会出现使用默认语言。
Split APKs是 Android 5.0 开始提供的多 APK 构建机制，借助 Split APKs 可以将一个 APK 基于 ABI、屏幕密度和 CPU 架构拆分成多个 APK ，这样可以有效减少单个 APK 体积。当用户下载应用程序安装包时，Google Play 会自动识别用户的语言和 CPU 架构，自动将对应平台 SO 和资源的 APK 下发给用户。
1.2. 动态功能模块
在 Android Studio 中新增了一个模块：动态功能模块。通过该模块开发出的功能可在用户需要时再进行下载，类似于目前在国内被广泛使用的热更新机制，只不过热更新大多是用来修复功能性 BUG 的，而动态功能模块更倾向于形成一个独立功能。
用户在安装 APK 时，只需要下载一个包含 APP 主要功能的 APK ，而其他附加功能可在用户需要时进行动态下载安装。这样就进一步减小了 APK 的体积，为用户改善了 APP 安装使用体验。比如正常使用的时候是不会加载直播模块,在使用直播功能时才下发直播相关代码和资源。
关于AAB格式加固
APK格式加固后:在 APP 运行时对 APK 的签名特征进行校验，若运行时的 APK 签名特征与加固前的 APK 签名特征不一致，则 APK 会直接闪退。
AndroidManifest.xml修改 这里说明一下:一些粗心大意的开发者甚至会将 APP 的 debuggable 开关设为 "true"，从而使得 APK 能够被轻易地调试
正常的加固如果靠开发者自己去做,会牵扯到,签名加固:资源混淆: DEX 格式和 SO 格式加固,防逆向,防数据防泄漏:处理技术方面的能力,还需要大量的时间,目前在360,乐固,爱加密,网易都推出了加固方案.
但是aab格式的加固目前都是要收费的,主要有2家收费还不便宜:
网易易盾(非游戏行业 一个应用端5W一年 不限加固次数)
百度应用加固,(14w一年 单次1.4w)
AAB格式包到googleplay应用市场上面,在安装过程中自动签名,下载到手机上面根据手机设备下发不同的模块,我这边测试拿到下发的apk解压,发现并没有CPU架构的依赖库(lib),多语言/屏幕密度是缺少,也就是apk包确实是不完整的,也就很难反编译以及注入代码了,就算反编译成功也难再次打包成功,至于是否要使用收费的方案,就看自己的公司和应用规模了
从谷歌上面下发的AAB转APK查看签名有如下提示
cmd命令代码：jarsigner -certs -verbose -verify xxx.apk
[证书的有效期为2021/11/8 下午4:21至2051/11/8 下午4:21]
[无效的证书链: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]
sm 24 Thu Jan 01 01:01:02 CST 1981 META-INF/MainAppSDK_release.kotlin_module
>>> 签名者
X.509, CN=Android, OU=Android, O=Google Inc., L=Mountain View, ST=California, C=US