4.3定制Android平台系统
通常产品厂商在拿到Android源码后会在Android源码基础上进行定制修改,以匹配适应自己的产品,从本节开始,我们从最原始的Android源码系统里一步一步定制出自己的Android系统。本节主要内容包含:根据Android源码,添加新产品编译项,定制系统启动界面和文字,定制系统启动动画和声音,定制系统桌面。
4.3.1 添加新产品编译项
Android系统的源代码是一个逻辑结构非常独立工程,在一套Android源码中可以编译出多个产品映像,在需要编译某一个产品系统时,只要通过lunch命令选择产品编译项即可。本节我们介绍如何在Android源码中创建新产品编译项并定制编译出该产品系统。
在创建新产品编译项时,要先了解下面几个概念:
Ø 目标产品:具体指某个最终用户买到的Android设备,如:iPhone5,乐PhoneS2,小米手机等。
Ø 产品系列:开发手机的团队通常由同一团队打造,在研发出一款产品后,往往要继续在其基础上研发出新产品,新产品往往是在老产品的硬件或软件基础上做一些升级,这些产品们就是一个产品系列。比如:联想的乐Phone系列手机包含:乐PhoneS1和乐PhoneS2,他们同属于一个系列。
Ø 目标设备:目标设备可以理解为手机主板,它是指手机设备硬件配置信息的集合体,每个手机产品都有设备硬件配置,一个设备硬件配置可能被不同产品使用,同一手机有高配置版本和低配置版本,如乐PhoneS2有512M RAM、8G Flash容量版本和1G RAM 、16G Flash容量版本。
在Android编译系统中,每个编译项编译出一个产品系统,每个目标产品都对应一个目标设备,一个产品系列包含多个不同的产品,一个目标设备可能被多个产品配置使用。
由前面描述可知,同一系列的新老产品之间可以存在“继承关系”,新产品是老产品的“子产品”,老产品是新产品的“父产品”,子产品可以复用父产品的特性,还可以重写、扩展父产品。如:老产品不支持NFC近距离通信技术,新产品支持NFC技术。同样,设备主板间也存在“继承关系”。
如图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/mycompany
2. 在厂商目录下创建设备目录
定义设备名为myphone。
$ mkdir device/mycompany/myphone
3. 添加新产品编译项配置文件,该配置文件在执行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.mk
AndroidProducts.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.mk
include build/target/product/full.mk
# Discard inherited values and use our owninstead.
PRODUCT_NAME := myproduct
PRODUCT_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.mk
PRODUCT_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.mk
PRODUCT_PACKAGES := \
OpenWnn \
PinyinIME \
VoiceDialer\
libWnnEngDic \
libWnnJpnDic \
libwnndict
# Additional settings used in all AOSP builds
PRODUCT_PROPERTY_OVERRIDES := \
keyguard.no_require_sim=true \
ro.com.android.dateformat=MM-dd-yyyy \
ro.com.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)
# Overrides
PRODUCT_NAME := full
PRODUCT_BRAND := generic
PRODUCT_DEVICE := generic
PRODUCT_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.mk
include build/target/board/generic/AndroidBoard.mk
“继承”的父AndroidBoard.mk,其内容:
@build/target/board/generic/AndroidBoard.mk
LOCAL_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.mk
includebuild/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 # 当前设备是否没有Bootloader
TARGET_NO_KERNEL := true # 当前设备是否没有Linux内核
TARGET_CPU_ABI := armeabi # 当前设备支持的目标架构
HAVE_HTC_AUDIO_DRIVER := true # 是否使用HTC的音频驱动
BOARD_USES_GENERIC_AUDIO := true # 是否使用通用音频技术
# no hardware camera
USE_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=REL
PLATFORM_VERSION=2.3.6
TARGET_PRODUCT=myproduct
TARGET_BUILD_VARIANT=eng
TARGET_SIMULATOR=false
TARGET_BUILD_TYPE=release
TARGET_BUILD_APPS=
TARGET_ARCH=arm
HOST_ARCH=x86
HOST_OS=linux
HOST_BUILD_TYPE=release
BUILD_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文件。
4.3.2 定制产品的意义及定制要点
Android系统是一个完全开源的系统,我们可以通过修改Linux内核代码和Android源码,定制具有独特创意的产品系统,对于产品同质化非常严重的移动市场, Android系统的细节个性化定制也可以让用户眼前一亮。另外,一些产品明确要求要修改或增加一些个性化,如:默认的Android系统开机界面是一个黄嘴的小企鹅,在Android系统启动过程中是一个ANDROID字样的动画效果,厂商一般都要求自己产品开机界面是厂商Logo,开机动画是一个能动态、鲜明表现公司活力的动画效果,我们从本节开始介绍定制产品系统的实现技术。
在整个开机过程中,屏幕上会出现三次内容,如图x-x 所示:
Ø Linux启动时画面,通常是个黄嘴的小企鹅
Ø Android系统init进程启动阶段画面,是“ANDROID”文字字样
Ø Android系统启动阶段动画,是滚动的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所示。
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.png
3. 重新编译Android的系统资源包framework-res.apk
$ source build/envsetup.sh
$ lunch generic-eng
$ mmm frameworks/base/core/res/
4. 生成新的system.img
$ make snod
5. 启动Android模拟器,实验效果如图x-x所示。
$ ./run_emulator.sh
【逐帧动画替换实验步骤】
1. 在/data/local/或/system/media/目录创建bootanimation.zip文件
如果放在/data/local目录下,不需要编译Android源码,直接通过adb命令或文件管理软件拷贝到目录下即可,如果集成进Android系统中,则需要放在/system/media/目录下,这时要重新编译生成system.img映像。
bootanimation.zip文件是直接由几个文件打包生成的,打包的格式是ZIP,打包时的压缩方式选择为存储。
bootanimation.zip文件打包前的结构为:
表x-x bootanimation.zip压缩包文件结构
文件 | 说明 |
desc.txt | 动画属性描述文件 |
part0/ | 第一阶段动画图片的目录 |
part1/ | 第二阶段动画图片的目录 |
其中part0和part1中的动画图片类似于电影胶片,两张图片之间变化较小,他们以固定的速度显示,从而产生动画效果,图片的大小和图片显示的时间控制由desc.txt文件说明。
desc.txt文件内容为:
480 250 15
p 1 0 part0
p 0 10 part1
desc.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 snod
3. 启动Android模拟器,查看动画效果,如图x-x和x-x所示。
$ ./run_emulator.sh
结论:通过实验看出,当我们使用逐帧动画时,蒙板动画就不播放了,这是因为Android系统只能使用一种启动动画方式,先判断是否使用了逐帧动画,如果没有使用逐帧动画时,才使用默认的蒙板动画。
版权声明:本文为博主原创文章,未经博主允许不得转载。