如何講CMAndroid移植到你的裝置？

關於將cm android移植到你的裝置上的一些技巧

你可能會遇到CM並不支援的手機裝置或者是平板裝置。

原來的時候我們可能會編譯那些cm支援的裝置原始碼，並將其燒錄到裝置中來測試執行，那個過程是相當輕鬆的，但是如果要移植到CM並不支援的裝置上去的話，可能需要費點力氣。

在這邊文章中，我們假設你所在的目錄是android的原始碼根目錄。

先決條件

移植cm到一個新的裝置上去可以是非常簡單的，也可能是非常困難的，這依賴於裝置本身，裝置當前是否執行一個最近版本的Android系統，還有一個原因就是你的開發技巧。

此外，你應該熟悉CM的原始碼。在整個移植過程中，你需要做的所有的工作都是在目錄/device/[vendor]/[codename],/vendor/[vendor]/[codename],和/kernel/[vendor]/[codename]中。

收集你的裝置的資訊

在你開始移植之前，你需要儘可能多的去收集你裝置的資訊。我們需要的資訊是裝置名稱，程式碼名稱，架構，記憶體大小，內部儲存大小和平臺架構。將這些資訊放在一個便於檢索的檔案中。嘗試更多的去了解你的裝置，包括它與其他裝置的相似性。

有用技巧

多裝置在架構上可能與一些其他裝置相似，這些其他裝置可能已經有cm支援了。當新的裝置出現的時候，檢視你是否能夠找到相似的其他裝置，僅僅在螢幕大小或者是記憶體或者是其他微小地方上的不同。如果你發現了你的裝置的一個”ancestor”或者是”sibling”，大部分工作已經為你做好了。

大多數你需要的資訊可以在網路上獲取得到，但是假如裝置已經執行了一個非cm的Android系統，你可以從裝置本身獲取一些資訊。為了檢視包含這些資訊的檔案，裝置可能需要獲取root許可權。然而，有的時候你可能線上獲取到一個韌體升級包，然後可以從.zip檔案包中檢視這些檔案。

檢視裝置的當前/system/build.prop

假設裝置已經執行了一個版本的Android系統，他的檔案系統中應該存在一個檔案，/system/build.prop，該檔案可以提供一些有用的資訊。該檔案包含用於Android設定和變數引數的定義。

所以，如果在你的計算機中已經安裝了adb，你可以使用下面的命令拉到你的計算機中：

adb pull /system/build.prop

如果收到了關於許可權的錯誤，裝置可能需要去獲取root許可權去訪問該檔案。然而，有其他方式去定位這個檔案。例如，他也會包含在韌體更新包中。

一旦你有了這個檔案：

• 寫下ro.product.manufacturer引數的值。這個就是你的vendor的名稱。[vendor]是裝置的製造商/提供商的名稱。CM已經為大多數主要的供應商簡歷了名稱，例如samsung,htc,lge等等。注意在這些目錄名稱中，vendor一直是小寫的，並且不包含空格。

• 寫下引數ro.product.device的值。該值就是你的裝置的codename。[codename]對應著裝置本身的專案程式碼名稱。如果你之前構建過CM，你應該熟悉每一個裝置的程式碼名稱的概念。就像是vendor名稱，codename一直都是小寫的，並且不包含空格。

  注意：
  有的時候，裝置會定義其他引數，例如ro.product.board

保留著build.prop檔案，因為後面我們會用到他。

檢查boot.img和recovery.img

如上所述，當進行移植的時候，你可能希望使用一個現存可用的預構建的核心而不是從原始碼重新編譯。依賴於您的裝置，你可能需要從裝置中提取該核心檔案。核心可能以一個單一檔案存在或者是在boot或者是recovery分割槽中被打包起來。

相似的，ramdisk的內容可能是非常有用的，並且能夠被提取出來。他可能為正確啟動，載入模組等提供特定的檔案。在大多數情況下，你可以從裝置的ramdisk中去檢視這些檔案。

