Java程式碼加密支援Android App Bundle動態化框架，守護核心程式碼安全

Google I/O大會上，Google向 Android 引入了新 App 動態化框架（Android App Bundle, AAB），被看作是對Android未來發展具有顛覆性的動態化解決方案。在給Android App帶來便利的同時，也給移動安全領域帶來了新的挑戰： 傳統App加殼技術無法應用在App Bundle模式生成的資料包之上。然而，幾維安全推出的 方案完美支援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，等要用的時候再下載。

Dynamic Delivery示意效果圖

(左) 舊版 APK 交付樣例 - 將全部資源都交付至裝置；(右) 動態交付樣例 - 只向裝置交付必要資源

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技術屬於程式碼靜態加密，沒有執行時劫持，可配合安全編譯器工作，達到高安全性、高相容性的要求。

相關閱讀：Java程式碼加密：