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



    http://blog.csdn.net/mu0206mu/article/details/7465603


           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的属性值。

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

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

    1. assert(!less_than_int(1331176658, getprop("ro.build.date.utc")));  
    2. assert(getprop("ro.product.device") == "tcc8800" ||  
    3.        getprop("ro.build.product") == "tcc8800");  
    4. show_progress(0.500000, 0);  
    5. format("yaffs2", "MTD", "system");  
    6. mount("yaffs2", "MTD", "system", "/system");  
    7. package_extract_dir("recovery", "/system");  
    8. package_extract_dir("system", "/system");  
    9. symlink("busybox", "/system/bin/cp", "/system/bin/grep",  
    10.         "/system/bin/tar", "/system/bin/unzip",  
    11.         "/system/bin/vi");  
    12. symlink("toolbox", "/system/bin/cat", "/system/bin/chmod",  
    13.         "/system/bin/chown", "/system/bin/cmp", "/system/bin/date",  
    14.         "/system/bin/dd", "/system/bin/df", "/system/bin/dmesg",  
    15.         "/system/bin/getevent", "/system/bin/getprop", "/system/bin/hd",  
    16.         "/system/bin/id", "/system/bin/ifconfig", "/system/bin/iftop",  
    17.         "/system/bin/insmod", "/system/bin/ioctl", "/system/bin/ionice",  
    18.         "/system/bin/kill", "/system/bin/ln", "/system/bin/log",  
    19.         "/system/bin/ls", "/system/bin/lsmod", "/system/bin/lsof",  
    20.         "/system/bin/mkdir", "/system/bin/mount", "/system/bin/mv",  
    21.         "/system/bin/nandread", "/system/bin/netstat",  
    22.         "/system/bin/newfs_msdos", "/system/bin/notify", "/system/bin/printenv",  
    23.         "/system/bin/ps", "/system/bin/reboot", "/system/bin/renice",  
    24.         "/system/bin/rm", "/system/bin/rmdir", "/system/bin/rmmod",  
    25.         "/system/bin/route", "/system/bin/schedtop", "/system/bin/sendevent",  
    26.         "/system/bin/setconsole", "/system/bin/setprop", "/system/bin/sleep",  
    27.         "/system/bin/smd", "/system/bin/start", "/system/bin/stop",  
    28.         "/system/bin/sync", "/system/bin/top", "/system/bin/umount",  
    29.         "/system/bin/uptime", "/system/bin/vmstat", "/system/bin/watchprops",  
    30.         "/system/bin/wipe");  
    31. set_perm_recursive(0, 0, 0755, 0644, "/system");  
    32. set_perm_recursive(0, 2000, 0755, 0755, "/system/bin");  
    33. set_perm(0, 3003, 02750, "/system/bin/netcfg");  
    34. set_perm(0, 3004, 02755, "/system/bin/ping");  
    35. set_perm(0, 2000, 06750, "/system/bin/run-as");  
    36. set_perm_recursive(1002, 1002, 0755, 0440, "/system/etc/bluetooth");  
    37. set_perm(0, 0, 0755, "/system/etc/bluetooth");  
    38. set_perm(1000, 1000, 0640, "/system/etc/bluetooth/auto_pairing.conf");  
    39. set_perm(3002, 3002, 0444, "/system/etc/bluetooth/blacklist.conf");  
    40. set_perm(1002, 1002, 0440, "/system/etc/dbus.conf");  
    41. set_perm(1014, 2000, 0550, "/system/etc/dhcpcd/dhcpcd-run-hooks");  
    42. set_perm(0, 2000, 0550, "/system/etc/init.goldfish.sh");  
    43. set_perm(0, 0, 0544, "/system/etc/install-recovery.sh");  
    44. set_perm_recursive(0, 0, 0755, 0555, "/system/etc/ppp");  
    45. set_perm_recursive(0, 2000, 0755, 0755, "/system/xbin");  
    46. set_perm(0, 0, 06755, "/system/xbin/librank");  
    47. set_perm(0, 0, 06755, "/system/xbin/procmem");  
    48. set_perm(0, 0, 06755, "/system/xbin/procrank");  
    49. set_perm(0, 0, 06755, "/system/xbin/su");  
    50. set_perm(0, 0, 06755, "/system/xbin/tcpdump");  
    51. show_progress(0.200000, 0);  
    52. show_progress(0.200000, 10);  
    53. assert(package_extract_file("boot.img", "/tmp/boot.img"),  
    54.        write_raw_image("/tmp/boot.img", "boot"),  
    55.        delete("/tmp/boot.img"));  
    56. show_progress(0.100000, 0);  
    57. 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服务的工作原理。另外详细分析其升级过程,对于我们在实际升级时,可以根据我们的需要做出相应的修改。

             不足之处,请大家不吝指正!



  • 相关阅读:
    C#:反射
    静态和非静态类
    数据的存入取出(注册机方式)
    退出unity运行
    网络流基础
    欧拉回路
    博弈论问题
    洛谷P5304 [GXOI/GZOI2019] 旅行者
    [ZJOI2006]物流运输
    POJ3278 Catch that cow
  • 原文地址:https://www.cnblogs.com/ztguang/p/12645423.html
Copyright © 2020-2023  润新知