(一):写在前面
在上面一个小节当中,我们学习了将CM移植到我们自己的设备的上半部分,这里,我们将下半部分学习一下,并尝试讲CM移植到一个平板上去。
(二):承接上文
device_[codename].mk
文件device_[codename].mk
包含关于构建哪一个Android包,去哪里复制指定文件和包或者是在整个编译阶段要设置的指定属性等的指令。
该文件可以在编译阶段被用来讲重要文件复制到ramdisk中。
- PRODUCT_COPY_FILES:用于在编译期间将文件复制到ramdisk中,该文件将被加载到
$OUT/recovery/root
中。
举个列子:
$(LOCAL_PATH)/sbin/offmode_charging:recovery/root/sbin/offmode_charging \
这会将文件offmode_charging二进制复制到位于ramdisk中的sbin
文件夹中。
- PRODUCT_NAME/PRODUCT_DEVICE:用于设置你的codename的值。这是你使用Lunch加载的设备的名称。
kernel
这个就是一个简单的预编译的内核镜像或者是一个你将要编译的内核,用于启动设备。内核的格式可能是zImage或者是uImage,这个依赖于你的设备架构的要求。
cm.mk
在这个文件中你需要去做一些改动来集成lunch
,brunch
,breakfast
命令,以便你的设备能够在列表中展现出来,并且能够正确编译。
你也需要去设置一些变量来表示应该使用多大的闪存,手机设备还是平板设备等等。
有些设置不仅仅用于编译recovery,你也可以现在去设置,因为一旦recovery构建成功并且正常运行,这里的设置是非常重要的。最好的方式就是去查看相似的设备是如何设置的。
recovery.fstab
recovery.fstab
文件定义了文件系统挂载点,文件系统类型,还有你的设备中的每一个分区的快设备。他的工作和linux系统中的/etc/fstab
是一样的。
举个例子:
/system ext4 /dev/block/mmcblk0p32
该命令设置位于mmcblk0p32的快设备以ext4
文件系统的方式挂在到/system
中。
所有的挂载点应该存在于该文件中,信息的正确性是非常重要的。假如一个recovery falsh被写到错误的位置,将会发生难以预料的错误。
vendorsetup.sh
当vendor.sh
运行的时候,vendorsetup.sh
被调用。他被用来讲非标准的lunch
组合添加到lunch
菜单中。
为了向lunch菜单中添加你的设备:
add_lunch_combo cm_<codename>-userdebug
然后构建一个测试的recovery镜像
为了能仅仅构建recovery,设置lunch
唯一一个常规构建,并且使用make recoveryimage
。
有用的技巧
如果你有fastboot,你可以尝试使用他讲recovery镜像安装到recovery分区。也有其他方法来安装recovery,例如使用`dd`命令。
这里不必说很多,但是一定要保证白运行CM之前,一定要确保recovery正常工作。一个100%正常工作的recovery模式是运行android系统之前必须的条件。
如果有必要,调整recovery_ui.cpp
你可能发现了,虽然recovery镜像运行了,有一些物理按键,例如声音按键和电源按键可能不能正常工作。
你可能需要去调整GPIO数值来使得按键被识别。相似的,你可能需要include/exclude选项或者是修改其他UI元素。
为了这样做,你可能需要去创建并且编辑/device/[vendor]/[codename]/recovery/recovery_ui.cpp
。
有用的提示
你的设备的GPIO可能在内核源码中找到。
向vendor/
目录中添加块
一旦我们构建了可以正常运行的recovery,我们就可以去构建CM系统了。
我们需要做的第一件事情就是获取所有的属性,二进制块到vendor/
目录下面,同时也需要.mk
文件来包含他们。
下面是必须的三个步骤:
- 创建
extract-files.sh
和setup-makediles.sh
脚本使用adb
将块文件从你的设备中拉下来,然后将他们放到/vendor/
目录中。 - 创建一个
.mk
文件在编译期间复制这些文件到$OUT
文件夹中,并将他们放到合适的位置。同样,可以参考其他设备的源码。一个例子文件名称可能是BoardConfigVendor.mk
。 - 确保刚刚创建的Makefile在你的主
BoardConfig.mk
中被包含了,也就是使用命令-include vendor/[vendor]/[codename]/BoardConfigVendor.mk
。
现在修改
device/
目录
既然我们有了一个正常工作的recovery,我们来修改位于device/
文件夹中的文件。同样,参考其他相似设备的源码。
从制造商&供应商那里获取帮助
很多生产该平台的生产厂商会提供wiki,文档和例子代码,这些都可以帮助以完成你的移植。你会发现一些公司对开发社区可能非常友好。下面是一些OEMS。
OEM | 平台 | 仓库/资源 |
---|---|---|
各种 | Google’s Git Repository,Nexus binary blobs | |
HTC | 各种 | Dev Center |
HP | 各种 | HP OPEN SOURCE |
Lenovo | 各种 | Lenovo Smartphones (Search your device) |
LG | 各种 | LG Open Source Code Distribution |
Motorola | 各种 | Motorola Open Source Center |
Nvidia | Tegra | Tegra’s GitWeb |
Qualcomm | MSM/QSD | Code Aurora Forum |
Samsung | 各种 | Samsung Open Source Release Center |
Texas Instruments | OMAP | www.omapzoom.com,Omappedia |
有的时候,如果你有问题需要咨询,你可以通过email或者是支持论坛来询问开发者。
添加XML
在你的device_[codename].mk
文件中,很有可能存在像下面这样的代码:
DEVICE_PACKAGE_OVERLAYS := \
device/[vendor]/[codename]/overlay
他所完成的工作就是数字overlay/
文件夹来允许你覆盖仅仅用于该设备的Android框架或者是APP的任何XML文件。为了这样做,我们需要创建一个目录结构,该结构反射指向一个XML文件的路径,从你的源码的根开始。然后把该文件放到你想覆盖的地方。
举个例子:假设你想覆盖一些标准Android设置。在frameworks/base/core/res/res/values/config.xml
文件中查看。然后将他复制到device/[vendor]/[codename]/overlay/frameworks/base/core/res/res/values/config.xml
文件中。现在你的版本将会使用。你仅仅需要要把你想覆盖的设置包含进去就行了–不是所有的,所以你可以削减文件来从默认的设置中修改。
你可以覆盖任何XML文件,包括layouts,settings,preferences,translations等。
从源码中构建内核和内核模块
如果之前你使用的是预构建的内核,你可能想要构建自己的内核。
后面我们有一片文章专门讲解如何修改BoardConfig.mk
文件。
总结
通过两篇文章就能把CM移植到你的设备上是不太可能的,中间可能会出现很多意向不到的问题,我们就可以根据出现的问题和这两篇文章就行修改来正确满足我们的需求。光看文章是不够的,我们抓紧开始一个设备的移植吧。
祝你好运。