Android Framework开发调试

目前调试遇到的问题

采用的方案

操作步骤
1 编译无优化系统

2 生成jar包或so

3 替换旧的jar包或so

4 网络挂载调试

转载请注明链接

给手机定制ROM，需要对framework进行较多修改，其中比较令人头疼的是开发完毕后的调试验证，比较笨的方法是重新编译系统，生成img或是升级包，然后烧写系统或是系统升级，这两种方式效率比较低下， 并且一旦开发出错，重新调试的成本将会大大提高，下面介绍一种能够提高framework开发效率的方法，此法涵盖jar及so的常规开发。

与本文不同的另外一种DDMS动态调试方法见如下链接：

http://blog.csdn.net/omnispace/article/details/73320935

1. 目前调试遇到的问题：

众所周知，android为了提高系统及APP的启动速度，对jar及应用在编译时进行了预优化，因为启动时ART虚拟机会将jar及APK中包含Dex字节码的classes.dex进行优化，得到后缀为.odex的文件，编译时预优化就省去了优化Dex字节码的时间，启动会更快。

但是这个优化过程阻碍了framework的调试，也就是当修改完framework代码后，生成的framework.jar不能直接替代旧的framework.jar，从而使修改后的代码生效。

2. 采用的方案：

在开发调试阶段，将这种预优化编译方式去掉，这样开发完毕的framework.jar就可以直接替换旧的jar从而生效。

3. 操作步骤：

3.1 编译无优化系统

也就是编译出没有预优化过的系统base，然后烧写或是升级，使调试系统没有.odex后缀文件。

修改编译选项：

找到源码目录下的build/core/main.mk文件，修改WITH_DEXPREOPT编译选项值：

WITH_DEXPREOPT = true->WITH_DEXPREOPT = false

这样修改表示编译时不再进行预优化，不再生成odex文件。

编译系统：

在源码编译根目录执行如下命令：

make clean

此步骤主要清除之前编译产生的中间成果物，防止make时仍会产生odex文件至img或是otapackage中。

make -j8

8核并行编译，具体还要看编译机器的cpu核心数，并不是越多越好。生成烧写的成果物img。

make otapackage

生成ota升级包，可以放在sdcard中升级用。

烧写或是升级系统

3.2 生成jar包或so：

在修改framework代码后，或是cpp代码后，在修改目录下执行：

mm -b

编译之后将生成没有优化的jar，或是so文件

3.3 替换旧的jar包或so：

一般所需替换的jar或是so在system路径下，这种情况在terminal下执行拷贝覆盖将会提示失败，因为system为只读的，因此需要先执行下面的命令：

mount -o remount ,rw /system

将system分区更改为可读写属性。然后执行替换，重启系统。相关代码组件将会更新。这是新的代码将会生效。

从上述过程来看，整个调试步骤不再需要每次重新编译整个base系统，然后烧写或是升级，只需要拷贝覆盖修改后的成果物，然后重启系统生效即可（当然你得有root权限）。这大大调高framework的调试效率。

3.4 网络挂载调试：

尽管上述步骤已经实现了较高效率的调试，但是如果你觉得拷贝成果物仍然比较费事，或是一旦开发的成果物有问题，可能会导致系统不能启动，这样仍然需要重新编译然后烧写机器，仍会造成比较大的困扰。

这样网络挂载模式就能够完美解决上述所有的问题了，网络挂载调试就是你的手机终端系统是通过网络从你的电脑上加载的。首先找到client端（手机）system分区对应在源码编译成果物的目录，然后将mm -b后生成的成果物直接拷贝到电脑成果物目录中去，重启client即可：

cp -f out/target/product/generic/system/lib/framework.jar out/target/product/generic/root/

system/lib/framework.jar