一、 update.zip包的目录结构
|----boot.img
|----system/
|----recovery/
`|----recovery-from-boot.p
`|----etc/
`|----install-recovery.sh
|---META-INF/
`|CERT.RSA
`|CERT.SF
`|MANIFEST.MF
`|----com/
`|----google/
`|----android/
`|----update-binary
`|----updater-script
`|----android/
`|----metadata
二、 update.zip包目录结构详解
以上是我们用命令make otapackage 制作的update.zip包的标准目录结构。
1、boot.img是更新boot分区所需要的文件。这个boot.img主要包括kernel+ramdisk。
2、system/目录的内容在升级后会放在系统的system分区。主要用来更新系统的一些应用或则应用会用到的一些库等等。可以将Android源码编译out/target/product/tcc8800/system/中的所有文件拷贝到这个目录来代替。
3、recovery/目录中的recovery-from-boot.p是boot.img和recovery.img的补丁(patch),主要用来更新recovery分区,其中etc/目录下的install-recovery.sh是更新脚本。
4、update-binary是一个二进制文件,相当于一个脚本解释器,能够识别updater-script中描述的操作。该文件在Android源码编译后out/target/product/tcc8800/system bin/updater生成,可将updater重命名为update-binary得到。
该文件在具体的更新包中的名字由源码中bootable/recovery/install.c中的宏ASSUMED_UPDATE_BINARY_NAME的值而定。
5、updater-script:此文件是一个脚本文件,具体描述了更新过程。我们可以根据具体情况编写该脚本来适应我们的具体需求。该文件的命名由源码中bootable/recovery/updater/updater.c文件中的宏SCRIPT_NAME的值而定。
6、 metadata文件是描述设备信息及环境变量的元数据。主要包括一些编译选项,签名公钥,时间戳以及设备型号等。
7、我们还可以在包中添加userdata目录,来更新系统中的用户数据部分。这部分内容在更新后会存放在系统的/data目录下。
8、update.zip包的签名:update.zip更新包在制作完成后需要对其签名,否则在升级时会出现认证失败的错误提示。而且签名要使用和目标板一致的加密公钥。加密公钥及加密需要的三个文件在Android源码编译后生成的具体路径为:
out/host/Linux-x86/framework/signapk.jar
build/target/product/security/testkey.x509.pem
build/target/product/security/testkey.pk8 。
我们用命令make otapackage制作生成的update.zip包是已签过名的,如果自己做update.zip包时必须手动对其签名。
具体的签名方法:$ java –jar gingerbread/out/host/linux/framework/signapk.jar –w gingerbread/build/target/product/security/testkey.x509.pem gingerbread/build/target/product/security/testkey.pk8 update.zip update_signed.zip
以上命令在update.zip包所在的路径下执行,其中signapk.jar testkey.x509.pem以及testkey.pk8文件的引用使用绝对路径。update.zip 是我们已经打好的包,update_signed.zip包是命令执行完生成的已经签过名的包。(这里的路劲很重要,要配置好,在update.zip包路径下,其他的要索引到相应的文件路径下)
签名工具要根据项目配置来决定,需和recovery所用保持一致。
见build/tools/releasetools/common.py SignFile()函数
9、MANIFEST.MF:这个manifest文件定义了与包的组成结构相关的数据。类似Android应用的mainfest.xml文件。
10、CERT.RSA:与签名文件相关联的签名程序块文件,它存储了用于签名JAR文件的公共签名。
11、CERT.SF:这是JAR文件的签名文件,其中前缀CERT代表签名者。
另外,在具体升级时,对update.zip包检查时大致会分三步:①检验SF文件与RSA文件是否匹配。②检验MANIFEST.MF与签名文件中的digest是否一致。③检验包中的文件与MANIFEST中所描述的是否一致。
三、
Android升级包update.zip的生成过程分析
1) 对于update.zip包的制作有两种方式,即手动制作和命令生成。
第一种手动制作:即按照update.zip的目录结构手动创建我们需要的目录。然后将对应的文件拷贝到相应的目录下,比如我们向系统中新加一个应用程序。可以将新增的应用拷贝到我们新建的update/system/app/下(system目录是事先拷贝编译源码后生成的system目录),打包并签名后,拷贝到SD卡就可以使用了。
第二种制作方式:命令制作。Android源码系统中为我们提供了制作update.zip刷机包的命令,即make otapackage。该命令在编译源码完成后并在源码根目录下执行。 具体操作方式:在源码根目录下执行
①$ . build/envsetup.sh。
②$ lunch 然后选择你需要的配置(如17)。
③$ make otapackage。
在编译完源码后最好再执行一遍上面的①、②步防止执行③时出现未找到对应规则的错误提示。命令执行完成后生成的升级包所在位置在out/target/product/full_tcc8800_evm_target_files-eng.mumu.20120309.111059.zip将这个包重新命名为update.zip,并拷贝到SD卡中即可使用。
下面是如何 手动制作 update.zip 升级包
1)创建一个目录(例如,名为“update”的文件夹)
里面包含需要打包到Update.zip用来升级或者替换原有ROM的内容:
update
/
update
/
system
update
/
system
/
app
update
/
system
/
app
/
xxxx
.
apk
update
/
META
-
INF
update
/
META
-
INF
/
com
update
/
META
-
INF
/
com
/
google
update
/
META
-
INF
/
com
/
google
/
android
update
/
META
-
INF
/
com
/
google
/
android
/
update
-
binary
update
/
META
-
INF
/
com
/
google
/
android
/
updater
-
script
其中,updater-script是update.zip在释放安装时所需要的脚本文件;updatebinary是脚本文件所需要调用的函数库,这个文件可以从ROM中提取
目前广泛使用的是Edify脚本(updater-script和update-binary);很久以前还有Amend脚本(update-script),现在已经不再支持:所以如果有看到名为
update-script的脚本示例,一般已经没有用了可以无视。
仍然以GMS为例,递归地Copy升级包中的文件到设备相应的目录中:
ui_print
(
"***********************************************"
);
ui_print
(
" GMS for Beta User "
);
ui_print
(
"***********************************************"
);
show_progress
(
1
,
3
);
mount
(
"ext4"
,
"EMMC"
,
"/dev/block/platform/msm_sdcc.1/by-name/system"
,
"/system"
);
package_extract_dir
(
"system"
,
"/system"
);
set_perm_recursive
(
0
,
0
,
0755
,
0644
,
"/system/app"
);
set_perm_recursive
(
0
,
0
,
0755
,
0644
,
"/system/etc/permissions"
);
set_perm_recursive
(
0
,
0
,
0755
,
0644
,
"/system/framework"
);
set_perm_recursive
(
0
,
0
,
0755
,
0644
,
"/system/lib"
);
set_perm_recursive
(
0
,
0
,
0755
,
0644
,
"/system/media"
);
set_perm_recursive
(
0
,
0
,
0755
,
0644
,
"/system/usr"
);
unmount
(
"/system"
);
ui_print
(
"GMS update complated."
);
上面“/system”的挂载点因设备而异。关于
Edify脚本语法和函数的介绍,网上有很多资料,有兴趣可以再搜索看看是否能符合你客制化的需求。
3)打压缩包
压缩包可以用压缩工具,也可以用下面的命令行来做。但是要保证压缩包内的根目录下就有META-INF:
如果是Ubuntu一类的Linux环境下用“zip”命令做压缩包,则需要在步骤(1)的根目录中使用命令:
$ zip -qry ../update_unsigned.zip ./
4)给压缩包签名
使用下面的命令为上一步骤中生成的update_unsigned.zip做签名:
$ java -Xmx512m -jar signapk.jar -w releasekey.x509.pem releasekey.pk8 update.unsigned.zip update.zip
文件的引用使用绝对路径,要不然会报错,找不到 文件,不能照搬 这条指令
其中:
-Xmx512m:指定了java最大内存堆栈,我的包比较大512不够用,设置成4096就成功;可以省去不要
signapk.jar:签名工具,在源码中可以找到(/prebuilts/sdk/tools/lib/signapk.jar) 在生成文件中 也可以找到 ,路径:out/host/ Linux-x86/framework/signapk.jar
releasekey.x509.pem
releasekey.pk8:这两个就是现有ROM发布时对应的签名Key,在 目录 build/target/product/security/ 下
update.unsigned.zip:未签名的包
update.zip:生成的签名包
5)应用update.zip升级包
至此,升级包已经制作完毕。将签过名的update.zip包放入SD卡或者其它能被访问到的目录(有些设备可能要求SD卡根目录)( USB ),
重启设备并进入Recovery模式,找到update.zip并升级(有些设备可能直接有“
apply update.zip
”的选项)
,成功后重启。
apk签名
java -jar out/host/linux-x86/framework/signapk.jar build/target/product/security/platform.x509.pem build/target/product/security/platform.pk8 ~/tmp/NetworkLocation.apk ~/tmp/NetworkLocation-sign.apk
查看apk签名信息:
jarsigner -verify -verbose -certs your_application.apk
增量包生成命令:
./build/tools/releasetools/ota_from_target_files -i A.zip B.zip update.zip
6)以上为全量包制作,接下来介绍下 增量包制作
将两次编译过程中生成的 中间生产物,最原始的升级包, 拷贝到 源码 目录下
中间生产物 路径: out/target/product/[项目名]/obj/PACKAGING/target_files_intermediates/目录下
文件名类似:rk3288-target_files-eng.root.zip
将两次生成的包重命名为 A.zip B.zip 旧的生成包,修改后的生成包
旧的包-新包 -生成的增量包
生成增量包命令: ./build/tools/releasetools/ota_from_target_files -i A.zip B.zip update.zip