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技术属于代码静态加密，没有运行时劫持，可配合安全编译器工做，达到高安全性、高兼容性的要求。

相关阅读：Java代码加密：https://www.kiwisec.com/produ...