先說說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