2023年7月23日发(作者：)

（九）---updater-script脚本语法简介以及执行流程

分类： Andriod2012-04-16 14:24 8888人阅读 评论(23) 收藏 举报

脚本android工作symlinksystempath

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

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

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

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

(condition)：如果condition参数的计算结果为False，则停止脚本执行，否则继续执行脚本。

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

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

(fs_type,partition_type,location,mount_point)：前两个参数同上，location要挂载的设备，mount_point挂载点。作用：挂载一个文件系统到指定的挂载点。 e_extract_dir(src_path,destination_path)：src_path，要提取的目录，destination_path目标目录。作用：从升级包内，提取目录到指定的位置。示例：package_extract_dir(“system”,”/system”)。

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

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

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

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

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

p(key)：通过指定key的值来获取对应的属性信息。示例：getprop(“”)获取的属性值。 二、updater-script脚本执行流程分析：

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

[plain] view plaincopy

1. assert(!less_than_int(1331176658, getprop("")));

2. assert(getprop("") == "tcc8800" ||

3. getprop("t") == "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_");

39. set_perm(3002, 3002, 0444, "/system/etc/bluetooth/");

40. set_perm(1002, 1002, 0440, "/system/etc/");

41. set_perm(1014, 2000, 0550, "/system/etc/dhcpcd/dhcpcd-run-hooks");

42. set_perm(0, 2000, 0550, "/system/etc/");

43. set_perm(0, 0, 0544, "/system/etc/");

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("", "/tmp/"),

54. write_raw_image("/tmp/", "boot"),

55. delete("/tmp/"));

56. show_progress(0.100000, 0);

57. unmount("/system");

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

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

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

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

④格式化system分区并挂载。 ⑤提取包中的recovery以及system目录下的内容到系统的/system下。

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

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

⑧将包中的提取到/tmp/。

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

⑩完成后卸载/system。

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

三、总结

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

不足之处，请大家不吝指正！