默認的rk3066升級工具是量產工具，不能保留已經安裝的程序，momo8默認設置甚至會刪除內置存儲數據（可以編輯升級config避免），修改系統文件一不小心不能進入系統又忘記備份的話，量產工具意味着一切重來。momo8現在的系統還不是很穩定，由於tf卡不夠用一直使用的內置存儲，在刷機過程中受夠了數據備份的苦頭，上午由於修改系統文件又忘了備份新安裝程序，到處找解決方法，在經歷重大損失后終於找到了方法。
需要的軟件：
1.刷機精靈： 下載http://www.shuame.com/
2.RK3066擦除工具 下載 http://www.yuandaocn.com/download.aspx?cid=7 或者http://kuai.xunlei.com/d/CRDPEIDHHSSW
3.官方rom包，MOMO8(IPS)-4.1.1固件20120920http://www.ployer.cn/prshow.asp?id=131&p=zc
4.老熊RK29固件修改工具 rk3066通用 http://pan.baidu.com/share/link?shareid=63747&uk=3373127877 或者http://bbs.imp3.net/thread-10480891-1-1.html
開工：
1.解壓縮老熊RK29固件修改工具，把官方rom包加壓出來的update.img復制到老熊RK29固件修改\rk29打包解包工具ultra2.1目錄里，運行 rk29打包解包工具ultra2.1目錄下"固件解包.bat"，解包出來的文件存放在該目錄下面"temp\image"下面。
2.注意rk29打包解包工具ultra2.1\temp目錄里面的parameter,這個文件存放的是各個映像包的偏移地址，
用記事本等打開，
mtdparts=rk29xxnand:后面則是各分區值
格式為: 分區大小@偏移大小（分區鏡像）
比如其中：0x00004000@0x00004000(kernel)
這里kerenl的偏移值則是 0x00004000
又如：0x00008000@0x00010000(recovery)
這里recovery的偏移值則是 0x00010000
再如：0x00100000@0x0031A000(system)
這里system的偏移值則是0x0031A000
注意！該偏移值為刷入固件的偏移值，偏移值填寫錯誤可能將導致系統其他分區被覆蓋而引起死機。
這個是momo8 rom中system分區的偏移地址是0x0031A000 ，上面下載的RK3066擦除工具默認system偏移地址是 0x0021A000 ，這個地址每個機型可能不一樣，需要根據parameter 的內容修改，其它kernel.img、recovery.img等的偏移地址也可以從parameter 找到備用。
3.安裝並運行刷機精靈，如果機子已經開啟usb調試的話，刷機精靈可以連接平板；沒開usb調試的話，直接用RK3066擦除工具的切換功能就行了。已一般情況來說已經開啟usb調試 ，刷機精靈-使用工具-點擊"進入fastboot模式"，平板自動重啟並進入刷機模式，不用拆機或恢復出廠設置再手動進入刷機（當初沒經驗，系統文件修改錯誤無法進入系統，恢復出廠還是不行就忘了這個方法了，白拆機了）。
4.解壓縮RK3066擦除工具，運行目錄RKDevelopTool_v1.35里面的RKAndroidTool
特別注意這里的地址欄里面的各個img偏移地址是否與解壓出來parameter里面是否一致，以momo8為例，kerenl、recovery、misc與默認地址一致，但是system不一致，對不一致的雙擊該地址欄，修改為上面解壓出來 parameter里面的地址，比如momo8的第7欄system地址修改為0x0031A000，點擊路徑之后的空白欄，選擇實際解壓出來的各個分區img，選擇好后，勾選要刷入的img，特別注意的是，如果選擇刷入misc的話，所有用戶數據以及內置sd卡都會被格式化，血的教訓啊,本來想保存用戶數據，結果連內置sd卡也被格式化了。一般只需要刷入system就行了，否則直接用量產工具不是更方便？
選擇好后，點擊執行，刷入很快，完畢后會自動重啟，之前安裝的程序包括root都會保留，每次刷機、升級不用鈦備份備份恢復了。
來自 <http://bbs.imp3.net/thread-10790799-1-1.html>
RKAndroidTool工具的各項image詳解(RK2918版本)
/********************************************************************************************
* author：conowen@大鍾
* E-mail：conowen@hotmail.com
* http://blog.csdn.net/conowen
* 注：本文為原創，僅作為學習交流使用，轉載請標明作者及出處。
********************************************************************************************/
..\rockdev\表示RKAndroidTool所在目錄的上一層目錄下的rockdev文件夾。
工具預設目錄為..\rockdev\，若掃描有Paremeter ，則載入，讀出分區表信息，關於Paremeter ，參看第2點。
工具的"偏移"（offset）表示分區的起始地址，也參看第2點。
1、Loader.bin (100K左右)
系統啟動必須的引導文件
RK29xxLoader(L)_V2.08.bin
2、Paremeter 分區信息表（50K左右）
打開rockdev目錄下的Paremeter 文件，內容如下
[java]
- FIRMWARE_VER:0.2.3
- MACHINE_MODEL:rk29sdk
- MACHINE_ID:007
- MANUFACTURER:RK29SDK
- MAGIC: 0x5041524B
- ATAG: 0x60000800
- MACHINE: 2929
- CHECK_MASK: 0x80
- KERNEL_IMG: 0x60408000
- #COMBINATION_KEY: 0,6,A,1,0
- CMDLINE: console=ttyS1,115200n8n androidboot.console=ttyS1 init=/init initrd=0x62000000,0x800000
- mtdparts=rk29xxnand:0x00002000@0x00002000(misc),0x00004000@0x00004000(kernel),0x00008000@0x00008000(boot),
- 0x00008000@0x00010000(recovery),0x00078000@0x00018000(backup),0x0003a000@0x00090000(cache),
-
0x00100000@0x000ca000(userdata),0x00002000@0x001ca000(kpanic),0x00080000@0x001cc000(system),-@0x0024c000(user)
misc
kernel——內核鏡像
boot——系統引導
recovery
backup
cache——緩存區
userdata——用戶rom區
kpanic
system——系統程序
user———用戶儲存區
前面是關於機器固件版本，機器型號，機器制造廠商的信息，當然也可以改成自己所喜歡的。
下面的
[java]
-
mtdparts=rk29xxnand
則表示機器nand flash的分區信息。
[java]
-
0x00002000@0x00002000(misc)
右邊的0x00002000表示起始地址，左邊的0x00002000表示misc分區的容量大小。至於為什么要從0x00002000開始，因為分區表Paremeter 也要占有flash的容量，Paremeter 是從0x00000000開始的。左右兩邊數值相加，就等於下一個分區的起始地址，如此類推。如到了recovery分區。
[java]
-
0x00008000@0x00010000(recovery)
起始地址為0x00010000，recovery分區大小為0x00008000，所以下一個backu分區的起始地址為0x00018000。
另外，關於用戶區userdata，也就是rom區。常說的擴容就是擴展此分區。
[java]
-
0x00100000@0x000ca000(userdata),
先來算算此分區的大小。
0x00100000為十六進制，折算成十進制為1048576，因為瑞芯微rockchip采用的是0.5K為單位。折算結果為
1048576*0.5K=524288K
524288K/1024=512M
也就是說rom區容量為512M。
假若要擴展此分區，則往后的各個偏移量都要相加推移。
到了最后一個user分區，
[java]
-
-@0x0024c000(user)
左邊的"-"表示user分區占有剩余的nand flash所有容量。也就是常常存放一些用戶的數據如電影、音樂之類的。不同於rom區的存放安裝軟件。
3、Misc.img（1K左右）
cpu加電之后，啟動bootloader，（即是RK29xxLoader(L)_V2.08.bin），就會讀取MISC分區第一塊的內容， 決定進入recovery模式還是升級基帶Baseband Processor（BP）或做其它事情。而更改Misc內容的操作為按下某個按鍵或者用戶設置系統。
4、kernel.img（6M左右）
內核鏡像，經過編譯得出zImage，即為Kernel.img。或者SDK包直接附帶。
5、boot.img（8M左右）
系統bootload啟動之后，進入正常啟動模式，就會讀取boot.img進去系統正常模式。
boot.img包括了kernel.img鏡像和一個根文件系統（rootfs）
6、recovery.img（12M左右）
系統bootload啟動之后，通過讀取Misc分區的內容，確認如果是進入Recovery模式的話，進去讀取Recovery.img。
recovery.img包括了一個kernel.img與一個根文件系統（rootfs），kernel鏡像與boot,img的完全一樣。
7、system.img（100+M左右）
包括了系統必要的app，詳細參考
http://blog.csdn.net/conowen/article/details/7251057
8、擦除IDB
表示清空分區表，就是低級格式化nand flash。這樣的話，要重新刷入parameter分區。
附：Recovery 根文件系統目錄結構
$ tree
.
├── advanced_meta_init.rc
├── data
├── default.prop
├── dev
├── etc
├── init
├── init.factory.rc
├── init.goldfish.rc
├── init.quacomm.rc
├── init.rc
├── meta_init.rc
├── proc
├── res
│ ├── images
│ │ ├── icon_error.png
│ │ ├── icon_installing.png
│ │ ├── indeterminate1.png
│ │ ├── indeterminate2.png
│ │ ├── indeterminate3.png
│ │ ├── indeterminate4.png
│ │ ├── indeterminate5.png
│ │ ├── indeterminate6.png
│ │ ├── progress_empty.png
│ │ └── progress_fill.png
│ └── keys
├── sbin
│ ├── adbd
│ ├── advanced_meta_init
│ ├── meta_init
│ ├── meta_tst
│ └── recovery
├── sys
├── system
└── tmp
來自 <http://blog.csdn.net/conowen/article/details/7251886>
第一步：系統引導bootloader，即RK29xxLoaderXXX.bin文件
加電后，CPU將先執行 bootloader程序，然后bootloader首先會讀寄存器地址base + APP_DATA1的內容， 根據這個地址的值決定是否進入recovery模式或者其它模式。bootloader還會讀取MISC分區第一塊的內容， 決定進入recovery模式還是升級基帶Baseband Processor（BP）或做其它事情
而上述寄存器與分區的值是有按鍵觸發或者軟件觸發的。
a) 開機按reset+返回鍵，系統進入recovery模式，加載recovery.img，recovery.img包含內核，基本的文件系統，用於工程模式的燒寫
b) 開機按Power，正常啟動系統，加載boot.img，boot.img包含內核，基本文件系統，用於正常啟動機器（以下只分析正常啟動的情況）
第二步： 啟動內核kernel
1) 源碼：kernel/*
2) 說明：kernel由bootloader加載
第三步： 文件系統(rootfs)及應用初始化（init）
1) 源碼：system/core/init/*
2) 配置文件：system/rootdir/init.rc，
3) 說明：init是一個由內核啟動的用戶級進程，它按照init.rc中的設置執行：啟動服務（這里的服務指linux底層服務，如adbd提供adb支持，vold提供SD卡掛載等），執行命令和按其中的配置語句執行相應功能
第四步： 重要的后台程序zygote
1) 源碼：frameworks/base/cmds/app_main.cpp等
2) 說明：zygote是一個在init.rc中被指定啟動的服務，該服務對應的命令是/system/bin/app_process
a) 建立Java Runtime，建立虛擬機
b) 建立Socket接收ActivityManangerService的請求，用於Fork應用程序
c) 啟動SystemServer
第五步： 系統服務system server
1) 源碼：frameworks/base/services/java/com/android/server/SystemServer.java
2) 說明：被zygote啟動，通過System Manager管理android的服務（這里的服務指frameworks/base/services下的服務，如衛星定位服務，剪切板服務等）
第六步：桌面launcher
1) 源碼：ActivityManagerService.java為入口，packages/apps/launcher*實現
2) 說 明：系統啟動成功后SystemServer使用xxx.systemReady()通知各個服務，系統已經就緒，桌面程序Home就是在 ActivityManagerService.systemReady()通知的過程中建立的，最終調用 ()啟launcher
第七步： 解鎖
1) 源碼：
frameworks/policies/base/phone/com/android/internal/policy/impl/*lock*
2) 說 明：系統啟動成功后SystemServer調用wm.systemReady()通知WindowManagerService，進而調用 PhoneWindowManager，最終通過LockPatternKeyguardView顯示解鎖界面，跟蹤代碼可以看到解鎖界面並不是一個 Activity，這是只是向特定層上繪圖，其代碼了存放在特殊的位置
第八步： 開機自啟動的第三方應用程序
1) 源碼：
frameworks/base/services/java/com/android/server/am/ActivityManagerService.java
2) 說 明：系統啟動成功后SystemServer調用ActivityManagerNative.getDefault().systemReady()通知ActivityManager啟動成功，ActivityManager會通過置變量mBooting，通知它的另一線程，該線程會發送廣播android.intent.action.BOOT_COMPLETED以告知已注冊的第三方程序在開機時自動啟動。
第九步： 總結
綜上所述，系統層次關於啟動最核心的部分是zygote(即app_process)和system server，zygote它負責最基本的虛擬機的建立，以支持各個應用程序的啟動，而systemserver用於管理android后台服務，啟動步驟及順序。
10. 參考
http://blog.csdn.net/basonjiang_sz/category/648399.aspx
來自 <http://blog.csdn.net/conowen/article/details/7252490>
Recovery簡介
Android利用Recovery模式，進行恢復出廠設置，OTA升級，patch升級及firmware升級。
升級一般通過運行升級包中的META-INF/com/google/android/update-script腳本來執行自定義升級，腳本中是一組recovery系統能識別的UI控制，文件系統操作命令，例如write_raw_image（寫FLASH分區），copy_dir（復制目錄）。該包一般被下載至SDCARD和CACHE分區下。如果對該包內容感興趣，可以從http://forum.xda-developers.com/showthread.php?t=442480下載JF升級包來看看。
升級中還涉及到包的數字簽名，簽名方式和普通JAR文件簽名差不錯。公鑰會被硬編譯入recovery，編譯時生成在：out/target/product/XX/obj/PACKAGING/ota_keys_inc_intermediates/keys.inc
G1中的三種啟動模式
MAGIC KEY:
- camera + power：bootloader模式，ADP里則可以使用fastboot模式
- home + power：recovery模式
-
正常啟動
Bootloader正常啟動，又有三種方式，按照BCB（Bootloader Control Block, 下節介紹）中的command分類：
- command == 'boot-recovery' → 啟動recovery.img。recovery模式
- command == 'update-radio/hboot' → 更新firmware（bootloader)
-
其他 → 啟動boot.img
Recovery涉及到的其他系統及文件
-
CACHE分區文件
Recovery 工具通過NAND cache分區上的三個文件和主系統打交道。主系統（包括恢復出廠設置和OTA升級）可以寫入recovery所需的命令，讀出recovery過程中的LOG和intent。
- /cache/recovery/command： recovery命令，由主系統寫入。所有命令如下：
- --send_intent=anystring - write the text out to recovery.intent
- --update_package=root:path - verify install an OTA package file
- --wipe_data - erase user data (and cache), then reboot
- --wipe_cache - wipe cache (but not user data), then reboot
- /cache/recovery/log：recovery過程日志，由主系統讀出
- /cache/recovery/intent：recovery輸出的intent
- MISC分區內容
Bootloader Control Block (BCB) 存放recovery bootloader message。結構如下：
struct bootloader_message {
char command[32];
char recovery[1024];
}; - command可以有以下兩個值
"boot-recovery"：標示recovery正在進行，或指示bootloader應該進入recovery mode
"update-hboot/radio"：指示bootloader更新firmware -
recovery內容
"recovery\n
<recovery command>\n
<recovery command>"
其中recovery command為CACHE:/recovery/command命令兩種Recovery Case
- FACTORY RESET（恢復出廠設置）
- 用戶選擇"恢復出廠設置"
- 設置系統將"--wipe_data"命令寫入/cache/recovery/command
- 系統重啟，並進入recover模式（/sbin/recovery）
- get_args() 將 "boot-recovery"和"--wipe_data"寫入BCB
- erase_root() 格式化（擦除）DATA分區
- erase_root() 格式化（擦除）CACHE分區
- finish_recovery() 擦除BCB
- 重啟系統
- OTA INSTALL（OTA升級）
- 升級系統下載 OTA包到/cache/some-filename.zip
- 升級系統寫入recovery命令"--update_package=CACHE:some-filename.zip"
- 重啟，並進入recovery模式
- get_args() 將"boot-recovery" 和 "--update_package=..." 寫入BCB
- install_package() 作升級
- finish_recovery() 擦除 BCB
- ** 如果安裝包失敗 ** prompt_and_wait() 等待用戶操作，選擇ALT+S或ALT+W 升級或恢復出廠設置
- main() 調用 maybe_install_firmware_update()
- 如果包里有hboot/radio的firmware則繼續，否則返回
- 將 "boot-recovery" 和 "--wipe_cache" 寫入BCB
- 將 firmware image寫入cache分區
- 將 "update-radio/hboot" 和 "--wipe_cache" 寫入BCB
- 重啟系統
- bootloader自身更新firmware
- bootloader 將 "boot-recovery" 寫入BCB
- erase_root() 擦除CACHE分區
- 清除 BCB
-
main() 調用 reboot() 重啟系統
Recovery模式流程
/init → init.rc → /sbin/recovery →
main():recovery.c
- ui_init():ui.c ［UI initialize］
- gr_init():minui/graphics.c ［set tty0 to graphic mode, open fb0]
- ev_init():minui/events.c [open /dev/input/event*]
- res_create_surface:minui/resource.c [create surfaces for all bitmaps used later, include icons, bmps]
- create 2 threads: progress/input_thread [create progress show and input event handler thread]
- get_args():recovery.c
- get_bootloader_message():bootloader.c [read mtdblock0(misc partition) 2nd page for commandline]
- check if nand misc partition has boot message. If yes, fill argc/argv.
- If no, get arguments from /cache/recovery/command, and fill argc/argv.
- set_bootloader_message():bootloader.c [set bootloader message back to mtdblock0]
- Parser argv[] filled above
- register_update_commands():commands.c [ register all commands with name and hook function ]
- registerCommand():commands.c
- Register command with name, hook, type, cookie.
- Commands, e.g: assert, delete, copy_dir, symlink, write_raw_image.
- registerFunction():commands.c
- Register function with name, hook, cookie.
- Function, e.g: get_mark, matches, getprop, file_contains
- install_package():
- translate_root_path():roots.c [ "SYSTEM:lib" and turns it into a string like "/system/lib", translate the updater.zip path ]
- mzOpenZipArchive():zip.c [ open updater.zip file (uncompass) ]
- handle_update_package():install.c
- verify_jar_signature():verifier.c [ verify signature with keys.inc key; verify manifest and zip package archive ]
- verifySignature() [ verify the signature file: CERT.sf/rsa. ]
- digestEntry():verifier.c [ get SHA-1 digest of CERT.sf file ]
- RSA_verify(public key:keys.inc, signature:CERT.rsa, CERT.sf's digest):libc/rsa.c [ Verify a 2048 bit RSA PKCS1.5 signature against an expected SHA-1 hash. Use public key to decrypt the CERT.rsa to get original SHA digest, then compare to digest of CERT.sf ]
- verifyManifest() [ Get manifest SHA1-Digest from CERT.sf. Then do digest to MANIFEST.MF. Compare them ]
- verifyArchive() [ verify all the files in update.zip with digest listed in MANIFEST.MF ]
- find_update_script():install.c [ find META-INF/com/google/android/update-script updater script ]
- handle_update_script():install.c [ read cmds from script file, and do parser, exec ]
- parseAmendScript():amend.c [ call yyparse() to parse to command ]
- exeCommandList():install.c
- exeCommand():execute.c [ call command hook function ]
- erase DATA/CACHE partition
- prompt_and_wait():recovery.c [ wait for user input: 1) reboot 2) update.zip 3) wipe data ]
- ui_key_xxx get ALT+x keys
- 1) do nothing
- 2) install_package('SDCARD:update.zip')
- 3) erase_root() → format_root_device() DATA/CACHE
- may_install_firmware_update():firmware.c [ remember_firmware_update() is called by write_hboot/radio_image command, it stores the bootloader image to CACHE partition, and write update-hboot/radio command to MISC partition for bootloader message to let bootloader update itself after reboot ]
- set_bootloader_message()
- write_update_for_bootloader():bootloader.c [ write firmware image into CACHE partition with update_header, busyimage and failimage ]
- finish_recovery():recovery.c [ clear the recovery command and prepare to boot a (hopefully working) system, copy our log file to cache as well (for the system to read), and record any intent we were asked to communicate back to the system. ]
-
reboot()
Recovery模式流程圖
以下流程圖繪制了系統從啟動加載bootloader后的行為流程。
來自 <http://blog.csdn.net/conowen/article/details/7253503>