Android系统Recovery工作原理之使用update.zip升级过程---updater-script脚本语法简介以及执行流程(转)

 

目前update-script脚本格式是edify,其与amend有何区别,暂不讨论,我们只分析其中主要的语法,以及脚本的流程控制。

一、update-script脚本语法简介:

 

        我们顺着所生成的脚本来看其中主要涉及的语法。

        1.assert(condition):如果condition参数的计算结果为False,则停止脚本执行,否则继续执行脚本。

        2.show_progress(frac,sec):frac表示进度完成的数值,sec表示整个过程的总秒数。主要用与显示UI上的进度条。

        3.format(fs_type,partition_type,location):fs_type,文件系统类型,取值一般为“yaffs2”或“ext4”。Partition_type,分区类型,一般取值为“MTD”或则“EMMC”。主要用于格式化为指定的文件系统。事例如下:format(”yaffs2”,”MTD”,”system”)。

        4.mount(fs_type,partition_type,location,mount_point):前两个参数同上,location要挂载的设备,mount_point挂载点。作用:挂载一个文件系统到指定的挂载点。

        5.package_extract_dir(src_path,destination_path):src_path,要提取的目录,destination_path目标目录。作用:从升级包内,提取目录到指定的位置。示例:package_extract_dir(“system”,”/system”)。

        6.symlink(target,src1,src2,……,srcN):target,字符串类型,是符号连接的目标。SrcX代表要创建的符号连接的目标点。示例:symlink(“toolbox”,”/system/bin/ps”),建立指向toolbox符号连接/system/bin/ps,值得注意的是,在建立新的符号连接之前,要断开已经存在的符号连接。

        7.set_perm(uid,gid,mode,file1,file2,……,fileN):作用是设置单个文件或则一系列文件的权限,最少要指定一个文件。

        8.set_perm_recursive(uid,gid,mode,dir1,dir2,……,dirN):作用同上,但是这里同时改变的是一个或多个目录及其文件的权限。

        9.package_extract_file(srcfile_path,desfile_paht):srcfile_path,要提取的文件,desfile_path,提取文件的目标位置。示例:package_extract_file(“boot.img”,”/tmp/boot.img”)将升级包中的boot.img文件拷贝到内存文件系统的/tmp下。

      10.write_raw_image(src-image,partition):src-image源镜像文件,partition,目标分区。作用:将镜像写入目标分区。示例:write_raw_image(“/tmp/boot.img”,”boot”)将boot.img镜像写入到系统的boot分区。

      11.getprop(key):通过指定key的值来获取对应的属性信息。示例:getprop(“ro.product.device”)获取ro.product.device的属性值。

     12. ui_print(String): 用于在Flash Mode要显示的内容

     13. delete(FilePath): 用于删除文件的命令

     14. run_program(Shell, ScriptPath): 例如:run_program("/sbin/sh", "/system/bin/install.sh");

     15. umount(Path): 卸载文件系统

     16. cmdlist:

is_mounted
unmount
format
show_progress
set_progress
delete
delete_recursive
package_extract_dir
package_extract_file
retouch_binaries
undo_retouch_binaries
symlink
set_perm
set_perm_recursive
getprop
file_getprop
write_raw_image
apply_patch
apply_patch_check
apply_patch_space
read_file
sha1_check
wipe_cache
ui_print
run_program
set_bootloader_env

 

二、updater-script脚本执行流程分析:

          先看一下在测试过程中用命令make otapackage生成的升级脚本如下:

assert(!less_than_int(1331176658, getprop("ro.build.date.utc")));
assert(getprop("ro.product.device") == "tcc8800" ||
       getprop("ro.build.product") == "tcc8800");
show_progress(0.500000, 0);
format("yaffs2", "MTD", "system");
mount("yaffs2", "MTD", "system", "/system");
package_extract_dir("recovery", "/system");
package_extract_dir("system", "/system");
symlink("busybox", "/system/bin/cp", "/system/bin/grep",
        "/system/bin/tar", "/system/bin/unzip",
        "/system/bin/vi");
symlink("toolbox", "/system/bin/cat", "/system/bin/chmod",
        "/system/bin/chown", "/system/bin/cmp", "/system/bin/date",
        "/system/bin/dd", "/system/bin/df", "/system/bin/dmesg",
        "/system/bin/getevent", "/system/bin/getprop", "/system/bin/hd",
        "/system/bin/id", "/system/bin/ifconfig", "/system/bin/iftop",
        "/system/bin/insmod", "/system/bin/ioctl", "/system/bin/ionice",
        "/system/bin/kill", "/system/bin/ln", "/system/bin/log",
        "/system/bin/ls", "/system/bin/lsmod", "/system/bin/lsof",
        "/system/bin/mkdir", "/system/bin/mount", "/system/bin/mv",
        "/system/bin/nandread", "/system/bin/netstat",
        "/system/bin/newfs_msdos", "/system/bin/notify", "/system/bin/printenv",
        "/system/bin/ps", "/system/bin/reboot", "/system/bin/renice",
        "/system/bin/rm", "/system/bin/rmdir", "/system/bin/rmmod",
        "/system/bin/route", "/system/bin/schedtop", "/system/bin/sendevent",
        "/system/bin/setconsole", "/system/bin/setprop", "/system/bin/sleep",
        "/system/bin/smd", "/system/bin/start", "/system/bin/stop",
        "/system/bin/sync", "/system/bin/top", "/system/bin/umount",
        "/system/bin/uptime", "/system/bin/vmstat", "/system/bin/watchprops",
        "/system/bin/wipe");
