本教程同步更新在http://blog.csdn.net/airk000
轉載請註明出處http://blog.csdn.net/airk000/article/details/8916797

*本教程假設你已經擁有一個Android編譯環境及ShenduOS最新程式碼

1.為新機器製作Recovery

你需要準備：recovery.img(或boot.img)
如果你準備的是boot.img，那麼你還需要官方的recovery.fstab，這個檔案會在recovery.img中，通過解包，會在etc/下發現這個檔案。這個檔案至關重要，如果不對，可能導致機器變磚。所以，如果條件允許，最好還是準備一個已經能夠正常使用的recovery.img，官方的recovery.img也可，這樣更安全些。當然，也可以準備boot.img，而自己通過cat核心裝置來計算出一個recovery.fstab，不過~~~何必呢？

進入ShenduOS原始碼目錄，執行

make otatools -jX

X為編譯執行緒數。

在編譯完成後，對將out/host/linux-x86/bin加入系統環境變數：

echo "export PATH=$PATH:/XXX/out/host/linux-x86/bin/" >> ~/.bashrc
source ~/.bashrc

其中XXX為原始碼目錄路徑。

在原始碼目錄下，執行：

./build/tools/device/mkvendor.sh <MENUFACTURE> <MODEL> <image>

MENUFACTURE 為廠商名字，如HTC Samsung Huawei ZTE, etc.
MODEL 為產品代號，如saga（HTC Desire S), i9100, n909, etc.
image 為你所準備的img檔案路徑

成功執行以上命令後，系統會自動為你的裝置生成device code，這個時候如果你準備的是boot.img，那麼必須要注意的是：需要替換或修改recovery.fstab，這個檔案就在新生成的這個device code下邊，如device/htc/saga/，這一步非常的重要，因為系統提供的預設recovery.fstab很有可能導致你的機器變磚。當然，如果你準備的是recovery.img，那麼這個檔案就沒有必要替換了，他已經是正確的，這就是用recovery做recovery的優勢所在。

2.為ShenduOS已經支援的機型製作Recovery

雖然可能這個意義不大，但是相信也會有不少人來嘗試的，直接執行：

./build/envsetup.sh
breakfast xxx

xxx 為ShenduOS已經支援的機型代號，如c8812，saga，etc.

3.開始製作Recovery

有兩種製作方式：

make recoveryzip
make recoveryimage

make recoveryzip，一般用來除錯，這個操作會直接生成在recovery下可以直接刷入的update.zip，刷了他不會覆蓋原有recovery，只是看看樣子而已，所以除錯經常用這個。與adb sideload配合除錯效率高。
make recoveryimage， 用來生成recovery.img，一般都是在除錯好了之後確認無誤了，就來生成他，生成後，可以使用installrecovery命令進行recovery的安裝操作（這個命令要在. build/envsetup.sh之後方可使用）

4.除錯Recovery

這個將是本教程重點講述的部分，編譯Recovery人人都能，只要給予一定的引導，都能在短時間內輕鬆搞定（編譯系統也一樣），麻煩而有重要的事情在後續的除錯上。下面將敘述幾個ShenduOS Recovery的除錯要點，方便大家開發與參與。

1）顏色模式
通常情況下，一個新機器編譯出recovery後顏色模式大多都是不對的，因為現在的機器很多都是8888模式，而recovery下的模式是預設565的，所以最終導致的現象就是顏色不對（藍黃對調），按鍵時候會發生螢幕偏移抖動。
引數的改變在recovery/minui/Android.mk中：

ifeq ($(TARGET_RECOVERY_PIXEL_FORMAT),"RGBX_8888")
  LOCAL_CFLAGS += -DRECOVERY_RGBX
endif
ifeq ($(TARGET_RECOVERY_PIXEL_FORMAT),"BGRA_8888")
  LOCAL_CFLAGS += -DRECOVERY_BGRA
endif

TARGET_RECOVERY_PIXEL_FORMAT 是需要寫在device code下的BoardConfig.mk中的，可以分別嘗試TARGET_RECOVERY_PIXEL_FORMAT := "RGBX_8888" 或 "BGRA_8888"重新編譯檢測是否能夠修正，一般情況下都可以輕鬆修正，如果不能，那麼就需要分析graphics.c中的程式碼流程了。實話說，這個檔案，在1.3版本中還是有隱患的，不敢保證所有機器都能夠正常使用。

2）上下按鍵生效，電源鍵不生效
在BoardConfig.mk中讓BOARD_HAS_NO_SELECT_BUTTON := true就可以了。

3）自定義字型大小
在BoardConfig.mk中BOARD_USE_CUSTOM_RECOVERY_FONT := \"xxx\"， 這裡的xxx就是在minui下邊的字型檔案，以font開頭，.h結尾的。

4）支援虛擬按鍵觸控
自ShenduOS Recovery1.2版本之後，添加了支援虛擬按鍵觸控的功能。為了相容問題，在程式碼中做了限制。如果想要使用觸控功能，要進行一定的修改與除錯。