注意：

ramdisk是一個檔案和目錄的小組，它通過核心載入到記憶體當中。核心接著執行位於ramdisk中稱為init的一個檔案，然後執行一個指令碼檔案(init.rc，init.[codename].rc等)，該指令碼檔案載入Android的其他部分。我們可以使用稱為mkbootimg，mkimage或其他方法以不同方式講ramdisk和核心打包在一起。

我們可以使用dd從一個獲取root許可權的android裝置中提取出boot和recovery映象檔案（我們稱為boot.img和recovery.img），或者是如果你可以從供應商中訪問一個更新包.zip檔案的話，你在裡面也可以找到這些檔案。

收集任何現有的原始碼

使用Android的裝置的製造商或者是供應商都會盡可能的遵守GPL協議，將原始碼包括核心公開的，所以，我們需要這樣一份程式碼。

決定分割槽表

你的移動裝置的基本上長期儲存部分 – 通常是一個”emmc”(嵌入式多媒體卡) – 看上去更像是計算機的硬碟，他能以不同的方式去定義和隔離不同資料的區域。這些獨一無二的區域被稱為分割槽，他們有很多不同型別的資料儲存在這裡面。一些分割槽包含原聲資料 – 韌體，核心，ramdisk等等。大多數情況下，一個分割槽被格式化去使用一個特定的檔案系統，該檔案系統會被核心重新識別，這樣檔案和目錄就能夠被讀取和寫入了。

在你可以使用CM替換原來的作業系統的時候，確定裝置的分割槽表是非常重要的。你構建的recovery映象需要這個資訊去了解到哪裡去查詢各種各樣的Android目錄。特別的，你需要知道哪一個分割槽被分配到/system,/data,/cache和/sdcard。你需要知道哪一個分割槽存在，在什麼裝置上，他們是怎樣被掛在的，還有就是分割槽的大小。這些資訊後續都需要傳送到位於你的/vendor目錄中的BoardConfig.mk檔案中。

如果你幸運的話，recovery.fstab檔案坐落在recovery.img映象中，這樣就能夠加快我們弄清楚什麼去哪裡的速度。當然，位於ramdisk中的inint.[codename].rc檔案也會有一些有用資訊。我們通過下面的命令來檢視分割槽被掛載到哪裡了：

cat /proc/partitions

從一個執行的裝置中可以幫助我們定義分割槽。也可以檢視/proc/emmc,/proc/mounts,/proc/mtd。你也可以從命令mount中獲取一些資訊。（以root身份執行)。

也要檢查/cache/recovery.log或者是/tmp/recovery.log檔案。

最後，如果你有bootloader的原始碼，你也可以獲取一些資訊。

注意：
要知道會有一些特殊例子，例如HP Touchpad，他就使用了一個抽象的虛擬檔案系統。

設定三個新的目錄

現在，我們已經收集了關於我們的裝置的一些資訊，是時候為你的裝置配置生成一些資料夾了。

• device/[vendor]/[codename]/–這個是存放你的裝置特有的安裝檔案的地方。device/目錄包含配置設定的99-100%和用於特別裝置的其他程式碼。你將會發現這個目錄是非常好的。正如上面提到的，當為這個裝置開始了一個資料夾，模仿和他相似的裝置的目錄是一個好主意。
• vendor/[vendor]/[codename]/–vendor/目錄包含了屬性，從原始裝置備份來的二進位制塊（或者是有供應商提供的）。
• kernel/[vendor]/[codename]/–核心原始碼的位置。當你初次開始移植嘗試的時候，你可能希望簡單是使用預編譯的核心而不是通過原始碼重新編譯。方法就是從其他系統中提取出核心，然後帶著新的ramdisk重新打包它，把他打包成你的裝置可以使用的格式。該方法在裝置和裝置之間是不同的，所以檢視相似的裝置是非常有用的。從原始碼中構建核心不是對每一個裝置都很嚴格，但是本著開源精神，對CM來說這個是更好的方式。