set_perm_recursive(0, 0, 0755, 0644, "/system");
set_perm_recursive(0, 2000, 0755, 0755, "/system/bin");
set_perm(0, 3003, 02750, "/system/bin/netcfg");
set_perm(0, 3004, 02755, "/system/bin/ping");
set_perm(0, 2000, 06750, "/system/bin/run-as");
set_perm_recursive(1002, 1002, 0755, 0440, "/system/etc/bluetooth");
set_perm(0, 0, 0755, "/system/etc/bluetooth");
set_perm(1000, 1000, 0640, "/system/etc/bluetooth/auto_pairing.conf");
set_perm(3002, 3002, 0444, "/system/etc/bluetooth/blacklist.conf");
set_perm(1002, 1002, 0440, "/system/etc/dbus.conf");
set_perm(1014, 2000, 0550, "/system/etc/dhcpcd/dhcpcd-run-hooks");
set_perm(0, 2000, 0550, "/system/etc/init.goldfish.sh");
set_perm(0, 0, 0544, "/system/etc/install-recovery.sh");
set_perm_recursive(0, 0, 0755, 0555, "/system/etc/ppp");
set_perm_recursive(0, 2000, 0755, 0755, "/system/xbin");
set_perm(0, 0, 06755, "/system/xbin/librank");
set_perm(0, 0, 06755, "/system/xbin/procmem");
set_perm(0, 0, 06755, "/system/xbin/procrank");
set_perm(0, 0, 06755, "/system/xbin/su");
set_perm(0, 0, 06755, "/system/xbin/tcpdump");
show_progress(0.200000, 0);
show_progress(0.200000, 10);
assert(package_extract_file("boot.img", "/tmp/boot.img"),
       write_raw_image("/tmp/boot.img", "boot"),
       delete("/tmp/boot.img"));
show_progress(0.100000, 0);
unmount("/system");

下面分析下这个脚本的执行过程:

         ①比较时间戳:如果升级包较旧则终止脚本的执行。

         ②匹配设备信息:如果和当前的设备信息不一致,则停止脚本的执行。

         ③显示进度条:如果以上两步匹配则开始显示升级进度条。

         ④格式化system分区并挂载。

         ⑤提取包中的recovery以及system目录下的内容到系统的/system下。

         ⑥为/system/bin/下的命令文件建立符号连接。

         ⑦设置/system/下目录以及文件的属性。

         ⑧将包中的boot.img提取到/tmp/boot.img。

         ⑨将/tmp/boot.img镜像文件写入到boot分区。

         ⑩完成后卸载/system。

         以上就是updater-script脚本中的语法,及其执行的具体过程。通过分析其执行流程,我们可以发现在执行过程中,并未将升级包另外解压到一个地方,而是需要什么提取什么。值得主要的是在提取recovery和system目录中的内容时,一并放在了/system/下。在操作的过程中,并未删除或改变update.zip包中的任何内容。在实际的更新完成后,我们的update.zip包确实还存在于原来的位置。

 

三、总结

        以上的九篇着重分析了Android系统中Recovery模式中的一种,即我们做好的update.zip包在系统更新时所走过的流程。其核心部分就是Recovery服务的工作原理。其他两种FACTORY RESET、ENCRYPTED FILE SYSTEM ENABLE/DISABLE与OTA INSTALL是相通的。重点是要理解Recovery服务的工作原理。另外详细分析其升级过程,对于我们在实际升级时,可以根据我们的需要做出相应的修改。

http://blog.csdn.net/tody_guo/article/details/7948083

 

时间: 2024-08-02 21:58:29

Android系统Recovery工作原理之使用update.zip升级过程---updater-script脚本语法简介以及执行流程(转)的相关文章

深入了解SQL Server系统数据库工作原理

数据库管理员(DBA)的一项基本的技能是对SQL数据库引擎的系统数据库的深刻理解.数据库开发人员了解SQLSERVER自带的系统数据库也是十分有用的.下面就列出了其中的一些系统数据库.(注:如果你决定研究一下这些系统数据库,那么你需要有一个开发数据库.) Master Master数据库保存有放在SQLSERVER实体上的所有数据库,它还是将引擎固定起来的粘合剂.由于如果不使用主数据库,SQLSERVER就不能启动,所以你必须要小心地管理好这个数据库.因此,对这个数据库进行常规备份是十分必要的.

