网站首页 > 技术文章 正文
上一篇文章中我们分析了recovery升级的基本流程。今天让我们来分析下升级包update.zip,看看升级包里面有些什么东西,升级包是如何制作的。
一、目录结构
update.zip包的目录结构,如下图所示:
二、目录结构分析
下面分析以全量包升级为准。
1、META文件夹
bootargs.txt bootargs启动参数
filesystem_config.txt system目录文件权限
recovery.fstab 分区表
2、META-INF目录
目录结构如下:|---META-INF/ |CERT.RSA |CERT.SF |MANIFEST.MF |----com/ |----android/ |----metadata |----google/ |----android/ |----update-binary |----updater-script
CERT.RSA:与签名文件相关联的签名程序块文件,它存储了用于签名JAR文件的公共签名。
CERT.SF:这是JAR文件的签名文件,其中前缀CERT代表签名者。
MANIFEST.MF:这个manifest文件定义了与包的组成结构相关的数据。类似Android应用的mainfest.xml文件。
metadata文件:是描述设备信息及环境变量的元数据。主要包括一些编译选项,签名公钥,时间戳以及设备型号等。
updater-script:此文件是一个脚本文件,具体描述了更新过程。我们可以根据具体情况编写该脚本来适应我们的具体需求。
update-binary:是一个二进制文件,相当于一个脚本解释器,能够识别updater-script中描述的操作。
META-INF目录中的文件是生成的:
- CERT.RSA、CERT.SF、MANIFEST.MF、metadata文件是自动生成的(怎么生成详见下文签名部分)
- update-binary一般是系统编译过程中自动生成的升级脚本,但是这部分是可以通过手动编辑(详见后文update-binary脚本语言详解)
- update-binary在sdk中哪个部分
./device/hisilicon/bigfish/build/emmc.mk cp -a $(PRODUCT_OUT)/system/bin/updater \ $(EMMC_PRODUCT_OUT)/update/file/META-INF/com/google/android/update-binary
又上面脚本部分可知update-binary其实就是updater,updater部分是通过源码编译生成的,源码路径在:
bootable/recovery/updater/
3、system目录
system/目录的内容在升级后会放在系统的system分区。主要用来更新系统的一些应用或则应用会用到的一些库等等。有的时候会以打包的形式(system.img)存在。
4、userdata目录
userdata目录,用来更新系统中的用户数据部分。这部分内容在更新后会存放在系统的/data目录下。有的时候会以打包的形式(userdata.img)存在。
5、其他文件
*.img是更新各个分区分区所需要的文件。
三、如何制作一个update升级包
update升级包一般有两种方式得到:
- 一种是通过编译系统得到update.zip包(make ota-package)
- 另一种是通过自己手动创建的方式得到update升级包
这里我们主要介绍下如何通过自己手动创建的方式得到update升级包
1、创建文件夹并拷贝你需要的升级文件
可以将原有的升级包中的升级文件解压拷贝过来,再替换你需要的文件,比如在system中添加一个apk或者修改写升级脚本updater-script。
2、打包
将你需要的升级文件导入进来后,通过压缩打包成update.zip包
接下来就是最重要的一步,进行update包签名。
3、update包签名
update.zip更新包在制作完成后需要对其签名,否则在升级时会出现认证失败的错误提示。而且签名要使用和目标板一致的加密公钥。
加密公钥及加密需要的三个文件在Android源码编译后生成的具体路径为(以下以testkey秘钥为准):
out/host/linux-x86/framework/signapk.jar build/target/product/security/testkey.x509.pem build/target/product/security/testkey.pk8
我们用命令make 制作生成的update.zip包是已签过名的,如果自己做update.zip包时必须手动对其签名。具体的加密方法:
java –jar yourpath/signapk.jar –w yourpath/testkey.x509.pem \ yourpath/testkey.pk8 update.zip update_signed.zip
以上命令在update.zip包所在的路径下执行,其中signapk.jar testkey.x509.pem以及testkey.pk8文件的引用使用你自己(yourpath替换你的)绝对路径。update.zip 是我们已经打好的包,update_signed.zip包是命令执行完生成的已经签过名的包。
另外,在具体升级时,对update.zip包检查时大致会分三步:
- 检验SF文件与RSA文件是否匹配。
- 检验MANIFEST.MF与签名文件中的digest是否一致。
- 检验包中的文件与MANIFEST中所描述的是否一致。
结束语
以上就是对update.zip的分析,希望对大家有所帮助。后续我们还会带来系统升级流程的相关知识介绍,感兴趣的同学可以关注我们的同名微信公众号麻辣软硬件。
猜你喜欢
- 2024-09-29 reFlutter:一款针对Flutter的逆向工程分析工具
- 2024-09-29 APP编译打包流程 编译apk
- 2024-09-29 抖音团队内测新版本 应用于PC、平板端
- 2024-09-29 android 5.0 创建多用户 双开多开应用(1)
- 2024-09-29 MT管理器-简单实战-去除启动页 怎么用mt管理器去掉软件启动广告
- 2024-09-29 windows11 安装安卓应用apk,访问google play商店!详细安装教程
- 2024-09-29 微信发布安卓内测版 7.0.23 更新 安卓微信7.0.21内测
- 2024-09-29 APK 是怎么来的?Android 构建流程解析
- 2024-09-29 软件测试 | 应用程序签名机制实现的源代码分析
- 2024-09-29 Android 用命令给apk签名 apk签名工具怎么使用
你 发表评论:
欢迎- 最近发表
- 标签列表
-
- oraclesql优化 (66)
- 类的加载机制 (75)
- feignclient (62)
- 一致性hash算法 (71)
- dockfile (66)
- 锁机制 (57)
- javaresponse (60)
- 查看hive版本 (59)
- phpworkerman (57)
- spark算子 (58)
- vue双向绑定的原理 (68)
- springbootget请求 (58)
- docker网络三种模式 (67)
- spring控制反转 (71)
- data:image/jpeg (69)
- base64 (69)
- java分页 (64)
- kibanadocker (60)
- qabstracttablemodel (62)
- java生成pdf文件 (69)
- deletelater (62)
- com.aspose.words (58)
- android.mk (62)
- qopengl (73)
- epoch_millis (61)
本文暂时没有评论,来添加一个吧(●'◡'●)