website: update translations (#1760)
This commit is contained in:
@@ -4,7 +4,7 @@ The App Profile is a mechanism provided by KernelSU for customizing the configur
|
||||
|
||||
For applications granted root permissions (i.e., able to use `su`), the App Profile can also be referred to as the Root Profile. It allows customization of the `uid`, `gid`, `groups`, `capabilities`, and `SELinux` rules of the `su` command, thereby restricting the privileges of the root user. For example, it can grant network permissions only to firewall applications while denying file access permissions, or it can grant shell permissions instead of full root access for freeze applications: **keeping the power confined with the principle of least privilege.**
|
||||
|
||||
For ordinary applications without root permissions, the App Profile can control the behavior of the kernel and module system towards these applications. For instance, it can determine whether modifications resulting from modules should be addressed. The kernel and module system can make decisions based on this configuration, such as performing operations akin to "hiding"
|
||||
For ordinary applications without root permissions, the App Profile can control the behavior of the kernel and module system towards these applications. For instance, it can determine whether modifications resulting from modules should be addressed. The kernel and module system can make decisions based on this configuration, such as performing operations akin to "hiding".
|
||||
|
||||
## Root Profile
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ Certainly, yes.
|
||||
|
||||
## Does KernelSU support modules?
|
||||
|
||||
Yes, check [Module Page](module.md) please.
|
||||
Yes, check [Module Guide](module.md) please.
|
||||
|
||||
## Does KernelSU support Xposed?
|
||||
|
||||
|
||||
@@ -2,11 +2,11 @@
|
||||
|
||||
First, you should read the Android Official docs for kernel build:
|
||||
|
||||
1. [Building Kernels](https://source.android.com/docs/setup/build/building-kernels).
|
||||
2. [GKI Release Builds](https://source.android.com/docs/core/architecture/kernel/gki-release-builds).
|
||||
1. [Building Kernels](https://source.android.com/docs/setup/build/building-kernels)
|
||||
2. [GKI Release Builds](https://source.android.com/docs/core/architecture/kernel/gki-release-builds)
|
||||
|
||||
::: warning
|
||||
This page is for GKI devices, if you use an old kernel, please refer [how to integrate KernelSU for old kernel](how-to-integrate-for-non-gki).
|
||||
This page is for GKI devices, if you use an old kernel, please refer [How to integrate KernelSU for non-GKI kernels](how-to-integrate-for-non-gki).
|
||||
:::
|
||||
|
||||
## Build Kernel
|
||||
@@ -32,7 +32,7 @@ For example, to build an aarch64 kernel image:
|
||||
LTO=thin BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
|
||||
```
|
||||
|
||||
Don't forget to add the `LTO=thin` flag, otherwise the build may fail if your computer's memory is less then 24Gb.
|
||||
Don't forget to add the `LTO=thin` flag, otherwise the build may fail if your computer's memory is less then 24 GB.
|
||||
|
||||
Starting from Android 13, the kernel is built by `bazel`:
|
||||
|
||||
|
||||
@@ -8,8 +8,8 @@ First, you should be able to build a bootable kernel from kernel source code. If
|
||||
|
||||
If you can build a bootable kernel, there are two ways to integrate KernelSU to the kernel source code:
|
||||
|
||||
1. Automatically with `kprobe`.
|
||||
2. Manually.
|
||||
1. Automatically with `kprobe`
|
||||
2. Manually
|
||||
|
||||
## Integrate with kprobe
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
Download KernelSU manager APP from [GitHub Releases](https://github.com/tiann/KernelSU/releases) and install it to your device:
|
||||
|
||||
- If the app shows `Unsupported`, it means **You should compile the kernel yourself**, KernelSU won't and never provide a boot image for you to flash.
|
||||
- If the app shows `Unsupported`, it means **you should compile the kernel yourself**, KernelSU won't and never provide a boot image for you to flash.
|
||||
- If the app shows `Not installed`, then your devices is officially supported by KernelSU.
|
||||
|
||||
:::info
|
||||
@@ -53,7 +53,7 @@ Therefore, kernels with latest security patch levels are preferred for maintaini
|
||||
|
||||
Please note: **Kernel version and Android version are not necessarily the same!**
|
||||
|
||||
If you find that your kernel version is `android12-5.10.101`, but your Android system version is Android 13 or other, please don't be surprised, because the version number of the Android system is not necessarily the same as the version number of the Linux kernel. The version number of the Linux kernel is generally correspondent to the version of the Android system that comes with the **device when it is shipped**. If the Android system is upgraded later, the kernel version will generally not change. So before flashing anything, **please always refer to the kernel version!!**
|
||||
If you find that your kernel version is `android12-5.10.101`, but your Android system version is Android 13 or other, please don't be surprised, because the version number of the Android system is not necessarily the same as the version number of the Linux kernel. The version number of the Linux kernel is generally correspondent to the version of the Android system that comes with the **device when it is shipped**. If the Android system is upgraded later, the kernel version will generally not change. So before flashing anything, **please always refer to the kernel version!**
|
||||
|
||||
## Introduction
|
||||
|
||||
@@ -64,14 +64,14 @@ Since version `0.9.0`, KernelSU supports two running modes on GKI devices:
|
||||
|
||||
These two modes are suitable for different scenarios, and you can choose the one according to your needs.
|
||||
|
||||
### GKI Mode {#gki-mode}
|
||||
### GKI mode {#gki-mode}
|
||||
|
||||
In GKI mode, the original kernel of the device will be replaced with the generic kernel image provided by KernelSU. The advantages of GKI mode are:
|
||||
|
||||
1. Strong universality, suitable for most devices; for example, Samsung has enabled KNOX devices, and LKM mode cannot operate. There are also some niche modified devices that can only use GKI mode.
|
||||
2. Can be used without relying on official firmware; no need to wait for official firmware updates, as long as the KMI is consistent, it can be used.
|
||||
|
||||
### LKM Mode {#lkm-mode}
|
||||
### LKM mode {#lkm-mode}
|
||||
|
||||
In LKM mode, the original kernel of the device will not be replaced, but the loadable kernel module will be loaded into the device kernel. The advantages of LKM mode are:
|
||||
|
||||
@@ -88,7 +88,7 @@ After opening the manager, you can see the current mode of the device on the hom
|
||||
|
||||
If your device is a mobile phone, we recommend that you prioritize LKM mode; if your device is an emulator, WSA, or Waydroid, we recommend that you prioritize GKI mode.
|
||||
|
||||
## LKM Installation
|
||||
## LKM installation
|
||||
|
||||
### Get the official firmware
|
||||
|
||||
@@ -105,7 +105,7 @@ Unlike GKI mode, LKM mode will modify the `ramdisk`, so on devices with Android
|
||||
Open the manager, click the installation icon in the upper right corner, and several options will appear:
|
||||
|
||||
1. Select and patch a file; if your phone does not have root permissions, you can choose this option, and then select your official firmware, the manager will automatically patch it; you only need to flash this patched file to permanently obtain root permissions.
|
||||
2. Install directly; if your phone is already rooted, you can choose this option, the manager will automatically get your device information, and then automatically patch the official firmware, and then flash it; you can consider using `fastboot boot` KernelSU's GKI kernel to get temporary root and install the manager, and then use this option; this is also the main way to upgrade KernelSU;
|
||||
2. Install directly; if your phone is already rooted, you can choose this option, the manager will automatically get your device information, and then automatically patch the official firmware, and then flash it; you can consider using `fastboot boot` KernelSU's GKI kernel to get temporary root and install the manager, and then use this option; this is also the main way to upgrade KernelSU.
|
||||
3. Install to another partition; if your device supports A/B partition, you can choose this option, the manager will automatically patch the official firmware, and then install it to another partition; this method is suitable for devices after OTA, you can directly install it to another partition after OTA, and then restart the device.
|
||||
|
||||
### Use the command line
|
||||
@@ -146,7 +146,7 @@ The most common usage is:
|
||||
ksud boot-patch -b <boot.img> --kmi android13-5.10
|
||||
```
|
||||
|
||||
## GKI mode Installation
|
||||
## GKI mode installation
|
||||
|
||||
There are several installation methods for GKI mode, each suitable for a different scenario, so please choose accordingly:
|
||||
|
||||
@@ -163,7 +163,7 @@ If your device's `boot.img` uses a commonly used compression format, you can use
|
||||
|
||||
KernelSU provides a generic boot.img for GKI devices, and you should flash the boot.img to the boot partition of the device.
|
||||
|
||||
You can download boot.img from [GitHub Release](https://github.com/tiann/KernelSU/releases), please note that you should use the correct version of boot.img. If you don't know which file to download, please carefully read the description of [KMI](#kmi) and [Security Patch Level](#security-patch-level) in this document.
|
||||
You can download boot.img from [GitHub Release](https://github.com/tiann/KernelSU/releases), please note that you should use the correct version of boot.img. If you don't know which file to download, please carefully read the description of [KMI](#kmi) and [Security patch level](#security-patch-level) in this document.
|
||||
|
||||
Normally, there are three boot files in different formats under the same KMI and security patch level. They are all the same except for the kernel compression format. Please check the kernel compression format of your original boot.img. You should use the correct format, such as `lz4`, `gz`; if you use an incorrect compression format, you may encounter bootloop after flashing boot.
|
||||
|
||||
@@ -173,7 +173,7 @@ Normally, there are three boot files in different formats under the same KMI and
|
||||
3. For Pixel devices, follow the instructions below.
|
||||
:::
|
||||
|
||||
### flash boot.img to device
|
||||
### Flash boot.img to device
|
||||
|
||||
Use `adb` to connect your device, then execute `adb reboot bootloader` to enter fastboot mode, then use this command to flash KernelSU:
|
||||
|
||||
@@ -185,7 +185,7 @@ fastboot flash boot boot.img
|
||||
If your device supports `fastboot boot`, you can first use `fastboot boot boot.img` to try to use boot.img to boot the system first. If something unexpected happens, restart it again to boot.
|
||||
:::
|
||||
|
||||
### reboot
|
||||
### Reboot
|
||||
|
||||
After the flashing process is complete, you should reboot your device:
|
||||
|
||||
@@ -195,7 +195,7 @@ fastboot reboot
|
||||
|
||||
## Install with Kernel Flasher
|
||||
|
||||
Step:
|
||||
Steps:
|
||||
|
||||
1. Download the AnyKernel3 zip. If you don't know which file to download, please carefully read the description of [KMI](#kmi) and [Security Patch Level](#security-patch-level) in this document.
|
||||
2. Open the Kernel Flash App (grant necessary root permissions) and use the provided AnyKernel3 zip to flash.
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Module guides
|
||||
# Module Guide
|
||||
|
||||
KernelSU provides a module mechanism that achieves the effect of modifying the system directory while maintaining the integrity of the system partition. This mechanism is commonly known as "systemless".
|
||||
|
||||
@@ -16,12 +16,12 @@ Every single shell script running in the context of KernelSU will be executed in
|
||||
|
||||
For those who want to use this "Standalone Mode" feature outside of KernelSU, there are 2 ways to enable it:
|
||||
|
||||
1. Set environment variable `ASH_STANDALONE` to `1` .<br>Example: `ASH_STANDALONE=1 /data/adb/ksu/bin/busybox sh <script>`
|
||||
1. Set environment variable `ASH_STANDALONE` to `1` <br>Example: `ASH_STANDALONE=1 /data/adb/ksu/bin/busybox sh <script>`
|
||||
2. Toggle with command-line options:<br>`/data/adb/ksu/bin/busybox sh -o standalone <script>`
|
||||
|
||||
To make sure all subsequent `sh` shell executed also runs in standalone mode, option 1 is the preferred method (and this is what KernelSU and the KernelSU manager use internally) as environment variables are inherited down to child processes.
|
||||
|
||||
::: tip difference with Magisk
|
||||
::: tip Difference with Magisk
|
||||
|
||||
KernelSU's BusyBox is now using the binary file compiled directly from the Magisk project. **Thanks to Magisk!** Therefore, you don't have to worry about compatibility issues between BusyBox scripts in Magisk and KernelSU because they are exactly the same!
|
||||
:::
|
||||
@@ -82,7 +82,7 @@ A KernelSU module is a folder placed in `/data/adb/modules` with the structure b
|
||||
├── .
|
||||
```
|
||||
|
||||
::: tip difference with Magisk
|
||||
::: tip Difference with Magisk
|
||||
KernelSU does not have built-in support for Zygisk, so there is no content related to Zygisk in the module. However, you can use [ZygiskNext](https://github.com/Dr-TSNG/ZygiskNext) to support Zygisk modules. In this case, the content of the Zygisk module is identical to that supported by Magisk.
|
||||
:::
|
||||
|
||||
@@ -108,11 +108,11 @@ description=<string>
|
||||
|
||||
### Shell scripts
|
||||
|
||||
Please read the [Boot Scripts](#boot-scripts) section to understand the difference between `post-fs-data.sh` and `service.sh`. For most module developers, `service.sh` should be good enough if you just need to run a boot script, if you need to run the script after boot completed, please use `boot-completed.sh`. If you want to do something after mounting overlayfs, please use `post-mount.sh`.
|
||||
Please read the [Boot scripts](#boot-scripts) section to understand the difference between `post-fs-data.sh` and `service.sh`. For most module developers, `service.sh` should be good enough if you just need to run a boot script, if you need to run the script after boot completed, please use `boot-completed.sh`. If you want to do something after mounting overlayfs, please use `post-mount.sh`.
|
||||
|
||||
In all scripts of your module, please use `MODDIR=${0%/*}` to get your module's base directory path; do **NOT** hardcode your module path in scripts.
|
||||
|
||||
::: tip difference with Magisk
|
||||
::: tip Difference with Magisk
|
||||
You can use the environment variable KSU to determine if a script is running in KernelSU or Magisk. If running in KernelSU, this value will be set to true.
|
||||
:::
|
||||
|
||||
@@ -134,20 +134,22 @@ REMOVE="
|
||||
"
|
||||
```
|
||||
|
||||
The above list will execute `mknod $MODPATH/system/app/YouTuBe c 0 0` and `mknod $MODPATH/system/app/Bloatware c 0 0`; and `/system/app/YouTube` and `/system/app/Bloatware` will be removed after the module takes effect.
|
||||
The above list will execute `mknod $MODPATH/system/app/YouTube c 0 0` and `mknod $MODPATH/system/app/Bloatware c 0 0`; and `/system/app/YouTube` and `/system/app/Bloatware` will be removed after the module takes effect.
|
||||
|
||||
If you want to replace a directory in the system, you need to create a directory with the same path in your module directory, and then set the attribute `setfattr -n trusted.overlay.opaque -v y <TARGET>` for this directory. This way, the overlayfs system will automatically replace the corresponding directory in the system (without changing the /system partition).
|
||||
|
||||
You can declare a variable named `REPLACE` in your `customize.sh` file, which includes a list of directories to be replaced, and KernelSU will automatically perform the corresponding operations in your module directory. For example:
|
||||
|
||||
```sh
|
||||
REPLACE="
|
||||
/system/app/YouTube
|
||||
/system/app/Bloatware
|
||||
"
|
||||
```
|
||||
|
||||
This list will automatically create the directories `$MODPATH/system/app/YouTube` and `$MODPATH/system/app/Bloatware`, and then execute `setfattr -n trusted.overlay.opaque -v y $MODPATH/system/app/YouTube` and `setfattr -n trusted.overlay.opaque -v y $MODPATH/system/app/Bloatware`. After the module takes effect, `/system/app/YouTube` and `/system/app/Bloatware` will be replaced with empty directories.
|
||||
|
||||
::: tip difference with Magisk
|
||||
::: tip Difference with Magisk
|
||||
|
||||
KernelSU's systemless mechanism is implemented through the kernel's overlayfs, while Magisk currently uses magic mount (bind mount). The two implementation methods have significant differences, but the ultimate goal is the same: to modify /system files without physically modifying the /system partition.
|
||||
:::
|
||||
@@ -177,7 +179,7 @@ module.zip
|
||||
```
|
||||
|
||||
:::warning
|
||||
KernelSU module is NOT supported to be installed via a custom recovery!!
|
||||
KernelSU module is **NOT** supported to be installed via a Custom Recovery!
|
||||
:::
|
||||
|
||||
### Customization
|
||||
@@ -203,7 +205,7 @@ The `customize.sh` script runs in KernelSU's BusyBox `ash` shell with "Standalon
|
||||
- `API` (int): the API level (Android version) of the device (e.g., `23` for Android 6.0).
|
||||
|
||||
::: warning
|
||||
In KernelSU, MAGISK_VER_CODE is always 25200 and MAGISK_VER is always v25.2. Please do not use these two variables to determine whether it is running on KernelSU or not.
|
||||
In KernelSU, `MAGISK_VER_CODE` is always `25200` and `MAGISK_VER` is always `v25.2`. Please do not use these two variables to determine whether it is running on KernelSU or not.
|
||||
:::
|
||||
|
||||
#### Functions
|
||||
@@ -248,12 +250,12 @@ In KernelSU, scripts are divided into two types based on their running mode: pos
|
||||
|
||||
In KernelSU, startup scripts are divided into two types based on their storage location: general scripts and module scripts.
|
||||
|
||||
- General Scripts
|
||||
- General scripts
|
||||
- Placed in `/data/adb/post-fs-data.d`, `/data/adb/service.d`, `/data/adb/post-mount.d` or `/data/adb/boot-completed.d.`
|
||||
- Only executed if the script is set as executable (`chmod +x script.sh`)
|
||||
- Scripts in `post-fs-data.d` runs in post-fs-data mode, and scripts in `service.d` runs in late_start service mode.
|
||||
- Modules should **NOT** add general scripts during installation.
|
||||
- Module Scripts
|
||||
- Module scripts
|
||||
- Placed in the module's own folder.
|
||||
- Only executed if the module is enabled.
|
||||
- `post-fs-data.sh` runs in post-fs-data mode, `service.sh` runs in late_start service mode, `boot-completed.sh` runs on boot completed, `post-mount.sh` runs on overlayfs mounted.
|
||||
|
||||
@@ -20,8 +20,8 @@ Installing modules can be a more common cause of bricking your device, but we mu
|
||||
|
||||
If you have flashed a module that has been proven to be safe but causes your device to fail to boot, then this situation is easily recoverable in KernelSU without any worries. KernelSU has built-in mechanisms to rescue your device, including the following:
|
||||
|
||||
1. AB update.
|
||||
2. Rescue by pressing Volume Down.
|
||||
1. AB update
|
||||
2. Rescue by pressing Volume Down
|
||||
|
||||
#### AB update
|
||||
|
||||
|
||||
@@ -8,13 +8,13 @@ The main feature of KernelSU is it is **Kernel-based**. KernelSU works in kernel
|
||||
|
||||
And also, KernelSU provides a module system via overlayfs, which allows you to load your custom plugin into system. It also provides a mechanism to modify files in `/system` partition.
|
||||
|
||||
## How to use
|
||||
## How to use?
|
||||
|
||||
Please refer: [Installation](installation)
|
||||
|
||||
## How to build
|
||||
## How to build?
|
||||
|
||||
[How to build](how-to-build)
|
||||
Please refer: [How to build](how-to-build)
|
||||
|
||||
## Discussion
|
||||
|
||||
|
||||
Reference in New Issue
Block a user