多渠道打包方案,其实很有玄机

2019-08-20 18:00



Walle及VasDolly:美团多渠道打包方案和的多渠道打包方案其实在V1签名的处理上有所差异,Walle是添加空文件,VasDolly是添加zipcomment,v2签名就就往signing block里添加id-value的数据。


方案点评:这个方案其实当时真的很想很想用在项目里,但是不管是walle还是vaslloy针对的情况都是无需重签名添加渠道信息的,和业务需求格格不入。


得到启发


当时其实是在apk知识这一块受到了资源混淆框架AndResGuard的影响和启迪,当时资源混淆这一块的设计对我影响很大,当时就萌生了一种想法,AndResGuard混淆的原理其实也是通过修改读取arsc资源表的内容加以操作,其实就让笔者回顾当时看到apktool的做法。


因为便萌生了apktool多渠道打包,并封装成gradle-plugin的过程。


/   技术落地与困难   /


基于上面的探索和原理,梳理一遍整个多渠道打包的流程。


apktool解压apk

读取manifest中信息,重点是读取application标签中的icon,roundIcon,label,并保存起来,由于manifest已经经过了编译,所以其实这个icon,roundIcon,label都是对应的resource.arsc文件的资源id

读取resource.arsc文件的内容,修改label对应id的app名称,保存icon,roundIcon的资源id对应res目录下的资源

修改上一步记录的res中的资源文件

写回arsc文件,写回arsc文件和修改res资源文件的两个操作并发执行

7zip压缩

重签名


技术落地的过程其实借鉴了微信和美团的设计,其实整个arsc的读取操作都是根据apktool提供的jar包实现的,而我自己便在此之上添加写回的操作,笔者认为整个多渠道打包工具的难点在于resource.arsc文件的读取,修改以及写回操作。


困难1:resource.arsc读取


读取resource.arsc资源索引表的时候,会出现读多的异常。


问题原因:其实出现这个问题的原因就是因为笔者在书写读取操作的时候,其实并不想把太多东西保存在内存,而只是想把笔者想要的资源保存起来,所以其实并没有采取apktool中的读取流程,所以在读到最后一个TypeSpec中的Type的时候发现他会读多了。


解决方案:这个问题的解决方案有很多:


直接catch EOF这个异常,因为如果遇到EOF异常就说明肯定读完,但是这样做的话,要把读过的数据保存在内存中,其实对于内存相对较低的情况不太友好

还原apktool的做法

自实现一种机制去检测读取的位置


困难2:修改resource.arsc中的字符串


这里字符串的编码格式踩了坑,由于没注意编码格式导致了出现乱码的状况,最后分别对StringBlock中的utf-8和utf-16编码进行适配与转换。解决代码如下:


 

最新动态

相关资讯



服务支持

我们珍惜您每一次在线询盘,有问必答,用专业的态度,贴心的服务。

让您真正感受到我们的与众不同!