深入分析 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 ,发现:
原来玄机 就在 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 里面发现验证也就是一句函数调用的问题了:
上面是我修改后的代码了, 也就是把 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 弹出菜单的.