有至少三種方法來生成這些目錄：

方法一：使用mkvendor.sh來生成基本檔案

使用位於build/tools/device/中的mkvendor.sh來自動生成目錄。

注意：

mkvendor指令碼僅僅在裝置使用一個標準的boot.img，使用標準的Android協議和標頭檔案的時候才能正常運轉，在其他方式下是不能正常工作的。

該指令碼接受三個引數：vendor,codename,還有一個boot.img檔案。

舉例：

./build/tools/device/mkvendor.sh samsung i9300 ~/Desktop/i9300boot.img

在上面的例子中,samsung代表vendor，i9300代表codename，最後一個引數是boot.img所在的路徑。

其中的boot.img是使用dd命令從boot分割槽下載的或者是從更新包中獲取的。

上面的命令應該會在你的CM原始碼目錄下建立一個/device/samsung/i9300資料夾。在資料夾裡面，會有檔案AndroidBoard.mk，AndroidProducts.mk，BoardConfig.mk，cm.mk，device_[codename].mk，kernel，recovery.fstab等等。

這個命令並不會建立kernel/目錄。當我們準備好構建核心的時候，我們需要手動建立該資料夾。

注意：

如果返回資訊”unpackbootimg not found.Is your android build environment set up and have the host tools been built?”，請執行下面的命令：

`make -j4 otatools`

方法2：fork一個相似裝置的git倉庫

方法3：手動建立目錄和檔案

你可以手動的建立相應的目錄和檔案。這個不太推薦，因為這或許是一個無聊的方法，但是很有指導意義。你可以檢視其他裝置作為參考你需要什麼檔案。

定製檔案

在device/資料夾中有很多檔案。我們將會通過關注四個檔案BoardConfig.mk,device_[codename].mk,cm.mk,recovery.fstab和kernel開始。

我們來檢查每一個檔案：

BoardConfig.mk

這個檔案包含關於你裝置母板，CPU和其他硬體架構的重要資訊。正確的獲取這個檔案是非常重要的。為了得到一個基本的recovery booting，在這個檔案中需要設定一些引數。

為了編譯一個正常運轉的recovery映象，下面的引數必須要在BoardConfig中設定：

• TARGET_ARCH：這個是裝置的架構，他通常是arm或者是omap3.
• BOARD_KERNEL_CMDLINE：不是所有的裝置傳遞boot引數，然而如果你的裝置這樣做的話，為了成功啟動，這個選項一定要正確填寫。你可以在ramdisk.img中找到這個資訊。
• BOARD_KERNEL_PAGESIZE：boot.img的頁面大小，為了能夠啟動，一定要正確設定。該引數典型的數值是2048和4096。該資訊可以從核心中提取出來。
• BOARD_BOOTIMAGE_PARTITION_SIZE：分配給核心映象分割槽的位元組數
• BOARD_RECOVERYIMAGE_PARTITION_SIZE：分配給recovery映象分割槽的位元組數
• BOARD_SYSTEMIMAGE_PARTITION_SIZE：分配給Android系統檔案系統分割槽的位元組數

• BOARD_USERDATAIMAGE_PARTITION_SIZE：分配給Android資料檔案系統分割槽的大小

  注意：
  上面的資訊都可以從/proc/partitions或者是/proc/mtd獲取的到，典型的就是1024。

• BOARD_HAS_NO_SELECT_BUTTON：（可選），如果你的裝置需要使用他的Power按鈕來確認選擇就使用該選項。

• BOARD_FORCE_RAMDISK_ADDRESS/BOARD_MKBOOTIMG_ARGS：（可選），使用這些來為ramdisk強制一個專用地址。這些值可以從核心中獲取到，前一個引數在Android 4.2.x失效了，後一個引數現在在Android 4.2.x和更高版本中使用。

現在先到這裡，後面的教程會在下一篇文章中講解！！謝謝大家。