深入分析 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 彈出菜單的.