website: update translations (#1760)

This commit is contained in:
igor
2024-05-25 00:08:35 -03:00
committed by GitHub
parent 49157113c3
commit 57a5f39f81
15 changed files with 89 additions and 87 deletions

View File

@@ -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 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 ## Root Profile

View File

@@ -12,7 +12,7 @@ Certainly, yes.
## Does KernelSU support modules? ## Does KernelSU support modules?
Yes, check [Module Page](module.md) please. Yes, check [Module Guide](module.md) please.
## Does KernelSU support Xposed? ## Does KernelSU support Xposed?

View File

@@ -2,11 +2,11 @@
First, you should read the Android Official docs for kernel build: First, you should read the Android Official docs for kernel build:
1. [Building Kernels](https://source.android.com/docs/setup/build/building-kernels). 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). 2. [GKI Release Builds](https://source.android.com/docs/core/architecture/kernel/gki-release-builds)
::: warning ::: 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 ## 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 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`: Starting from Android 13, the kernel is built by `bazel`:

View File

@@ -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: If you can build a bootable kernel, there are two ways to integrate KernelSU to the kernel source code:
1. Automatically with `kprobe`. 1. Automatically with `kprobe`
2. Manually. 2. Manually
## Integrate with kprobe ## Integrate with kprobe

View File

@@ -4,7 +4,7 @@
Download KernelSU manager APP from [GitHub Releases](https://github.com/tiann/KernelSU/releases) and install it to your device: 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. - If the app shows `Not installed`, then your devices is officially supported by KernelSU.
:::info :::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!** 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 ## 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. 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: 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. 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. 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: 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. 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 ### 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: 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. 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. 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 ### Use the command line
@@ -146,7 +146,7 @@ The most common usage is:
ksud boot-patch -b <boot.img> --kmi android13-5.10 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: 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. 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. 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. 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: 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. 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: After the flashing process is complete, you should reboot your device:
@@ -195,7 +195,7 @@ fastboot reboot
## Install with Kernel Flasher ## 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. 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. 2. Open the Kernel Flash App (grant necessary root permissions) and use the provided AnyKernel3 zip to flash.

View File

@@ -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". 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: 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>` 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. 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! 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. 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 ### 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. 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. 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). 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: 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=" REPLACE="
/system/app/YouTube /system/app/YouTube
/system/app/Bloatware /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. 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. 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 :::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 ### 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). - `API` (int): the API level (Android version) of the device (e.g., `23` for Android 6.0).
::: warning ::: 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 #### 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. 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.` - 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`) - 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. - 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. - Modules should **NOT** add general scripts during installation.
- Module Scripts - Module scripts
- Placed in the module's own folder. - Placed in the module's own folder.
- Only executed if the module is enabled. - 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. - `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.

View File

@@ -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: 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. 1. AB update
2. Rescue by pressing Volume Down. 2. Rescue by pressing Volume Down
#### AB update #### AB update

View File

@@ -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. 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) 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 ## Discussion

View File

@@ -47,7 +47,7 @@ Achamos que não e esse não é o nosso objetivo. O Magisk é bom o suficiente p
É possível, o KernelSU é portado para o kernel 4.14 agora, para o kernel mais antigo, você precisa portar manualmente e PRs são sempre bem-vindas! É possível, o KernelSU é portado para o kernel 4.14 agora, para o kernel mais antigo, você precisa portar manualmente e PRs são sempre bem-vindas!
## Como integrar o KernelSU para o kernel antigo? ## Como integrar o KernelSU para um kernel antigo?
Por favor, consulte a guia [Como integrar o KernelSU para kernels não GKI](how-to-integrate-for-non-gki). Por favor, consulte a guia [Como integrar o KernelSU para kernels não GKI](how-to-integrate-for-non-gki).
@@ -69,7 +69,7 @@ Claro. Mas o KernelSU não tem suporte a hosts integrados, você pode instalar [
## Por que existe um enorme arquivo de 1 TB? ## Por que existe um enorme arquivo de 1 TB?
O arquivo `modules.img` de 1 TB é um arquivo de imagem de disco, **não se preocupe com seu tamanho**, é um tipo especial de arquivo conhecido como [arquivo esparso](https://en.wikipedia.org/wiki/Sparse_file), seu tamanho real é apenas o tamanho do módulo que você usa e diminuirá dinamicamente após você excluir o módulo. Na verdade, ele não ocupa 1 TB de espaço em disco (na verdade, seu celular pode não ter tanto espaço). O arquivo `modules.img` de 1 TB é um arquivo de imagem de disco, **não se preocupe com seu tamanho**, é um tipo especial de arquivo conhecido como [arquivo esparso](https://en.wikipedia.org/wiki/Sparse_file), seu tamanho real é apenas o tamanho do módulo que você usa e diminuirá dinamicamente após você excluir o módulo. Na verdade, ele não ocupa 1 TB de espaço em disco (seu celular pode não ter tanto espaço).
Se você estiver realmente insatisfeito com o tamanho deste arquivo, você pode usar o comando `resize2fs -M` para torná-lo seu tamanho real, mas o módulo pode não funcionar corretamente neste momento e não forneceremos nenhum suporte para isso. Se você estiver realmente insatisfeito com o tamanho deste arquivo, você pode usar o comando `resize2fs -M` para torná-lo seu tamanho real, mas o módulo pode não funcionar corretamente neste momento e não forneceremos nenhum suporte para isso.

View File

@@ -26,7 +26,7 @@ O `<kernel_manifest.xml>` é um arquivo de manifesto que pode determinar uma com
Por favor, verifique [Como criar kernels](https://source.android.com/docs/setup/build/building-kernels) primeiro. Por favor, verifique [Como criar kernels](https://source.android.com/docs/setup/build/building-kernels) primeiro.
Por exemplo, precisamos compilar a imagem do kernel `aarch64`: Por exemplo, para compilar uma imagem de kernel `aarch64`:
```sh ```sh
LTO=thin BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh LTO=thin BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
@@ -41,7 +41,7 @@ tools/bazel build --config=fast //common:kernel_aarch64_dist
``` ```
:::info INFORMAÇÕES :::info INFORMAÇÕES
Para alguns kernel do Android 14, para fazer o Wi-Fi/Bluetooth funcionar. Pode ser necessário remover todas as exportações protegidas pelo GKI: Para alguns kernel do Android 14, para fazer o Wi-Fi/Bluetooth funcionar, pode ser necessário remover todas as exportações protegidas pelo GKI:
```sh ```sh
rm common/android/abi_gki_protected_exports_* rm common/android/abi_gki_protected_exports_*
@@ -50,7 +50,7 @@ rm common/android/abi_gki_protected_exports_*
## Compilar o kernel com KernelSU ## Compilar o kernel com KernelSU
Se você conseguir compilar o kernel com sucesso, então compilar o KernelSU é muito fácil. Selecione qualquer um executado no diretório raiz de origem do kernel: Se você conseguir compilar o kernel com sucesso, adicionar suporte ao KernelSU a ele será relativamente fácil. Na raiz do diretório de origem do kernel, execute qualquer uma das opções listadas abaixo:
::: code-group ::: code-group

View File

@@ -2,7 +2,7 @@
O KernelSU pode ser integrado em kernels não GKI e foi portado para 4.14 e versões anteriores. O KernelSU pode ser integrado em kernels não GKI e foi portado para 4.14 e versões anteriores.
Devido à fragmentação de kernels não GKI, não temos uma maneira uniforme de construí-lo, portanto não podemos fornecer o boot.img não GKI. Mas você mesmo pode compilar o kernel com o KernelSU integrado. Devido à fragmentação de kernels não GKI, não temos uma maneira universal de construí-lo, portanto não podemos fornecer o boot.img não GKI. Mas você mesmo pode compilar o kernel com o KernelSU integrado.
Primeiro, você deve ser capaz de compilar um kernel inicializável a partir do código-fonte do kernel. Se o kernel não for de código aberto, será difícil executar o KernelSU no seu dispositivo. Primeiro, você deve ser capaz de compilar um kernel inicializável a partir do código-fonte do kernel. Se o kernel não for de código aberto, será difícil executar o KernelSU no seu dispositivo.
@@ -23,17 +23,17 @@ curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh
Então, você deve verificar se o kprobe está ativado na configuração do seu kernel, se não estiver, adicione estas configurações a ele: Então, você deve verificar se o kprobe está ativado na configuração do seu kernel, se não estiver, adicione estas configurações a ele:
``` ```txt
CONFIG_KPROBES=y CONFIG_KPROBES=y
CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KPROBES=y
CONFIG_KPROBE_EVENTS=y CONFIG_KPROBE_EVENTS=y
``` ```
E construa seu kernel novamente, KernelSU deve funcionar bem. E agora, quando você recompilar seu kernel, o KernelSU deve funcionar bem.
Se você descobrir que o KPROBES ainda não está ativado, você pode tentar ativar `CONFIG_MODULES`. (Se ainda assim não surtir efeito, use `make menuconfig` para procurar outras dependências do KPROBES) Se você descobrir que o KPROBES ainda não está ativado, você pode tentar ativar `CONFIG_MODULES`. Se ainda assim não surtir efeito, use `make menuconfig` para procurar outras dependências do KPROBES.
Mas se você entrar em um bootloop quando o KernelSU for integrado, talvez o **kprobe esteja quebrado em seu kernel**. Você deve corrigir o bug do kprobe ou usar o segundo caminho. Mas se você entrar em um bootloop quando o KernelSU for integrado, pode ser porque o **kprobe esteja quebrado em seu kernel**, o que significa que você deve corrigir o bug do kprobe ou usar outra maneira.
:::tip COMO VERIFICAR SE O KPROBE ESTÁ QUEBRADO? :::tip COMO VERIFICAR SE O KPROBE ESTÁ QUEBRADO?
@@ -47,7 +47,7 @@ Se o seu kernel for inferior a 5.9, você deve portar `path_umount` para `fs/nam
## Modifique manualmente a fonte do kernel ## Modifique manualmente a fonte do kernel
Se o kprobe não funcionar no seu kernel (pode ser um bug do upstream ou do kernel abaixo de 4.8), então você pode tentar desta forma: Se o kprobe não funcionar no seu kernel (pode ser um bug do upstream ou do kernel abaixo de 4.8), então você pode tentar o seguinte:
Primeiro, adicione o KernelSU à árvore de origem do kernel: Primeiro, adicione o KernelSU à árvore de origem do kernel:
@@ -67,9 +67,9 @@ curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh
::: :::
Tenha em mente que em alguns dispositivos, seu defconfig pode estar em `arch/arm64/configs` ou em outros casos `arch/arm64/configs/vendor/your_defconfig`. Por exemplo, em seu defconfig, habilite `CONFIG_KSU` com **y** para habilitar ou **n** para desabilitar. Seu caminho será algo como: Tenha em mente que em alguns dispositivos, seu defconfig pode estar em `arch/arm64/configs` ou em outros casos `arch/arm64/configs/vendor/your_defconfig`. Para qualquer defconfig que você estiver usando, certifique-se de ativar `CONFIG_KSU` com `y` para ativa-lo ou `n` para desativa-lo. Por exemplo, caso você opte por ativa-lo, seu defconfig deverá conter a seguinte string:
`arch/arm64/configs/...`
``` ```txt
# KernelSU # KernelSU
CONFIG_KSU=y CONFIG_KSU=y
``` ```
@@ -200,12 +200,12 @@ index 376543199b5a..82adcef03ecc 100644
Você deve encontrar as quatro funções no código-fonte do kernel: Você deve encontrar as quatro funções no código-fonte do kernel:
1. do_faccessat, geralmente em `fs/open.c` 1. `do_faccessat`, geralmente em `fs/open.c`
2. do_execveat_common, geralmente em `fs/exec.c` 2. `do_execveat_common`, geralmente em `fs/exec.c`
3. vfs_read, geralmente em `fs/read_write.c` 3. `vfs_read`, geralmente em `fs/read_write.c`
4. vfs_statx, geralmente em `fs/stat.c` 4. `vfs_statx`, geralmente em `fs/stat.c`
Se o seu kernel não tiver `vfs_statx`, use `vfs_fstatat`: Se o seu kernel não tiver a função `vfs_statx`, use `vfs_fstatat`:
```diff ```diff
diff --git a/fs/stat.c b/fs/stat.c diff --git a/fs/stat.c b/fs/stat.c
@@ -266,7 +266,7 @@ index 2ff887661237..e758d7db7663 100644
### Modo de Segurança ### Modo de Segurança
Para ativar o Modo de Segurança integrado do KernelSU, você também deve modificar `input_handle_event` em `drivers/input/input.c`: Para ativar o Modo de Segurança integrado do KernelSU, você também deve modificar a função `input_handle_event` em `drivers/input/input.c`:
:::tip DICA :::tip DICA
É altamente recomendável ativar este recurso, é muito útil para evitar bootloops! É altamente recomendável ativar este recurso, é muito útil para evitar bootloops!

View File

@@ -45,15 +45,15 @@ Observe que o SubLevel na versão do kernel não faz parte do KMI! Isso signific
### Nível do patch de segurança {#security-patch-level} ### Nível do patch de segurança {#security-patch-level}
Dispositivos Android mais recentes podem ter mecanismos anti-rollback que não permitem flashar um boot.img com um nível do patch de segurança antigo. Por exemplo, se o kernel do seu dispositivo for `5.10.101-android12-9-g30979850fc20`, o patch de segurança será `2023-11`, mesmo se você atualizar o kernel consistente com o KMI do kernel, se o nível do patch de segurança for anterior a `2023-11` (como `2023-06`), então isso pode causar bootloop. Dispositivos Android mais recentes podem ter mecanismos anti-rollback que não permitem flashar um boot.img com um nível do patch de segurança antigo. Por exemplo, se o kernel do seu dispositivo for `5.10.101-android12-9-g30979850fc20`, o patch de segurança será `2023-11`, mesmo se você atualizar o kernel correspondente ao KMI do kernel, se o nível do patch de segurança for anterior a `2023-11` (como `2023-06`), então isso pode causar bootloop.
Portanto, os kernels com os níveis do patch de segurança mais recentes são preferidos, mantendo a consistência do KMI. Portanto, os kernels com os níveis do patch de segurança mais recentes são preferidos para manter a correspondência com o KMI.
### Versão do kernel vs Versão do Android ### Versão do kernel vs Versão do Android
Por favor, observe: **A versão do kernel e a versão do Android não são necessariamente iguais!** Por favor, observe: **A versão do kernel e a versão do Android não são necessariamente iguais!**
Se você descobrir que a versão do seu kernel é `android12-5.10.101`, mas a versão do seu sistema Android é Android 13 ou outra, não se surpreenda, pois o número da versão do sistema Android não é necessariamente igual ao número da versão do kernel Linux. O número da versão do kernel Linux geralmente é consistente com a versão do sistema Android que acompanha o **dispositivo quando ele é enviado**. Se o sistema Android for atualizado posteriormente, a versão do kernel geralmente não será alterada. Se você precisar fazer o flash, **por favor, consulte sempre a versão do kernel!** Se você descobrir que a versão do seu kernel é `android12-5.10.101`, mas a versão do seu sistema Android é Android 13 ou outra, não se surpreenda, pois o número da versão do sistema Android não é necessariamente igual ao número da versão do kernel Linux. O número da versão do kernel Linux geralmente é correspondente à versão do sistema Android que acompanha o **dispositivo quando ele é enviado**. Se o sistema Android for atualizado posteriormente, a versão do kernel geralmente não será alterada. Então, antes de flashar qualquer coisa, **consulte sempre a versão do kernel!**
## Introdução ## Introdução
@@ -76,9 +76,9 @@ No modo GKI, o kernel original do dispositivo será substituído pela imagem gen
No modo LKM, o kernel original do dispositivo não será substituído, mas o módulo do kernel carregável será carregado no kernel do dispositivo. As vantagens do modo LKM são: No modo LKM, o kernel original do dispositivo não será substituído, mas o módulo do kernel carregável será carregado no kernel do dispositivo. As vantagens do modo LKM são:
1. Não substituirá o kernel original do dispositivo. Se você tiver os requisitos especiais para o kernel original do dispositivo ou quiser usar o KernelSU enquanto usa um kernel de terceiros, poderá usar o modo LKM. 1. Não substituirá o kernel original do dispositivo. Se você tiver os requisitos especiais para o kernel original do dispositivo ou quiser usar o KernelSU enquanto usa um kernel de terceiros, poderá usar o modo LKM.
2. É mais conveniente atualizar o OTA. Ao atualizar o KernelSU, você pode instalá-lo diretamente no gerenciador sem atualizar manualmente. Após o sistema OTA, você pode instalá-lo diretamente no segundo slot sem flashar manualmente. 2. É mais conveniente atualizar o OTA. Ao atualizar o KernelSU, você pode instalá-lo diretamente no gerenciador sem flashar manualmente. Após o sistema OTA, você pode instalá-lo diretamente no segundo slot sem flashar manualmente.
3. Adequado para alguns cenários especiais, por exemplo, o LKM também pode ser carregado com privilégios root temporários. Como não é necessário substituir a partição boot, ele não acionará o AVB e não causará o bloqueio do dispositivo. 3. Adequado para alguns cenários especiais, por exemplo, o LKM também pode ser carregado com privilégios root temporários. Como não é necessário substituir a partição boot, ele não acionará o AVB e não causará o bloqueio do dispositivo.
4. O LKM pode ser desinstalado temporariamente. Se você deseja cancelar temporariamente o root, você pode desinstalar o LKM, este processo não requer o flash de partições, nem mesmo a reinicialização do dispositivo. Se quiser fazer root novamente, basta reiniciar o dispositivo. 4. O LKM pode ser desinstalado temporariamente. Se você deseja desativar temporariamente o acesso root, você pode desinstalar o LKM, este processo não requer o flash de partições, nem mesmo a reinicialização do dispositivo. Se quiser ativar o root novamente, basta reiniciar o dispositivo.
:::tip COEXISTÊNCIA DE DOIS MODOS :::tip COEXISTÊNCIA DE DOIS MODOS
Após abrir o gerenciador, você pode ver o modo atual do dispositivo na página inicial. Observe que a prioridade do modo GKI é maior que a do LKM. Por exemplo, se você usar o kernel GKI para substituir o kernel original e usar LKM para corrigir o kernel GKI, o LKM será ignorado e o dispositivo sempre será executado no modo GKI. Após abrir o gerenciador, você pode ver o modo atual do dispositivo na página inicial. Observe que a prioridade do modo GKI é maior que a do LKM. Por exemplo, se você usar o kernel GKI para substituir o kernel original e usar LKM para corrigir o kernel GKI, o LKM será ignorado e o dispositivo sempre será executado no modo GKI.
@@ -98,13 +98,13 @@ Existem muitas maneiras de obter o firmware oficial. Se o seu dispositivo suport
Se o seu dispositivo não suportar `fastboot boot`, pode ser necessário baixar manualmente o pacote de firmware oficial e extrair o boot dele. Se o seu dispositivo não suportar `fastboot boot`, pode ser necessário baixar manualmente o pacote de firmware oficial e extrair o boot dele.
Ao contrário do modo GKI, o modo LKM modificará o `ramdisk`, portanto, em dispositivos com Android 13, ele precisa corrigir a partição `init_boot` em vez da partição `boot`, enquanto o modo GKI sempre opera a partição `boot`. Ao contrário do modo GKI, o modo LKM modificará o `ramdisk`, portanto, em dispositivos com Android 13, ele precisa corrigir a partição `init_boot` em vez da partição `boot`, enquanto isso, o modo GKI sempre opera a partição `boot`.
### Use o gerenciador ### Use o gerenciador
Abra o gerenciador, clique no ícone de instalação no canto superior direito e diversas opções aparecerão: Abra o gerenciador, clique no ícone de instalação no canto superior direito e diversas opções aparecerão:
1. Selecione e corrija um arquivo. Se o seu telefone não tiver privilégios root, você pode escolher esta opção e, em seguida, selecionar seu firmware oficial, e o gerenciador irá corrigi-lo automaticamente. Você só precisa flashar este arquivo corrigido para obter privilégios root permanentemente. 1. Selecione e corrija um arquivo. Se o seu telefone não tiver privilégios root, você pode escolher esta opção e, em seguida, selecionar seu firmware oficial, o gerenciador irá corrigi-lo automaticamente. Você só precisa flashar este arquivo corrigido para obter privilégios root permanentemente.
2. Instale diretamente. Se o seu telefone já estiver rooteado, você pode escolher esta opção, o gerenciador obterá automaticamente as informações do seu dispositivo e, em seguida, corrigirá o firmware oficial e irá fazer o flash automaticamente. Você pode considerar usar `fastboot boot` e o kernel GKI do KernelSU para obter root temporário e instalar o gerenciador, e então usar esta opção. Esta também é a principal forma de atualizar o KernelSU. 2. Instale diretamente. Se o seu telefone já estiver rooteado, você pode escolher esta opção, o gerenciador obterá automaticamente as informações do seu dispositivo e, em seguida, corrigirá o firmware oficial e irá fazer o flash automaticamente. Você pode considerar usar `fastboot boot` e o kernel GKI do KernelSU para obter root temporário e instalar o gerenciador, e então usar esta opção. Esta também é a principal forma de atualizar o KernelSU.
3. Instale em outra partição. Se o seu dispositivo suportar partição A/B, você pode escolher esta opção, o gerenciador irá corrigir automaticamente o firmware oficial e, em seguida, instalá-lo em outra partição. Este método é adequado para dispositivos após o OTA, você pode instalá-lo diretamente em outra partição após o OTA e, em seguida, reiniciar o dispositivo. 3. Instale em outra partição. Se o seu dispositivo suportar partição A/B, você pode escolher esta opção, o gerenciador irá corrigir automaticamente o firmware oficial e, em seguida, instalá-lo em outra partição. Este método é adequado para dispositivos após o OTA, você pode instalá-lo diretamente em outra partição após o OTA e, em seguida, reiniciar o dispositivo.
@@ -114,7 +114,7 @@ Se não quiser usar o gerenciador, você também pode usar a linha de comando pa
Esta ferramenta oferece suporte ao macOS, Linux e Windows. Você pode baixar a versão correspondente em [GitHub Release](https://github.com/tiann/KernelSU/releases). Esta ferramenta oferece suporte ao macOS, Linux e Windows. Você pode baixar a versão correspondente em [GitHub Release](https://github.com/tiann/KernelSU/releases).
Uso: `ksud boot-patch` você pode verificar a ajuda da linha de comando para o uso específico. Uso: `ksud boot-patch` você pode verificar a ajuda da linha de comando para opções específicas.
```sh ```sh
oriole:/ # ksud boot-patch -h oriole:/ # ksud boot-patch -h
@@ -168,7 +168,7 @@ Você pode baixar o boot.img em [GitHub Release](https://github.com/tiann/Kernel
Normalmente, existem três arquivos de inicialização em formatos diferentes no mesmo KMI e nível do patch de segurança. Eles são todos iguais, exceto pelo formato de compactação do kernel. Por favor, verifique o formato de compactação do kernel de seu boot.img original. Você deve usar o formato correto, como `lz4` ou `gz`. Se você usar um formato de compactação incorreto, poderá encontrar bootloop após flashar o boot.img. Normalmente, existem três arquivos de inicialização em formatos diferentes no mesmo KMI e nível do patch de segurança. Eles são todos iguais, exceto pelo formato de compactação do kernel. Por favor, verifique o formato de compactação do kernel de seu boot.img original. Você deve usar o formato correto, como `lz4` ou `gz`. Se você usar um formato de compactação incorreto, poderá encontrar bootloop após flashar o boot.img.
::: info FORMATO DE COMPACTAÇÃO DO BOOT.IMG ::: info FORMATO DE COMPACTAÇÃO DO BOOT.IMG
1. Você pode usar o magiskboot para obter o formato de compactação de seu boot original; é claro que você também pode perguntar a outras pessoas mais experientes com o mesmo modelo do seu dispositivo. Além disso, o formato de compactação do kernel geralmente não muda, portanto, se você inicializar com êxito com um determinado formato de compactação, poderá tentar esse formato mais tarde. 1. Você pode usar o magiskboot para obter o formato de compactação de seu boot original; alternativamente, você também pode solicitá-lo a membros/desenvolvedores da comunidade com o mesmo modelo do seu dispositivo. Além disso, o formato de compactação do kernel geralmente não muda, portanto, se você inicializar com êxito com um determinado formato de compactação, poderá tentar esse formato mais tarde.
2. Os dispositivos Xiaomi geralmente usam `gz` ou `uncompressed`. 2. Os dispositivos Xiaomi geralmente usam `gz` ou `uncompressed`.
3. Para dispositivos Pixel, siga as instruções abaixo: 3. Para dispositivos Pixel, siga as instruções abaixo:
::: :::
@@ -203,7 +203,7 @@ Etapa:
Dessa forma, é necessário que o app Kernel Flasher tenha privilégios root. Você pode usar os seguintes métodos para conseguir isso: Dessa forma, é necessário que o app Kernel Flasher tenha privilégios root. Você pode usar os seguintes métodos para conseguir isso:
1. Seu dispositivo está rooteado. Por exemplo, você instalou o KernelSU e deseja atualizar para a versão mais recente ou fez o root por meio de outros métodos (como Magisk). 1. Seu dispositivo está rooteado. Por exemplo, você instalou o KernelSU e deseja atualizar para a versão mais recente ou fez o root por meio de outros métodos (como Magisk).
2. Se o seu telefone não estiver rooteado, mas o telefone suportar o método de inicialização temporária como `fastboot boot boot.img`, você pode usar a imagem GKI fornecida pelo KernelSU para inicializar temporariamente o seu dispositivo, obter privilégios root temporário e, em seguida, usar o Kernel Flasher para obter privilégios root permanente. 2. Se o seu dispositivo não estiver rooteado, mas suportar o método de inicialização temporária como `fastboot boot boot.img`, você pode usar a imagem GKI fornecida pelo KernelSU para inicializar temporariamente o seu dispositivo, obter privilégios root temporário e, em seguida, usar o Kernel Flasher para obter privilégios root permanente.
1. [Kernel Flasher](https://github.com/capntrips/KernelFlasher/releases) 1. [Kernel Flasher](https://github.com/capntrips/KernelFlasher/releases)
2. [Franco Kernel Manager](https://play.google.com/store/apps/details?id=com.franco.kernel) 2. [Franco Kernel Manager](https://play.google.com/store/apps/details?id=com.franco.kernel)
@@ -213,7 +213,7 @@ Observação: Este método é mais conveniente ao atualizar o KernelSU e pode se
## Corrigir boot.img manualmente {#patch-boot-image} ## Corrigir boot.img manualmente {#patch-boot-image}
Para alguns dispositivos, o formato boot.img não é tão comum como `lz4`, `gz` e `uncompressed`. O mais típico é o Pixel, seu formato boot.img é `lz4_legacy` compactado, ramdisk pode ser `gz` e também pode ser compactado `lz4_legacy`. Neste momento, se você flashar diretamente o boot.img fornecido pelo KernelSU, o telefone pode não conseguir inicializar. Neste momento, você pode corrigir manualmente o boot.img para conseguir isso. Para alguns dispositivos, o formato boot.img não é tão comum como `lz4`, `gz` e `uncompressed`. O mais típico é o Pixel, seu formato boot.img é `lz4_legacy` compactado, ramdisk pode ser `gz` e também pode ser compactado `lz4_legacy`. Atualmente, se você flashar diretamente o boot.img fornecido pelo KernelSU, o telefone pode não conseguir inicializar. Neste momento, você pode corrigir manualmente o boot.img para conseguir isso.
É sempre recomendado usar `magiskboot` para corrigir imagens, existem duas maneiras: É sempre recomendado usar `magiskboot` para corrigir imagens, existem duas maneiras:
@@ -223,7 +223,7 @@ Para alguns dispositivos, o formato boot.img não é tão comum como `lz4`, `gz`
A versão oficial do `magiskboot` só pode rodar em dispositivos Android, se você quiser rodar no PC, você pode tentar a segunda opção. A versão oficial do `magiskboot` só pode rodar em dispositivos Android, se você quiser rodar no PC, você pode tentar a segunda opção.
::: tip DICA ::: tip DICA
Android-Image-Kitchen não é recomendado agora, porque ele não lida corretamente com os metadados de inicialização (como o nível do patch de segurança). Portanto, pode não funcionar em alguns dispositivos. Android-Image-Kitchen não é recomendado por enquanto, porque ele não lida corretamente com os metadados de inicialização (como o nível do patch de segurança). Portanto, pode não funcionar em alguns dispositivos.
::: :::
### Preparação ### Preparação
@@ -240,16 +240,16 @@ Android-Image-Kitchen não é recomendado agora, porque ele não lida corretamen
4. Envie o boot.img padrão e Image em AnyKernel3 para o seu dispositivo. 4. Envie o boot.img padrão e Image em AnyKernel3 para o seu dispositivo.
5. Entre no ADB shell e no diretório cd `/data/local/tmp/`, em seguida, `chmod +x magiskboot`. 5. Entre no ADB shell e no diretório cd `/data/local/tmp/`, em seguida, `chmod +x magiskboot`.
6. Entre no ADB shell e no diretório cd `/data/local/tmp/`, execute `./magiskboot unpack boot.img` para descompactar `boot.img`, você obterá um arquivo `kernel`, este é o seu kernel padrão. 6. Entre no ADB shell e no diretório cd `/data/local/tmp/`, execute `./magiskboot unpack boot.img` para descompactar `boot.img`, você obterá um arquivo `kernel`, este é o seu kernel padrão.
7. Substitua `kernel` por `Image`: `mv -f Image kernel`. 7. Substitua `kernel` por `Image` executando o comando: `mv -f Image kernel`.
8. Execute `./magiskboot repack boot.img` para reembalar o boot.img, e você obterá um arquivo `new-boot.img`, faça o flash deste arquivo para o dispositivo por fastboot. 8. Execute `./magiskboot repack boot.img` para reembalar o boot.img, e você obterá um arquivo `new-boot.img`, faça o flash deste arquivo para o dispositivo por fastboot.
### Usando o magiskboot no PC Windows/macOS/Linux {#using-magiskboot-on-PC} ### Usando o magiskboot no PC Windows/macOS/Linux {#using-magiskboot-on-PC}
1. Baixe o `magiskboot` adequado para o seu sistema operacional em [magiskboot_build](https://github.com/ookiineko/magiskboot_build/releases/tag/last-ci). 1. Baixe o `magiskboot` adequado para o seu sistema operacional em [magiskboot_build](https://github.com/ookiineko/magiskboot_build/releases/tag/last-ci).
2. Prepare o `boot.img` padrão e `Image` em seu PC. 2. Prepare o `boot.img` padrão e `Image` em seu PC.
3. `chmod +x magiskboot` 3. Execute `chmod +x magiskboot`.
4. Entre no diretório apropriado, execute `./magiskboot unpack boot.img` para descompactar `boot.img`. Você obterá um arquivo `kernel`, este é o seu kernel padrão. 4. Entre no diretório apropriado, execute `./magiskboot unpack boot.img` para descompactar `boot.img`. Você obterá um arquivo `kernel`, este é o seu kernel padrão.
5. Substitua `kernel` por `Image`: `mv -f Image kernel`. 5. Substitua `kernel` por `Image` executando o comando: `mv -f Image kernel`.
6. Execute `./magiskboot repack boot.img` para reembalar o boot.img, e você obterá um arquivo `new-boot.img`, faça o flash deste arquivo para o dispositivo por fastboot. 6. Execute `./magiskboot repack boot.img` para reembalar o boot.img, e você obterá um arquivo `new-boot.img`, faça o flash deste arquivo para o dispositivo por fastboot.
::: info INFORMAÇÕES ::: info INFORMAÇÕES
@@ -258,13 +258,13 @@ O `magiskboot` oficial pode executar o dispositivo `Linux` normalmente. Se você
## Instalar com Recovery personalizado {#install-with-custom-recovery} ## Instalar com Recovery personalizado {#install-with-custom-recovery}
Pré-requisito: Seu dispositivo deve ter um Recovery personalizado, como TWRP. Se apenas o Recovery oficial estiver disponível, use outro método. Pré-requisito: Seu dispositivo deve ter um Recovery personalizado, como TWRP. Se não houver Recovery personalizado disponível para o seu dispositivo, use outro método.
Etapa: Etapas:
1. Em [GitHub Releases](https://github.com/tiann/KernelSU/releases), baixe o pacote ZIP começando com AnyKernel3 que corresponde à versão do seu telefone. Por exemplo, a versão do kernel do telefone é `android12-5.10. 66`, então você deve baixar o arquivo `AnyKernel3-android12-5.10.66_yyyy-MM.zip` (onde `yyyy` é o ano e `MM` é o mês). 1. Em [GitHub Releases](https://github.com/tiann/KernelSU/releases), baixe o pacote ZIP começando com AnyKernel3 que corresponde à versão do seu telefone. Por exemplo, a versão do kernel do dispositivo é `android12-5.10. 66`, então você deve baixar o arquivo `AnyKernel3-android12-5.10.66_yyyy-MM.zip` (onde `yyyy` é o ano e `MM` é o mês).
2. Reinicie o telefone no TWRP. 2. Reinicie o telefone no TWRP.
3. Use o ADB para colocar AnyKernel3-*.zip no telefone em /sdcard e escolha instalá-lo na interface do TWRP, ou você pode diretamente `adb sideload AnyKernel-*.zip` para instalar. 3. Use o ADB para colocar AnyKernel3-*.zip no dispositivo em `/sdcard` e escolha instalá-lo na interface do TWRP, ou você pode diretamente executar `adb sideload AnyKernel-*.zip` para instalar.
Observação: Este método é adequado para qualquer instalação (não limitado à instalação inicial ou atualizações subsequentes), desde que você use o TWRP. Observação: Este método é adequado para qualquer instalação (não limitado à instalação inicial ou atualizações subsequentes), desde que você use o TWRP.
@@ -272,7 +272,7 @@ Observação: Este método é adequado para qualquer instalação (não limitado
Na verdade, todos esses métodos de instalação têm apenas uma ideia principal, que é **substituir o kernel original pelo fornecido pelo KernelSU**, desde que isso possa ser alcançado, ele pode ser instalado. Por exemplo, a seguir estão outros métodos possíveis. Na verdade, todos esses métodos de instalação têm apenas uma ideia principal, que é **substituir o kernel original pelo fornecido pelo KernelSU**, desde que isso possa ser alcançado, ele pode ser instalado. Por exemplo, a seguir estão outros métodos possíveis.
1. Primeiro instale o Magisk, obtenha privilégios root através do Magisk e então use o Kernel Flasher para fazer o flash no zip AnyKernel do KernelSU. 1. Primeiro instale o Magisk, obtenha privilégios root através do Magisk e então use o Kernel Flasher para fazer o flash no ZIP AnyKernel3 do KernelSU.
2. Use algum kit de ferramentas de flash em PCs para flashar no kernel fornecido pelo KernelSU. 2. Use algum kit de ferramentas de flash em PC para flashar no kernel fornecido pelo KernelSU.
Mas se não funcionar, por favor, tente o método `magiskboot`. No entanto, se não funcionar, por favor, tente o método `magiskboot`.

View File

@@ -6,7 +6,7 @@ O mecanismo de módulos do KernelSU é quase o mesmo do Magisk. Se você está f
## WebUI ## WebUI
Os módulos do KernelSU suportam a exibição de interfaces e a interação com os usuários, consulte a [documentação do WebUI](module-webui.md). Os módulos do KernelSU suportam a exibição de interfaces e a interação com os usuários. Para mais, consulte a [documentação do WebUI](module-webui.md).
## BusyBox ## BusyBox
@@ -193,16 +193,16 @@ O script `customize.sh` é executado no shell BusyBox `ash` do KernelSU com o Mo
#### Variáveis #### Variáveis
- `KSU` (bool): uma variável para marcar que o script está sendo executado no ambiente KernelSU, e o valor desta variável sempre será `true`. Você pode usá-lo para distinguir entre KernelSU e Magisk. - `KSU` (bool): uma variável para marcar que o script está sendo executado no ambiente KernelSU, e o valor desta variável sempre será `true`. Você pode usá-lo para distinguir entre KernelSU e Magisk.
- `KSU_VER` (string): a string da versão do KernelSU atualmente instalado (por exemplo: `v0.4.0`). - `KSU_VER` (string): a string da versão do KernelSU atualmente instalado (ex.: `v0.4.0`).
- `KSU_VER_CODE` (int): o código da versão do KernelSU atualmente instalado no espaço do usuário (por exemplo: `10672`). - `KSU_VER_CODE` (int): o código da versão do KernelSU atualmente instalado no espaço do usuário (ex.: `10672`).
- `KSU_KERNEL_VER_CODE` (int): o código da versão do KernelSU atualmente instalado no espaço do kernel (por exemplo: `10672`). - `KSU_KERNEL_VER_CODE` (int): o código da versão do KernelSU atualmente instalado no espaço do kernel (ex.: `10672`).
- `BOOTMODE` (bool): sempre será `true` no KernelSU. - `BOOTMODE` (bool): sempre será `true` no KernelSU.
- `MODPATH` (path): o caminho onde os arquivos do seu módulo devem ser instalados. - `MODPATH` (path): o caminho onde os arquivos do seu módulo devem ser instalados.
- `TMPDIR` (path): um lugar onde você pode armazenar arquivos temporariamente. - `TMPDIR` (path): um lugar onde você pode armazenar arquivos temporariamente.
- `ZIPFILE` (path): ZIP de instalação do seu módulo. - `ZIPFILE` (path): ZIP de instalação do seu módulo.
- `ARCH` (string): a arquitetura da CPU do dispositivo. O valor é `arm`, `arm64`, `x86` ou `x64`. - `ARCH` (string): a arquitetura da CPU do dispositivo. O valor é `arm`, `arm64`, `x86` ou `x64`.
- `IS64BIT` (bool): `true` se `$ARCH` for `arm64` ou `x64`. - `IS64BIT` (bool): `true` se `$ARCH` for `arm64` ou `x64`.
- `API` (int): o nível da API (versão do Android) do dispositivo (por exemplo: `23` para Android 6.0). - `API` (int): o nível da API (versão do Android) do dispositivo (ex.: `23` para Android 6.0).
::: warning AVISO ::: warning AVISO
No KernelSU, `MAGISK_VER_CODE` é sempre `25200` e `MAGISK_VER` é sempre `v25.2`. Por favor, não use essas duas variáveis para determinar se ele está sendo executado no KernelSU ou não. No KernelSU, `MAGISK_VER_CODE` é sempre `25200` e `MAGISK_VER` é sempre `v25.2`. Por favor, não use essas duas variáveis para determinar se ele está sendo executado no KernelSU ou não.
@@ -236,7 +236,7 @@ set_perm_recursive <directory> <owner> <group> <dirpermission> <filepermission>
## Scripts de inicialização ## Scripts de inicialização
No KernelSU, os scripts são divididos em dois tipos com base em seu modo de execução: modo post-fs-data e modo de serviço late_start: No KernelSU, os scripts são divididos em dois tipos com base em seu modo de execução: modo post-fs-data e modo de serviço late_start.
- modo post-fs-data - modo post-fs-data
- Esta etapa está BLOQUEANDO. O processo de inicialização é pausado antes da execução ser concluída ou 10 segundos se passaram. - Esta etapa está BLOQUEANDO. O processo de inicialização é pausado antes da execução ser concluída ou 10 segundos se passaram.
@@ -248,7 +248,7 @@ No KernelSU, os scripts são divididos em dois tipos com base em seu modo de exe
- Esta etapa é SEM BLOQUEIO. Seu script é executado em paralelo com o restante do processo de inicialização. - Esta etapa é SEM BLOQUEIO. Seu script é executado em paralelo com o restante do processo de inicialização.
- **Este é o estágio recomendado para executar a maioria dos scripts**. - **Este é o estágio recomendado para executar a maioria dos scripts**.
No KernelSU, os scripts de inicialização são divididos em dois tipos com base no local de armazenamento: scripts gerais e scripts de módulo: No KernelSU, os scripts de inicialização são divididos em dois tipos com base no local de armazenamento: scripts gerais e scripts de módulo.
- Scripts gerais - Scripts gerais
- Colocado em `/data/adb/post-fs-data.d`, `/data/adb/service.d`, `/data/adb/post-mount.d` ou `/data/adb/boot-completed.d`. - Colocado em `/data/adb/post-fs-data.d`, `/data/adb/service.d`, `/data/adb/post-mount.d` ou `/data/adb/boot-completed.d`.

View File

@@ -44,7 +44,7 @@ O Modo de Segurança integrado é implementado no kernel, portanto não há poss
### Módulos maliciosos ### Módulos maliciosos
Se os métodos acima não conseguirem recuperar seu dispositivo, é altamente provável que o módulo que você instalou tenha operações maliciosas ou tenha danificado seu dispositivo por outros meios. Neste caso, existem apenas duas sugestões: Se os métodos acima não conseguirem recuperar seu dispositivo, é muito provável que o módulo que você instalou tenha operações maliciosas ou tenha danificado seu dispositivo por outros meios. Neste caso, existem apenas duas sugestões:
1. Limpar os dados e instalar o sistema oficial. 1. Limpar os dados e instalar o sistema oficial.
2. Consultar o serviço pós-venda. 2. Consultar o serviço pós-venda.

View File

@@ -1,6 +1,6 @@
# O que é KernelSU? # O que é KernelSU?
O KernelSU é uma solução root para dispositivos Android GKI, funciona no modo kernel e concede privilégios root ao app do espaço do usuário diretamente no espaço do kernel. O KernelSU é uma solução root para dispositivos Android GKI, funciona no modo kernel e concede privilégios root para apps do espaço do usuário diretamente no espaço do kernel.
## Características ## Características