展讯文档

展讯OTA升级客户指导-Android 7.0


OTA 升级指导文档

NOTE:

ALL MATERIALS INCLUDED HEREIN ARE COPYRIGHTED AND CONFIDENTIAL
UNLESS OTHERWISE INDICATED. The information is intended only for the person
or entity to which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination, or other use of or taking of any
action in reliance upon this information by persons or entities other than the
intended recipient is prohibited.

This document is subject to change without notice. Please verify that your company
has the most recent specification.

Copyright . 2013 Spreadtrum Communications Inc.

 

目 录

1. 概述 …………………………………………………………………………………………………………….. 4
1.1. Request & Purpose ………………………………………………………………………………. 4
1.2. Definitions & Abbreviations ……………………………………………………………………. 4
2. 简介 …………………………………………………………………………………………………………….. 4
2.1. OTA简介 …………………………………………………………………………………………….. 4
2.2. OTA升级 …………………………………………………………………………………………….. 5
2.2.1. Recovery升级 …………………………………………………………………………….. 6
2.2.2. 几个关键部分 ……………………………………………………………………………… 6
2.2.3. 展讯特有分区以及其升级 ………………………………………………………………. 8
3. Recovery系统 ………………………………………………………………………………………………. 9
3.1. 启动及运行流程 ………………………………………………………………………………….. 10
3.1.1. 启动流程 …………………………………………………………………………………… 10
3.1.2. 运行流程 …………………………………………………………………………………… 10
4. 升级包制作与升级 ………………………………………………………………………………………… 12
4.1. 制作原理 ……………………………………………………………………………………………. 12
4.1.1. Target 文件说明 ………………………………………………………………………… 12
4.1.2. 升级包构成简单说明 …………………………………………………………………… 12
4.2. 制作方法 ……………………………………………………………………………………………. 15
4.2.1. 整体升级包步骤 …………………………………………………………………………. 15
4.2.2. 差分升级包步骤 …………………………………………………………………………. 15
4.3. Modem bins改名方法 …………………………………………………………………………. 16
5. 展讯平台部分细节说明 …………………………………………………………………………………. 17
5.1. nvmerge和splmerge ………………………………………………………………………….. 17
5.2. nvmerge具体说明 ………………………………………………………………………………. 18
5.3. Secure boot支持 ………………………………………………………………………………… 18
5.3.1. Android 6.0以前的OTA包制作 …………………………………………………… 18
5.3.2. Android 7.0的OTA包制作………………………………………………………….. 19
5.4. 关于adb的支持 …………………………………………………………………………………. 19
6. Android 7.0上新加入功能和注意事项 ……………………………………………………………… 19
6.1. 升级中加入Repart起因 ……………………………………………………………………….. 19
6.1.1. System分区自适应功能 ……………………………………………………………… 19
6.1.2. Dm_verify功能使能 ……………………………………………………………………. 20
6.2. OTA升级加入repart …………………………………………………………………………… 20
6.3. Repart带来的影响 ………………………………………………………………………………. 21
6.3.1. 用户数据丢失 ……………………………………………………………………………. 21
6.3.2. 升级须插sd卡 …………………………………………………………………………… 21
6.3.3. 升级时间变长 ……………………………………………………………………………. 21
6.3.4. 掉电无法开机风险变大 ……………………………………………………………….. 22
6.4. 应对措施 ……………………………………………………………………………………………. 22

6.4.1. 去掉system分区自适应功能 ……………………………………………………….. 22
6.4.2. 降低repart的概率 ……………………………………………………………………… 22
7. OTA升级测试说明 ……………………………………………………………………………………….. 23
8. 大版本升级 …………………………………………………………………………………………………. 23
8.1. Android 4.4/5.0&5.1/6.0之间分区变更的大版本升级 ………………………………… 23
8.1.1. 参数使用说明 ……………………………………………………………………………. 24
8.1.2. 升级方法 …………………………………………………………………………………… 24
8.1.3. 升级注意事项 ……………………………………………………………………………. 24
8.2. Android 5.0&5.1/6.0到Android 7.0的大版本升级 ……………………………………. 25
9. Recovery log抓取办法 …………………………………………………………………………………. 25

 

1. 概述

 

1.1. Request & Purpose

本文重点描述以下几个方面

. 什么是OTA升级
. 什么是Recovery升级
. Recovery升级的原理
. Reocvery升级的流程
. 升级包制作步骤
. 展讯特有分区的升级策略
. Recovery log的获取
. Android 7.0 OTA升级新特点及注意事项

 

1.2. Definitions & Abbreviations

OTA

Over-The-Air Technology

BP

Baseband Processor

Repart

重新划分分区的可执行程序

Dm_verify

一种对system分区进行完整性校验的功能

 

2. 简介

 

2.1. OTA简介

OTA(Over-The-Air)一项基于短消息机制,通过手机终端或服务器(网上)方式实现
SIM卡内业务菜单的动态下载、删除与更新,使用户获取个性化信息服务的数据增值业务
(简称OTA业务),是通过移动通信(GSM或CDMA)的空中接口对SIM卡数据及应
用进行远程管理的技术。空中接口可以采用WAP、 GPRS、CDMA1X及短消息技术。
OTA技术的应用,使得移动通信不仅可以提供语音和数据服务,而且还能提供新业务下
载。

较早的系统升级界面。

较新的智能手机的系统升级界面更加人性化,比如检测到新版本提示,显示新版本解决的
问题,是否需要自动下载等交互界面。

