Android App Bundle出來了，App加殼技術不能用了怎麼辦？

Google I/O大會上，Google向 Android 引入了新 App 動態化框架（Android App Bundle, AAB），被看做是對Android將來發展具備顛覆性的動態化解決方案。在給Android App帶來便利的同時，也給移動安全領域帶來了新的挑戰：傳統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，等要用的時候再下載。

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