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

App 瘦身新姿勢：Android App Bundle

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

1.Split APKs

多APK支持以下類型屏幕密度ABI，使用新的拆分機制，構(gòu)建同一個應(yīng)用程序的hdpi版本和mdpi版本，能夠共享很多的任務(wù) （如 javac，dx，proguard）。此外，它會被認(rèn)為是一個單一的variant，并且同一個測試程序?qū)挥脕頊y試每個多APK。

2.Dynamic Feature Module

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

Android App加固新變化

傳統(tǒng)加固方式

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

APK包里面的文件結(jié)構(gòu)：

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

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

幾維安全Java2c加固方案

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

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