[セットトップ]AndroidシステムRecoveryの動作原理update.zipアップグレードプロセス分析(9)---updater-scriptスクリプト構文の概要と実行プロセス
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、ファイルシステムタイプ、値は一般的に「yaffs 2」または「ext 4」です.Partition_type、パーティションタイプ、一般的には「MTD」または「EMMC」の値をとる.主に指定されたファイルシステムにフォーマットされます.事例はformat("yaffs 2","MTD","system")である.
4.mount(fs_type,partition_type,location,mount_point):最初の2つのパラメータが同じで、locationがマウントするデバイス、mount_ポイントマウントポイント.役割:指定したマウントポイントにファイルシステムをマウントします.
5.package_extract_dir(src_path,destination_path):src_Path、抽出するディレクトリ、destination_pathターゲットディレクトリ.≪アクション|Actions|emdw≫:アップグレード・パッケージから、ディレクトリを指定した場所に抽出します.例:package_extract_dir(“system”,”/system”).
6.symlink(target,src 1,src 2,......,srcN):target、文字列タイプ、シンボル接続のターゲットです.SrcXは、作成するシンボル接続のターゲットポイントを表します.例:symlink(「toolbox」/system/bin/ps」)は、toolboxシンボルへの接続/system/bin/psを確立します.新しいシンボル接続を確立する前に、既存のシンボル接続を切断することに注意してください.
7.set_perm(uid,gid,mode,file 1,file 2,......,file N):単一ファイルまたは一連のファイルの権限を設定し、少なくとも1つのファイルを指定する役割を果たします.
8.set_perm_recursive(uid,gid,mode,dir 1,dir 2,......,dirN):役割は同じですが、ここで同時に変更されるのは1つ以上のディレクトリとそのファイルの権限です.
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で生成されたアップグレードスクリプトを見てみましょう.
このスクリプトの実行手順を分析します.
①タイムスタンプの比較:アップグレードパッケージが古い場合は、スクリプトの実行を終了します.
②デバイス情報の照合:現在のデバイス情報と一致しない場合は、スクリプトの実行を停止します.
③進捗バーの表示:上記2ステップが一致している場合は、進捗バーの表示を開始します.
④システムパーティションをフォーマットしてマウントする.
⑤パケット内の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パッケージは確かに元の場所に存在します.
三、まとめ
以上の9編では、AndroidシステムにおけるRecoveryモードの1つ、すなわち、私たちが作成したupdate.zipパッケージがシステム更新時に歩んできた流れを重点的に分析しました.その核心部分がRecoveryサービスの仕組みです.他の2種類のFACTORY RESET、ENCRYPTED FILE SYSTEM ENABLE/DISABLEはOTA INSTALLに通じている.ポイントは、Recoveryサービスの仕組みを理解することです.また、そのアップグレードプロセスを詳細に分析すると、実際にアップグレードするときに、必要に応じて修正することができます.
足りないところは,皆さんご指摘を惜しまないでください.
現在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、ファイルシステムタイプ、値は一般的に「yaffs 2」または「ext 4」です.Partition_type、パーティションタイプ、一般的には「MTD」または「EMMC」の値をとる.主に指定されたファイルシステムにフォーマットされます.事例はformat("yaffs 2","MTD","system")である.
4.mount(fs_type,partition_type,location,mount_point):最初の2つのパラメータが同じで、locationがマウントするデバイス、mount_ポイントマウントポイント.役割:指定したマウントポイントにファイルシステムをマウントします.
5.package_extract_dir(src_path,destination_path):src_Path、抽出するディレクトリ、destination_pathターゲットディレクトリ.≪アクション|Actions|emdw≫:アップグレード・パッケージから、ディレクトリを指定した場所に抽出します.例:package_extract_dir(“system”,”/system”).
6.symlink(target,src 1,src 2,......,srcN):target、文字列タイプ、シンボル接続のターゲットです.SrcXは、作成するシンボル接続のターゲットポイントを表します.例:symlink(「toolbox」/system/bin/ps」)は、toolboxシンボルへの接続/system/bin/psを確立します.新しいシンボル接続を確立する前に、既存のシンボル接続を切断することに注意してください.
7.set_perm(uid,gid,mode,file 1,file 2,......,file N):単一ファイルまたは一連のファイルの権限を設定し、少なくとも1つのファイルを指定する役割を果たします.
8.set_perm_recursive(uid,gid,mode,dir 1,dir 2,......,dirN):役割は同じですが、ここで同時に変更されるのは1つ以上のディレクトリとそのファイルの権限です.
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で生成されたアップグレードスクリプトを見てみましょう.
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");
このスクリプトの実行手順を分析します.
①タイムスタンプの比較:アップグレードパッケージが古い場合は、スクリプトの実行を終了します.
②デバイス情報の照合:現在のデバイス情報と一致しない場合は、スクリプトの実行を停止します.
③進捗バーの表示:上記2ステップが一致している場合は、進捗バーの表示を開始します.
④システムパーティションをフォーマットしてマウントする.
⑤パケット内の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パッケージは確かに元の場所に存在します.
三、まとめ
以上の9編では、AndroidシステムにおけるRecoveryモードの1つ、すなわち、私たちが作成したupdate.zipパッケージがシステム更新時に歩んできた流れを重点的に分析しました.その核心部分がRecoveryサービスの仕組みです.他の2種類のFACTORY RESET、ENCRYPTED FILE SYSTEM ENABLE/DISABLEはOTA INSTALLに通じている.ポイントは、Recoveryサービスの仕組みを理解することです.また、そのアップグレードプロセスを詳細に分析すると、実際にアップグレードするときに、必要に応じて修正することができます.
足りないところは,皆さんご指摘を惜しまないでください.