2.2. OTA升级

OTA升级是Android系统提供的标准软件升级方式。它功能强大,可以无损失升级
系统,主要通过网络(例如WIFI、3G/4G)自动下载OTA升级包、自动升级,但是也支
持通过下载OTA升级包到SD卡升级。

OTA升级包非常的小,一般几兆到十几兆,如果你用网络升级,非常的方便,基本
是在系统上点击几下就完成了升级,并且重要的是,OTA升级无需备份数据,较短时间
即能完成升级工作,所有数据都会完好无损的保留下来。

广义上来讲,OTA升级是一个复杂的系统。包括编译、版本发布、终端版本检测、
在终端上检测服务器上最新版本、通过终端版本制作对应差分升级包、终端下载服务器上
的升级包、本地升级等一系列过程。

而平时通常所说OTA升级仅涉及到本地升级,即把升级包下载到本地之后,进行升
级的过程。而升级包放置到服务器和手机的“系统升级”app检测到升级包并下载到本地
的过程主要由售后服务部门以及app来完成,不在本文档介绍之列。由于升级这个过程
是通过Recovery系统进行的,因此又称之为Recovery升级。本文接下来对Recovery
升级展开描述。

2.2.1. Recovery升级

Recovery升级会涉及到两部分内容,Recovery系统和升级包。这两个部分是相对独
立的。在升级的过程中,Recovery系统仅提供基本的功能(比如挂载需要用到的分区到
特定目录、输出log到log文件),所有与升级有关的操作均由升级包中的update-binary(升级程序)来完成。

2.2.2. 几个关键部分

在源码中与Recovery升级有关的关键部分有这么几个:init.rc、recovery.fstab、
recovery主程序、updater主程序、制作升级包的脚本。下面简单介绍一下。

1) Init.rc

 

Recovery.img中的init.rc仅包含了最简单的初始化和少数几个服务,包括adb、
recovery等。

2) recovery.fstab

 

用于recovery系统处理各个分区。包括格式化、升级都会用到。

3) recovery主程序

 

在recovery系统启动后init会将其作为服务启动。

4) updater主程序

 

即上文所述的升级程序update

binary

用于真正的升级操作。在制作升级包时,
会将其放到升级包内执行升级脚本,完成升级操作。

5) 制作升级包的脚本

 

主要用于生成升级包中由update

binary
来解释执行的升级脚本
updater

script
,
同时将需要用的文件打包为升级包。

Init.rc

在编译系统中,在芯片通用的板级配置文件中定义TARGET_RECOVERY_INITRC
为芯片目录下recovery/init.rc,如Android 6.0/7.0 9832的定义:

scx35l/common/BoardConfigCommon.mk:TARGET_RECOVERY_INITRC :=
$(PLATCOMM)/recovery/init.rc

编译后,这个文件存放在:
out/target/product/$(TARGET_DEVICE)/recovery/root/init.rc,最终编译到recovery.img

recovery.fstab

正常Android系统的fstab用于系统启动时system、data等分区的挂载以及存储设备
的挂载、卸载、格式化等操作,而Recovery系统中的fstab用于对所有可能需要升级的

分区进行操作。这两种fstab的格式是一致的,但是包含的分区不同,正常Android系统
的fstab仅包含system、data、sdcard等分区,Recovery系统的fstab需要包含所有可
能需要升级的分区。

在编译系统中,用变量TARGET_RECOVERY_FSTAB来定义recovery.img中的
recovery.fstab。以Android 7.0的9861e为例,TARGET_RECOVERY_FSTAB如下定
义:

device/sprdiwhale2/common/BoardConfigCommon.mk:TARGET_RECOVERY_FSTAB := $(RECOVERYCOMM)/recovery.fstab

展讯Android 5.0&5.1按照芯片和存储方案规定了跟Android 4.4一样的存放路径,还
根据是否secureboot版本是否独立物理内卡分区等情况定义了不同的recovery.fstab文
件,而具体使用哪个文件则根据项目的device定义组合成想要的名字对应的fstab。具体
可参见下图:

recovery.fstab中定义了需要用到的或者需要修改的分区列表。

原生的recovery.fstab一般会包含这几个分区:sdcard、system、data、boot、
recovery。

如果需要对bootloader或者modem文件进行升级,或者支持使用内置SD卡,就需
要将对应的分区加到这里。制作升级包时,脚本会读取这个文件,以便根据预置升级步
骤生成对应的脚本。

recovery主程序

源码文件可以查看bootable/recovery/Androd.mk中关于编译模块recovery的定义,
对应编译的源文件如下:

LOCAL_SRC_FILES := \

recovery.cpp \

bootloader.cpp \

install.cpp \

roots.cpp \

ui.cpp \

screen_ui.cpp \

verifier.cpp \

adb_install.cpp

recovery主程序主要就是对recovery系统的流程进行控制,或者升级,或者恢复出
厂设置。错误!未找到引用源。

updater主程序

Recovery系统在进行升级时,会执行升级包中的文件/META-
INF/com/google/android/update-binary。这个文件就是updater主程序。

Android 7.0上查看bootable/recovery/updater/Android.mk可以得知这个程序的源码
包含如下文件:

updater_src_files := \

install.cpp \

blockimg.cpp \

updater.cpp

updater实际是个解释器,它运行后实际是运行升级包中的脚本文件/META-
INF/com/google/android/updater-script。制作升级包时,会生成这个脚本文件,将
updater和生成的脚本打包到升级包。

