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

website: enhanced english/portuguese translation (#2427)

Browse Source 
Enhanced english/portuguese translation for better fluency, grammar,
clarity, and text accuracy.
This commit is contained in:
igor
2025-02-13 00:54:30 -03:00
committed by GitHub
parent 633bc4fc47
commit cbff9b8ba1
35 changed files with 458 additions and 458 deletions
Download Patch File Download Diff File Expand all files Collapse all files

56
website/docs/guide/how-to-integrate-for-non-gki.md
View File

@@ -1,19 +1,19 @@
# How to integrate KernelSU for non-GKI kernels?
# Intergrate for non-GKI devices
KernelSU can be integrated into non-GKI kernels, and was backported to 4.14 and below.
KernelSU can be integrated into non-GKI kernels and was backported to 4.14 and earlier versions.
Due to the fragmentization of non-GKI kernels, we do not have a universal way to build it, so we cannot provide non-GKI boot images. But you can build the kernel yourself with KernelSU integrated.
Due to the fragmentation of non-GKI kernels, we don't have a universal method to build it, so we cannot provide the non-GKI boot.img. However, you can build the kernel with KernelSU integrated on your own.
First, you should be able to build a bootable kernel from kernel source code. If the kernel is not open source, then it is difficult to run KernelSU for your device.
First, you should be able to build a bootable kernel from kernel source code. If the kernel isn't open source, then it is difficult to run KernelSU for your device.
If you can build a bootable kernel, there are two ways to integrate KernelSU to the kernel source code:
If you're able to build a bootable kernel, there are two ways to integrate KernelSU into the kernel source code:
1. Automatically with `kprobe`
2. Manually
## Integrate with kprobe
KernelSU uses kprobe to do kernel hooks, if the *kprobe* runs well in your kernel, it is recommended to use this way.
KernelSU uses kprobe to do kernel hooks, if kprobe runs well in your kernel, it's recommended to use it this way.
First, add KernelSU to your kernel source tree:
@@ -21,11 +21,11 @@ First, add KernelSU to your kernel source tree:
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s v0.9.5
```
:::info
[KernelSU 1.0 and later versions no longer support non-GKI kernels](https://github.com/tiann/KernelSU/issues/1705). The last supported version is `v0.9.5`, please make sure to use the correct version.
::: info
[KernelSU 1.0 and later versions no longer support non-GKI kernels](https://github.com/tiann/KernelSU/issues/1705). The last supported version is `v0.9.5`, so make sure to use the correct version.
:::
Then, you should check if *kprobe* is enabled in your kernel config, if it is not, please add these configs to it:
Then, you should check if kprobe is enabled in your kernel config. If it isn't, add these configs to it:
```txt
CONFIG_KPROBES=y
@@ -33,25 +33,23 @@ CONFIG_HAVE_KPROBES=y
CONFIG_KPROBE_EVENTS=y
```
And now when you re-build your kernel, KernelSU should work well.
Now, when you re-build your kernel, KernelSU should work correctly.
If you find that KPROBES is still not activated, you can try enabling `CONFIG_MODULES`. If it still doesn't take effect, use `make menuconfig` to search for other dependencies of KPROBES.
If you find that KPROBES is still not enabled, you can try enabling `CONFIG_MODULES`. If that doesn't solve the issue, use `make menuconfig` to search for other KPROBES dependencies.
But if you encounter a boot loop when integrated KernelSU, it might be because *kprobe is broken in your kernel*, which means that you should fix the kprobe bug or use another way.
However, if you encounter a bootloop after integrating KernelSU, this may indicate that the **kprobe is broken in your kernel**, which means that you should fix the kprobe bug or use another way.
:::tip How to check if kprobe is broken？
comment out `ksu_enable_sucompat()` and `ksu_enable_ksud()` in `KernelSU/kernel/ksu.c`, if the device boots normally, then kprobe may be broken.
::: tip HOW TO CHECK IF KPROBE IS BROKEN？
Comment out `ksu_enable_sucompat()` and `ksu_enable_ksud()` in `KernelSU/kernel/ksu.c`, if the device boots normally, then kprobe may be broken.
:::
:::info How to get module umount feature working on pre-GKI?
If your kernel is older than 5.9, you should backport `path_umount` to `fs/namespace.c`. This is required to get module umount feature working. If you don't backport `path_umount`, module umount feature won't work. You can get more info on how to achieve this at the end of this page.
::: info HOW TO GET MODULE UMOUNT FEATURE WORKING ON PRE-GKI?
If your kernel is older than 5.9, you should backport `path_umount` to `fs/namespace.c`. This is required to get "Umount module" feature work correctly. If you don't backport `path_umount`, "Umount module" feature won't work. You can get more info on how to achieve this at the end of this page.
:::
## Manually modify the kernel source
If kprobe does not work in your kernel (may be an upstream or kernel bug below 4.8), then you can try the following:
If kprobe doesn't work on your kernel this may be caused by an upstream bug or if the kernel is below 4.8), then you can try the following:
First, add KernelSU to your kernel source tree:
@@ -59,14 +57,14 @@ First, add KernelSU to your kernel source tree:
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s v0.9.5
```
Keep in mind that on some devices, your defconfig may be in `arch/arm64/configs` or in other cases `arch/arm64/configs/vendor/your_defconfig`. For whichever defconfig you are using, make sure to enable `CONFIG_KSU` with `y` to enable or `n` to disable it. For example, in case you chose to enable it, you defconfig should contain the following string:
Keep in mind that, on some devices, your defconfig may be located at `arch/arm64/configs` or in other cases, it may be at `arch/arm64/configs/vendor/your_defconfig`. Regardless of the defconfig you're using, make sure to enable `CONFIG_KSU` with `y` to enable or `n` to disable it. For example, if you choose to enable it, your defconfig should contain the following string:
```txt
# KernelSU
CONFIG_KSU=y
```
Then, add KernelSU calls to the kernel source, here are some patches for reference:
Next, add KernelSU calls to the kernel source. Below are some patches for reference:
::: code-group
@@ -197,7 +195,7 @@ You should find the four functions in kernel source:
3. `vfs_read`, usually in `fs/read_write.c`
4. `vfs_statx`, usually in `fs/stat.c`
If your kernel does not have the `vfs_statx` function, use `vfs_fstatat` instead:
If your kernel doesn't have the `vfs_statx` function, use `vfs_fstatat` instead:
```diff
diff --git a/fs/stat.c b/fs/stat.c
@@ -258,10 +256,10 @@ index 2ff887661237..e758d7db7663 100644
### Safe Mode
To enable KernelSU's built-in Safe Mode, you should additionally modify `input_handle_event` function in `drivers/input/input.c`:
To enable KernelSU's built-in Safe Mode, you should modify the `input_handle_event` function in `drivers/input/input.c`:
:::tip
It is strongly recommended to enable this feature, it is very helpful in preventing bootloops!
::: tip
It's strongly recommended to enable this feature, it's very useful for preventing bootloops!
:::
```diff
@@ -291,8 +289,8 @@ index 45306f9ef247..815091ebfca4 100755
add_input_randomness(type, code, value);
```
:::info Entering safe mode accidentally?
If you use manual integration and do not disable `CONFIG_KPROBES`, then the user may trigger safe mode by pressing the volume down button after booting! Therefore if using manual integration you need to disable `CONFIG_KPROBES`!
::: info ENTERING SAFE MODE ACCIDENTALLY?
If you're using manual integration and don't disable `CONFIG_KPROBES`, the user will be able to trigger Safe Mode by pressing the volume down button after booting! Therefore, if you're using manual integration, it's necessary to disable `CONFIG_KPROBES`!
:::
### Failed to execute `pm` in terminal?
@@ -329,7 +327,7 @@ index 32f6f1c68..d69d8eca2 100644
### How to backport path_umount
You can get "Umount modules" feature working on pre-GKI kernels by manually backporting `path_umount` from 5.9. You can use this patch as reference:
You can make the "Umount modules" feature work on pre-GKI kernels by manually backporting `path_umount` from 5.9. You can use this patch as reference:
```diff
--- a/fs/namespace.c
@@ -376,4 +374,4 @@ You can get "Umount modules" feature working on pre-GKI kernels by manually back
* This is important for filesystems which use unnamed block devices.
```
Finally, build your kernel again, KernelSU should work well.
Finally, build your kernel again, and KernelSU should work correctly.