404 Not Found
The requested URL /bp_2659j77jwd6c4rp7poq0_1.html was not found on this server.深入浅出 - Android系统移植与平台开发（十一）- Android系统的定制
深入浅出 - Android系统移植与平台开发（十一）- Android系统的定制
专注Android系统移动平台，从事3D打印互联网产品技术研究，著有《深入浅出嵌入式底层软件开发》北航出版社
15461人阅读
Android移植（59）
版权声明：本文为博主原创文章，未经博主允许不得转载。
定制Android平台系统通常产品厂商在拿到Android源码后会在Android源码基础上进行定制修改，以匹配适应自己的产品，从本节开始，我们从最原始的Android源码系统里一步一步定制出自己的Android系统。本节主要内容包含：根据Android源码，添加新产品编译项，定制系统启动界面和文字，定制系统启动动画和声音，定制系统桌面。添加新产品编译项Android系统的源代码是一个逻辑结构非常独立工程，在一套Android源码中可以编译出多个产品映像，在需要编译某一个产品系统时，只要通过lunch命令选择产品编译项即可。本节我们介绍如何在Android源码中创建新产品编译项并定制编译出该产品系统。在创建新产品编译项时，要先了解下面几个概念：?&目标产品：具体指某个最终用户买到的Android设备，如：iPhone5，乐PhoneS2，小米手机等。?&产品系列：开发手机的团队通常由同一团队打造，在研发出一款产品后，往往要继续在其基础上研发出新产品，新产品往往是在老产品的硬件或软件基础上做一些升级，这些产品们就是一个产品系列。比如：联想的乐Phone系列手机包含：乐PhoneS1和乐PhoneS2，他们同属于一个系列。?&目标设备：目标设备可以理解为手机主板，它是指手机设备硬件配置信息的集合体，每个手机产品都有设备硬件配置，一个设备硬件配置可能被不同产品使用，同一手机有高配置版本和低配置版本，如乐PhoneS2有512M RAM、8G Flash容量版本和1G RAM 、16G Flash容量版本。在Android编译系统中，每个编译项编译出一个产品系统，每个目标产品都对应一个目标设备，一个产品系列包含多个不同的产品，一个目标设备可能被多个产品配置使用。由前面描述可知，同一系列的新老产品之间可以存在“继承关系”，新产品是老产品的“子产品”，老产品是新产品的“父产品”，子产品可以复用父产品的特性，还可以重写、扩展父产品。如：老产品不支持NFC近距离通信技术，新产品支持NFC技术。同样，设备主板间也存在“继承关系”。&图x-x 产品、设备与编译项关系图&如图x-x所示，某一产品系列包含3个产品，2个目标设备，其中产品2继承了产品1，产品2 使用了设备2，它是基于产品1所使用的设备1的升级。产品3使用了和产品2一样的设备2，他们硬件配置一样，但是却不是同一产品，3个不同产品都对应一个产品编译项。在Android编译系统中，产品编译项相关配置文件都在device/&厂商名&/目录下。厂商的产品列表由AndroidProducts.mk文件定义，目标产品信息由&产品名&.mk定义，目标设备信息由BoardConfig.mk和AndroidBoard.mk定义。创建新产品的编译项就是创建上述几个mk文件的过程。1.&&&&&&创建厂商目录不同的手机厂商对应device/下不同目录，在厂商目录下放置该厂商的产品相关信息，我们厂商名定义为mycompany。$ cd ~/android/android_source$ mkdir device/mycompany2.&&&&&&在厂商目录下创建设备目录定义设备名为myphone。$ mkdir device/mycompany/myphone3.&&&&&&添加新产品编译项配置文件，该配置文件在执行source build/envsetup.sh时，被加载执行$ vim device/mycompany/myphone/vendorsetup.sh在vendorsetup.sh文件时添加下面一条命令，用于向编译系统添加编译项，新添加的产品名为：myproduct，编译类型为eng。add_lunch_combo myproduct-eng注：add_lunch_combo命令是build/envsetup.sh脚本中定义的函数，表示将一个新产品编译项添加到lunch菜单里。4.&&&&&&创建产品列表配置文件AndroidProducts.mkAndroidProducts.mk文件用于定义当前厂商所拥有的所有产品列表，每个产品都对应一个配置文件：$ vimdevice/mycompany/myphone/AndroidProducts.mk在产品列表配置文件中添加如下内容：PRODUCT_MAKEFILES := \&&&$(LOCAL_DIR)/full_product.mk注：PRODUCT_MAKEFILES变量用于保存所有产品配置信息列表，$(LOCAL_DIR)表示当前目录，full_product.mk表示某一款产品的配置文件。5.&&&&&&配置full_product.mk文件，定义产品的配置信息，添加如下内容：include build/target/product/languages_full.mkinclude build/target/product/full.mk&# Discard inherited values and use our owninstead.PRODUCT_NAME := myproductPRODUCT_DEVICE := myphone产品配置也可以和Java中的类一样被继承，通过inclulde命令可以将指定的文件包含进来，然后在后面可以对里面的内容进行重写。一般而言不同的产品产品名和设备名都不一样，在full_product.mk中对继承的full.mk中的产品名和设备名进行重写：PRODUCT_NAME为myproduct，PRODUCT_DEVICE为myphone。在full_product.mk文件中继承的languages_full.mk内容如下：@build/target/product/languages_full.mkPRODUCT_LOCALES := en_US fr_FR it_IT es_ES de_DEnl_NL cs_CZ pl_PL ja_JP zh_TW zh_CN ru_RU ko_KR nb_NO es_US da_DK el_GR tr_TRpt_PT pt_BR rm_CH sv_SE bg_BG ca_ES en_GB fi_FI hr_HR hu_HU in_ID iw_IL lt_LTlv_LV ro_RO sk_SK sl_SI sr_RS uk_UA vi_VN tl_PH该配置文件里表示的是当前产品系统里默认支持的本地语言，由上述配置信息可知，它基本包含了Android所支持的所有语言包。@build/target/product/full.mkPRODUCT_PACKAGES := \&&&OpenWnn \&&&PinyinIME \&&& VoiceDialer\&&&libWnnEngDic \&&&libWnnJpnDic \&&&libwnndict&# Additional settings used in all AOSP buildsPRODUCT_PROPERTY_OVERRIDES := \&&&keyguard.no_require_sim=true \&&&.android.dateformat=MM-dd-yyyy \&&&.android.dataroaming=true \&&&ro.ril.hsxpa=1 \&&&ro.ril.gprsclass=10&PRODUCT_COPY_FILES := \&&&development/data/etc/apns-conf.xml:system/etc/apns-conf.xml \&&&development/data/etc/vold.conf:system/etc/vold.conf&# Pick up some sounds - stick with the shortlist to save space# on smaller devices.$(call inherit-product,frameworks/base/data/sounds/OriginalAudio.mk)&# Get the TTS language packs$(call inherit-product-if-exists,external/svox/pico/lang/all_pico_languages.mk)&# Get a list of languages. We use the small listto save space# on smaller devices.$(call inherit-product,build/target/product/languages_small.mk)&$(call inherit-product,build/target/product/generic.mk)&# OverridesPRODUCT_NAME := fullPRODUCT_BRAND := genericPRODUCT_DEVICE := genericPRODUCT_MODEL := Full Android继承的full.mk文件内容比较多，我们将主要的一些变量列出如表x-x所示。
PRODUCT_PACKAGES
系统预置的模块列表，不仅仅只是Android应用程序，还可以包含库，可执行程序等
直接将系统中要安装的模块名以空格隔开列出
PRODUCT_PROPERTY_OVERRIDES
系统设置的属性值
将所有预设的属性以空格隔开列出，属性格式为：key-value
PRODUCT_COPY_FILES
要拷贝的文件
将文件列表拷贝到文件系统中，文件格式为：源文件：目标文件
PRODUCT_NAME
该产品名要和编译项中产品名一致
PRODUCT_BRAND
PRODUCT_DEVICE
产品对应的设备名
该名字要和产品设备主板配置文件（BoardConfig.mk）所在目录名一致
PRODUCT_MODEL
& 总结：我们自己定义的full_product产品继承了build/target/product/目录下的full.mk和languages_full.mk，full.mk文件是Android系统定义的一个“通用产品”，languages_full.mk文件是全部语言包配置文件，这样，自己的产品full_product就具有了通用产品的特点并且支持全部语言包。6.&&&&&&定义目标产品对应的设备配置文件AndroidBoard.mk和BoardConfig.mk同样的道理，我们可以继承使用通用设备配置文件：build/target/board/generic/目录下的AndroidBoard.mk和BoardConfig.mk文件。?&创建AndroidBoard.mk和BoardConfig.mk文件$ touch AndroidBoard.mk BoardConfig.mk?&添加AndoridBoard.mk的内容如下：@ device/mycompany/myphone/AndroidBoard.mkinclude build/target/board/generic/AndroidBoard.mk“继承”的父AndroidBoard.mk，其内容：@build/target/board/generic/AndroidBoard.mkLOCAL_PATH := $(call my-dir)&file := $(TARGET_OUT_KEYLAYOUT)/tuttle2.kl&&&&&&&&&& # Linux内核按键码布局文件ALL_PREBUILT += $(file)$(file) : $(LOCAL_PATH)/tuttle2.kl | $(ACP)&&&&&&&& $(transform-prebuilt-to-target)&include $(CLEAR_VARS)LOCAL_SRC_FILES := tuttle2.kcm&&&&&&&&&&& #&Android按键码映射文件include $(BUILD_KEY_CHAR_MAP)其实build/target/board/generic/AndroidBoard.mk文件里只是拷贝了按键映射文件和默认系统属性文件，我们可以将其内容直接拷贝到device/mycompany/myphone/AndroidBoard.mk中。?&添加BoardConfig.mk的内容如下：@ device/mycompany/myphone/BoardConfig.mkincludebuild/target/board/generic/BoardConfig.mk“继承”的父BoardConfig.mk内容：@build/target/board/generic/BoardConfig.mk# config.mk## Product-specific compile-time definitions.#&# The generic product target doesn't have anyhardware-specific pieces.TARGET_NO_BOOTLOADER := true&&&&&&&&&&&&&&&&& # 当前设备是否没有BootloaderTARGET_NO_KERNEL := true&&&&&&&&&&&&&&&&&&&&&&&&&&& # 当前设备是否没有Linux内核TARGET_CPU_ABI := armeabi&&&&&&&&&&&&&&&&&&&&&&&&&& # 当前设备支持的目标架构HAVE_HTC_AUDIO_DRIVER := true&&&&&&&&&&&&&&&&&& # 是否使用HTC的音频驱动BOARD_USES_GENERIC_AUDIO := true&&&&&&&&& # 是否使用通用音频技术&# no hardware cameraUSE_CAMERA_STUB := true&&&&&&&&&&&&&&&&&&& # 是否使用摄像头Stub通过BoardConfig.mk的信息可知，其实该文件就是定义了一些设备硬件相关的一些变量，这些变量用来裁剪系统的功能，决定Android系统可运行的体系构架。7.&&&&&&根据需要定义产品默认属性和键值信息Android系统的属性服务类似于Windows的注册表，记录着系统的一些设置信息，我们可以在新产品中预定义一些属性值来设置自己产品。在Android编译系统中，属性都保存在xxx.prop文件中，在build/target/board/generic/system.prop中定义了默认的属性，我们可以在它基础上进行修改。复制属性文件：$ cp build/target/board/generic/system.prop& device/mycompany/myphone/在Android系统中，底层使用Linux内核来接收来自按键硬件上报的键值信息，上层处理用户按键的是Android的框架，二者之间通过两个键值布局文件来进行键值的映射。?&Keylayout文件：按键布局文件，以kl后缀命名，该文件用来定义按键驱动里上报的键值号（数字）和Linux内核中通过event事件上报的键值（字符）之间的映射关系。kl文件要放在/system/usr/keylayout/目录下或/data/usr/keylayout/目录下。?&KeyCharMap文件：键值字符映射文件，以kcm后缀命名，它用来将Linux内核上报来的键值（字符）进行转换，转换成Android系统里可以识别的键盘码或组合按键。kcm文件要放在/system/usr/keychars/目录下或/data/usr/keychars/目录下。上述两个按键映射文件使用按键驱动名作为其文件名，如果没有驱动名对应的布局文件，则使用/system/usr/keylayout/qwerty.kl和/system/usr/keychars/qwerty.kcm作为默认的按键映射文件。这两个文件名都通过AndroidBoard.mk文件负责拷贝和安装。如果我们要使用模拟器作为目标设备，只需要将源码build/target/board/generic/目录里的tuttole2.kl和tuttle2.kcm拷贝到AndroidBoard.mk所在的目录中即可。$ cp build/target/board/generic/tuttle2.kl& device/mycompany/myphone/tuttle2.kl$ cp build/target/board/generic/tuttle2.kcm& device/mycompany/myphone/tuttle2.kcm& 如果想要自定义系统的物理按键与Android系统的按键映射关系，则需要在tuttle2.kl和tuttle2.kcm的基础上进行修改，然后再修改AndroidBoard.mk的内容：$ cp build/target/board/generic/tuttle2.kl& device/mycompany/myphone/&按键驱动名&.kl$ cp build/target/board/generic/tuttle2.kcm& device/mycompany/myphone/&按键驱动名&.kcm& 修改device/mycompany/myphone/AndroidBoard.mk文件：LOCAL_PATH := $(call my-dir)&file := $(TARGET_OUT_KEYLAYOUT)/&按键驱动名&.kl&&&&&&&&&& # Linux内核按键码布局文件ALL_PREBUILT += $(file)$(file) : $(LOCAL_PATH)/&按键驱动名&.kl | $(ACP)&&&&&&&& $(transform-prebuilt-to-target)&include $(CLEAR_VARS)LOCAL_SRC_FILES := &按键驱动名&.kcm&&&&&&&&&&&&&&&&& #& Android按键码映射文件include $(BUILD_KEY_CHAR_MAP)注：kcm文件最终被编译系统的key_char_map.mk编译成xxx.kcm.bin的二进制形式，这是因为每个Android应用程序都要加载该按键映射文件，为了加快读取速度刻意而为之的。创建新产品编译项时创建的目录与文件结构如下：device/mycompany/&&&&&&&&&&&&&&&&&&&&&&&&& # 厂商目录└── vendorsetup.sh&&&&&&&&&& # 添加编译项命令文件└── myphone/&&&&&&&&&&&&&&&&&&& # 设备名目录├── AndroidBoard.mk&&&&&&&&&&&&&&&&& # 设备属性和键值映射配置文件├── AndroidProducts.mk&&&&&&&&&&&& # 产品列表文件├── BoardConfig.mk&&&&&&&&& # 设备硬件配置及目标架构配置文件├── full_product.mk&&&&&&&&&&& # 目标产品配置文件├── system.prop&&&&&&&&&&&&&&&&&&&&&&&&& # 系统默认属性配置文件├── tuttle2.kcm&&&&&&&&&&&&&&&&&&&&&&&&&&& # Android系统键值映射文件├── tuttle2.kl&&&&&&&&&&&&&&&&&&&&& # Linux内核按键布局文件确认上述目录和文件创建没有问题了，执行Android编译步骤：sourcebuild/envsetup.sh，lunch选择myproduct-eng编译项。如果看到如下信息，说明我们已经添加新产品成功。============================================PLATFORM_VERSION_CODENAME=RELPLATFORM_VERSION=2.3.6TARGET_PRODUCT=myproductTARGET_BUILD_VARIANT=engTARGET_SIMULATOR=falseTARGET_BUILD_TYPE=releaseTARGET_BUILD_APPS=TARGET_ARCH=armHOST_ARCH=x86HOST_OS=linuxHOST_BUILD_TYPE=releaseBUILD_ID=GRK39F============================================8.&&&&&&常见问题?&问题1： lunch菜单里没有出现myproduct编译项原因及解决方法：在执行lunch之前，要执行source build/envsetup.sh命令，确认vendorsetup.sh文件存在及其内容正确无误。?&问题2：选择完lunch菜单里的编译项后，出错：*** No matches for product"myproduct".& Stop.** Don't have a product spec for:'myproduct'** Do you have the right repo manifest?原因及解决方法：编译系统找不到用户选择的编译项里的myproduct产品，确认AndroidProducts.mk文件里列出了myproduct产品的配置文件full_product.mk，并且full_product.mk文件中PRODUCT_NAME变量的值为产品名：myproduct?&问题3：选择完lunch菜单里的编译项后，出错：*** No config file found for TARGET_DEVICEmyphone.& Stop.** Don't have a product spec for:'myproduct'** Do you have the right repo manifest?原因及解决方法：编译系统找不到myproduct产品对应的设备myphone，确认myproduct产品的配置文件full_product.mk中PRODUCT_DEVICE变量的值为产品名：myphone，并且在device/mycompany/目录下创建了myphone的设备目录，在该目录下存在BoardConfig.mk文件。定制产品的意义及定制要点Android系统是一个完全开源的系统，我们可以通过修改Linux内核代码和Android源码，定制具有独特创意的产品系统，对于产品同质化非常严重的移动市场， Android系统的细节个性化定制也可以让用户眼前一亮。另外，一些产品明确要求要修改或增加一些个性化，如：默认的Android系统开机界面是一个黄嘴的小企鹅，在Android系统启动过程中是一个ANDROID字样的动画效果，厂商一般都要求自己产品开机界面是厂商Logo，开机动画是一个能动态、鲜明表现公司活力的动画效果，我们从本节开始介绍定制产品系统的实现技术。在整个开机过程中，屏幕上会出现三次内容，如图x-x 所示：?& Linux启动时画面，通常是个黄嘴的小企鹅?& Android系统init进程启动阶段画面，是“ANDROID”文字字样?& Android系统启动阶段动画，是滚动的ANDROID动画图 x-x 开机界面与Android动画定制系统开机动画【实验背景知识】Android的开机动画是由Linux本地守护程序bootanimation专门控制实现的，其代码在：frameworks/base/cmds/bootanimation/目录下，修改Android开机动画有两种方式：?&蒙板图片替换：替换frameworks/base/core/res/assets/images/目录下的两个图片文件：android-logo-mask.png和android-logo-shine.png。android-logo-mask.png是镂空蒙板图片，android-logo-shine.png是镂空蒙板后面的闪光png图片。两个图片通过叠加移动来达到动画效果。?&逐帧动画替换：在/data/local/或/system/media/目录创建bootanimation.zip文件，该压缩包文件里存放有逐帧动画及控制脚本。【实验组成】本实验分为两部分：蒙板图片替换实验和逐帧动画替换实验。【实验内容】分析Android系统的两种开机动画实现方式，制作并替换开机动画，最终在Android模拟器中运行定制开机动画的系统。【实验目的】通过实验，了解Android系统的两种开机动画实现方式，掌握如何定制产品的开机动画，并在Android模拟器中，运行定制开机动画的Android系统。【实验平台】拥有Android源码编译环境的Ubuntu操作系统（可以在Windows系统中虚拟Ubuntu系统）。【蒙板图片替换实验步骤】1.&&&&&& 使用PhotoShop等图像处理软件制作一张背景为黑色，中间镂空的png格式的图片，命名为：android-logo-mask.png，如图x-x所示。图x-x 制作镂空动画2.&&&&&&将android-logo-mask.png拷贝到frameworks/base/core/res/assets/images/目录下替换Android默认的图片，为了防止源码不编译图片资源，将图片时间戳更新一下。$ cp android-logo-mask.png&&& ~/android/android_source/frameworks/base/core/res/assets/images/$ touch ~/android/android_source/frameworks/base/core/res/assets/images/android-logo-mask.png3.&&&&&&重新编译Android的系统资源包framework-res.apk$ source build/envsetup.sh$ lunch generic-eng$ mmm frameworks/base/core/res/4.&&&&&&生成新的system.img$ make snod5.&&&&&&启动Android模拟器，实验效果如图x-x所示。$ ./run_emulator.sh&图x-x 定制开机动画效果&&【逐帧动画替换实验步骤】1.&&&&&&在/data/local/或/system/media/目录创建bootanimation.zip文件如果放在/data/local目录下，不需要编译Android源码，直接通过adb命令或文件管理软件拷贝到目录下即可，如果集成进Android系统中，则需要放在/system/media/目录下，这时要重新编译生成system.img映像。bootanimation.zip文件是直接由几个文件打包生成的，打包的格式是ZIP，打包时的压缩方式选择为存储。图x-x 压缩文件方式&bootanimation.zip文件打包前的结构为：表x-x bootanimation.zip压缩包文件结构
动画属性描述文件
第一阶段动画图片的目录
第二阶段动画图片的目录 其中part0和part1中的动画图片类似于电影胶片，两张图片之间变化较小，他们以固定的速度显示，从而产生动画效果，图片的大小和图片显示的时间控制由desc.txt文件说明。desc.txt文件内容为：480 250 15p 1 0 part0p 0 10 part1desc.txt文件的格式为：
数据及说明
320（图片宽）
320（图片高）
15（每秒显示帧数）
第一阶段动画属性
P（默写标志符）
1（循环次数为1 ）
0（进入该阶段的间隔时间）
part0（该阶段图片存放目录）
第二阶段动画属性
p（默写标志符）
0（无限循环）
10（进入该阶段的间隔时间）
part1（该阶段图片存放目录） 注：标识符：p&是必须的。循环次数：指该目录中图片循环显示的次数，0表示本阶段无限循环。每秒显示帧数：就是每秒显示的图片数量，决定每张图片显示的时间。阶段切换间隔时间：指的是该阶段结束后间隔多长时间显示下一阶段的图片，其单位是每张图片显示的时间。对应图片目录：就是该阶段动画的系列图片，以图片文件目录的顺序显示动画，而且图片的格式必须要为PNG。由于逐帧动画不太方便制做，我们直接使用光盘中：章节实验/第四章定制系统开机动画/bootanimation.zip文件作为演示。2.&&&&&&如果bootanimation.zip放到/system/media/目录下，则重新编译生成system.img$ source build/envsetup.sh$ lunch generic-eng$ make snod3.&&&&&&启动Android模拟器，查看动画效果，如图x-x和x-x所示。$ ./run_emulator.sh&图x-x 第一阶段开机动画&图x-x 第二阶段开机动画结论：通过实验看出，当我们使用逐帧动画时，蒙板动画就不播放了，这是因为Android系统只能使用一种启动动画方式，先判断是否使用了逐帧动画，如果没有使用逐帧动画时，才使用默认的蒙板动画。
我的同类文章
Android移植（59）
·····
·····
发表评论：
馆藏&20411
TA的最新馆藏深入浅出 - Android系统移植与平台开发（四）－ Android启动流程
一、Android init进程启动
还是从Linux的启动开始吧。Linux被bootloader加载到了内存之后，开始运行，在初始化完Linux运行环境之后，挂载ramdisk.img根文件系统映像，运行里面的init程序，这也是Linux的第一个用户程序，其pid为1。下面的文章是作者关于init进程启动的描述。
二、Android本地服务的启动
&init进程启动完之后，开始初始化并启动Dalvik虚拟机，在Dalvik虚拟机启动之前做了一些工作，请看下面一篇文章。
Android启动总结：
init进程在执行过程中可以分为以下几个阶段：
&O& 启动准备：创建文件系统的基本目录、打开标准输入、标准输出、标准错误，初始化log日志功能等
&O& 解析init.rc和init.hardware.rc文件：将rc文件逐行解析成Action或Service。解析出来的Action和Service分别存放在action_list和service_list链表里，每个Action都对应一个或多个Commands，每个依附于Action的Commands也由一个链表维护。
&O& 将early-initAction添加到action_queue队列里，等待执行
&O& 将init Action添加到action_queue队列里，等待执行
&O& 添加其它条件的Action到action_queue队列里
&O& 进入死循环
o&&& 从action_queue队列里依次取出每个Action，执行其维护的Commands链表里的命令
o&&& 重新启动service_list中标记为SVC_RESTARTING服务
o&&& 监听系统属性状态变化事件、子进程信号、Keychord组合按键事件
注：在代码里没有明显运行service_list里服务的代码，每个服务都有一个class属性，该属性决定了服务的分类，在init.rc文件的on boot Action最后有两个命令：
class_start core
class_start main
class_start命令是指运行某一类的服务，先启动了class为core的服务，然后再启动了class为main的服务。
init.rc中class为core的服务有：
&对应程序及参数
&/sbin/ueventd
&/system/bin/sh
&/sbin/adbd
servicemanager
&/system/bin/servicemanager
&/system/bin/vold
class为main的服务有：
&对应程序及参数
&/system/bin/netd
&/system/bin/debuggerd
ril-daemon
&/system/bin/rild
surfaceflinger
&/system/bin/surfaceflinger
&/system/bin/app_process -Xzygote /system/bin --zygote--start-system-server
&/system/bin/drmserver
&/system/bin/mediaserver
&/system/bin/bootanimation
&/system/bin/dbus-daemon --system --nofork
bluetoothd
&/system/bin/bluetoothd -n
&/system/bin/installd
flash_recovery
&/system/etc/install-recovery.sh
&/system/bin/racoon
&/system/bin/mtpd
&/system/bin/keystore /data/misc/keystore
&/system/bin/dumpstate -s
(window.slotbydup=window.slotbydup || []).push({
id: '2467140',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467141',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467143',
container: s,
size: '1000,90',
display: 'inlay-fix'
(window.slotbydup=window.slotbydup || []).push({
id: '2467148',
container: s,
size: '1000,90',
display: 'inlay-fix'简单游戏 快乐生活
您当前的位置：
>> >> >>论Android移植到现有硬件平台的可行性
论Android移植到现有硬件平台的可行性
来源：Android实验室
发布时间： 10:04:03
　　通过前两天对Android的Linux平台 以及启动过程 的初步学习，我觉得Android的意义不仅仅是手机平台那么简单，通过对其框架，结构的分析，我们可以将Android应用到任何移动硬件平台上，甚至自己研发出新的更好的框架。连Google自己也说，我们的目标是，让我们发布的强大的平台能够应用到数千种不同的移动设备上。这是可以理解的， Google就是这样，它的每个策略都比常理要更进一步。不推出专属的硬件，而是一个通用的移动设备的软件平台，使Android可以更方便的快速占领手机操作系统的市场，而最终可以达到的份额也会非常的可观。
　　当然，这都是后话了，group上这几天的焦点话题就是，我们如何让Android在现有的硬件平台上跑起来，而不是仅仅用模拟器来模拟它？这个命题估计对所有hacker都有巨大的吸引力，如果Android能在自己的手机平台上跑起来，所有的开发，就突然变得有意义了。我不是说目前的开发没有意义，毕竟Google N位数的奖金在那里摆着的，呵呵，不过对于上层开发者来说，最终目的还是应用的实际性和流行性，对吧？应用有没有实际价值，实际硬件平台上跑一跑就知道了。
　　从Android现有的开源情况看，所有的hacking已经有一个比较明确的指导方向了，就是依靠Benno最先放出的方法来hack各种 image并分析一些东西，从我之前的两篇文章也可以看出大致步骤。我们现在能够得到的东西，包括ramdisk image，system image以及data image，当然还有open source的Linux kernel。所以，所有的工作都应该从这几个东西入手。
　　先看看kernel部分。由于Android基于Linux,因此所有的目标移植平台都应该允许运行Linux，对于尝试阶段的我们来说，最好是找一款默认就是采用Linux操作系统并提供完善的develop environment的设备，这样，我们只需要找出Google提供的Linux 2.6.23 kernel和现有的kernel有什么不同，把所有需要的修改做成patch，patch到现有系统上，就有可能成功移植整个Android，无须重新编译Google的Linux 2.6.23 kernel，然后绞尽脑汁想怎么port到某个设备上。先下载一个standard Linux 2.6.23 kernel，然后使用命令
　　diff -ruN linux-2.6.23/ Google-linux-2.6.23/ &lk.patch
　　打开lk.patch，God，有3万多行。仔细分析一下，大部分都是和Qemu以及goldfish有关的。我们要做的事情，是让Android 在真实平台上跑起来，所以不管是用于虚拟处理器的Qemu还是SDK模拟的硬件平台Goldfish，都不是我们所需要的，要在patch里面去掉他们，因为我们希望运行在真实的硬件平台上。恩，说实话，是一个很麻烦的事情，你要分析又30000多行的patch阿……不过里面有一超长段是关于yaffs 的补丁，如果你目标平台所带的内核已经支持yaffs了，就没必要要了。这是我修改后的patch ，放在googlepages上的，要是哪天又被和谐了我也没有办法。
　　下一步，就是让打了Android patch的内核运行在你的目标硬件上，具体步骤是和不用硬件的开发环境相联系的。当然，还需要导入Android的rootfs以及filesystem。将他们用mkfs.jffs2构建成jffs文件系统即可。
　　需要注意的是，这个合适的硬件平台是需要挑选的，看看Android模拟器里面的信息：
# cat /proc/cpuinfoProcessor : ARM926EJ-S rev 5 (v5l)BogoMIPS : 331.77Features : swp half thumb fastmult vfp edsp java
　　Google默认的是ARM926EJ-S核心。这就在一定程度上限制了我们能够port的平台选择，Benno曾经试验在Openmoko上移植Android ，最后失败了，原因就是ARM926EJ-S采用的是ARMv5TEJ指令集，而Openmoko的ARM920T采用的是ARMv4T指令集。所以，不仅仅是需要能运行兼容EABI的Linux的设备那么简单。
　　以上是理论步骤的逻辑分析，由于我目前手上没有试验平台，所以也无法验证，如果有朋友最后成功移植了Android，多多交流。
你有遇到过玩游戏时切换出来查看攻略，不幸导致游戏崩溃的情况吗？下载，边玩游戏边用手机看攻略，轻松愉快，大家都在用。
关注安卓中文网官方微信
扫描左侧二维码即可添加安卓中文网官方微信
您也可以在微信上搜索“安卓中文网”或“anzhuozww”，获取更多数码资讯
24小时热点