recovery的研究

深入分析 paul 的r5  root 会发现 , 他自己的recovery执行文件 是进入 recovery模式 后拷贝进去 然后手工执行的.

也就是说,  paul通过这个新的recovery 屏蔽了系统本身的, 然后实现刷自定义rom .

当然这个recovery 是支持 zip更新包的 testkey 完整性验证的.

 

那么为什么他使用 testkey 而不干脆直接去掉这个验证呢,

另外 , 有谁敢保证 , 他这个recovery 没有加入什么其他的东西呢 (额的洁癖有犯病了)

 

ok , 干脆自己搞一个:

 

recovery的源码在 bootable/recovery目录下.

单纯编译出来的执行文件 在recovery 模式下是可以执行的

可惜因为确认键的识别缺失(没法 catch住除了声音键外任何按钮的型号 )

 

在 device/htc/passion/recovery/recovery_ui.c  这里有一个似乎是htc 专用的 recovery ui ,发现:

int device_handle_key(int key_code, int visible) { if (visible) { switch (key_code) { case KEY_DOWN: case KEY_VOLUMEDOWN: return HIGHLIGHT_DOWN; case KEY_UP: case KEY_VOLUMEUP: return HIGHLIGHT_UP; case KEY_ENTER: case BTN_MOUSE: // trackball button return SELECT_ITEM; } } return NO_ACTION; }

原来玄机 就在 BTN_MOUSE 这个case上.

 

拷贝该文件到bootable/recovery/

修改 Android.mk

 

LOCAL_STATIC_LIBRARIES :=
ifeq ($(TARGET_RECOVERY_UI_LIB),)
  LOCAL_SRC_FILES +=  recovery_ui.c  #(这里原来是 default_recovery.c)
else
  LOCAL_STATIC_LIBRARIES += $(TARGET_RECOVERY_UI_LIB)
endif

 

在 recovery_ui.c 上 把recover_firmware_update_log(); 这行注释掉(还没有研究该函数的调用意义, 不过不影响使用)

 

 

可以发现 recovery已经编译成功, 编译方法:

. build/envsetup.sh
make recovery

 

注意这两个目录, 编译中间文件和需要的静态库都在这里, 有什么用 , 你懂的...

out/target/product/generic/obj/EXECUTABLES/recovery_intermediates/
out/target/product/generic/obj/STATIC_LIBRARIES/

 

 

 

但最终目标是取消完整性验证:

在 install.c 里面发现验证也就是一句函数调用的问题了:

 

    int err; // err = verify_file(path, loadedKeys, numKeys); free(loadedKeys); err=VERIFY_SUCCESS; LOGI("verify_file returned %d/n", err); if (err != VERIFY_SUCCESS) { LOGE("signature verification failed/n"); return INSTALL_CORRUPT; }

 

上面是我修改后的代码了,  也就是把 verify_file()函数注释 , 然后直接给返回值而已.

 

 

ok, 尝试刷自己的rom , 而且是没有经过test_key签名的,  失败!

从 /tmp/recovery.log 上可以发现 验证已经通过! 

提示没有找到update_binary.

 

这里特别感谢这篇文章的作者:http://blog.csdn.net/linux_lyb/archive/2010/03/03/5341296.aspx

新版本的 recovery 已经是通过 update_binary 和updater_script 实现update脚本了.

同时, 文章还提到 update_binary就在bootable/recovery/updater

再次郑重感谢!

 

也只怪自己大意了, updater.c 写明:

// Where in the package we expect to find the edify script to execute.
// (Note it's "updateR-script", not the older "update-script".)
#define SCRIPT_NAME "META-INF/com/google/android/updater-script"

 

把updater 可执行 更名为 updte_binary

从网上搜索最新的自定rom , 学习新的updater_script脚本.

其实发现改变也就是把命令从命令模式 更改为函数模式而已...

把两个文件都放在 META-INF/com/google/android/中, 打包.

刷rom , 成功!

 

 

实话说, 我虚伪了....

三个晚上的摸索, 并不是上面几个步骤可以说清楚的,

我甚至把cup-cake 的recovery下载下来 , 尝试旧版本的recovery , 甚至意图把新旧两份代码合并.

但是最终还是上面这种方式最简单了.

 

实现了以后可以做什么, 起码以后刷新rom 会方便不少, 实现自动化也指日可待 ,

最后提一句,  这个recovery 的启动是通过 电源键 + vol_up 弹出菜单的.