android/SukiSU-Ultra
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

add main branch files

Browse Source
This commit is contained in:
樱檩殇雪
2025-03-17 02:38:37 +08:00
commit a6e3221bdc
360 changed files with 44453 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

26
website/docs/ja_JP/guide/difference-with-magisk.md Normal file
View File

@@ -0,0 +1,26 @@
# Magisk との違い
KernelSU モジュールと Magisk モジュールには多くの共通点がありますが、実装の仕組みが全く異なるため、必然的にいくつかの相違点が存在します。Magisk と KernelSU の両方でモジュールを動作させたい場合、これらの違いを理解する必要があります。
## 似ているところ
- モジュールファイルの形式：どちらもzip形式でモジュールを整理しており、モジュールの形式はほぼ同じです。
- モジュールのインストールディレクトリ：どちらも `/data/adb/modules` に配置されます。
- システムレス：どちらもモジュールによるシステムレスな方法で /system を変更できます。
- post-fs-data.sh: 実行時間と意味は全く同じです。
- service.sh: 実行時間と意味は全く同じです。
- system.prop：全く同じです。
- sepolicy.rule：全く同じです。
- BusyBox：スクリプトは BusyBox で実行され、どちらの場合も「スタンドアロンモード」が有効です。
## 違うところ
違いを理解する前に、モジュールが KernelSU で動作しているか Magisk で動作しているかを区別する方法を知っておく必要があります。環境変数 `KSU` を使うとモジュールスクリプトを実行できるすべての場所 (`customize.sh`, `post-fs-data.sh`, `service.sh`) で区別できます。KernelSU では、この環境変数に `true` が設定されます。
以下は違いです：
- KernelSU モジュールは、リカバリーモードではインストールできません。
- KernelSU モジュールには Zygisk のサポートが組み込まれていません（ただし[ZygiskNext](https://github.com/Dr-TSNG/ZygiskNext)を使うと Zygisk モジュールを使用できます）。
- KernelSU モジュールにおけるファイルの置換や削除の方法は、Magisk とは全く異なります。KernelSU は `.replace` メソッドをサポートしていません。その代わり、`mknod filename c 0 0` で同名のファイルを作成し、対応するファイルを削除する必要があります。
- BusyBox 用のディレクトリが違います。KernelSU の組み込み BusyBox は `/data/adb/ksu/bin/busybox` に、Magisk では `/data/adb/magisk/busybox` に配置されます。**これは KernelSU の内部動作であり、将来的に変更される可能性があることに注意してください!**
- KernelSU は `.replace` ファイルをサポートしていません。しかし、KernelSU はファイルやフォルダを削除したり置き換えたりするための `REMOVE` と `REPLACE` 変数をサポートしています。

67
website/docs/ja_JP/guide/faq.md Normal file
View File

@@ -0,0 +1,67 @@
# よくある質問
## 私のデバイスは KernelSU に対応していますか?
まず、お使いのデバイスがブートローダーのロックを解除できる必要があります。もしできないのであれば、サポート外です。
もし KernelSU アプリで「非対応」と表示されたら、そのデバイスは最初からサポートされていないことになりますが、カーネルソースをビルドして KernelSU を組み込むか、[非公式の対応デバイス](unofficially-support-devices)で動作させることが可能です。
## KernelSU を使うにはブートローダーのロックを解除する必要がありますか？
はい。
## KernelSU はモジュールに対応していますか?
はい。ただし初期バージョンであるためバグがある可能性があります。安定するのをお待ちください。
## KernelSU は Xposed に対応していますか?
はい。[Dreamland](https://github.com/canyie/Dreamland) や [TaiChi](https://taichi.cool) が動作します。LSPosed については、[ZygiskNext](https://github.com/Dr-TSNG/ZygiskNext) を使うと動作するようにできます。
## KernelSU は Zygisk に対応していますか?
KernelSU は Zygisk サポートを内蔵していません。[ZygiskNext](https://github.com/Dr-TSNG/ZygiskNext) を使ってください。
## KernelSU は Magisk と互換性がありますか?
KernelSU のモジュールシステムは Magisk のマジックマウントと競合しており、KernelSU で有効になっているモジュールがある場合、Magisk 全体が動作しなくなります。
しかし、KernelSU の `su` だけを使うのであれば、Magisk とうまく連携することができます。KernelSU は `kernel` を、Magisk は `ramdisk` を修正するため、両者は共存できます。
## KernelSU は Magisk の代わりになりますか？
私たちはそうは思っていませんし、それが目標でもありません。Magisk はユーザ空間の root ソリューションとして十分であり、長く使われ続けるでしょう。KernelSU の目標は、ユーザーにカーネルインターフェースを提供することであり、Magisk の代用ではありません。
## KernelSU は GKI 以外のデバイスに対応できますか？
可能です。ただしカーネルソースをダウンロードし、KernelSU をソースツリーに統合して、自分でカーネルをビルドする必要があります。
## KernelSU は Android 12 以下のデバイスに対応できますか？
KernelSU の互換性に影響を与えるのはデバイスのカーネルであり、Android のバージョンとは無関係です。唯一の制限は、Android 12 で発売されたデバイスはカーネル5.10以上（GKI デバイス）でなければならないことです：
1. Android 12 をプリインストールして発売された端末は対応しているはずです。
2. カーネルが古い端末（一部の Android 12 端末はカーネルも古い）は対応可能ですが、カーネルは自分でビルドする必要があります。
## KernelSU は古いカーネルに対応できますか？
KernelSU は現在カーネル4.14にバックポートされていますが、それ以前のカーネルについては手動でバックポートする必要があります。プルリクエスト歓迎です！
## 古いカーネルに KernelSU を組み込むには？
[ガイド](../../guide/how-to-integrate-for-non-gki) を参考にしてください。
## Android のバージョンが13なのに、カーネルは「android12-5.10」と表示されるのはなぜ？
カーネルのバージョンは Android のバージョンと関係ありません。カーネルを書き込む必要がある場合は、常にカーネルのバージョンを使用してください。Android のバージョンはそれほど重要ではありません。
## KernelSU に-mount-master/global のマウント名前空間はありますか？
今はまだありませんが（将来的にはあるかもしれません）、グローバルマウントの名前空間に手動で切り替える方法は、以下のようにたくさんあります：
1. `nsenter -t 1 -m sh` でシェルをグローバル名前空間にします。
2. `nsenter --mount=/proc/1/ns/mnt` を実行したいコマンドに追加すればグローバル名前空間で実行されます。 KernelSU は [このような使い方](https://github.com/tiann/KernelSU/blob/77056a710073d7a5f7ee38f9e77c9fd0b3256576/manager/app/src/main/java/shirkneko/zako/mksu/ui/util/KsuCli.kt#L115) もできます。
## GKI 1.0 なのですが、使えますか？
GKI1 は GKI2 と全く異なるため、カーネルは自分でビルドする必要があります。

7
website/docs/ja_JP/guide/hidden-features.md Normal file
View File

@@ -0,0 +1,7 @@
# 隠し機能
## .ksurc
デフォルトでは `/system/bin/sh` は `/system/etc/mkshrc` を読み込みます。
`/data/adb/ksu/.ksurc` ファイルを作成することで、カスタマイズした rc ファイルを su に読み込ませられます。

58
website/docs/ja_JP/guide/how-to-build.md Normal file
View File

@@ -0,0 +1,58 @@
# KernelSU のビルド方法は？
まず、Android の公式ドキュメントを読むべきです：
1. [カーネルをビルドする](https://source.android.com/docs/setup/build/building-kernels)
2. [GKI リリースビルド](https://source.android.com/docs/core/architecture/kernel/gki-release-builds)
::: 警告
このページは GKI デバイス用です。もし古いカーネルを使用している場合は、[古いカーネルへの KernelSU の統合方法](how-to-integrate-for-non-gki)を参照してください。
:::
## カーネルビルド
### カーネルソースコードの同期
```sh
repo init -u https://android.googlesource.com/kernel/manifest
mv <kernel_manifest.xml> .repo/manifests
repo init -m manifest.xml
repo sync
```
`<kernel_manifest.xml>` は、ビルドを一意に決定するマニフェストファイルです。マニフェストを使用して再現可能なビルドを行えます。マニフェストファイルは [Google GKI リリースビルド](https://source.android.com/docs/core/architecture/kernel/gki-release-builds) からダウンロードしてください。
### ビルド
まずは [公式ドキュメント](https://source.android.com/docs/setup/build/building-kernels)を確認してください。
たとえば、aarch64 カーネルイメージをビルドする必要があります：
```sh
LTO=thin BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
```
`LTO=thin` フラグを追加するのを忘れないでください。それをしないと、コンピュータのメモリが 24Gb 未満の場合にビルドに失敗する可能性があります。
Android 13 からは、カーネルは `bazel` によってビルドされます：
```sh
tools/bazel build --config=fast //common:kernel_aarch64_dist
```
## KernelSU を使ったカーネルビルド
もしカーネルを正常にビルドできた場合、KernelSU をビルドするのは簡単です。カーネルソースのルートディレクトリで任意のものを選択して実行します：
::: code-group
```sh[最新タグ(安定版)]
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -
```
```sh[ main ブランチ (開発用)]
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s main
```
```sh[タグを選択 (例：v0.5.2)]
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s v0.5.2
```
:::
その後でカーネルを再ビルドすると、KernelSU が組み込まれたカーネルイメージが得られます！

303
website/docs/ja_JP/guide/how-to-integrate-for-non-gki.md Normal file
View File

@@ -0,0 +1,303 @@
# 非 GKI カーネルで KernelSU を統合する方法は？
KernelSU は非 GKI カーネルに統合することが可能であり、4.14 以下のバージョンにバックポートされました。
非 GKI カーネルの断片化のため、統一されたビルド方法がありませんので、非 GKI ブートイメージを提供することができません。しかし、KernelSU を統合して自分自身でカーネルをビルドすることができます。
まず、カーネルソースコードからブート可能なカーネルをビルドできる能力が必要です。もしカーネルがオープンソースでない場合、あなたのデバイスで KernelSU を実行することは困難です。
ブート可能なカーネルをビルドできるなら、カーネルソースコードに KernelSU を統合する方法は二つあります：
1. `kprobe` で自動的に
2. 手動で
## kprobe で統合する
KernelSU は kprobe を使ってカーネルフックを行います。もし *kprobe* があなたのカーネルでうまく動作する場合、この方法を使うことを推奨します。
まず、KernelSU をカーネルソースツリーに追加してください：
```sh
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -
```
次に、*kprobe* がカーネル設定で有効になっているか確認してください。もし有効でなければ、これらの設定を追加してください：
```
CONFIG_KPROBES=y
CONFIG_HAVE_KPROBES=y
CONFIG_KPROBE_EVENTS=y
```
そしてカーネルを再度ビルドしてください。KernelSU はうまく動作するはずです。
KPROBES がまだ有効化されていない場合は、CONFIG_MODULES を有効化して試みることができます。（それでも効果がない場合は、make menuconfig を使って KPROBES の他の依存関係を検索してください）
しかし、KernelSU を統合した際にブートループに遭遇した場合、それは *kprobe* があなたのカーネルで破損している可能性があります。kprobe のバグを修正するか、二番目の方法を使用するべきです。
:::tip kprobe が破損しているかどうかを確認する方法は？
`KernelSU/kernel/ksu.c` にある `ksu_enable_sucompat()` と `ksu_enable_ksud()` をコメントアウトし、デバイスが正常にブートするか試してください。もし正常にブートするならば、kprobe が破損している可能性があります。
## カーネルソースを手動で変更する
もし kprobe があなたのカーネルで機能しない場合（上流のバグや 4.8 以下のカーネルバグが原因かもしれません）、以下の方法を試すことができます。
まず、KernelSU をカーネルソースツリーに追加してください：
::: code-group
## カーネルソースを手動で変更する
もし kprobe があなたのカーネルで機能しない場合（上流のバグや 4.8 以下のカーネルバグが原因かもしれません）、以下の方法を試すことができます。
まず、KernelSU をカーネルソースツリーに追加してください：
::: code-group
```sh
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -
```
[ main branch(dev)]
```sh
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s main
```
[Select tag(Such as v0.5.2)]
```sh
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s v0.5.2
```
:::
いくつかのデバイスでは、あなたの defconfig が `arch/arm64/configs` にあったり、または他のケースでは `arch/arm64/configs/vendor/your_defconfig` にあることを念頭に置いてください。例えばあなたの defconfig で、`CONFIG_KSU` を y で有効に、または n で無効に設定します。あなたのパスは次のようになるでしょう：
`arch/arm64/configs/...`
```
# KernelSU
CONFIG_KSU=y
```
次に、KernelSU の呼び出しをカーネルソースに追加します。こちらは参照のためのパッチです：
::: code-group
```diff[exec.c]
diff --git a/fs/exec.c b/fs/exec.c
index ac59664eaecf..bdd585e1d2cc 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -1890,11 +1890,14 @@ static int __do_execve_file(int fd, struct filename *filename,
return retval;
}
+#ifdef CONFIG_KSU
+extern bool ksu_execveat_hook __read_mostly;
+extern int ksu_handle_execveat(int *fd, struct filename **filename_ptr, void *argv,
+ void *envp, int *flags);
+extern int ksu_handle_execveat_sucompat(int *fd, struct filename **filename_ptr,
+ void *argv, void *envp, int *flags);
+#endif
static int do_execveat_common(int fd, struct filename *filename,
struct user_arg_ptr argv,
struct user_arg_ptr envp,
int flags)
{
+ #ifdef CONFIG_KSU
+ if (unlikely(ksu_execveat_hook))
+ ksu_handle_execveat(&fd, &filename, &argv, &envp, &flags);
+ else
+ ksu_handle_execveat_sucompat(&fd, &filename, &argv, &envp, &flags);
+ #endif
return __do_execve_file(fd, filename, argv, envp, flags, NULL);
}
```
```diff[open.c]
diff --git a/fs/open.c b/fs/open.c
index 05036d819197..965b84d486b8 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -348,6 +348,8 @@ SYSCALL_DEFINE4(fallocate, int, fd, int, mode, loff_t, offset, loff_t, len)
return ksys_fallocate(fd, mode, offset, len);
}
+#ifdef CONFIG_KSU
+extern int ksu_handle_faccessat(int *dfd, const char __user **filename_user, int *mode,
+ int *flags);
+#endif
/*
* access() needs to use the real uid/gid, not the effective uid/gid.
* We do this by temporarily clearing all FS-related capabilities and
@@ -355,6 +357,7 @@ SYSCALL_DEFINE4(fallocate, int, fd, int, mode, loff_t, offset, loff_t, len)
*/
long do_faccessat(int dfd, const char __user *filename, int mode)
{
const struct cred *old_cred;
struct cred *override_cred;
struct path path;
struct inode *inode;
struct vfsmount *mnt;
int res;
unsigned int lookup_flags = LOOKUP_FOLLOW;
+ #ifdef CONFIG_KSU
+ ksu_handle_faccessat(&dfd, &filename, &mode, NULL);
+ #endif
if (mode & ~S_IRWXO) /* where's F_OK, X_OK, W_OK, R_OK? */
return -EINVAL;
```
```diff[read_write.c]
diff --git a/fs/read_write.c b/fs/read_write.c
index 650fc7e0f3a6..55be193913b6 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -434,10 +434,14 @@ ssize_t kernel_read(struct file *file, void *buf, size_t count, loff_t *pos)
}
EXPORT_SYMBOL(kernel_read);
+#ifdef CONFIG_KSU
+extern bool ksu_vfs_read_hook __read_mostly;
+extern int ksu_handle_vfs_read(struct file **file_ptr, char __user **buf_ptr,
+ size_t *count_ptr, loff_t **pos);
+#endif
ssize_t vfs_read(struct file *file, char __user *buf, size_t count, loff_t *pos)
{
ssize_t ret;
+ #ifdef CONFIG_KSU
+ if (unlikely(ksu_vfs_read_hook))
+ ksu_handle_vfs_read(&file, &buf, &count, &pos);
+ #endif
+
if (!(file->f_mode & FMODE_READ))
return -EBADF;
if (!(file->f_mode & FMODE_CAN_READ))
```
```diff[stat.c]
diff --git a/fs/stat.c b/fs/stat.c
index 376543199b5a..82adcef03ecc 100644
--- a/fs/stat.c
+++ b/fs/stat.c
@@ -148,6 +148,8 @@ int vfs_statx_fd(unsigned int fd, struct kstat *stat,
}
EXPORT_SYMBOL(vfs_statx_fd);
+#ifdef CONFIG_KSU
+extern int ksu_handle_stat(int *dfd, const char __user **filename_user, int *flags);
+#endif
+
/**
* vfs_statx - Get basic and extra attributes by filename
* @dfd: A file descriptor representing the base dir for a relative filename
@@ -170,6 +172,7 @@ int vfs_statx(int dfd, const char __user *filename, int flags,
int error = -EINVAL;
unsigned int lookup_flags = LOOKUP_FOLLOW | LOOKUP_AUTOMOUNT;
+ #ifdef CONFIG_KSU
+ ksu_handle_stat(&dfd, &filename, &flags);
+ #endif
if ((flags & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT |
AT_EMPTY_PATH | KSTAT_QUERY_FLAGS)) != 0)
return -EINVAL;
```
カーネル ソースには 4 つの関数があるはずです。
1. do_faccessat、通常は `fs/open.c` にあります
2. do_execveat_common (通常は `fs/exec.c` にあります)
3. vfs_read (通常は `fs/read_write.c` にあります)
4. vfs_statx (通常は「fs/stat.c」にあります)
カーネルに `vfs_statx` がない場合は、代わりに `vfs_fstatat` を使用してください:
```diff
diff --git a/fs/stat.c b/fs/stat.c
index 068fdbcc9e26..5348b7bb9db2 100644
--- a/fs/stat.c
+++ b/fs/stat.c
@@ -87,6 +87,8 @@ int vfs_fstat(unsigned int fd, struct kstat *stat)
}
EXPORT_SYMBOL(vfs_fstat);
+#ifdef CONFIG_KSU
+extern int ksu_handle_stat(int *dfd, const char __user **filename_user, int *flags);
+#endif
int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat,
int flag)
{
@@ -94,6 +96,8 @@ int vfs_fstatat(int dfd, const char __user *filename, struct kstat *stat,
int error = -EINVAL;
unsigned int lookup_flags = 0;
+ #ifdef CONFIG_KSU
+ ksu_handle_stat(&dfd, &filename, &flag);
+ #endif
+
if ((flag & ~(AT_SYMLINK_NOFOLLOW | AT_NO_AUTOMOUNT |
AT_EMPTY_PATH)) != 0)
goto out;
```
4.17 より前のカーネルの場合、`do faccessat` が見つからない場合は、`faccessat` システムコールの定義に移動して、そこで呼び出しを実行します。
```diff
diff --git a/fs/open.c b/fs/open.c
index 2ff887661237..e758d7db7663 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -355,6 +355,9 @@ SYSCALL_DEFINE4(fallocate, int, fd, int, mode, loff_t, offset, loff_t, len)
return error;
}
+#ifdef CONFIG_KSU
+extern int ksu_handle_faccessat(int *dfd, const char __user **filename_user, int *mode,
+ int *flags);
+#endif
+
/*
* access() needs to use the real uid/gid, not the effective uid/gid.
* We do this by temporarily clearing all FS-related capabilities and
@@ -370,6 +373,8 @@ SYSCALL_DEFINE3(faccessat, int, dfd, const char __user *, filename, int, mode)
int res;
unsigned int lookup_flags = LOOKUP_FOLLOW;
+ #ifdef CONFIG_KSU
+ ksu_handle_faccessat(&dfd, &filename, &mode, NULL);
+ #endif
+
if (mode & ~S_IRWXO) /* where's F_OK, X_OK, W_OK, R_OK? */
return -EINVAL;
```
KernelSU の組み込み SafeMode を有効にするには、`drivers/input/input.c` の `input_handle_event` も変更する必要があります。
:::ヒント
この機能を有効にすることを強くお勧めします。ブートループを防ぐのに非常に役立ちます!
:::
```diff
diff --git a/drivers/input/input.c b/drivers/input/input.c
index 45306f9ef247..815091ebfca4 100755
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -367,10 +367,13 @@ static int input_get_disposition(struct input_dev *dev,
return disposition;
}
+#ifdef CONFIG_KSU
+extern bool ksu_input_hook __read_mostly;
+extern int ksu_handle_input_handle_event(unsigned int *type, unsigned int *code, int *value);
+#endif
+
static void input_handle_event(struct input_dev *dev,
unsigned int type, unsigned int code, int value)
{
int disposition = input_get_disposition(dev, type, code, &value);
+ #ifdef CONFIG_KSU
+ if (unlikely(ksu_input_hook))
+ ksu_handle_input_handle_event(&type, &code, &value);
+ #endif
if (disposition != INPUT_IGNORE_EVENT && type != EV_SYN)
add_input_randomness(type, code, value);
```
最後に、カーネルを再度ビルドすると、KernelSU が正常に動作するはずです。
:::info 誤ってセーフ モードに入ってしまった場合は、
手動統合を使用し、`CONFIG_KPROBES` を無効にしない場合、ユーザーは起動後に音量を下げるボタンを押してセーフ モードをトリガーする可能性があります。 したがって、手動統合を使用する場合は、`CONFIG_KPROBES` を無効にする必要があります。
:::

274
website/docs/ja_JP/guide/installation.md Normal file
View File

@@ -0,0 +1,274 @@
# インストール
## デバイスが対応しているか確認する
[GitHub Releases](https://github.com/tiann/KernelSU/releases) から KernelSU Manager アプリをダウンロードし、お使いのデバイスにインストールしてください。
- アプリが「非対応」と表示した場合は、**自分でカーネルをコンパイルする必要がある**という意味です。KernelSU は書き込むためのブートイメージを提供しません。
- アプリが「未インストール」と表示した場合、お使いのデバイスは KernelSU に対応しています。
::: info ヒント
非対応と表示されているデバイスについては、[非公式の対応デバイス](unofficially-support-devices.md)であればご自身でカーネルをビルドできます。
:::
## 純正の boot.img をバックアップ
書き込む前に、まず純正の boot.img をバックアップする必要があります。ブートループが発生した場合は、fastboot を使用して純正のブートイメージを書き込むことでいつでもシステムを復旧できます。
::: warning 警告
書き込みによりデータ損失を引き起こす可能性があります。次のステップに進む前に、このステップを必ず行うようにしてください！また、可能であればすべてのデータをバックアップしてください。
:::
## 必要な知識
### ADB と fastboot
このチュートリアルでは、デフォルトで ADB と fastboot のツールを使用します。ご存じない方は、まず検索エンジンを使って勉強されることをおすすめします。
### KMI
同じ Kernel Module Interface (KMI) のカーネルバージョンは**互換性があります**。これが GKI の「汎用」という意味です。逆に言えば KMI が異なればカーネルには互換性がなく、お使いのデバイスと異なる KMI のカーネルイメージを書き込むと、ブートループが発生する場合があります。
具体的には GKI デバイスの場合、カーネルバージョンの形式は以下のようになります：
```txt
KernelRelease :=
Version.PatchLevel.SubLevel-AndroidRelease-KmiGeneration-suffix
w .x .y -zzz -k -something
```
`w.x-zzz-k` は KMI のバージョンです。例えば、デバイスのカーネルバージョンが `5.10.101-android12-9-g30979850fc20` である場合、その KMIは `5.10-android12-9` であり、理論的には他の KMI カーネルでも正常に起動できます。
::: tip ヒント
カーネルバージョンの SubLevel は、KMI の一部ではないことに注意してください。`5.10.101-android12-9-g30979850fc20` は `5.10.137-android12-9-g30979850fc20` と同じ KMI を持っているということになります。
:::
### セキュリティパッチレベル {#security-patch-level}
新しめの Android 端末には、セキュリティパッチレベルが古い boot イメージのフラッシュを許可しないロールバック防止機構が導入されていることがあります。例えば、もしあなたの端末のカーネルが `5.10.101-android12-9-g30979850fc20` であれば、セキュリティパッチレベルは `2023-11` です。たとえ KMI に対応するカーネルをフラッシュしても、セキュリティパッチレベルが (`2023-06` のように) `2023-11` より低い場合、ブートループを起こす可能性があります。
### Kernel バージョンと Android バージョンの違い
注意： **カーネルバージョンと Android バージョンは必ずしも同じではありません**。
カーネルのバージョンは「android12-5.10.101」なのに、Android システムのバージョンは「Android 13」などとなっている場合、驚かないでください。Linux カーネルのバージョン番号は、必ずしも**デバイスの出荷時**にプリインストールされている Android システムのバージョンと一致していません。Android システムが後でアップグレードされた場合、一般的にはカーネルのバージョンは変更されません。書き込む際は、**必ずカーネルバージョンを参照してください**!!!
## はじめに
バージョン [0.9.0](https://github.com/tiann/KernelSU/releases/tag/v0.9.0) 以降、KernelSU は GKI 端末において 2 つの動作モードに対応しています。
1. `GKI`: 端末本来のカーネルを KernelSU によって提供される **汎用カーネルイメージ** (GKI) で置き換えます。
2. `LKM`: 端末本来のカーネルを置き換えずに、カーネルに **ローダブルカーネルモジュール** (LKM) を読み込みます。
これらの 2 つのモードはそれぞれ異なる状況に適しており、必要に応じてどちらかを選ぶことができます。
### GKI モード {#gki-mode}
GKI モードでは、端末本来のカーネルは KernelSU によって提供される汎用カーネルイメージによって置き換えられます。GKI モードの利点は:
1. 強い汎用性があり、大部分の端末に適合。例えば、Samsung 端末は KNOX が有効であり、LKM モードは動作できません。また、GKI モードしか使えないニッチな改造を施された端末もあります。
2. 公式ファームウェアに依存せずに使うことができます。KMI が一致している限り、公式ファームウェアの更新を待つことなく使うことができます。
### LKM モード {#lkm-mode}
LKM モードでは、端末本来のカーネルを置き換えずに、カーネルにローダブルカーネルモジュールを読み込みます。LKM モードの利点は:
1. 端末本来のカーネルを置き換えません。端末本来のカーネルに特別な要件がある場合や、KernelSU をサードパーティのカーネルと両用したい場合、LKM モードを利用できます。
2. アップグレードと OTA がより便利です。KernelSU をアップデートする時は、手動でフラッシュすることなくマネージャーから直接インストールできます。システム OTA の後は、手動でフラッシュすることなく非アクティブなスロットに直接インストールすることができます。
3. いくつかの特殊な状況に適しています。例えば、LKM は一時的な Root 権限を用いて読み込むことができます。boot パーティションを置き換えないので、AVB を動作させず、端末を文鎮化しません。
4. LKM は一時的にアンインストールすることができます。一時的に root アクセスを無効化したい場合、LKM をアンインストールすることができます。この過程でパーティションをフラッシュすることも、また再起動することさえも必要ありません。root アクセスを再度有効化したい場合は、再起動するだけです。
:::tip 2 つのモードの共存
マネージャーを開くと、ホームで現在の端末の動作モードを確認できます。GKI モードの優先度は LKM モードより高いことに留意してください。例えば、本来のカーネルを GKI カーネルで置き換えたうえで LKM を使って GKI カーネルにパッチしている場合、LKM は無視され、端末は常時 GKI モードで動作します。
:::
### どちらを選ぶべきですか? {#which-one}
端末が携帯電話の場合、LKM モードを優先することを推奨します。端末がエミュレーター、WSA、または Waydroid の場合、GKI モードを優先することを推奨します。
## LKM モードのインストール
### 公式ファームウェアの入手
LKM モードを使うためには、公式ファームウェアを入手し、それを基にパッチを当てる必要があります。サードパーティのカーネルを使う場合、その `boot.img` を公式ファームウェアとして利用できます。
公式ファームウェアを入手する方法はたくさんあります。端末が `fastboot boot` に対応している場合、`fastboot boot` を使って一時的に KernelSU が提供する GKI カーネルを起動する、 **最も推奨される、最も簡単な** 方法を推奨します。
端末が `fastboot boot` に対応していない場合、公式ファームウェアのパッケージを手動でダウンロードし、そこから `boot.img` を展開する必要があります。
GKI モードとは異なり、LKM モードは `ramdisk` を展開します。そのため、Android 13 の端末では `boot` パーティションの代わりに `init_boot` パーティションにパッチを当てる必要があります。一方で、GKI モードは常に `boot` パーティションを操作します。
### マネージャーを使う
マネージャーを開き、右上のインストールアイコンをタップすると、いくつかのオプションが現れます:
1. ファイルを選択しパッチを当てる。端末が Root 権限を持っていない場合、このオプションを選択し、公式ファームウェアを選択すると、マネージャーが自動的にパッチを当てます。恒久的に Root 権限を獲得するには、パッチが当てられたファイルをフラッシュするだけです。
2. 直接インストール。端末が既に Root 化されている場合、このオプションを選択すると、マネージャーが自動的に端末の情報を取得し、自動的に公式ファームウェアにパッチを当て、それをフラッシュします。`fastboot boot` で KernelSU の GKI を起動し一時的に Root 権限を獲得したうえでこのオプションを利用することもできます。これは KernelSU をアップグレードする主な方法でもあります。
3. 非アクティブなスロットにインストール。端末が A/B パーティションに対応している場合、このオプションを選択すると、マネージャーが自動的に公式ファームウェアにパッチを当て、もう一方のパーティションにインストールします。この方法は OTA 後の端末に適しており、OTA 後にもう一方のパーティションに直接 KernelSU をインストールし、端末を再起動することができます。
### コマンドラインを使う
マネージャーを使いたくない場合、コマンドラインを使って LKM をインストールできます。KernelSU の提供する `ksud` ツールを使うと、迅速に公式ファームウェアにパッチを当てフラッシュすることができます。
このツールは macOS、Linux および Windows に対応しています。[GitHub Release](https://github.com/tiann/KernelSU/releases) から対応するバージョンをダウンロードしてください。
使用方法: `ksud bootpatch` コマンドの各オプションのヘルプをコマンドラインから確認できます。
```sh
oriole:/ # ksud boot-patch -h
Patch boot or init_boot images to apply KernelSU
Usage: ksud boot-patch [OPTIONS]
Options:
-b, --boot <BOOT> boot image path, if not specified, will try to find the boot image automatically
-k, --kernel <KERNEL> kernel image path to replace
-m, --module <MODULE> LKM module path to replace, if not specified, will use the builtin one
-i, --init <INIT> init to be replaced
-u, --ota will use another slot when boot image is not specified
-f, --flash Flash it to boot partition after patch
-o, --out <OUT> output path, if not specified, will use current directory
--magiskboot <MAGISKBOOT> magiskboot path, if not specified, will use builtin one
--kmi <KMI> KMI version, if specified, will use the specified KMI
-h, --help Print help
```
説明が必要ないくつかのオプション:
1. `--magiskboot` オプションは magiskboot のパスを指定します。指定されていない場合、ksud は環境変数を参照します。magiskboot の入手方法がわからない場合、[こちら](#patch-boot-image) を参照してください。
2. `--kmi` オプションは `KMI` バージョンを指定します。端末のカーネル名が KMI の仕様に準拠していない場合は、このオプションで指定することができます。
最も一般的な使い方:
```sh
ksud boot-patch -b <boot.img> --kmi android13-5.10
```
## GKI モードのインストール
GKI モードのインストール方法はいくつかあり、それぞれ適したシーンが異なりますので、必要に応じて選択してください。
1. KernelSU が提供する boot.img を使用し、fastboot でインストールする
2. KernelFlasher などのカーネル管理アプリでインストールする
3. boot.img を手動でパッチしてインストールする
4. カスタムリカバリー（TWRPなど）でインストールする
## KernelSU が提供する boot.img を使用してインストール
この方法は TWRP や root 権限を必要としないので、KernelSU を初めてインストールする場合に適しています。
### 正しい boot.img を見つける
KernelSU では、GKI デバイス用の汎用 boot.img を提供しています。デバイスの boot パーティションに boot.img をフラッシュする必要があります。
boot.img は、[GitHub Release](https://github.com/tiann/KernelSU/releases) からダウンロードできます。例えば、あなたのデバイスがカーネル `android12-5.10.101` の場合、`android-5.10.101_yyyy-MM.boot-<format>.img`をダウンロードする必要があります。（KMI を同じにしてください！）。
`<format>`は純正 boot.img のカーネル圧縮形式を指します。純正の boot.img のカーネル圧縮形式を確認してください。間違った圧縮形式を使うと、ブートループするかもしれません。
::: info 情報
1. magiskboot を使えば、元のブートの圧縮形式を知ることができます。もちろん、あなたのデバイスと同じモデルを持つ、より経験豊富な他の人にも聞くこともできます。また、カーネルの圧縮形式は通常変更されないので、ある圧縮形式でうまく起動した場合、後でその形式を試すことも可能です。
2. Xiaomi デバイスでは通常 `gz` か**無圧縮**が使われます。
3. Pixel デバイスでは以下の手順に従ってください。
:::
### boot.img をデバイスに書き込む
`adb` でデバイスを接続し、`adb reboot bootloader` で fastboot モードにし、このコマンドで KernelSU を書き込んでください：
```sh
fastboot flash boot boot.img
```
::: info 情報
デバイスが `fastboot boot` をサポートしている場合、まず `fastboot boot.img` を使えば書き込みせずにシステムを起動できます。予期せぬことが起こった場合は、もう一度再起動して起動してください。
:::
### 再起動
書き込みが完了したら、デバイスを再起動します：
```sh
fastboot reboot
```
## カーネル管理アプリでインストール
前提条件：お使いのデバイスが root 化されている必要があります。例えば、Magisk をインストールして root を取得した場合、または古いバージョンの KernelSU をインストールしており、別のバージョンの KernelSU にアップグレードする必要がある場合などです。お使いのデバイスが root 化されていない場合、他の方法をお試しください。
手順:
1. AnyKernel3 ZIP をダウンロードします。ダウンロード方法は、「カスタムリカバリーでインストール」を参照してください。
2. カーネル管理アプリを開き、AnyKernel3 の ZIP をインストールします。
カーネル管理アプリは以下のようなものが人気です：
1. [Kernel Flasher](https://github.com/capntrips/KernelFlasher/releases)
2. [Franco Kernel Manager](https://play.google.com/store/apps/details?id=com.franco.kernel)
3. [Ex Kernel Manager](https://play.google.com/store/apps/details?id=flar2.exkernelmanager)
この方法は KernelSU をアップグレードするときに便利で、パソコンがなくてもできます。（まずはバックアップしてください！）
## boot.img を手動でパッチ {#patch-boot-image}
デバイスによっては、boot.img のフォーマットが `lz4` でない、`gz` である、無圧縮であるなど、あまり一般的でないことがあります。最も典型的なのは Pixel で、boot.img フォーマットは `lz4_legacy` 圧縮、RAM ディスクは `gz` か `lz4_legacy` 圧縮です。この時、KernelSU が提供した boot.img を直接書き込むとデバイスが起動できなくなる場合があります。その場合は手動で boot.img に対してパッチしてください。
常に `magiskboot` を利用してイメージにパッチを当てることが推奨されます。2 つの方法があります:
1. [magiskboot](https://github.com/topjohnwu/Magisk/releases)
2. [magiskboot_build](https://github.com/ookiineko/magiskboot_build/releases/tag/last-ci)
公式の `magisikboot` ビルドは Android 端末でしか動作しないため、PC で作業したい場合、2 つめの方法を試してください。
:::tip
Android-Image-Kitchen は現在非推奨です。セキュリティパッチレベルなどの boot メタデータを正しく扱わないため、一部のデバイスでは動作しない可能性があります。
:::
### 準備
1. お使いのデバイスの純正 boot.img を入手します。デバイスメーカーから入手できます。[payload-dumper-go](https://github.com/ssut/payload-dumper-go)が必要かもしれません。
2. お使いのデバイスの KMI バージョンに合った、KernelSU が提供する AnyKernel3 の ZIP ファイルをダウンロードします（*カスタムリカバリーでインストール*を参照してください）。
3. AnyKernel3 パッケージを展開し、KernelSU のカーネルファイルである `Image` ファイルを取得します。
### Android 端末で magiskboot を使う {#using-magiskboot-on-Android-devices}
1. 最新の Magisk を[リリースページ](https://github.com/topjohnwu/Magisk/releases)からダウンロードしてください。
2. `Magisk-*(version).apk` を `Magisk-*.zip` に名前を変更して展開してください。
3. `Magisk-*/lib/arm64-v8a/libmagiskboot.so`を adb でデバイスに転送します：`adb push Magisk-*/lib/arm64-v8a/libmagiskboot.so /data/local/tmp/magiskboot`
4. 純正 boot.img と AnyKernel3 の中の Image をデバイスに転送します。
5. adb shell に入り、`cd /data/local/tmp/` し、`chmod +x magiskboot` を実行します。
6. adb shell に入り、`cd /data/local/tmp/` し、`./magiskboot unpack boot.img` を実行して `boot.img` を抽出します。`kernel` ファイルが純正カーネルです。
7. `kernel` を `Image` で置き換えます: `mv -f Image kernel`
8. `./magiskboot repack boot.img` を実行してブートイメージをリパックします。出来上がった `new-boot.img` を fastboot でデバイスに書き込んでください。
### Windows/macOS/Linux PC で magiskboot を使う {#using-magiskboot-on-PC}
1. OS に対応する `magiskboot` バイナリを [magiskboot_build](https://github.com/ookiineko/magiskboot_build/releases/tag/last-ci) からダウンロードします。
2. 純正の `boot.img` と `Image` を PC 上に準備します。
3. `chmod +x magiskboot` を実行します。
4. 対応するディレクトリに入り、`./magiskboot unpack boot.img` を実行して `boot.img` を展開します。展開された `kernel` ファイルが純正のカーネルです。
5. 下記のコマンドを実行し、`kernel` を `Image` で置き換えてください: `mv -f Image kernel`
6. `./magiskboot repack boot.img` を実行し、boot イメージを再パックします。作成された `new-boot.img` ファイルを、fastboot を利用して端末にフラッシュします。
::: info
公式の `magiskboot` は、`Linux` 環境においては正常に動作します。Linux を使っている場合、公式のビルドを利用できます。
:::
## カスタムリカバリーでインストール {#install-with-custom-recovery}
前提条件：デバイスに TWRP などのカスタムリカバリーがあること。ない場合、または公式リカバリーしかない場合は他の方法を使用してください。
手順:
1. KernelSUの[リリースページ](https://github.com/tiann/KernelSU/releases)から、お使いのデバイスのバージョンにあった AnyKernel3 で始まる ZIP パッケージをダウンロードします。例えば、デバイスのカーネルのバージョンが`android12-5.10. 66`の場合、AnyKernel3-android12-5.10.66_yyyy-MM.zip`（yyyy`は年、`MM`は月）のファイルをダウンロードします。
2. デバイスを TWRP へ再起動します。
3. adb を使用して AnyKernel3-*.zip をデバイスの /sdcard に入れ、TWRP GUI でインストールを選択します。または直接`adb sideload AnyKernel-*.zip` でインストールできます。
この方法は TWRP を使用できるならどのようなインストール（初期インストールやその後のアップグレード）にも適しています。
## その他の方法
実はこれらのインストール方法はすべて、**元のカーネルを KernelSU が提供するカーネルに置き換える**という主旨でしかなく、これが実現できれば他の方法でもインストール可能です：
1. まず Magisk をインストールし、Magisk を通じて root 権限を取得し、カーネル管理アプリで KernelSU の AnyKernel ZIPをインストールする
2. PC 上で何らかの書き込みツールを使用し、KernelSU が提供するカーネルを書き込む
しかし、これらの方法でうまく行かない場合、`magiskboot` を使う方法を試してみてください。

48
website/docs/ja_JP/guide/module-webui.md Normal file
View File

@@ -0,0 +1,48 @@
# Module WebUI
KernelSU のモジュールは、ブートスクリプトの実行やシステムファイルの修正に加えて、UI インターフェースの表示やユーザーとの対話もサポートしています。
モジュールは、任意の Web 技術を通じて HTML + CSS + JavaScript のページを作成することができます。KernelSU のマネージャーは WebView を通じてこれらのページを表示します。また、シェルコマンドの実行など、システムと対話するためのいくつかのAPIを提供しています。
## `webroot` ディレクトリ
Web リソースファイルは、モジュールのルートディレクトリの `webroot` サブディレクトリに置かれるべきであり、`index.html` という名前のファイルが必ず存在しなければなりません。これがモジュールページのエントリです。Web インターフェイスを含む最もシンプルなモジュール構造は以下の通りです：
```txt
❯ tree .
.
|-- module.prop
`-- webroot
`-- index.html
```
:::警告
モジュールをインストールするとき、KernelSU はこのディレクトリのパーミッションと SELinux コンテキストを自動的に設定します。何をしているかわからないのであれば、自分でこのディレクトリのパーミッションを設定しないでください！
:::
ページに css や JavaScript が含まれている場合は、このディレクトリに配置する必要があります。
## JavaScript API
単なる表示ページであれば、通常の Web ページとの違いはありません。より重要なのは、KernelSU がモジュールの固有機能を実装させるための一連のシステム API を提供することです。
KernelSU は JavaScript ライブラリを提供し、[npm で公開しています](https://www.npmjs.com/package/kernelsu)。これを Web ページの JavaScript コードで使用することができます。
たとえば、特定の設定を取得したり、プロパティを変更するために、シェルコマンドを実行することができます：
```JavaScript
import { exec } from 'kernelsu';
const { errno, stdout } = exec("getprop ro.product.model");
```
別の例として、Webページをフルスクリーンで表示したり、トーストを表示することができます。
[API ドキュメント](https://www.npmjs.com/package/kernelsu)
既存のAPIがご自身のニーズを満たしていない、または使い勝手が不便である場合、[こちら](https://github.com/tiann/KernelSU/issues)でご提案いただければ幸いです！
## いくつかのヒント
1. `localStorage` を通常通りに使用してデータを保存することができますが、Manager アプリをアンインストールした後には失われます。永続的に保存する必要がある場合は、自分でいくつかのディレクトリにデータを書き込むことができます。
2. シンプルなページには、[parceljs](https://parceljs.org/)を使用することをお勧めします。設定が不要で非常に便利です。しかし、フロントエンドの達人である場合や、自分の好みがある場合は、気に入ったものを選んでください！

255
website/docs/ja_JP/guide/module.md Normal file
View File

@@ -0,0 +1,255 @@
# モジュールのガイド
KernelSU はシステムパーティションの整合性を維持しながら、システムディレクトリを変更する効果を実現するモジュール機構を提供します。この機構は一般に「システムレス」と呼ばれています。
KernelSU のモジュール機構は、Magisk とほぼ同じです。Magisk のモジュール開発に慣れている方であれば、KernelSU のモジュール開発も簡単でしょう。その場合は以下のモジュールの紹介は読み飛ばして、[Magisk との違い](difference-with-magisk.md)の内容だけ読めばOKです。
## Busybox
KernelSU には、機能的に完全な Busybox バイナリ (SELinux の完全サポートを含む) が同梱されています。実行ファイルは `/data/adb/ksu/bin/busybox` に配置されています。KernelSU の Busybox はランタイムに切り替え可能な「ASH スタンドアローンシェルモード」をサポートしています。このスタンドアロンモードとは、Busybox の `ash` シェルで実行する場合 `PATH` として設定されているものに関係なく、すべてのコマンドが Busybox 内のアプレットを直接使用するというものです。たとえば、`ls`、`rm`、`chmod` などのコマンドは、`PATH` にあるもの（Android の場合、デフォルトではそれぞれ `/system/bin/ls`, `/system/bin/rm`, `/system/bin/chmod`）ではなく、直接 Busybox 内部のアプレットを呼び出すことになります。これにより、スクリプトは常に予測可能な環境で実行され、どの Android バージョンで実行されていても常にコマンドを利用できます。Busybox を使用しないコマンドを強制的に実行するには、フルパスで実行ファイルを呼び出す必要があります。
KernelSU のコンテキストで実行されるすべてのシェルスクリプトは、Busybox の `ash` シェルでスタンドアロンモードが有効な状態で実行されます。サードパーティの開発者に関係するものとしては、すべてのブートスクリプトとモジュールのインストールスクリプトが含まれます。
この「スタンドアロンモード」機能を KernelSU 以外で使用したい場合、2つの方法で有効にできます：
1. 環境変数 `ASH_STANDALONE` を `1` にする<br>例: `ASH_STANDALONE=1 /data/adb/ksu/bin/busybox sh <script>`
2. コマンドラインのオプションで変更する:<br>`/data/adb/ksu/bin/busybox sh -o standalone <script>`
環境変数が子プロセスに継承されるため、その後に実行されるすべての `sh` シェルもスタンドアロンモードで実行されるようにするにはオプション 1 が望ましい方法です（KernelSU と KernelSU Managerが内部的に使用しているのもこちらです）。
::: tip Magisk との違い
KernelSU の Busybox は、Magisk プロジェクトから直接コンパイルされたバイナリファイルを使用するようになりました。Magisk と KernelSU の Busybox スクリプトはまったく同じものなので、互換性の問題を心配する必要はありません！
:::
## KernelSU モジュール
KernelSU モジュールは、`/data/adb/modules` に配置された以下の構造を持つフォルダーです：
```txt
/data/adb/modules
├── .
├── .
|
├── $MODID <--- フォルダの名前はモジュールの ID で付けます
│ │
│ │ *** モジュールの ID ***
│ │
│ ├── module.prop <--- このファイルにモジュールのメタデータを保存します
│ │
│ │ *** メインコンテンツ ***
│ │
│ ├── system <--- skip_mount が存在しない場合、このフォルダがマウントされます
│ │ ├── ...
│ │ ├── ...
│ │ └── ...
│ │
│ │ *** ステータスフラグ ***
│ │
│ ├── skip_mount <--- 存在する場合、KernelSU はシステムフォルダをマウントしません
│ ├── disable <--- 存在する場合、モジュールは無効化されます
│ ├── remove <--- 存在する場合、次の再起動時にモジュールが削除されます
│ │
│ │ *** 任意のファイル ***
│ │
│ ├── post-fs-data.sh <--- このスクリプトは post-fs-data で実行されます
│ ├── service.sh <--- このスクリプトは late_start サービスで実行されます
| ├── uninstall.sh <--- このスクリプトは KernelSU がモジュールを削除するときに実行されます
│ ├── system.prop <--- このファイルのプロパティは resetprop によってシステムプロパティとして読み込まれます
│ ├── sepolicy.rule <--- カスタム SEPolicy ルールを追加します
│ │
│ │ *** 自動生成されるため、手動で作成または変更しないでください ***
│ │
│ ├── vendor <--- $MODID/system/vendor へのシンボリックリンク
│ ├── product <--- $MODID/system/product へのシンボリックリンク
│ ├── system_ext <--- $MODID/system/system_ext へのシンボリックリンク
│ │
│ │ *** その他のファイル/フォルダの追加も可能です ***
│ │
│ ├── ...
│ └── ...
|
├── another_module
│ ├── .
│ └── .
├── .
├── .
```
::: tip Magisk との違い
KernelSU は Zygisk をビルトインでサポートしていないため、モジュール内に Zygisk に関連するコンテンツは存在しません。 しかし、[ZygiskNext](https://github.com/Dr-TSNG/ZygiskNext) をインストールすれば Zygisk モジュールを使えます。その場合の Zygisk モジュールのコンテンツは Magisk と同じです。
:::
### module.prop
module.prop はモジュールの設定ファイルです。KernelSU ではこのファイルを含まないモジュールは、モジュールとして認識されません。このファイルの形式は以下の通りです：
```txt
id=<string>
name=<string>
version=<string>
versionCode=<int>
author=<string>
description=<string>
```
- `id` はこの正規表現に一致していなければいけません: `^[a-zA-Z][a-zA-Z0-9._-]+$`<br>
例: ✓ `a_module`, ✓ `a.module`, ✓ `module-101`, ✗ `a module`, ✗ `1_module`, ✗ `-a-module`<br>
これはモジュールの**ユニークな ID** です。公開後は変更しないでください。
- `versionCode` は **integer** です。バージョンの比較に使います。
- 他のものには**単一行** の文字であれば何でも使えます。
- 改行文字は `UNIX (LF)` を使ってください。`Windows (CR+LF)` や `Macintosh (CR)` は使ってはいけません。
### シェルスクリプト
`post-fs-data.sh` と `service.sh` の違いについては、[ブートスクリプト](#boot-scripts)のセクションを読んでください。ほとんどのモジュール開発者にとって、ブートスクリプトを実行するだけなら `service.sh` で十分なはずです。
モジュールのすべてのスクリプトでは、`MODDIR=${0%/*}`を使えばモジュールのベースディレクトリのパスを取得できます。スクリプト内でモジュールのパスをハードコードしないでください。
::: tip Magisk との違い
環境変数 `KSU` を使用すると、スクリプトが KernelSU と Magisk どちらで実行されているかを判断できます。KernelSU で実行されている場合、この値は `true` に設定されます。
:::
### `system` ディレクトリ
このディレクトリの内容は、システムの起動後に OverlayFS を使用してシステムの /system パーティションの上にオーバーレイされます：
1. システム内の対応するディレクトリにあるファイルと同名のファイルは、このディレクトリにあるファイルで上書きされます。
2. システム内の対応するディレクトリにあるフォルダと同じ名前のフォルダは、このディレクトリにあるフォルダと統合されます。
元のシステムディレクトリにあるファイルやフォルダを削除したい場合は、`mknod filename c 0 0` を使ってモジュールディレクトリにそのファイル/フォルダと同じ名前のファイルを作成する必要があります。こうすることで、OverlayFS システムはこのファイルを削除したかのように自動的に「ホワイトアウト」します（/system パーティションは実際には変更されません）。
また、`customize.sh` 内で `REMOVE` という変数に削除操作を実行するディレクトリのリストを宣言すると、KernelSU は自動的にそのモジュールの対応するディレクトリで `mknod <TARGET> c 0 0` を実行します。例えば
```sh
REMOVE="
/system/app/YouTube
/system/app/Bloatware
"
```
上記の場合は、`mknod $MODPATH/system/app/YouTuBe c 0 0`と`mknod $MODPATH/system/app/Bloatware c 0 0`を実行し、`/system/app/YouTube`と`/system/app/Bloatware`はモジュール有効化後に削除されます。
システム内のディレクトリを置き換えたい場合は、モジュールディレクトリに同じパスのディレクトリを作成し、このディレクトリに `setfattr -n trusted.overlay.opaque -v y <TARGET>` という属性を設定する必要があります。こうすることで、OverlayFS システムは（/system パーティションを変更することなく）システム内の対応するディレクトリを自動的に置き換えることができます。
`customize.sh` ファイル内に `REPLACE` という変数を宣言し、その中に置換するディレクトリのリストを入れておけば、KernelSU は自動的にモジュールディレクトリに対応した処理を行います。例えば：
REPLACE="
/system/app/YouTube
/system/app/Bloatware
"
このリストは、自動的に `$MODPATH/system/app/YouTube` と `$MODPATH/system/app/Bloatware` というディレクトリを作成し、 `setfattr -n trusted.overlay.opaque -v y $MODPATH/system/app/YouTube` と `setfattr -n trusted.overlay.opaque -v y $MODPATH/system/app/Bloatware` を実行します。モジュールが有効になると、`/system/app/YouTube` と `/system/app/Bloatware` は空のディレクトリに置き換えられます。
::: tip Magisk との違い
KernelSU のシステムレスメカニズムはカーネルの OverlayFS によって実装され、Magisk は現在マジックマウント（bind mount）を使用しています。この2つの実装方法には大きな違いがありますが最終的な目的は同じで、/system パーティションを物理的に変更することなく、/system のファイルを変更できます。
:::
OverlayFS に興味があれば、Linux カーネルの [OverlayFS のドキュメンテーション](https://docs.kernel.org/filesystems/overlayfs.html) を読んでみてください。
### system.prop
このファイルは `build.prop` と同じ形式をとっています。各行は `[key]=[value]` で構成されます。
### sepolicy.rule
もしあなたのモジュールが追加の SEPolicy パッチを必要とする場合は、それらのルールをこのファイルに追加してください。このファイルの各行は、ポリシーステートメントとして扱われます。
## モジュールのインストーラー
KernelSU モジュールインストーラーは、KernelSU Manager アプリでインストールできる、ZIP ファイルにパッケージされた KernelSU モジュールです。最もシンプルな KernelSU モジュールインストーラーは、KernelSU モジュールを ZIP ファイルとしてパックしただけのものです。
```txt
module.zip
│
├── customize.sh <--- (任意、詳細は後述)
│ このスクリプトは update-binary から読み込まれます
├── ...
├── ... /* 残りのモジュールのファイル */
│
```
::: warning 警告
KernelSU モジュールは、カスタムリカバリーからのインストールには非対応です！
:::
### カスタマイズ
モジュールのインストールプロセスをカスタマイズする必要がある場合、`customize.sh` という名前のスクリプトを作成してください。このスクリプトは、すべてのファイルが抽出され、デフォルトのパーミッションと secontext が適用された後、モジュールインストーラースクリプトによって読み込み (実行ではなく) されます。これは、モジュールがデバイスの ABI に基づいて追加設定を必要とする場合や、モジュールファイルの一部に特別なパーミッション/コンテキストを設定する必要がある場合に、非常に便利です。
インストールプロセスを完全に制御しカスタマイズしたい場合は、`customize.sh` で `SKIPUNZIP=1` と宣言すればデフォルトのインストールステップをすべてスキップできます。そうすることで、`customize.sh` が責任をもってすべてをインストールするようになります。
`customize.sh`スクリプトは、KernelSU の Busybox `ash` シェルで、「スタンドアロンモード」を有効にして実行します。以下の変数と関数が利用可能です：
#### 変数
- `KSU` (bool): スクリプトが KernelSU 環境で実行されていることを示すための変数で、この変数の値は常に true になります。KernelSU と Magisk を区別するために使用できます。
- `KSU_VER` (string): 現在インストールされている KernelSU のバージョン文字列 (例: `v0.4.0`)
- `KSU_VER_CODE` (int): ユーザー空間に現在インストールされているKernelSUのバージョンコード (例: `10672`)
- `KSU_KERNEL_VER_CODE` (int): 現在インストールされている KernelSU のカーネル空間でのバージョンコード（例：`10672`）
- `BOOTMODE` (bool): KernelSU では常に `true`
- `MODPATH` (path): モジュールファイルがインストールされるパス
- `TMPDIR` (path): ファイルを一時的に保存しておく場所
- `ZIPFILE` (path): あなたのモジュールのインストールZIP
- `ARCH` (string): デバイスの CPU アーキテクチャ。値は `arm`、`arm64`、`x86`、`x64` のいずれか
- `IS64BIT` (bool): `ARCH` が `arm64` または `x64` のときは `true`
- `API` (int): 端末の API レベル・Android のバージョン（例：Android 6.0 なら`23`）
::: warning 警告
KernelSU では、MAGISK_VER_CODE は常に25200、MAGISK_VER は常にv25.2です。この2つの変数で KernelSU 上で動作しているかどうかを判断するのはやめてください。
:::
#### 機能
```txt
ui_print <msg>
コンソールに <msg> を表示します
カスタムリカバリーのコンソールでは表示されないため、「echo」の使用は避けてください
abort <msg>
エラーメッセージ<msg>をコンソールに出力し、インストールを終了させます
終了時のクリーンアップがスキップされてしまうため、「exit」の使用は避けてください
set_perm <target> <owner> <group> <permission> [context]
[context] が設定されていない場合、デフォルトは "u:object_r:system_file:s0" です。
この機能は、次のコマンドの略記です：
chown owner.group target
chmod permission target
chcon context target
set_perm_recursive <directory> <owner> <group> <dirpermission> <filepermission> [context]
[context] が設定されていない場合、デフォルトは "u:object_r:system_file:s0" です。
<directory> 内のすべてのファイルに対しては以下が実行されます:
set_perm file owner group filepermission context
<directory> 内のすべてのディレクトリ（自身を含む）に対しては以下が実行されます:
set_perm dir owner group dirpermission context
```
## ブートスクリプト
KernelSU では、スクリプトは実行モードによって post-fs-data モードと late_start サービスモードの2種類に分けられます：
- post-fs-data モード
- 同期処理です。実行が終わるか、10秒が経過するまでブートプロセスが一時停止されます。
- スクリプトはモジュールがマウントされる前に実行されます。モジュール開発者はモジュールがマウントされる前に、動的にモジュールを調整できます。
- このステージは Zygote が始まる前に起こるので、Android のほぼすべての処理の前に割り込めます
- **警告:** `setprop` を使うとブートプロセスのデッドロックを引き起こします! `resetprop -n <prop_name> <prop_value>` を使ってください。
- **本当に必要な場合だけこのモードでコマンド実行してください**
- late_start サービスモード
- 非同期処理です。スクリプトは、起動プロセスの残りの部分と並行して実行されます。
- **ほとんどのスクリプトにはこちらがおすすめです**
KernelSU では、起動スクリプトは保存場所によって一般スクリプトとモジュールスクリプトの2種類に分けられます：
- 一般スクリプト
- `/data/adb/post-fs-data.d` か `/data/adb/service.d` に配置されます
- スクリプトが実行可能な状態に設定されている場合にのみ実行されます (`chmod +x script.sh`)
- `post-fs-data.d` のスクリプトは post-fs-data モードで実行され、`service.d` のスクリプトは late_start サービスモードで実行されます
- モジュールはインストール時に一般スクリプトを追加するべきではありません
- モジュールスクリプト
- モジュール独自のフォルダに配置されます
- モジュールが有効な場合のみ実行されます
- `post-fs-data.sh` は post-fs-data モードで実行され、`service.sh` は late_start サービスモードで実行されます
すべてのブートスクリプトは、KernelSU の Busybox `ash` シェルで「スタンドアロンモード」を有効にした状態で実行されます。

50
website/docs/ja_JP/guide/rescue-from-bootloop.md Normal file
View File

@@ -0,0 +1,50 @@
# ブートループからの復旧
デバイスに書き込む際、デバイスが「文鎮化」状態になる場面に遭遇することがあります。理論的には、fastboot で boot パーティションを書き込んだだけだったり、不適切なモジュールをインストールしてデバイスが起動しなくなったりした場合なら、適切な操作で復旧できます。このページでは、「文鎮化」状態になったデバイスを復旧させるための緊急手段を紹介します。
## boot パーティションの書き込みによる文鎮化
KernelSU では、以下のような状況で boot パーティションを書き込んだときに文鎮化する場合があります：
1. 間違った形式の boot イメージを書き込んでしまった場合。例えばお使いのデバイスのパーティション形式が `gz` なのに `lz4` 形式のイメージを書き込んでしまうと、起動しなくなります。
2. お使いのデバイスが起動するために AVB 検証を無効にする必要がある場合（通常、無効にするにはすべてのデータを消去する必要があります）。
3. カーネルにバグがある、または書き込みに適していない場合。
どのような状況であっても、**純正の boot イメージを書き込む**ことで復旧できます。したがって、インストールする前にまずは純正の boot パーティションをバックアップすることを強くおすすめします。バックアップしていない場合は、あなたと同じデバイスを持つ他のユーザー、または公式ファームウェアから純正の boot イメージを入手できます。
## モジュールによる文鎮化
モジュールのインストールはデバイスを文鎮化させる一般的な原因です。**モジュールを未知のソースからインストールしないでください**！モジュールは root 権限を持つため、あなたのデバイスに不可逆的なダメージを与える可能性があります！
### 通常のモジュール
安全であることが確認されているモジュールをインストールしてデバイスが起動しなくなった場合、KernelSU では心配することなく簡単に復旧できます。KernelSU には、以下のようなデバイスを救出するための仕組みが組み込まれています：
1. AB アップデート
2. 音量下ボタンでの復旧
#### AB アップデート
KernelSU のモジュール更新は、OTA アップデートで使用される Android システムの AB アップデート機構からヒントを得ています。新しいモジュールをインストールしたり、既存のモジュールを更新したりする場合、現在使用されているモジュールファイルを直接変更することはありません。代わりに、すべてのモジュールが別のアップデートイメージに組み込まれます。システムが再起動された後、このアップデートイメージの使用を開始しようとします。Android システムが正常に起動した場合、モジュールは本当に更新されます。
そのため、デバイスを復旧する最もシンプルで一般的な方法は、**強制的に再起動すること**です。モジュールをインストールした後にシステムを起動できなくなった場合、電源ボタンを10秒以上長押しするとシステムが自動的に再起動します。再起動後はモジュールを更新する前の状態にロールバックされ、以前に更新したモジュールは自動的に無効化されます。
#### 音量下ボタンでの復旧
AB アップデートでも解決しない場合は、**セーフモード**を使用してみてください。セーフモードでは、すべてのモジュールが無効化されます。
セーフモードに入るには、2つの方法があります：
1. 一部のシステムの内蔵セーフモード：音量下ボタンの長押しでセーフモードに入れるシステムもあれば、リカバリーでセーフモードに入れるシステム（MIUI など）もあります。システムのセーフモードに入ると KernelSU もセーフモードに入り、自動的にモジュールを無効化します。
2. KernelSU の内蔵セーフモード：最初の起動画面の後、**音量下キーを3回以上連続して押す**と入れます。なお、押す→離すを三回繰り返すのであって、長押しではありません。
セーフモードに入ると、KernelSU Manager のモジュールページにあるすべてのモジュールが無効になります。「アンインストール」操作を行うことで、問題を起こしている可能性のあるモジュールをアンインストールできます。
内蔵のセーフモードはカーネルに実装されているため、キーイベントを見逃す可能性はありません。ただし、GKI 以外のカーネルでは手動によるコードの統合が必要な場合があるため、公式ドキュメントを参考にしてください。
### 悪意のあるモジュール
上記の方法でデバイスを救出できない場合、インストールしたモジュールが悪意のある操作をしているか、他の手段でデバイスを損傷している可能性が高いです。この場合、2つの方法しかありません：
1. データを消去して純正システムをインストールし直す
2. アフターセールスサービスに問い合わせする

30
website/docs/ja_JP/guide/unofficially-support-devices.md Normal file
View File

@@ -0,0 +1,30 @@
# 非公式の対応デバイス
::: warning 警告
このページでは他の開発者が管理している、KernelSU をサポートする GKI 以外のデバイス用のカーネルを紹介しています。
:::
::: warning 警告
このページはあなたのデバイスに対応するソースコードを見つけるためのものであり、そのソースコードが _KernelSU 開発者_ によってレビューされたことを意味するものではありません。ご自身の責任においてご利用ください。
:::
<script setup>
import data from '../../repos.json'
</script>
<table>
<thead>
<tr>
<th>メンテナー</th>
<th>リポジトリ</th>
<th>対応デバイス</th>
</tr>
</thead>
<tbody>
<tr v-for="repo in data" :key="repo.devices">
<td><a :href="repo.maintainer_link" target="_blank" rel="noreferrer">{{ repo.maintainer }}</a></td>
<td><a :href="repo.kernel_link" target="_blank" rel="noreferrer">{{ repo.kernel_name }}</a></td>
<td>{{ repo.devices }}</td>
</tr>
</tbody>
</table>

21
website/docs/ja_JP/guide/what-is-kernelsu.md Normal file
View File

@@ -0,0 +1,21 @@
# KernelSU とは?
KernelSU は Android GKI デバイスのための root ソリューションです。カーネルモードで動作し、カーネル空間で直接ユーザー空間アプリに root 権限を付与します。
## 機能
KernelSU の最大の特徴は、**カーネルベース**であることです。KernelSU はカーネルモードで動作するため、今までにないカーネルインターフェイスを提供できます。例えば、カーネルモードで任意のプロセスにハードウェアブレークポイントを追加できる、誰にも気づかれずに任意のプロセスの物理メモリにアクセスできる、カーネル空間で任意のシステムコールを傍受できる、などです。
また、KernelSU は OverlayFS によるモジュールシステムを提供しており、カスタムプラグインをシステムに読み込めます。`/system` パーティションを変更する仕組みも提供しています。
## 使用方法
こちらをご覧ください: [インストール方法](installation)
## ビルド方法
[ビルドするには](../../guide/how-to-build)
## ディスカッション
- Telegram: [@KernelSU](https://t.me/KernelSU)