制作升级包的脚本

不管用哪种方式制作升级包,最终都是使用:

build/tools/releasetools/ota_from_target_files 来生成的升级包。

这个脚本会根据target文件来生成升级包。target文件包含system、boot、recovery
中的所有文件,以及其它信息文件。当然其中包含了上面提到的recovery.fstab。

制作升级包有两种方式:一种是一个特定版本的target文件制作为一个包含完整系统
的升级包,称为整体升级包;另一种是使用两个版本的target文件,将其中一个版本作
为基础版本,将另一个版本与基础版本的差异对比出来,制作成升级包,称为差分升级
包。

这个脚本在执行时,会根据制作升级包的方式生成以及需要升级的文件,生成升级脚
本,并将需要用到的文件打包,最终生成升级包。

2.2.3. 展讯特有分区以及其升级

展讯特有的分区及其升级:

. Spl:分区对应的bin为u-boot-spl-16k.bin,主要是负责对硬件信息的确认与初始化,
负责对u-boot.bin进行引导和secureboot校验。由于其为关键引导程序,会在u-
boot-spl-16k.bin的基础上添加上一些校验值和magicdata等校验数据,故直接对此

 

分区采用覆盖新版本bin的方法不适用,这部分展讯有专门的升级程序splmerge来
进行升级,即根据新版本的u-boot-spl-16k.bin(跟老版本不一样)计算新的
magicdata、校验值、pad_data等写到到新版本的bin的头部,然后再写入到对应分
区中去。
. Modem_bins:展讯的modem对应的各个bins,其中有CP的各个bins和wcn的
bins,这个各平台bins会不一样,在device的项目定义中定义,后续在如何制作升
级包中会详细讲到命名规则。这些bins的升级有的是直接全部覆盖,有的则是进行
差分升级,会分开对待。进行何种升级是在device/sprd/scxXX下面的modem.cfg文
件中来规定的。
. Nv参数:包括modem的nvitem和wcn的nvitem,由于一些参数跟硬件单体密切依
赖,比如校准参数,所以这个分区升级也是采用展讯独有的升级程序nvmerge来完
成,详细后边有介绍

 

这些分区的升级脚本是在展讯本地化脚本releasetools.py中,Android 6.0(含)之
前的位置是vendor/sprd/open-source/tools/ota/releasetools.py,Android 7.0上的位置是
vendor/sprd/tools/ota/releasetools.py。然后在芯片级通用Board配置文件中通过变量
TARGET_RELEASETOOLS_EXTENSIONS来指定这个路径的。

而Android 5.0以后的展讯特有分区的升级则是由releasetools.py来读取modem配

置文件device/sprd/scx3XX/modem.cfg来判断哪些modem需要升级升级方式如何。此
文件也是在板级配置文件中定义了MODEM_UPDATE_CONFIG_FILE供编译系统使用。

3. Recovery
系统

 

Recovery系统是一个区别于正常启动的系统(以下简称Android系统)的系统,可
以用来对手机系统做出一系列的更改。如:恢复出厂设置、升级、root等。

Android系统包含boot.img、system.img、userdata.img。而Recovery系统仅包含
一个recovery.img。和boot.img一样,recovery.img包含了kernel和ramdisk。而且正
常编译出来的recovery.img和boot.img使用的kernel是一样的,recovery.img和
boot.img的区别在于ramdisk。其中最重要的区别就是recovery.img和boot.img的init.rc
不一样。Init.rc的不同就决定了kernel在启动之后运行Recovery系统还是运行Android
系统。

在系统启动进入
Recovery
模式后,可以从参数中


升级包
路径并
进行升级,也可
以在出现
Recovery
菜单后选择特定升级包进行升级。

 

3.1. 启动及运行流程

3.1.1. 启动流程

 

recovery_system_boot_process

3

1
启动流程

 

3.1.2. 运行流程

 

 

recovery_system_run_process

3

2
运行流程

 

 

4. 升级包制作
与升级

 

4.1. 制作原理

编译升级包需要经历两个过程:

1. 将image以及一些参数制作成target文件
2. 从target文件制作成升级包文件

 

 

 

 

build_update_package

4

1
制作原理

 

4.1.1. Target 文件说明

target文件是包含一个版本所有信息的一个集合。不但可以通过target文件制作升级
包,也可以通过target文件制作所有的image文件。

除了image文件的信息,它还包含了制作升级包所需要的一些参数。这些参数大多存
放在target文件的META/misc_info.txt。在制作升级包的过程中这些参数会被读取出来,
做不同的处理。

制作target文件是通过命令make targe-files-package完成,执行完后target文件的
位置在:

out/target/product/board/obj/PACKAGING/target_files_intermediates/scx35_***-
target_files-eng.apuser.zip

4.1.2. 升级包构成简单说明

按照制作方式来划分,升级包分两种:整体升级包和差分升级包。但从
Recovery

统中升级的流程来看,两种升级包实质上是一样的。

 

理论上来说,升级包中只要包含一个
update

binary
就好了,
Recovery
系统在使用升
级包升级时,只是简单的创建了一个进程去执行
update

binary
而已。

 

实际上,除了
update

binary
,升级包中还包含了一个
updater

script
。而这个
script
才是升级过程的真正主导者,
update

binary
只是一个解释器,用来执行
script
中的命令。

 

升级包内文件分布如下:

 

