关于将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和更高版本中使用。
现在先到这里，后面的教程会在下一篇文章中讲解！！谢谢大家。