数字基带系统的工作原理

  数字基带传输系统的基本组成框图如图 4-9 所示,它通常由脉冲形成器.发送滤波器.信道.接收滤波器.抽样判决器与码元再生器组成.系统工作过程及各部分作用如下.     图 4-9 数字基带传输系统方框图 脉冲形成器输入的是由电传机.计算机等终端设备发送来的二进制数据序列或是经模数转换后的二进制(也可是多进制)脉冲序列,它们一般是脉冲宽度为 的单极性 NRZ 码,如图 4-10 ( a )波形 所示.根据上节对单极性码讨论的结果可知, 并不适合信道传输. 脉冲形成器的作用是将 变换成为比较适合

剖析Memcached分布式内存对象缓存系统的工作原理

风信网(ithov.com)原创文章:Memcached是一种C/S模式,在服务器端启动服务守护进程,此时可以指定监听的IP地址.端口号以及使用多少内存来处理客户端的请求等几个关键参数.服务器端的服务启动后就一直处于等待处理客户端的连接状态.Memcached是由C语言来实现的,采用的是异步I/O,其实现方式是基于事件的单进程和单线程的.使用libevent作为事件通知机制,多个服务器端可以http://www.aliyun.com/zixun/aggregation/18521.html"&g

Android应用性能优化最佳实践.2.1 Android系统显示原理

绘?制?优?化 Android应用启动慢,使用时经常卡顿,是非常影响用户体验的,应该尽量避免出现.卡顿的场景有很多,按场景可以分成4类:UI绘制.应用启动.页面跳转.事件响应,如 图2-1所示.在这四种场景下又有多个小分类,基本上覆盖了卡顿的各个场景.   图2-1 卡顿主要场景 这4种卡顿场景的根本原因又可以分成两大类. 界面绘制:主要原因是绘制的层级深.页面复杂.刷新不合理,由于这些原因导致卡顿的场景更多出现在UI和启动后的初始界面以及跳转到页面的绘制上. 数据处理:导致这种卡顿场景的原因是

Android系统进程间通信(IPC)机制Binder中的Client获得Server远程接口过程源代码分析_Android

     在上一篇文章中,我们分析了Android系统进程间通信机制Binder中的Server在启动过程使用Service Manager的addService接口把自己添加到Service Manager守护过程中接受管理.在这一篇文章中,我们将深入到Binder驱动程序源代码去分析Client是如何通过Service Manager的getService接口中来获得Server远程接口的.Client只有获得了Server的远程接口之后,才能进一步调用Server提供的服务.       

apply sdcard:update.zip是什么意思

一般官方的Recovery都会有apply sdcard:update.zip(刷ROM升级包)的选项 Android system recovery <3e>: rebott system now:重启系统 apply sdcard:update.zip:刷ROM包 wipe data/factory reset:恢复出厂值 wipe cache partition:清除分区缓存 apply sdcard:update.zip是刷ROM升级包的选项,如果你要刷机(就好比电脑上重装系统)就可以

Android中新引进的Google Authenticator验证系统工作原理浅析

为了改进Android的安全问题,Google在Android系统中引入了谷歌验证应用(Google Authenticator)来保证账号的安全.谷歌验证应用的使用方法是:用户安装手机客户端,生成临时身份验证码,提交到服务器验证身份,类似的验证系统还有Authy.Robbie在其GitHub页面发布了自己用Go语言实现的版本,并撰写了一篇博文来解释其工作原理. 通常来讲,身份验证系统都实现了基于时间的一次性密码算法,即著名的TOTP(Time-Based One-Time Password).

Uber首席系统架构师Matt Ranney:可伸缩的软件系统工作原理

据报导,在短短四年间,Uber已经惊人地增长了38倍.现在,Uber的首席系统架构师Matt Ranney 在他的报告"可伸缩Uber实时市场平台"中,对Uber软件系统的工作原理进行了一个有趣而又详细的介绍. 如果你对Uber迅猛增长的单价感兴趣,这个并没有在报告中涉及.但是我们可以了解Uber的调度系统,怎样实行地理空间索引,怎样规划他们的系统,怎样实行高利用率和怎样处理失败,包括令人惊讶的方式处理数据中心故障,使用驱动的手机作为恢复外部分布式存储系统. 在Matt的报告中,给人印

Android系统Root原理初探(转)

  http://www.imooc.com/learn/126             chkconfig setup                 解压update.zip这个文件,可发现它一般打包了如下这几个文件: 或者没有updates而是system这个目录,不同的原因是我这里在updates里放置的是system.img等镜像文件,这些文件都由源码编译而来.而如果是system目录,这里一般放的是android系统的system目录下的内容,可以是整个android系统的syste