大家好，我是极客范的本期栏目编辑小友，现在为大家讲解Java代码加密支持Android App Bundle动态化框架问题。
传统的App包装技术无法应用于App Bundle模式生成的数据包。而多维度安全引入的Java2C加固方案，完美支撑了安卓App Bundle的动态框架，守护了企业的核心代码和数据安全。
App瘦身新姿势：安卓App Bundle
安卓捆绑包采用Split Apk方式动态加载，AAB动态分发方式可以大大减少应用量，加快用户安装速度。使用安卓新的应用发布格式和谷歌Play的工作台来交付和上传应用，并生成和提供针对每个用户设备优化的APK。只需在Android Studio中构建一个App Bundle，就可以覆盖应用需要的所有内容(适用于所有设备):所有语言、所有设备屏幕尺寸、所有硬件架构。它本身不支持动态，只是动态的载体文件，并不是真正实现逻辑的。
1.分裂杀伤人员地雷
多APK支持以下类型的屏幕密度ABI。使用新的拆分机制，同一应用程序的hdpi版本和mdpi版本可以共享许多任务(如javac、dx、proguard)。此外，它将被视为一个单一的变种，相同的测试程序将用于测试每个多重APK。
2.动态特征模块
这个概念感觉就像是在游戏中下载一个新的地图，而不是一次下载所有的资源。这让apk变小了，就像游戏逻辑一样，拥有高级副本的新手地图用户没有机会进入，所以没必要下载这部分内容。有些用户可能长时间不使用某些功能，可以放在动态功能模块中，需要时下载。
安卓强化新变化
传统加固方法
对象是一个安卓安装包，也就是一个APK文件。APK文件基本上包含了所有的内容。一般要加固。有必要确保将APK的DEX和支持的体系结构放入包中，然后对其进行增强。当然，也有一些热更新框架，但是强化对这些热更新框架并没有好处。
APK包中的文件结构：
Android AppBundle动态框架根据需要更新代码模块和资源文件，导致传统加固不合适。而且，当谷歌要求上传的Google Play商店上传打包的App Bundle时，也就是以AAB格式结尾的文件实际上是一个压缩包。具体文件结构基本如下：
Base表示应用程序的基本模块，feature1和feature2是动态模块。用户安装包的时候，Google Play会生成一个基础包，安装在设备上，然后在需要某个功能的时候下载动态模块，传统的加固是无法加固的。
多维安全Java2c加固方案
AAB文件被直接加密，其中的索引被加密并转换成加密的SO。这个加固方案自然支持安卓App Bundle的动态框架。在Java2C增强之后，输出也是一个AAB文件。上传到谷歌后，完全不会影响其分包和分销策略。
Java2C是最新一代的Android-Dex保护方案。此前，针对安卓的应用加密经历了四代(第一代动态加载、第二代整体加解密、第三代类方法抽取、第四代定制DVM运行时)。然而，这四代并没有解决应用加密后的安全性和兼容性问题。根本原因是这四代技术的底层都是基于运行时拦截等手段实现安卓代码保护，而碎片化、开源的安卓生态使得此类技术无法从根本上解决安全问题。而安全几个维度的Java2C技术属于代码静态加密，没有运行时劫持，可以与安全编译器协同工作，满足高安全性和兼容性的要求。
传统的App包装技术无法应用于App Bundle模式生成的数据包。但格威安全推出的Java2C加固方案完美支持安卓App Bun。
dle动态化框架，守护企业的核心代码和数据安全。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技术属于代码静态加密，没有运行时劫持，可配合安全编译器工作，达到高安全性、高兼容性的要求。
.dfma { position: relative; width: 1000px; margin: 0 auto; } .dfma a::after { position: absolute; left: 0; bottom: 0; width: 30px; line-height: 1.4; text-align: center; background-color: rgba(0, 0, 0, .5); color: #fff; font-size: 12px; content:"广告"; } .dfma img { display: block; }