モジュール開発ガイド​

大部分の内容において、ShiroSU はMagiskとKernelSUとほぼ同じです。ここでは異なる点のみを紹介します。

Systemless^[1]​

ShiroSU の Systemless は、Magisk に類似したマウントメカニズムであり、そのインターフェースは.replaceの用法など、Magisk と完全に互換性があります。ただし、ShiroSU のマウントメカニズムは互換性が高く、動的なパーティション認識に基づいています。つまり、モジュールはodmなど、他の root 実装ではマウントできないパーティションを直接 Systemless でマウントでき、そのために余分な労力を費やす必要はありません。

さらに、より高い安全性を確保するために、ShiroSU の Systemless は、モジュールがマウントするファイル/ディレクトリの SELinux コンテキスト、ディレクトリの権限、およびファイル/ディレクトリのユーザー/グループを無視します。ファイルが存在しないディレクトリにマウントされた場合、そのSELinux コンテキスト、権限、ユーザー/グループは親ディレクトリから継承されます。通常、これらの動作はモジュールの実行に影響を与えず、むしろ安定性の向上に役立ちます。

Shell​

ShiroSU は、この点で他の root 実装とは大きく異なります。ShiroSU で実行される Shell スクリプトは、デフォルトではBusyBoxで "独立モード" で実行されません。

Shell スクリプトの開発を容易にするために、ShiroSU はsush(Rust で記述されたBash) を使用して Shell スクリプトを実行し、uutils(Rust で記述されたcoreutils) のコマンドセットを優先的に使用し、Magisk の BusyBox を代替として使用します。つまり、コマンドは最初に uutils から取得され、存在しないコマンドのみが BusyBox から取得されます。

BusyBox で "独立モード" で実行されないため、コマンドはPATH環境変数を介して注入されます。モジュールの Shell スクリプト内でPATHをハードコーディングして変更しないでください！

環境変数​

区別を容易にするために、ShiroSU はモジュールの実行時に以下の変数を注入します。

• SSU(ブール値): ShiroSU 環境で実行されている場合、この値はtrueになります。ただし、$SSU && # code ...を使用してコードを実行できるわけではありません。常に[ "$SSU" = true ]または同様の方法を使用して ShiroSU を検出する必要があります。
• SSU_VER(文字列): ShiroSU のバージョン番号 (パッチ番号は含まれません)
• SSU_VER_CODE(整数値): ShiroSU の純粋な数値バージョン番号 (パッチ番号を含む)

Recovery​

ShiroSU は Recovery を介したモジュールのインストールをサポートしていません。モジュールのインストール時にMETA-INF/com/google/android/update-binary内のコードは実行されません。

SU 呼び出し​

ShiroSU の SU 実装には、デフォルトで Shell コマンドを直接実行するためだけに使用できるsudoが付属しています。たとえば、sudo ls /を実行できます。

sudoは、簡素化されたsu -cの代替としてのみ存在しますが、モジュール内でsudoまたはsu -cを使用して Shell コマンドを実行するべきではありません！

同様に、モジュールはハードコーディングによってコマンドを取得するべきではありません。たとえば、/data/adb/ssu/bin/busybox crondなどです。BusyBox の "独立モード" であっても、PATHを介してコマンドが直接注入されていても、コマンドはすでに直接呼び出すことができ、ハードコーディングされた手動取得は不要です。

ANSI エスケープコード^[2]​

ShiroSU では、module.propまたは Shell スクリプトでANSI エスケープコードを使用してテキストの表示を豊かにすることができます。たとえば、module.propで次のコードを使用できます。

id=ssu_cmd_ext
name=Command Set Extension
version=Auto-generated by SSU
versionAnsi=\e[1mAuto-generated\e[0m by SSU
versionCode=1
author=SSU Developers (OOM. WG.)
description=Add coreutils, busybox, and bash to /system/bin.
descriptionAnsi=Add \e[1mcoreutils, busybox, and bash\e[0m to \e[1m/system/bin\e[0m.

上記のmodule.propを使用すると、モジュールが ShiroSU マネージャーに表示されるときに、Auto-generated、coreutils, busybox, and bash、および/system/binが太字で表示されます。

module.propでは、nameAnsi、versionAnsi、authorAnsi、およびdescriptionAnsiを使用して、ANSI エスケープコードを含むテキストを表示できます。

Ansiサフィックスが含まれていなくても使用できますが、互換性を確保するために、そうしてください。

ShiroSU はmodule.propの内容を順番に解析して読み取るため、Ansiサフィックスを含む値が後にあることを確認してください。

モジュール WebUI​

ShiroSU とKernelSUも同様に、モジュールが WebUI を使用して機能を提供することを許可しています。詳細については、モジュール WebUIを参照してください。

module.prop​

ShiroSU マネージャーには、module.propが破損しているか、仕様に準拠しているかを検出するメカニズムがあります。破損しているか、仕様に準拠していない場合、ShiroSU マネージャーはそのモジュールの上部にラベルを表示します。

ShiroSU マネージャーは、具体的に次の内容を検出します。

• module.prop内に構文に準拠しないコンテンツが含まれているかどうか
• id、name、version、author、descriptionが空かどうか (Ansiサフィックスが付いている場合も同様に検出)
• idが次の正規表現に準拠しているかどうか:^[a-zA-Z][a-zA-Z0-9._-]+$
• versionCodeが0より大きいかどうか
• module.prop内に大文字と小文字の区別が正しくない箇所があるかどうか (ShiroSU マネージャーは正常に解析しますが、ラベルは表示されます)

module.propが破損しているだけの場合は、モジュールを再インストールすることで通常この問題を解決できます。仕様に準拠していない場合は、開発者が自分で修正してこの問題を解決する必要があります。

カーネルインターフェース​

ShiroSU は/data/adb/ssu/._settingsをカーネル設定ディレクトリとして使用します。通常、次のファイルが含まれます。

• ._su_list: スーパーユーザー権限の使用を許可されたリスト
• ._bypass_list: SELinux 制限をバイパスするリスト
• ._hide_list: root 使用の痕跡を隠す必要があるリスト

上記のファイルはすべて、バイナリ UID(32 ビット整数) +\0+パッケージ名形式で保存され、複数の値は\nで区切られます

その他の違い​

ShiroSU は、今後のアップデートでモジュールバックアップインターフェース、モジュール更新インターフェース (更新時に元のモジュールのコードを実行)、モジュールストレージインターフェースなどの機能を提供する予定です。これらの内容はまだ計画段階であり、今後のアップデートでリリースされます。

Contributors

白彩恋 YumeYuka

Changelog