update

binary /META

INF/com/google/android/update

binary

 

updater

script /META

INF/com/google/android/updater

script

 

system
分区
/system
目录下所有文件

 

boot
分区
/boot.img

 


modem.bin
即需要直接覆盖分区的
modem.bin

 

system.transfer.list:块升级system分区的升级动作文件,如果是整包,则此文件为

空,如果是差分包,则里面规定了各个升级动作。

system.patch.dat:块升级system分区的patch集合。如果是整包,此文件为空,差

分升级则不为空。

system.new.dat
:块升级
system
分区的目标
img
数据合集,整包升级则此文

 

件实为新版本的
img
,差分升级则只包含新增文件的数据集合。

 

 

典型的整包升级包包含文件如下图所示:

 

典型的差分升级包包含文件如下图所示:

典型的使能dm_verify功能的整包包含文件如下图所示:

典型的使能dm_verify功能的差分包包含文件如下图所示:

4.2. 制作方法

4.2.1. 整体升级包步骤

1. 下载项目AP部分的代码
2. 设置编译环境source build/envsetup.sh lunch kheader
3. 通过make命令全编整个工程
4. 进入device/sprd/XXXX/目录(XXXX代表贵司项目名字的子目录),手动建立
modem_bins子目录
5. 然后将展讯发布的对应AP版本的modem bins按照device/sprd/spXXXX/
AndroidBoard.mk中的规定更改名字后拷贝到device/sprd/XXXX/modem_bins/目录
下。以下是7731平台示例:

 

LOCAL_PATH := $(call my

dir)

 

 

$(call add

radio

file,modem_bins/wmodem.bin)

 

$(call add

radio

file,modem_bins/wnvitem.bin)

 

$(call add

radio

file,modem_bins/wdsp.bin)

 

ifeq ($(strip
$(USE_SPRD_WCN)),true)

 

$(call add

radio

file,modem_bins/wcnnvitem.bin)

 

$(call add

radio

file,modem_bins/wcnmodem.bin)

 

endif

 

如果
USE_SPRD_WCN
是定义的,此型号就需要拷贝
5

bin
到上述目录。

 

具体名字更改办法下边小节会详细说明。

 

6. 然后通过命令“
make otapackage
”编译
ota
整包
此命令运行完后会在
out
目录下得

ota
整包:
得到整体升级包

out/target/p
roduct/spXXXX/spXXXX

ota

*.zip

 

注意

