傳統App加殼技術無法應用在App Bundle模式生成的數據包之上。然而，幾維安全推出的Java2C加固方案完美支持Android App Bundle動態化框架，守護企業的核心代碼和數據安全。

App 瘦身新姿勢：Android App Bundle

Android App Bundle是借助Split Apk完成動態加載，使用AAB動態下發方式，可以大幅度減少應用體積，加快用戶安裝速度。使用Android的新應用發布格式和Google Play的工臺交付上傳應用，生成和提供針對每個用戶的設備進行優化的APK。只須在 Android Studio 中構建一個應用 (App Bundle)，就可以將應用所需的全部內容 (適用于所有設備) 都涵蓋在內：所有語言、所有設備屏幕大小、所有硬件架構。它本身并不支持動態化，只是動態化的一個載體文件，真正實現邏輯并不是它。

1.Split APKs

多APK支持以下類型屏幕密度ABI，使用新的拆分機制，構建同一個應用程序的hdpi版本和mdpi版本，能夠共享很多的任務 （如 javac，dx，proguard）。此外，它會被認為是一個單一的variant，并且同一個測試程序將會被用來測試每個多APK。

2.Dynamic Feature Module

這個概念感覺像是游戲里面到某個新地圖才開始下載那樣，不是一來就把所有資源都下載下來。這樣顯得apk更小了，而且就像游戲邏輯一樣，高級副本的地圖新手沒機會進入，就不必要下載這部分內容，有的用戶可能很久都不會用到部分功能，就可以放在Dynamic Feature Module，等要用的時候再下載。

Android App加固新變化

傳統加固方式

其對象是一個Android的安裝包，也就是一個APK文件，APK文件里面包含了基本所有的內容，一般對其進行加固，必須保證APK里面的DEX和支持的架構都放到包里面，然后對其進行加固處理，當然也有一些熱更新框架，但是加固對于這些熱更新的框架支持性并不好。

APK包里面的文件結構：

而Android App Bundle動態化框架，是按需要來進行更新代碼模塊和資源文件的，這就導致傳統加固并不合適，而且Google要求上傳的Google Play 商店的時候上傳打包好的AppBundle，就是以AAB格式的結尾的文件，其實也是一個壓縮包，具體的文件結構基本如圖：

base代表應用程序的基本模塊，feature1 和feature2是動態模塊，當用戶安裝包的時候，Google Play會生成一個基本包，將包安裝到設備上，然后運行到需要某個功能的時候才會下載動態模塊，所以傳統的加固是無法對其進行加固處理的。

幾維安全Java2c加固方案

直接對AAB文件進行加密處理，將里面的Dex進行加密轉換成加密后的SO，這樣的加固方案天然支持Android App Bundle的動態框架。經過Java2C加固之后輸出的也是一個AAB文件，上傳Google之后完全不影響其分包下發策略。

幾維安全Java2C是最新一代Android-Dex保護方案，之前針對Android的應用加密已經經歷了4代更迭（第一代動態加載，第二代整體加密解密，第三代類方法抽取，第四代自定義DVM運行時），然而這4代更迭并未很好的解決應用加密后的安全性、兼容性等問題，根本原因是這4代技術底層基于運行時攔截等手段實現Android代碼防護，而碎片化、開源化的Android生態讓這類技術不能從根本上解決安全問題。而幾維安全Java2C技術屬于代碼靜態加密，沒有運行時劫持，可配合安全編譯器工作，達到高安全性、高兼容性的要求。