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

Update Japanese translation (#508)

Browse Source 
I'm not familiar with vitepress, so there may be some mistakes in the
settings.
This commit is contained in:
AndroPlus
2023-05-17 00:40:54 +09:00
committed by GitHub
parent 76612b9cf7
commit 4c934d460b
13 changed files with 814 additions and 70 deletions
Download Patch File Download Diff File Expand all files Collapse all files

7
website/docs/.vitepress/locales/index.ts
View File

@@ -4,6 +4,7 @@ import zh_CN from './zh_CN'
import zh_TW from './zh_TW'
import vi_VN from './vi_VN'
import id_ID from './id_ID'
import ja_JP from './ja_JP'
export default defineConfig({
locales: {
@@ -25,6 +26,12 @@ export default defineConfig({
themeConfig: zh_TW.themeConfig,
description: zh_TW.description
},
ja_JP: {
label: '日本語',
lang: ja_JP.lang,
themeConfig: ja_JP.themeConfig,
description: ja_JP.description
},
vi_VN: {
label: 'Tiếng Việt',
lang: vi_VN.lang,

60
website/docs/.vitepress/locales/ja_JP.ts Normal file
View File

@@ -0,0 +1,60 @@
import { createRequire } from 'module'
import { defineConfig } from 'vitepress'
const require = createRequire(import.meta.url)
const pkg = require('vitepress/package.json')
export default defineConfig({
lang: 'ja-JP',
description: 'Android GKI デバイス向けのカーネルベースの root ソリューション',
themeConfig: {
nav: nav(),
lastUpdatedText: '最終更新',
sidebar: {
'/ja_JP/guide/': sidebarGuide()
},
socialLinks: [
{ icon: 'github', link: 'https://github.com/tiann/KernelSU' }
],
footer: {
message: 'GPL3 ライセンスでリリースされています。',
copyright: 'Copyright © 2022-present KernelSU Developers'
},
editLink: {
pattern: 'https://github.com/tiann/KernelSU/edit/main/website/docs/:path',
text: 'GitHub でこのページを編集'
}
}
})
function nav() {
return [
{ text: 'ガイド', link: '/ja_JP/guide/what-is-kernelsu' },
{ text: 'Github', link: 'https://github.com/tiann/KernelSU' }
]
}
function sidebarGuide() {
return [
{
text: 'ガイド',
items: [
{ text: 'KernelSU とは?', link: '/ja_JP/guide/what-is-kernelsu' },
{ text: 'インストール', link: '/ja_JP/guide/installation' },
{ text: 'ビルドするには?', link: '/guide/how-to-build' },
{ text: '非 GKI デバイスでの実装', link: '/guide/how-to-integrate-for-non-gki' },
{ text: '非公式の対応デバイス', link: '/ja_JP/guide/unofficially-support-devices.md' },
{ text: 'モジュールのガイド', link: '/ja_JP/guide/module.md' },
{ text: 'ブートループからの復旧', link: '/ja_JP/guide/rescue-from-bootloop.md' },
{ text: 'よくある質問', link: '/ja_JP/guide/faq' },
{ text: '隠し機能', link: '/ja_JP/guide/hidden-features' },
]
}
]
}

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 のサポートが組み込まれていません（ただし[ZygiskOnKernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU)を使うと 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 については、[Zygisk on KernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU) を使うと動作するようにできます。
## KernelSU は Zygisk に対応していますか?
KernelSU は Zygisk サポートを内蔵していません。[Zygisk on KernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU) を使ってください。
## 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 を組み込むには？
[ガイド](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/me/weishu/kernelsu/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 に読み込ませられます。

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

@@ -0,0 +1,169 @@
# インストール
## デバイスが対応しているか確認する
[GitHub Releases](https://github.com/tiann/KernelSU/releases) または [Coolapk market](https://www.coolapk.com/apk/me.weishu.kernelsu) から KernelSU Manager アプリをダウンロードし、お使いのデバイスにインストールしてください。
- アプリが「非対応」と表示した場合は、**自分でカーネルをコンパイルする必要がある**という意味です。KernelSU は書き込むためのブートイメージを提供しません。
- アプリが「未インストール」と表示した場合、お使いのデバイスは KernelSU に対応しています。
::: 情報
非対応と表示されているデバイスについては、[非公式の対応デバイス](unofficially-support-devices.md)であればご自身でカーネルをビルドできます。
:::
## 純正の boot.img をバックアップ
書き込む前に、まず純正の boot.img をバックアップする必要があります。ブートループが発生した場合は、fastboot を使用して純正のブートイメージを書き込むことでいつでもシステムを復旧できます。
::: 警告
書き込みによりデータ損失を引き起こす可能性があります。次のステップに進む前に、このステップを必ず行うようにしてください！また、可能であればすべてのデータをバックアップしてください。
:::
## 必要な知識
### 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 カーネルでも正常に起動できます。
::: ヒント
カーネルバージョンの SubLevel は、KMI の一部ではないことに注意してください。`5.10.101-android12-9-g30979850fc20` は `5.10.137-android12-9-g30979850fc20` と同じ KMI を持っているということになります。
:::
### Kernel バージョンと Android バージョンの違い
注意： **カーネルバージョンと Android バージョンは必ずしも同じではありません**。
カーネルのバージョンは「android12-5.10.101」なのに、Android システムのバージョンは「Android 13」などとなっている場合、驚かないでください。Linux カーネルのバージョン番号は、必ずしも**デバイスの出荷時**にプリインストールされている Android システムのバージョンと一致していません。Android システムが後でアップグレードされた場合、一般的にはカーネルのバージョンは変更されません。書き込む際は、**必ずカーネルバージョンを参照してください**!!!
## インストール方法
KernelSU のインストール方法はいくつかあり、それぞれ適したシーンが異なりますので、必要に応じて選択してください。
1. カスタムリカバリー（TWRPなど）でインストールする
2. Franco Kernel Manager などのカーネル管理アプリでインストールする
3. KernelSU が提供する boot.img を使用し、fastboot でインストールする
4. boot.img を手動でパッチしてインストールする
## カスタムリカバリーでインストール
前提条件：デバイスに 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 を使用できるならどのようなインストール（初期インストールやその後のアップグレード）にも適しています。
## カーネル管理アプリでインストール
前提条件：お使いのデバイスが 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 をアップグレードするときに便利で、パソコンがなくてもできます。（まずはバックアップしてください！）
## 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 のカーネル圧縮形式を確認してください。間違った圧縮形式を使うと、ブートループするかもしれません。
::: 情報
1. magiskboot を使えば、元のブートの圧縮形式を知ることができます。もちろん、あなたのデバイスと同じモデルを持つ、より経験豊富な他の人にも聞くこともできます。また、カーネルの圧縮形式は通常変更されないので、ある圧縮形式でうまく起動した場合、後でその形式を試すことも可能です。
2. Xiaomi デバイスでは通常 `gz` か**無圧縮**が使われます。
3. Pixel デバイスでは以下の手順に従ってください。
:::
### boot.img をデバイスに書き込む
`adb` でデバイスを接続し、`adb reboot bootloader` で fastboot モードにし、このコマンドで KernelSU を書き込んでください：
```sh
fastboot flash boot boot.img
```
::: 情報
デバイスが `fastboot boot` をサポートしている場合、まず `fastboot boot.img` を使えば書き込みせずにシステムを起動できます。予期せぬことが起こった場合は、もう一度再起動して起動してください。
:::
### 再起動
書き込みが完了したら、デバイスを再起動します：
```sh
fastboot reboot
```
## boot.img を手動でパッチ
デバイスによっては、boot.img のフォーマットが `lz4` でない、`gz` である、無圧縮であるなど、あまり一般的でないことがあります。最も典型的なのは Pixel で、boot.img フォーマットは `lz4_legacy` 圧縮、RAM ディスクは `gz` か `lz4_legacy` 圧縮です。この時、KernelSU が提供した boot.img を直接書き込むとデバイスが起動できなくなる場合があります。その場合は手動で boot.img に対してパッチしてください。
パッチ方式は一般的に2種類あります：
1. [Android-Image-Kitchen](https://forum.xda-developers.com/t/tool-android-image-kitchen-unpack-repack-kernel-ramdisk-win-android-linux-mac.2073775/)
2. [magiskboot](https://github.com/topjohnwu/Magisk/releases)
このうち、Android-Image-Kitchen は PC での操作に適しており、magiskboot はデバイスとの連携が必要です。
### 準備
1. お使いのデバイスの純正 boot.img を入手します。デバイスメーカーから入手できます。[payload-dumper-go](https://github.com/ssut/payload-dumper-go)が必要かもしれません。
2. お使いのデバイスの KMI バージョンに合った、KernelSU が提供する AnyKernel3 の ZIP ファイルをダウンロードします（*カスタムリカバリーでインストール*を参照してください）。
3. AnyKernel3 パッケージを展開し、KernelSU のカーネルファイルである `Image` ファイルを取得します。
### Android-Image-Kitchen を使う
1. Android-Image-Kitchen を PC にダウンロードします。
2. 純正 boot.img を Android-Image-Kitchen のルートフォルダに入れます。
3. Android-Image-Kitchen のルートディレクトリで `./unpackimg.sh boot.img` を実行して、boot.imgを展開します。
4. `split_img` ディレクトリの `boot.img-kernel` を AnyKernel3 から展開した `Image` に置き換えます（boot.img-kernelに名前が変わっていることに注意してください）。
5. Android-Image-Kitchen のルートディレクトリで `./repackimg.sh` を実行すると、 `image-new.img` というファイルが生成されます。
### magiskboot を使う
1. 最新の Magisk を[リリースページ](https://github.com/topjohnwu/Magisk/releases)からダウンロードしてください。
2. Magisk-*.apk を Magisk-vesion.zip に名前を変更して展開してください。
3. `Magisk-v25.2/lib/arm64-v8a/libmagiskboot.so`を adb でデバイスに転送します：`adb push Magisk-v25.2/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 でデバイスに書き込んでください。
## その他の方法
実はこれらのインストール方法はすべて、**元のカーネルを KernelSU が提供するカーネルに置き換える**という主旨でしかなく、これが実現できれば他の方法でもインストール可能です：
1. まず Magisk をインストールし、Magisk を通じて root 権限を取得し、カーネル管理アプリで KernelSU の AnyKernel ZIPをインストールする
2. PC 上で何らかの書き込みツールを使用し、KernelSU が提供するカーネルを書き込む

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が内部的に使用しているのもこちらです）。
::: Magisk との違い
KernelSU の Busybox は、Magisk プロジェクトから直接コンパイルされたバイナリファイルを使用するようになりました。**ありがとう 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
│ ├── .
│ └── .
├── .
├── .
```
::: Magisk との違い
KernelSU は Zygisk をビルトインでサポートしていないため、モジュール内に Zygisk に関連するコンテンツは存在しません。 しかし、[ZygiskOnKernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU) をインストールすれば 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%/*}`を使えばモジュールのベースディレクトリのパスを取得できます。スクリプト内でモジュールのパスをハードコードしないでください。
::: 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` は空のディレクトリに置き換えられます。
::: 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 から読み込まれます
├── ...
├── ... /* 残りのモジュールのファイル */
│
```
:::警告
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`）
::: 警告
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 @@
# 非公式の対応デバイス
::: 警告
このページでは他の開発者が管理している、KernelSU をサポートする GKI 以外のデバイス用のカーネルを紹介しています。
:::
::: 警告
このページはあなたのデバイスに対応するソースコードを見つけるためのものであり、そのソースコードが _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)
## ビルド方法
[ビルドするには](how-to-build)
## ディスカッション
- Telegram: [@KernelSU](https://t.me/KernelSU)

29
website/docs/ja_JP/index.md Normal file
View File

@@ -0,0 +1,29 @@
---
layout: home
title: Android 向けのカーネルベースの root ソリューション
hero:
name: KernelSU
text: Android 向けのカーネルベースの root ソリューション
tagline: ""
image:
src: /logo.png
alt: KernelSU
actions:
- theme: brand
text: はじめる
link: /guide/what-is-kernelsu
- theme: alt
text: GitHub で表示
link: https://github.com/tiann/KernelSU
features:
- title: カーネルベース
details: KernelSU は Linux カーネルモードで動作し、ユーザー空間よりも高度な制御が可能です。
- title: ホワイトリストの権限管理
details: root 権限を許可したアプリのみが `su` にアクセスでき、他のアプリは `su` を見つけられません。
- title: モジュール対応
details: KernelSU は OverlayFS により実際のシステムを改変せずに /system を変更できます。書き込み可能にすることさえできます。
- title: オープンソース
details: KernelSU は GPL-3 でライセンスされたオープンソースプロジェクトです。