首先，要看recovery/Android.mk中：

ifeq ($(BOARD_TOUCH_VIRTUAL_KEY_RECOVERY),true)
    LOCAL_CFLAGS += -DUSE_VIRTUAL_KEY
ifeq ($(TARGET_SCREEN_WIDTH),720)
    LOCAL_CFLAGS += -DVIRTUAL_KEY_720
endif
ifeq ($(TARGET_SCREEN_WIDTH),1080)
    LOCAL_CFLAGS += -DVIRTUAL_KEY_1080
endif
ifeq ($(TARGET_BOOTLOADER_BOARD_NAME),mako)
    LOCAL_CFLAGS += -DMAKO -DVIRTUAL_KEY_720
endif
endif

大前提是BOARD_TOUCH_VIRTUAL_KEY_RECOVERY，只有這個生效了，觸控才開始。
BOARD_TOUCH_VIRTUAL_KEY_RECOVERY 是決定是否使用虛擬按鍵觸控；
TARGET_SCREEN_WIDTH 是螢幕寬度，720P的就寫TARGET_SCREEN_WIDTH := 720，如果是480的就不用寫，因為480是預設值。
以上兩個都是要寫到BoardConfig.mk中的。

當然也可以向mako（Nexus 4）這樣定義：
當裝置名是mako的時候，定義一個MAKO標誌，而且使用720P的虛擬按鍵。MAKO標誌會在後邊用到。

5）除錯觸控事件
市面上太多機器的觸控介面標準不一，適合華為的介面不一定適合三星，適合三星的又不一定能夠用到HTC上，所以這也是觸控Recovery的難處。我已經在程式碼上把目前能夠想到的除錯不同機器需要修改的介面都留了出來，方便大家除錯修改。
這部分修改主要集中在recovery/ui.c中，先來看一個介面：

#ifdef USE_VIRTUAL_KEY
//#ifdef COMMON_TOUCH_DRIVER
   int touch_type = EV_ABS;
   int touch_code = ABS_MT_TOUCH_MAJOR;     //48
   int touch_pos_x = ABS_MT_POSITION_X;     //53
   int touch_pos_y = ABS_MT_POSITION_Y;     //54
   int lv = 0;  //left value
//#endif

touch_type 為觸控事件的型別值，linux標準為EV_ABS(3)， 所以這裡也作為預設，很多裝置這個都是通用的。EV_KEY EV_REL分別代表按鍵和軌跡輪。
touch_code 為觸控事件發生的標誌值（說法不標準），就是說觸控事件發生的時候，這個值一定會有，通常代表的是觸控面積，>0說明有觸控，<=0說明觸控時間完成。
touch_pos_x 為觸控事件中的x座標
touch_pos_y 為觸控事件中的y座標
lv 不是包包……是left value，也就是觸控時間結束的時候，code = touch_code的時候由驅動上報上來的值是什麼，一般是0，但是比如nexus 4就是-1，所以也留做了介面。

PS：除錯觸控的時候，通常要開啟TOUCH_DEBUG來在介面上直觀的顯示按鍵資訊。

如果你的機器驅動上報標準與這個一樣，那麼很可能你的Recovery一下子就成功了，但是往往事情不是這麼順利的，有兩點是經常遇到的問題：

a.觸控型別等值與標準不一
b.座標不符
下邊的程式碼（ui.c中），很好的解決了這兩個問題：

#ifdef MAKO
    touch_code = 57;
    lv = -1;
    if (ev.type == touch_type) {
        if (ev.code == touch_pos_x)
            ev.value = ev.value * 768 / 1536;
        else if (ev.code == touch_pos_y)
            ev.value = ev.value * 1280 / 2560;
    }
#endif

首先說a問題，mako除錯的時候發現觸控事件的開始與停止通過57而非48才能很好的區分開來，這樣就將touch_type定義為57，來替換標準介面中的48。
而同時，又發現，在除錯過程中，每次手指離開螢幕都回上報code = 57, value = -1， 而不是value = 0，所以又將介面中的lv 定義為了-1， 這樣recovery就能夠正常識別觸控事件的開始與結束。

然後，問題b，一般來說，（0.0）座標在螢幕左上角，但是有極個別廠家記性可能玩非主流在其他的地方，所以除錯的時候通常會先找出0點座標在哪，是否左上角，之後找出最大座標。
也許你的機器解析度是768*1280，但是最大座標是（1536，2560），別奇怪，這有可能，具體怎麼導致的就不深究了，直接分析mako的解決辦法：

對觸控事件中x y座標的上報資訊進行擷取轉換操作，使之匹配成正常的座標。這個公式也非常的簡單易懂，需要注意的是，他們都是整型資料做的除法操作，沒有餘數。

以上就是ShenduOS Recovery1.2版本以上編譯教程，包括了常見的除錯要點，希望大家注意，同時也希望大家能夠積極參與ShenduOS的一切在開發專案！