订阅移动开发RSS CSDN首页> 移动开发

如何反编译Android 5.0 framework

发表于2015-12-21 18:10| 次阅读| 来源投稿| 0 条评论| 作者储俊雄

摘要:不同厂商会不同程度地修改Android framework层对应的原生模块代码,来达到自己的目的。为了更好地适配,开发人员不得不对framework层进行反编译,在Android更新到5.0后,对framework的反编译也出现了新的变化。

CSDN移动将持续为您优选移动开发的精华内容,共同探讨移动开发的技术热点话题,涵盖移动应用、开发工具、移动游戏及引擎、智能硬件、物联网等方方面面。如果您想投稿、寻求《近匠》报道,或给文章挑错,欢迎发送邮件至tangxy#csdn.net(请把#改成@)。 


在Android平台,对于和硬件交互相关的模块来说,比如:和双卡对应的Telephony模块、和拍照对应的Camera模块,以及Bluetooth模块等等,不同厂商会不同程度的修改Android framework层对应的原生模块代码来达到他们自己的目的,这就给应用层的开发人员带来了让他们很头疼的适配问题,严重会导致Crash等问题。为了更好的适配,我们不得不对framework层进行反编译,在Android更新到5.0后,开发人员对framework的反编译也出现了新的变化。

一、相关背景介绍

在5.0以前,我们可以直接从手机system目录导出的framework文件夹根目录里找到相关的odex文件或者相关dex文件(解压jar文件或apk文件得到),然后通过smali和dex2jar等工具就可以成功反编译得到我们所需要的东西。但到了5.0,出现了两个问题。

1. 以前分散在framework文件夹根目录里的那些odex文件全部集中在了framework文件夹中的arm(或arm64)子文件夹中,而且通过正常的反编译发现这些odex并不是像5.0以前一样是我们所需要的东西。


图:arm文件夹里的各种odex文件

2. 在arm(arm64)子文件中出现了两个我们在5.0以前没有见过的东西:boot.oat文件和boot.art文件,这两个文件引起了我们的兴趣,也是我们接下来分析的重点。


图:arm文件夹里重要的boot.oat文件和boot.art文件

二、对oat文件的分析

说到这个oat文件和art文件,我们不能不提Google在4.4版本以后新引入的ART运行时,这里简要的说一下:我们都知道在4.4以前,Android应用程序运行的核心基础是Dalvik虚拟机,这个Dalvik虚拟机原先是Apache开源的一个JVM的优化版本,而Google又对Dalvik虚拟机进行了特别的优化来适应Android系统,所以Dalvik虚拟机本质就是JVM。

尽管Google花了大力气优化Dalvik虚拟机,但是效果目前来看还不能让Google满意。为了Android系统的流畅度能更上一层楼,在Android进化到4.4版本时,Google决定抛弃Dalvik虚拟机引入全新的ART运行时。其实,ART运行时依然还是Java虚拟机的实现,只是ART运行时更高效更好用。


图:左边对应Dalvik虚拟机,右边对应ART运行时(原图出处:罗升阳——Android ART运行时无缝替换Dalvik虚拟机的过程分析)

和Dalvik虚拟机相比,ART运行时执行的是本地机器码,虽然Dalvik虚拟机也使用JIT(Just-In-Time)将dex字节码翻译成本地机器码,但是是在应用程序的运行过程中进行的。所以在效率方面还无法和ART运行时相比,ART运行时会在应用程序安装的时候就通过dex2oat将dex字节码翻译成本地机器码,而这个由ART翻译出来的本地机器码会对应着一个oat文件。


图:函数run_dex2oat通过调用dex2oat来将dex字节码翻译成本地机器码

其实,oat文件是一种特殊的ELF文件(关于ELF文件的具体内容可以Google相关内容),通过前面的介绍可以知道它包含本地机器码(从dex翻译而来),此外还包含有原来的dex文件内容,本质上它依然是一种预编译文件。这就告诉我们,oat文件就是把过去的很多dex文件一起合并输入然后由ART运行时在安装时翻译成本地的机器码然后再打包转换