为了以后在版本升级时可以使用差分升级,同时要保留此版本对应的
target
文件。路径
为:
out/target/product/spXXXX/obj/PACKAGING/target_files_intermediates/*

target_files

*.zip

 

7. 如果想制作跟
target
包对应的
pac
包,请在此时执行命令生成
pac

 

注意
:请严格在执行完
make otapackage
后做
pac
包,因为
make otapackage
命令会对
system.img
等的时间做改动,只有在此步骤后做的
pac
包才是跟
target
包严格对应的!!

 

4.2.2. 差分升级包步骤

1. 下载
A
版本代码,按照整包制作整包步骤
1~6
步执行,然后保存此版本对应的
target

A

target.zip
2. 下载
B
版本代码,按照整包制作整包步骤
1~6
步执行,然后保存此版本对应的
target

B

target.zip
3. 制作差分升级包,执行
以下
命令
,由于
user
版本和
userdebug
版本使用的签名
key
不一样,故命令也不一样,而最终

k
后面参数为实际版本的
key
的放置目录,
编译命

 



. U
serdebug
版本:

 

./build/tools/releasetools/ota_from_target_files

i A

target.zip

k
build/target/product/security/testkey
B

target.zip A

B_update.zip

 

其中
A

B_update.zip
名字是最终的差分包名字

 

. U
ser
版本:

 

./build/tools/releasetools/ota_from_target_files

i
A

target.zip

k
build/target/product/security

 

/release/releasekey
B

target.zip A

B_update.zip

 

. 如果是使能了
dm_verify
功能,则
OTA
升级须使用块升级,
做整包命令还是使用
make otapackage
,而

差分包
包命令变为
如下:

 

./build/tools/releasetools/ota_from_target_files

block

i A

target.zip

k
build/target/product/security/release/releasekey
B

target.zip A

B_update.zip

 

 

4.3. Modem bins改名方法

以下是各平台的modem改名映射规则:

. 7731/7731c

 

SC8800G_pike_wcn_dts_modem.bin -> wcnmodem.bin

nvitem_wcn.bin-> wcnfdl.bin

DSP_DM_G2.bin – > wdsp.bin

SC7702_pike_modem_AndroidM.dat -> wmodem.bin

nvitem.bin -> wnvitem.bin

. 9832/9830

 

SC9600_sharkls_3593.dat -> ltemodem.bin

SHARKL_DM_DSP.bin -> ltegdsp.bin

PM_sharkls_arm7.bin -> pmsys.bin

LTE_DSP.bin -> ltedsp.bin

SC9600_sharkl_wphy_5mod_volte_zc.bin -> ltewarm.bin

EXEC_KERNEL_IMAGE0.bin -> wcnmodem.bin

fdl_wcn.bin -> wcnnvitem.bin

nvitem.bin -> ltenvitem.bin

. 9820

 

SC9600_pikel_tddcsfb_3592_V11_RTM7910V31.bin -> ltemodem.bin

PM_pikel_arm7.bin -> pmsys.bin

LTE_DSP.bin -> ltedsp.bin

PIKEL_DM_DSP.bin -> ltegdsp.bin

pikel_tddcsfb_3592_V11_nvitem.bin -> ltenvitem.bin

. 9860

 

SC9600_sp9860G2_v1_pubcp_volte_modem.dat -> ltemodem.bin

sp9860G2_v1_pubcp_volte_AGCP_DSP.bin -> lteagdsp.bin

sp9860G2_v1_pubcp_volte_DM_DSP.bin -> ltetgdsp.bin

sp9860G2_v1_pubcp_volte_LTEA_DSP.bin -> ltedsp.bin

EXEC_KERNEL_IMAGE.bin -> wcnmodem.bin

sp9850s_cm4.bin -> pmsys.bin

sp9860G3_pubcp_volte_nvitem.bin -> ltenvitem.bin

fdl_wcn.bin -> wcnnvitem.bin

. 9861e

 

SC9600_iwhale2_pubcp_volte_modem.dat -> ltemodem.bin

iwhale2_pubcp_volte_nvitem.bin -> ltenvitem.bin

iwhale2_pubcp_volte_LTEA_DSP.bin -> ltedsp.bin

iwhale2_pubcp_volte_AGCP_DSP.bin -> lteagdsp.bin

iwhale2_pubcp_volte_DM_DSP.bin -> ltetgdsp.bin

iwhale2_cm4.bin -> pmsys.bin

EXEC_KERNEL_IMAGE.bin -> wcnmodem.bin

. 9850

 

SC9600_sharkl2_pubcp_modem.dat -> ltemodem.bin

sharkl2_pubcp_DM_DSP.bin -> ltegdsp.bin

sharkl2_pubcp_LTEA_DSP.bin -> ltedsp.bin

sharkl2_arm7.bin -> pmsys.bin

sharkl2_pubcp_nvitem.bin -> ltenvitem.bin

EXEC_KERNEL_IMAGE.bin -> wcnmodem.bin

由于平台众多,modem bins的多少和名字也都有一些细微区别,如果不确定如何改
名字,可以联系我们,我们会给出指导。

5. 展讯平台
特有
部分细节说明

 

5.1. nvmerge和splmerge

在展讯平台上,有一些特殊的分区。在烧录或者升级时不能将编译好的文件直接写入
分区,需要进行一定的处理。如nvitem、spl就是这样的分区,为了能够正确的处理这两
种分区的升级,开发了nvmerge和splmerge,分别用于nvitem分区和spl分区的升级处
理。

nvmerge和splmerge的都是在升级包的updater-script中调用的,调用方式如下:

1
2
3
4

merge_spl(“/cache/u-boot-spl-16k.bin”, “/dev/block/mmcblk0boot0”, “EMMC”);
assert(run_program(“/tmp/nvmerge”, “/tmp/nvmerge.cfg”, “/dev/block/platform/sprd-sdhci.3/by-
name/wfixnv1”, “/cache/wnvitem.bin”, “/cache/merged_wnvitem.bin”, “0x40000”));
write_emmc_image(“/cache/merged_wnvitem.bin”, “/dev/block/platform/sprd-sdhci.3/by-name/wfixnv1”);
write_emmc_image(“/cache/merged_wnvitem.bin”, “/dev/block/platform/sprd-sdhci.3/by-name/wfixnv2”);

 

 

 

5.2. nvmerge具体说明

nvmerge
是用于处理
nvitem
分区升级的工具。可以
将手机中的某些需要保留的nv项
(如校准参数)备份下来,保证升级后不会被重置。这里的nv项,指的是与modem相
关的一些参数,这些参数均保存在nvitem分区。

其中具体的要备份的items保存在nvmerge.cfg 文件中,这个文件也会被打包进升级
包,里面的内容可以根据需要进行增减,以达到备份某些特殊数据的目的,比如IMEI号
等。

此文件在Android 4.4平台上是存放在bootable/recovery/nvmerge/下面,在Android
5.1以后平台上是存放在device/sprd/XXX/下面, XXX代表芯片系列,如scx35l, iwhale2,
sharkl2等。

 

5.3. Secure boot支持

Secure boot
1是一个安全解决方案,以安全启动的方式保证手机系统没有被篡改过。
通过对系统启动过程中用到的分区进行分级加密校验来实现。

 

1 可参见secure boot相关文档

对于升级来说,制作升级包
会加入
需要校验的分区
bin

secureboot
签名

Android
6.0
之前版本会在升级过程中校验签名是否正确。
Android 7.0
在升级中不对签名进行校验。

 

如何在版本中使能
secureboot
请参考专门的
secureboot
文档。

 

5.3.1. Android 6.0以前的OTA包制作

支持
secure boot
后,升级包制作的方法没有变化。但由于
secure boot
签名时需要
用到密码,因此在制作升级包时增加了输入密码的过程。

 

根据现有的工具,每个
key
对应一个
product_name
和一个
password
。由于目前采
用单一
key
方式验证,因此只需输入一次就可以。在制作升级包时会在处理第一个需要
签名的分区
image
时提示输入
product_name

password
。处理后面需要签名的分区时
直接使用这个
key
进行签名。

 

这种方式不适用于服务器制作升级包,因此提供了另一种方式。将
p
roduct_name

password
放入配置文件,在签名时直接从配置文件读取
product_name

password

息进行签名。如果要使用这种方式,需要设置环境变量

SPRD_SECURE_BOOT_SIGN_CONFIG
)为配置文件的路径
(即把包含如下内容的
文件的全路径赋给这个宏)
。格式为:

 

[[[ passwd ]]] product_name

如:
product_name

7731
密码为
12345678
的话,内容为:

 

[[[ 12345678 ]]] 7731

5.3.2. Android 7.0的OTA包制作

Android 7.0
上的
9832

7731
平台,默认不打开
secureboot
,升级包制作方法同
Android 6.0
(含)
之前的一样。

 

其余平台
9861e

iwhale2


sharkl2

isharkl2
都是默认打开
secureboot
的,在制

target
包时,都是自动进行各
img
(包括
modem bins
)的签名的,故无需特殊配置和
操作,在制作
ota
整包和差分包时直接用
target
包制作即可。

 

5.4. 关于adb的支持


Android 4.4
上面,已经加入
挂载
system
分区的内容,所以只要进入
recovery

式,且是
userdebug
版本,就能连接使用
adb

 


Android 5.0
&5.1
上面,需要先按音量上键,再按音量下键,重复此步骤
7

以后,

挂载
system
,则
adb
能使用。

 

Android 6.0
以后
,则把挂载
system
分区的动作放到
recovery
的菜单中
(菜单名为

mount /system
”)
去了,选择此菜单执行后即可连接
adb

userdebug
版本)。

 

6. Android 7.0
上新加入功能和注意事项

 

Android 7.0的OTA升级出现了一些有别于以前的特殊功能,主要一点就是升级过
程中的repart(重新分区)功能,这个功能加入的原因和带来的一些后果后面逐一阐述。

6.1. 升级中加入Repart起因

6.1.1. System分区自适应功能

为避免开发中频繁更改维护分区表、节省存储空间开发出的根据版本系统分区文件多
少自动调节system分区大小的功能。即不会像很早以前的平台(Android 4.4)固定死
system分区的img和物理分区的大小,而是根据版本演进中system分区中的文件多少
动态调节两者大小。具体是在代码中的build/core/partition_size_self_adaption.sh脚本。

其中计算最终system物理分区大小的算法是

其中红圈中的三个一样的值50可以认为是步长,即增减文件大小超过一定值(50M
– imgsize%50),物理分区大小即会改变,改变幅度是50M。

6.1.2. Dm_verify功能使能

Dm-verity是一项kernel的功能,它可以提供透明的对块设备的完整性校验,这可以
用于防止恶意程序对系统分区的篡改。其主要是针对system分区,此功能会对system
分区的全部数据进行校验,任何一个字节的改动都会导致校验失败,并导致system分区
挂载和数据读取失败,设备会开机不了。

在Android 7.0上此功能开启后,其算法要求system的img和物理分区大小须保持
一致。

代码中判断此功能是否开启:在device对应的borad的mk文件中是否定义:

./sp9832a_2h11/sp9832a_2h11_volte.mk:TARGET_DM_VERITY := true

如果定义为true,则为打开此功能的,且只有user版本时起作用,即userdebug版
本不对system是否完整进行校验,以方便工程师项目开发。

Dm_verify功能打开后,OTA升级时system分区升级方式将从文件升级方式转为块
升级方式,且升级后分区大小必须跟img大小一致。其具体细节请参考文档《dm_verify
对OTA升级影响及客户指导.docx》。

6.2. OTA升级加入repart

Dm_verify功能要求img和物理分区必须一样大小,加上system分区自适应功能,
只要system分区文件增减超过一定数值其分区大小进行调整时,在OTA升级时也必须
进行分区重新划分,否则结果是升级完后无法开机。这是加入repart过程的原因。

Reaprt程序源代码在vendor/sprd/tools/ota/repart下面,其在升级脚本中的体现是:

NormalText Code

1
2

package_extract_file(“META-INF/com/google/android/reparts”, “/tmp/repart”);
package_extract_file(“partition.cfg”, “/storage/sdcard0/partition.cfg”);
assert(run_programex(“/tmp/repart”,”-d”,”/dev/block/mmcblk0″,”-
c”,”/storage/sdcard0/partition.cfg”,”-b”,”/storage/sdcard0″,”-k”,”0″));

 

6.3. Repart带来的影响

6.3.1. 用户数据丢失

当system分区变化时,其空间会从userdata分区获得,这样会导致userdata分区
大小发生变化,其数据会被破坏。

Android 5.1平台进行Android 4.4到Android 5.1大版本升级时在repart前后会对
userdata分区的数据进行备份并恢复,这样就会保留userdata数据,备份方式是按照文
件进行,恢复也是按照文件方式写回。

Android 6.0(含)以后selinux规则不允许recovery对userdata分区进行写操作,
因此Android 7.0现在是没有备份恢复的动作,因为即使备份了也不允许恢复回去。由于
技术原因,现有方案还无法实现对userdata分区的数据保护。

6.3.2. 升级须插sd卡

必须插sd卡是因为要备份一些重要分区(recovery、misc、persist等),备份的原
因是一旦掉电等异常终止导致这些分区没升级完,手机会重新进入recovery进行继续升
级时把被中断的分区升级进去。

备份数据放在sd卡的原因是要进行repart,无法放在内置存储的data分区。如果不
插sd卡,分区又发生变化,则进行OTA升级时会直接报错退出。

无论整包升级还是差分升级都需要插sd卡,因为现在整包和差分升级都有repart动
作。

6.3.3. 升级时间变长

变长原因是两次对升级包进行解析。而原先只有一次,加入一次的原因是一旦发生分
区变化,recovery加入用户选择是否继续的提示菜单,这样就需提前解析升级包并计算
是否需要repart。这一次对升级包解析时间,差分包会变长十几秒几秒不等(据包大小
定),而整包则会变长五六十秒,因为整包体积大。

同时,在差分升级时由于要以现有手机中system分区内容做基础进行升级,分区变
化时须对system分区内容进行备份,备份地是sd卡,system分区本身特别大,加之sd
卡的读写速度,会使升级时间变得更长。

上述两因素会使整个升级时间变为无repart动作的三四倍甚至更长。

6.3.4. 掉电无法开机风险变大

一些关键的引导分区有备份以后极大减小意外掉电导致的开机不了的风险。但是
repart功能的加入则又增大这个风险。Repart过程中计算好新的分区表的各项数据后,
会写入到emmc的header中,写的过程中掉电的话,则手机无法开机。

6.4. 应对措施

由于上述不利影响,应采取措施降低repart的概率。一是彻底消除repart动作,即
拿掉分区自适应功能;二是通过修改自适应的参数降低repart的概率。

6.4.1. 去掉system分区自适应功能

在项目的开发过程中,system分区文件增减剧烈,不可避免的会带来repart的动作,
但是由于没有量产上市,上述不利影响不太敏感,故为了避免维护分区表的巨大的工作量,
还是保留此功能。

分区确定是个很重要的事情,在项目接近量产的时间段,须通盘考虑后续量产后
system分区文件增减的概率,目标是增减尽量在前期开发完成,量产后不要进行大的系
统分区文件增减。如果量产后增减文件概率很小,则建议直接拿掉system分区自适应功
能,把其大小固定。这样就不会进行repart,降低上述不利影响;即使不可控因素导致某
个版本system分区必须调大,也会有repart程序在,能进行分区变更的OTA升级。

如何去掉此功能以及固定system分区大小后面一章给出指导。

6.4.2. 降低repart的概率

我们严肃建议采取在关键时段固定住system分区的办法。

但是有些项目是存在一些客观因素无法在量产时固定system分区,比如是销往多个
地区项目,其预制内容差别大等,那只能修改自适应的计算参数降低repart的概率。

办法是加大system分区大小计算时的步长。具体在build/core/
partition_size_self_adaption.sh的图中红圈所示三个数值(三个值须同时改,算法决定):

此值调为多少视可能增加的文件数量定,比如版本之间频繁增加的文件大小为80M,则
此值定位100较保险。但是此值定的过大则浪费存储空间,比如定为200则浪费将近
300M的空间,需综合考量,取个平衡。

7. OTA
升级测试说明

 

1、准备升级前版本

1)整包升级需要保证手机版本比目标版本旧

2)差分升级需要保证手机版本为差分升级包的基础版本

2、升级

<1>通过Android进行升级

1)将“升级包”放到sd卡的根目录下并命名为update.zip

2)设置->关于->系统软件更新,就会自动重启并升级

<2>直接进入Recovery模式升级

1)将“升级包”放入到SD卡或者cache分区根目录下

2)使手机置于关机状态

3)用组合键方式开机进入Recovery模式(手机上操作方法:关机状态下,按
power键后立即按住音量下键,亮屏后松开power键和音量下键,进入Recovery模式)

4)根据“升级包”所在位置选择相应选项进入并选择升级包进行升级

5)升级完成后手动选择相应选项进行重启

注意:Android 6.0以后平台上将sd卡使用为内部存储后已经不能再作为本地升级
的存储升级包的普通sd卡使用,因为其已经被挂在为ext4格式,而非recovery能识别
的FAT格式。

8. 大版本升级

 

8.1. Android 4.4/5.0&5.1/6.0之间分区变更的大版本升级

此功能主要是进行分区重新划分,由于大版本间都伴随着分区大小的改变或者分区的
增减,差分升级不适用,只能进行整包升级。这时候制作整包的办法是:

首先编译出目标Android 5.0&5.1/6.0版本的target包,将

out/target/product/spXXXX/obj/PACKAGING/target_files_intermediates/*-target_files-
*.zip拷贝到工程根目录,然后运行以下命令制作变分区的大版本升级包:

./build/tools/releasetools/ota_from_target_files –HCSR *-target_files-*.zip
full_partition_modified.zip
其中四个参数的意义分别是:

-H: 用于表示大版本升级,目前脚本中只是作为标志,做包时此参数无用

-C: 版本间分区名有变化,即各分区的设备名有变化,必须加入此参数

-S: 版本间分区大小有变化,或者有新加分区,必须加入此参数

-R: 需要内置Android 4.4的recovery image,主要用于断电保护,因为分区变更,
recovery分区会被覆盖,所以如果断电,无法继续升级,需备份recovery一下

8.1.1. 参数使用说明

. 其中在Android 4.4升级到Android 5.0&5.1或者是Android 6.0时,伴随着分区变化
和设备名的改变,上述四个参数都需要加上。如无分区变化,则Android 4.4可以通
过差分升级包升级到Android 5.0&5.1。而Android 4.4到Android 6.0或者Android
5.0&5.1到Android 6.0都会有分区变化,因为modem bin变大了。
. Android 5.0&5.1升级到Android 6.0时,分区有变化,但设备名无改变,只需加-
HSR参数即可。

 

8.1.2. 升级方法

手机里面请烧录一个Android 4.4或者Android 5.0&5.1的版本,然后再将
full_partition_modified.zip改名为update.zip放入sd卡根目录后,从recovery模式的外
部存储进行升级。此种情况只能通过sd卡进行升级,因为data分区的用户数据是备份到
sd卡目录下的。如果分区有变化只能进行整包升级,无法进行差分包升级。

8.1.3. 升级注意事项

. 排查系统应用以及内置第三方应用的数据库兼容性

 

数据库的结构是否兼容,如Android 4.4新增的字段但Android 5.0没有,Android
5.0本身的数据库可能有改

变而Android 4.4自己做了修改,导致升级后数据不兼容,无法读取,理论上来说,
所有系统应用(包含自己研发应用)和内置第三方应用都应该排查下, 重点关注
的应用为Contacts(calllog) ,MMS,Settings等

. 数据兼容问题

 

需要各模块负责同事注意各自OTA升级的数据兼容问题,特别要注意采用物理内
卡方案,从Android 4.4进行大版本升级时,使用内外卡绝对路径的模块可能会存
在数据丢失问题,例如mediaprovider。

. 需采用同一种存储方案

 

必须采用同一种存储方案,例如,Android 4.4上采用的是内卡为物理卡的方案,
Android 5.0&6.0上也要采用内卡为物理卡的方案,而不能采用内卡为虚拟卡的方
案,否则会导致数据丢失

. Selinux开关

 

大版本升级需要确认Android 4.4版本selinux是否为打开的,否则升级后prodnv分
区读写会有问题。因为AndroidL是启用selinux 的, 升级不会改变这个分区, 未
启用selinux的prodnv分区的文件没有打标签,启用selinux后会有问题。

. 签名key保持一致

 

这个签名key包括升级包本身的签名key和在编译版本时的各个apk的签名key,两
个版本间必须统一。请参考build/core/Makefile中对
DEFAULT_SYSTEM_DEV_CERTIFICATE的定义。

. Board名称是否一致

 

大版本升级时,新旧版本的board名称须保持一致,否则会因为校验此名称失败
而升级失败。

8.2. Android 5.0&5.1/6.0到Android 7.0的大版本升级

由于Android 7.0的常规升级包里面就加入了repart程序,故而无需经过特殊命令制
作Android 5.1或者Android 6.0到Android 7.0的升级包,只需拿Android 7.0稳定版本
的OTA整包放入Android 5.1或者Android 6.0的手机直接进行升级即可。

9. R
ecovery log
抓取办法

 

不论是恢复出厂设置还是进行ota升级,如果出现问题,可以按照如下办法抓取
recovery的log:

. 如果恢复出厂设置或者ota升级出错了,一般会在recovery里面进入error界面,这
时候按音量上键或者下键(Android 5.1是home键或者power+up键)会进入菜单选
择模式,这时候用usb线将设备链接电脑,在Android 4.4上直接可以连adb,而5.1
需依次按上下键7次以上才会挂载system并连接adb。通过如下命令序列获取
recovery的log,这种抓取办法需要版本为userdebug版本:

 

adb root

adb pull /tmp/recovery.log D:\log

D盘log下的recovery.log即是所需要的log

. 如果恢复出厂设置或者ota升级出错了,停在recovery的error界面,按键进入菜单
选择模式,然后选择“reboot system”,系统重启进入主系统的Idle界面了,可以
选择如下命令获取有效log:

 

adb root //须是 userdebug版本

adb pull /cache/recovery/last_log D:\log

D盘下面log里面的last_log即是刚重启前失败动作的log。

. 如果是user版本在ota升级或者恢复出厂设置时失败,则recovery模式无法连接
adb或者开机后也无法访问cache分区。这时可升级一个userdebug版本,但是保持
cache分区不更新,然后开机获取cache分区的/cache/recovery/last_log文件即可。
. 如果卡在recovery中的某些画面,按键也不会有动作。拔出电池重启还是会重新进
入recovery模式,则可以如下获取log

 

连接usb线,看能否使用adb,如果能则按照第一步办法获取log

如果不能使用adb则使用reseachdownloader擦除misc分区,然后开机进入主系统
按照如下命令获取log:

adb root

adb pull /tmp/recovery.log D:\log

D盘log下的recovery.log即是所需要的log

. 另外一般恢复出厂或者升级出错后通过按键会显示出错界面,上面会显示最后的错误,
虽然有时候无法看出错误详细信息,但也有一定作用。
. Android 5.1以后平台在recovery的菜单里面添加了一项查看log的选项,拉到log
的最后把错误拍照共享,也能帮助分析。具体操作步骤:

 

出错后按照按键出现recovery菜单后,选择重启,然后关机,通过按键进入
recovery模式,按键(Android 5.1是按power+volup或者home键,Android 6.0是
按power+volup或者长按某键)出来菜单,选择“view recovery logs”这个菜单,
然后选择cache/recovery/last_log1(如果反复几次进入过recovery,则需选对对应
的后缀数字的文件)这个文件,滑动(或者按上下音量键)翻页到最后看看出错的语
句,即为有用log。

. Android 7.0平台会将本次升级的recovery log也拷贝到sd卡(根目录下)上一份,这
解决了user版本无法访问cache分区权限问题。Debug升级失败的问题,只需插入
sd卡,升级失败重启后拔出sd卡,里面的last_log即是本次升级失败的有效log。