docs: update documentation for the website (#1750)

Description:

I was originally browsing through project's FAQ on the
[website](https://kernelsu.org/) and noticed a few discrepancies across
the text.<br>I edited them out, and once having finished with the FAQ, I
looked through other website pages as well.

Changes:

- updated documentation for the project's website (English version).

--
P.S. I actually appreciate the partial documentation on GKI and in-depth
Android mechanisms present in it. While there is of course documentation
from Google, it is nice to have guidelines from a more practical
standpoint.

website/docs/guide/difference-with-magisk.md

@@ -4,14 +4,14 @@ Although there are many similarities between KernelSU modules and Magisk modules
 
 ## Similarities
 
-- Module file format: both use zip format to organize modules, and the format of modules is almost the same
+- Module file format: both use zip format to organize modules, and the format of modules is almost the same.
-- Module installation directory: both located in `/data/adb/modules`
+- Module installation directory: both located in `/data/adb/modules`.
-- Systemless: both support modifying /system in a systemless way through modules
+- Systemless: both support modifying /system in a systemless way through modules.
-- post-fs-data.sh: the execution time and semantics are exactly the same
+- post-fs-data.sh: the execution time and semantics are exactly the same.
-- service.sh: the execution time and semantics are exactly the same
+- service.sh: the execution time and semantics are exactly the same.
-- system.prop: completely the same
+- system.prop: completely the same.
-- sepolicy.rule: completely the same
+- sepolicy.rule: completely the same.
-- BusyBox: scripts are run in BusyBox with "standalone mode" enabled in both cases
+- BusyBox: scripts are run in BusyBox with "standalone mode" enabled in both cases.
 
 ## Differences
 
@@ -20,9 +20,9 @@ Before understanding the differences, you need to know how to differentiate whet
 Here are some differences:
 
 - KernelSU modules cannot be installed in Recovery mode.
-- KernelSU modules do not have built-in support for Zygisk (but you can use Zygisk modules through [ZygiskNext](https://github.com/Dr-TSNG/ZygiskNext).
+- KernelSU modules do not have built-in support for Zygisk (but you can use Zygisk modules through [ZygiskNext](https://github.com/Dr-TSNG/ZygiskNext)).
 - The method for replacing or deleting files in KernelSU modules is completely different from Magisk. KernelSU does not support the `.replace` method. Instead, you need to create a same-named file with `mknod filename c 0 0` to delete the corresponding file.
 - The directories for BusyBox are different. The built-in BusyBox in KernelSU is located in `/data/adb/ksu/bin/busybox`, while in Magisk it is in `/data/adb/magisk/busybox`. **Note that this is an internal behavior of KernelSU and may change in the future!**
 - KernelSU does not support `.replace` files; however, KernelSU supports the `REMOVE` and `REPLACE` variable to remove or replace files and folders.
 - KernelSU adds `boot-completed` stage to run some scripts on boot completed.
-- KernelSU adds `post-mount` stage to run some scripts after mounting overlayfs
+- KernelSU adds `post-mount` stage to run some scripts after mounting overlayfs.

website/docs/guide/faq.md

@@ -16,7 +16,7 @@ Yes, check [Module Page](module.md) please.
 
 ## Does KernelSU support Xposed?
 
-Yes, you can use LSPosed on [ZygiskNext](https://github.com/Dr-TSNG/ZygiskNext)
+Yes, you can use LSPosed on [ZygiskNext](https://github.com/Dr-TSNG/ZygiskNext).
 
 ## Does KernelSU support Zygisk?
 
@@ -26,7 +26,7 @@ KernelSU has no builtin Zygisk support, but you can use [ZygiskNext](https://git
 
 KernelSU's module system is conflict with Magisk's magic mount, if there is any module enabled in KernelSU, then the whole Magisk would not work.
 
-But if you only use the `su` of KernelSU, then it will work well with Magisk: KernelSU modify the `kernel` and Magisk modify the `ramdisk`, they can work together.
+But if you only use the `su` of KernelSU, then it will work well with Magisk: with KernelSU modifying the `kernel` and Magisk modifying the `ramdisk`, both of them can work together simultaneously.
 
 ## Will KernelSU substitute Magisk?
 
@@ -38,18 +38,18 @@ It is possible. But you should download the kernel source and intergrate KernelS
 
 ## Can KernelSU support devices below Android 12?
 
-It is device's kernel that affect KernelSU's compatability and it has nothing to do with Android version.The only restriction is that devices launched with Android 12 must be kernel 5.10+(GKI devices). So:
+It is device's kernel that affect KernelSU's compatability and it has nothing to do with Android version. The only restriction is that devices launched with Android 12 must be kernel of a 5.10+ version (GKI devices). So:
 
 1. Devices launched with Android 12 must be supported.
-2. Devices which have an old kernel (Some Android 12 devices is also old kernel) are compatible (You should build kernel yourself)
+2. Devices which have an old kernel (Some Android 12 devices is also old kernel) are compatible (You should build kernel yourself).
 
 ## Can KernelSU support old kernel?
 
-It is possible, KernelSU is backported to kernel 4.14 now, for older kernel, you need to backport it manully and PRs welcome!
+It is possible, KernelSU is backported to kernel 4.14 now; for older kernel, you need to backport it manually and PRs welcome!
 
-## How to integrate KernelSU for old kernel?
+## How to integrate KernelSU for an older kernel?
 
-Please refer [Guide](how-to-integrate-for-non-gki)
+Please refer to the following [Guide](how-to-integrate-for-non-gki).
 
 ## Why my Android version is 13, and the kernel shows "android12-5.10"?
 
@@ -59,17 +59,17 @@ The Kernel version has nothing to do with Android version, if you need to flash
 
 GKI1 is completely different from GKI2, you must compile kernel by yourself.
 
-## How can i make `/system` RW?
+## How can I make `/system` RW?
 
 We do not recommend you to modify the system partition directly. You should use the [module](module.md) to modify it systemlessly. If you insist on doing this, check [magisk_overlayfs](https://github.com/HuskyDG/magic_overlayfs).
 
-## Can KernelSU modify hosts? How can i use AdAway？
+## Can KernelSU modify hosts? How can I use AdAway？
 
-Of course. But KernelSU doesn't have builtin hosts support, you can install [systemless-hosts](https://github.com/symbuzzer/systemless-hosts-KernelSU-module) to do it.
+Of course. But KernelSU doesn't have built-in hosts support, you can install [systemless-hosts](https://github.com/symbuzzer/systemless-hosts-KernelSU-module) to do it.
 
 ## Why is there a huge 1 TB file?
 
-The 1 TB size `modules.img` is a disk image file, **don't worry about its size**, it's a special type of file known as a [sparse file](https://en.wikipedia.org/wiki/Sparse_file), its actual size is only the size of the module you use, and it will dynamically shrink after you delete the module; it does not actually occupy 1 TB of disk space (actually your mobile phone may not have that much space).
+The 1 TB size `modules.img` is a disk image file, **don't worry about its size**, it's a special type of file known as a [sparse file](https://en.wikipedia.org/wiki/Sparse_file), it's actual size is only the size of the module you use, and it will dynamically shrink after you delete the module; it does not actually occupy 1 TB of disk space (your mobile phone may not actually have that much space).
 
 If you're really unhappy with the size of this file, you can use the `resize2fs -M` command to make it the actual size; but the module may not work properly at this time, and we won't provide any support for this.
 

website/docs/guide/how-to-build.md

@@ -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)
+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
-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 old kernel](how-to-integrate-for-non-gki).
 :::
 
 ## Build Kernel
@@ -20,13 +20,13 @@ repo init -m manifest.xml
 repo sync
 ```
 
-The `<kernel_manifest.xml>` is a manifest file which can determine a build uniquely, you can use the manifest to do a re-preducable build. You should download the manifest file from [Google GKI release builds](https://source.android.com/docs/core/architecture/kernel/gki-release-builds)
+The `<kernel_manifest.xml>` is a manifest file which can determine a build uniquely, you can use the manifest to do a re-preducable build. You should download the manifest file from [Google GKI release builds](https://source.android.com/docs/core/architecture/kernel/gki-release-builds).
 
 ### Build
 
 Please check the [official docs](https://source.android.com/docs/setup/build/building-kernels) first.
 
-For example, we need to build aarch64 kernel image:
+For example, to build an aarch64 kernel image:
 
 ```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
-For some Android 14 Kernel, to make Wi-Fi/Bluetooth work. It may be necessary to remove all the GKI protected exports:
+For some of the Android 14 kernels, to make Wi-Fi/Bluetooth work, it might be necessary to remove all the GKI protected exports:
 
 ```sh
 rm common/android/abi_gki_protected_exports_*
@@ -50,7 +50,7 @@ rm common/android/abi_gki_protected_exports_*
 
 ## Build Kernel with KernelSU
 
-If you can build the kernel successfully, then build KernelSU is so easy, Select any one run in Kernel source root dir:
+If you're able to build the kernel successfully, then adding KernelSU support to it is relatively easy. In the root of kernel source directory, run any of the command options listed below:
 
 ::: code-group
 

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

@@ -1,15 +1,15 @@
-# How to integrate KernelSU for non GKI kernels?
+# How to integrate KernelSU for non-GKI kernels?
 
-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 below.
 
-Due to the fragmentization of non GKI kernels, we do not have a uniform way to build it, so we can not provide non GKI boot images. But you can build the kernel yourself with KernelSU integrated.
+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.
 
 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.
 
 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
 
@@ -23,17 +23,17 @@ curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh
 
 Then, you should check if *kprobe* is enabled in your kernel config, if it is not, please add these configs to it:
 
-```
+```txt
 CONFIG_KPROBES=y
 CONFIG_HAVE_KPROBES=y
 CONFIG_KPROBE_EVENTS=y
 ```
 
-And build your kernel again, KernelSU should works well.
+And now when you re-build your kernel, KernelSU should work well.
 
-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 activated, you can try enabling `CONFIG_MODULES`. If it still doesn't take effect, use `make menuconfig` to search for other dependencies of KPROBES.
 
-But if you encounter a boot loop when integrated KernelSU, it is maybe *kprobe is broken in your kernel*, you should fix the kprobe bug or use the second way.
+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.
 
 :::tip How to check if kprobe is broken？
 
@@ -47,7 +47,7 @@ If your kernel is older than 5.9, you should backport `path_umount` to `fs/names
 
 ## 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 this way:
+If kprobe does not work in your kernel (may be an upstream or kernel bug below 4.8), then you can try the following:
 
 First, add KernelSU to your kernel source tree:
 
@@ -67,14 +67,14 @@ curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh
 
 :::
 
-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 example in your defconfig, Enable `CONFIG_KSU` with y to enable, or n to disable. Your path will be something like:
+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're 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:
-`arch/arm64/configs/...` 
+
-```
+```txt
 # KernelSU
 CONFIG_KSU=y
 ```
 
-Then, add KernelSU calls to the kernel source, here are some patches to refer:
+Then, add KernelSU calls to the kernel source, here are some patches for reference:
 
 ::: code-group
 
@@ -200,12 +200,12 @@ index 376543199b5a..82adcef03ecc 100644
 
 You should find the four functions in kernel source:
 
-1. do_faccessat, usually in `fs/open.c`
+1. `do_faccessat`, usually in `fs/open.c`
-2. do_execveat_common, usually in `fs/exec.c`
+2. `do_execveat_common`, usually in `fs/exec.c`
-3. vfs_read, usually in `fs/read_write.c`
+3. `vfs_read`, usually in `fs/read_write.c`
-4. vfs_statx, usually in `fs/stat.c`
+4. `vfs_statx`, usually in `fs/stat.c`
 
-If your kernel does not have the `vfs_statx`, use `vfs_fstatat` instead:
+If your kernel does not have the `vfs_statx` function, use `vfs_fstatat` instead:
 
 ```diff
 diff --git a/fs/stat.c b/fs/stat.c
@@ -266,10 +266,10 @@ index 2ff887661237..e758d7db7663 100644
 
 ### Safe Mode
 
-To enable KernelSU's builtin SafeMode, You should also modify `input_handle_event` in `drivers/input/input.c`:
+To enable KernelSU's built-in SafeMode, you should additionally modify `input_handle_event` function in `drivers/input/input.c`:
 
 :::tip
-It is strongly recommended to enable this feature, it is very helpful to prevent bootloops!
+It is strongly recommended to enable this feature, it is very helpful in preventing bootloops!
 :::
 
 ```diff
@@ -299,7 +299,7 @@ index 45306f9ef247..815091ebfca4 100755
  		add_input_randomness(type, code, value);
 ```
 
-:::info Entering safe mode accidiently?
+:::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`!
 :::
 

website/docs/guide/installation.md

@@ -45,15 +45,15 @@ Note that the SubLevel in the kernel version is not part of the KMI! That means
 
 ### Security patch level {#security-patch-level}
 
-Newer Android devices may have anti-rollback mechanisms in place that do not allow flashing a boot image with an old security patch level. For example, if your device kernel is `5.10.101-android12-9-g30979850fc20`, its security patch is `2023-11`; even if you flash the kernel consistent with the kernel KMI, if the security patch level is older than `2023- 11`(such as `2023-06`), then it may cause bootloop.
+Newer Android devices may have anti-rollback mechanisms in place that do not allow flashing a boot image with an old security patch level. For example, if your device kernel is `5.10.101-android12-9-g30979850fc20`, it's security patch level is `2023-11`; even if you flash the kernel corresponding to the KMI, if the security patch level is older than `2023- 11` (such as `2023-06`), then it may cause bootloop.
 
-Therefore, kernels with latest security patch levels are preferred while maintaining KMI consistency.
+Therefore, kernels with latest security patch levels are preferred for maintaining the correspondence with KMI.
 
-### Kernel version vs. Android version
+### Kernel version vs Android version
 
 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 consistent with 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. If you need to flash, **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
 
@@ -62,23 +62,23 @@ Since version `0.9.0`, KernelSU supports two running modes on GKI devices:
 1. `GKI`: Replace the original kernel of the device with the **Generic Kernel Image** (GKI) provided by KernelSU.
 2. `LKM`: Load the **Loadable Kernel Module** (LKM) into the device kernel without replacing the original kernel.
 
-These two modes are suitable for different scenarios, and you can choose 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}
 
 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}
 
 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:
 
-1. Will not replace the original kernel of the device; if you have special requirements for the original kernel of the device, or you want to use KernelSU while using a third-party kernel, you can use LKM mode;
+1. Will not replace the original kernel of the device; if you have special requirements for the original kernel of the device, or you want to use KernelSU while using a third-party kernel, you can use LKM mode.
-2. It is more convenient to upgrade and OTA; when upgrading KernelSU, you can directly install it in the manager without manually flashing; after the system OTA, you can directly install it to the second slot without manually flashing;
+2. It is more convenient to upgrade and OTA; when upgrading KernelSU, you can directly install it in the manager without flashing manually; after the system OTA, you can directly install it to the second slot without manual flashing.
-3. Suitable for some special scenarios; for example, LKM can also be loaded with temporary ROOT permissions. Since it does not need to replace the boot partition, it will not trigger avb and will not cause the device to be bricked;
+3. Suitable for some special scenarios; for example, LKM can also be loaded with temporary ROOT permissions. Since it does not need to replace the boot partition, it will not trigger avb and will not cause the device to be bricked.
-4. LKM can be temporarily uninstalled; if you want to temporarily cancel root, you can uninstall LKM, this process does not require flashing partitions, or even rebooting the device; if you want to root again, just reboot the device;
+4. LKM can be temporarily uninstalled; if you want to temporarily disable root access, you can uninstall LKM, this process does not require flashing partitions, or even rebooting the device; if you want to enable root again, just reboot the device.
 
 :::tip Coexistence of two modes
 After opening the manager, you can see the current mode of the device on the homepage; note that the priority of GKI mode is higher than that of LKM. For example, if you use GKI kernel to replace the original kernel, and use LKM to patch the GKI kernel, then LKM will be ignored, and the device will always run in GKI mode.
@@ -98,15 +98,15 @@ There are many ways to get the official firmware. If your device supports `fastb
 
 If your device does not support `fastboot boot`, then you may need to manually download the official firmware package and then extract the boot from it.
 
-Unlike GKI mode, LKM mode will modify the `ramdisk`, so on devices with Android 13, it needs to patch the `init_boot` partition instead of the `boot` partition; while GKI mode always operates the `boot` partition.
+Unlike GKI mode, LKM mode will modify the `ramdisk`, so on devices with Android 13, it needs to patch the `init_boot` partition instead of the `boot` partition; meanwhile, GKI mode always operates the `boot` partition.
 
 ### Use the manager
 
 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, and 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;
-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
 
@@ -114,7 +114,7 @@ If you don’t want to use the manager, you can also use the command line to ins
 
 This tool supports macOS, Linux, and Windows. You can download the corresponding version from [GitHub Release](https://github.com/tiann/KernelSU/releases).
 
-Usage: `ksud boot-patch` You can check the command line help for specific usage.
+Usage: `ksud boot-patch`. You can check the command line help for specific options.
 
 ```sh
 oriole:/ # ksud boot-patch -h
@@ -137,8 +137,8 @@ Options:
 
 A few options that need to be explained:
 
-1. The `--magiskboot` option can specify the path of magiskboot. If it is not specified, ksud will look for it in the environment variables; if you don’t know how to get magiskboot, you can check [here](#patch-boot-image);
+1. The `--magiskboot` option can specify the path of magiskboot. If it is not specified, ksud will look for it in the environment variables; if you don’t know how to get magiskboot, you can refer to [this](#patch-boot-image).
-2. The `--kmi` option can specify the `KMI` version. If the kernel name of your device does not follow the KMI specification, you can specify it through this option;
+2. The `--kmi` option can specify the `KMI` version. If the kernel name of your device does not follow the KMI specification, you can specify it through this option.
 
 The most common usage is:
 
@@ -148,12 +148,12 @@ ksud boot-patch -b <boot.img> --kmi android13-5.10
 
 ## GKI mode Installation
 
-There are several installation methods for GKI mode, each suitable for a different scenario, so please choose as needed.
+There are several installation methods for GKI mode, each suitable for a different scenario, so please choose accordingly:
 
-1. Install with fastboot using the boot.img provided by KernelSU
+1. Install with fastboot using the boot.img provided by KernelSU.
-2. Install with a kernel flash app, such as KernelFlasher
+2. Install with a kernel flash app, such as KernelFlasher.
-3. Repair the boot.img manually and install it
+3. Repair the boot.img manually and install it.
-4. Install with custom Recovery (e.g. TWRP)
+4. Install with custom Recovery (e.g., TWRP).
 
 ## Install with boot.img provided by KernelSU
 
@@ -161,16 +161,16 @@ If your device's `boot.img` uses a commonly used compression format, you can use
 
 ### Find proper boot.img
 
-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.
 
 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.
 
 :::info Compression format of boot.img
-1. You can use magiskboot to get the compression format of your original boot; of course you can also ask other, more experienced kids with the same model as your device. Also, the compression format of the kernel usually does not change, so if you boot successfully with a certain compression format, you can try that format later.
+1. You can use magiskboot to get the compression format of your original boot; alternatively, you can also ask for it from community members/developers with the same model as your device. Also, the compression format of the kernel usually does not change, so if you boot successfully with a certain compression format, you can try that format later as well.
 2. Xiaomi devices usually use `gz` or **uncompressed**.
-3. For Pixel devices, follow below instructions.
+3. For Pixel devices, follow the instructions below.
 :::
 
 ### flash boot.img to device
@@ -187,7 +187,7 @@ If your device supports `fastboot boot`, you can first use `fastboot boot boot.i
 
 ### reboot
 
-After flashing is complete, you should reboot your device:
+After the flashing process is complete, you should reboot your device:
 
 ```sh
 fastboot reboot
@@ -202,77 +202,79 @@ Step:
 
 This way requires the kernel flash App to have root permissions. You can use the following methods to achieve this:
 
-1. Your device has rooted. For example, you have installed KernelSU and want to upgrade to the latest version, or you have rooted through other methods (such as Magisk).
+1. Your device is rooted. For example, you have installed KernelSU and want to upgrade to the latest version, or you have rooted through other methods (such as Magisk).
-2. If your phone is not rooted, but the phone supports the temporary boot method of `fastboot boot boot.img`, you can use the GKI image provided by KernelSU to temporarily boot your device, obtain temporary root permissions, and then use the kernel flash Flash the writer to obtain permanent root privileges.
+2. If your device is not rooted, but the phone supports the temporary boot method of `fastboot boot boot.img`, you can use the GKI image provided by KernelSU to temporarily boot your device, obtain temporary root permissions, and then use the Kernel Flash App to obtain permanent root privileges.
+
+Some of kernel flashing apps that can be used for this:
 
 1. [Kernel Flasher](https://github.com/capntrips/KernelFlasher/releases)
 2. [Franco Kernel Manager](https://play.google.com/store/apps/details?id=com.franco.kernel)
 3. [Ex Kernel Manager](https://play.google.com/store/apps/details?id=flar2.exkernelmanager)
 
-PS. This method is more convenient when upgrading KernelSU and can be done without a computer (backup first!). .
+P.S. This method is more convenient when upgrading KernelSU and can be done without a computer (make a backup first!).
 
 ## Patch boot.img manually {#patch-boot-image}
 
-For some devices, the boot.img format is not so common, such as not `lz4`, `gz` and uncompressed; the most typical is Pixel, its boot.img format is `lz4_legacy` compressed, ramdisk may be `gz` may also be `lz4_legacy` compression; at this time, if you directly flash the boot.img provided by KernelSU, the phone may not be able to boot; at this time, you can manually patch the boot.img to achieve.
+For some devices, the boot.img format is not so common, such as not `lz4`, `gz` and uncompressed; the most typical example is a Pixel, it's boot.img format is `lz4_legacy` compressed, ramdisk may be `gz` may also be `lz4_legacy` compression; currently, if you directly flash the boot.img provided by KernelSU, the phone may not be able to boot; as an alternative, and you can manually patch the boot.img to achieve this.
 
 It's always recommended to use `magiskboot` to patch images, there are two ways:
 
 1. [magiskboot](https://github.com/topjohnwu/Magisk/releases)
 2. [magiskboot_build](https://github.com/ookiineko/magiskboot_build/releases/tag/last-ci)
 
-The official build of `magiskboot` can only run on Android devices, if you want to run it on PC, you can try the second one.
+The official build of `magiskboot` can only run on Android devices, if you want to run it on PC, you can try the second option.
 
 ::: tip
-Android-Image-Kitchen is not recommended now, because it doesn't handle the boot metadata(such as security patch level) correctly, thus it may not work on some devices.
+Android-Image-Kitchen is not recommended for now, as it doesn't handle the boot metadata (such as security patch level) correctly, thus it may not work on some devices.
 :::
 
 ### Preparation
 
-1. Get your phone's stock boot.img; you can get it from your device manufacturers, you may need [payload-dumper-go](https://github.com/ssut/payload-dumper-go)
+1. Get your phone's stock boot.img; you can get it from your device manufacturers, you may need [payload-dumper-go](https://github.com/ssut/payload-dumper-go).
 2. Download the AnyKernel3 zip file provided by KernelSU that matches the KMI version of your device (you can refer to the *Install with custom Recovery*).
 3. Unpack the AnyKernel3 package and get the `Image` file, which is the kernel file of KernelSU.
 
 ### Using magiskboot on Android devices {#using-magiskboot-on-Android-devices}
 
-1. Download latest Magisk from [Release Page](https://github.com/topjohnwu/Magisk/releases)
+1. Download latest Magisk from [Release Page](https://github.com/topjohnwu/Magisk/releases).
 2. Rename `Magisk-*(version).apk` to `Magisk-*.zip` and unzip it.
 3. Push `Magisk-*/lib/arm64-v8a/libmagiskboot.so` to your device by adb: `adb push Magisk-*/lib/arm64-v8a/libmagiskboot.so /data/local/tmp/magiskboot`
 4. Push stock boot.img and Image in AnyKernel3 to your device.
-5. Enter adb shell and cd `/data/local/tmp/` directory, then `chmod +x magiskboot`
+5. Enter adb shell and run `cd /data/local/tmp/` directory, then `chmod +x magiskboot`
-6. Enter adb shell and cd `/data/local/tmp/` directory, execute `./magiskboot unpack boot.img` to unpack `boot.img`, you will get a `kernel` file, this is your stock kernel.
+6. Enter adb shell and run `cd /data/local/tmp/` directory, execute `./magiskboot unpack boot.img` to unpack `boot.img`, you will get a `kernel` file, this is your stock kernel.
-7. Replace `kernel` with `Image`: `mv -f Image kernel`
+7. Replace `kernel` with `Image` by running the command: `mv -f Image kernel`.
-8. Execute `./magiskboot repack boot.img` to repack boot img, and you will get a `new-boot.img` file, flash this file to device by fastboot.
+8. Execute `./magiskboot repack boot.img` to repack boot image, and you will get a `new-boot.img` file, flash this file to device by fastboot.
 
 ### Using magiskboot on Windows/macOS/Linux PC{#using-magiskboot-on-PC}
 
-1. Download proper `magiskboot` for your OS from [magiskboot_build](https://github.com/ookiineko/magiskboot_build/releases/tag/last-ci)
+1. Download the corresponding `magiskboot` binary for your OS from [magiskboot_build](https://github.com/ookiineko/magiskboot_build/releases/tag/last-ci).
 2. Prepare stock boot.img and Image in your PC.
-3. `chmod +x magiskboot`
+3. Run `chmod +x magiskboot`.
-4. Enter the proper directory, execute `./magiskboot unpack boot.img` to unpack `boot.img`, you will get a `kernel` file, this is your stock kernel.
+4. Enter the corresponding directory, execute `./magiskboot unpack boot.img` to unpack `boot.img`, you will get a `kernel` file, this is your stock kernel.
-5. Replace `kernel` with `Image`: `mv -f Image kernel`
+5. Replace `kernel` with `Image` by running the command: `mv -f Image kernel`.
-6. Execute `./magiskboot repack boot.img` to repack boot img, and you will get a `new-boot.img` file, flash this file to device by fastboot.
+6. Execute `./magiskboot repack boot.img` to repack the boot image, and you will get a `new-boot.img` file, flash this file to device by fastboot.
 
 ::: info
-Official `magiskboot` can run `Linux` device normally, if you are a Linux user, you can use official build.
+Official `magiskboot` can run in Linux environments normally, if you are a Linux user, you can use the official build.
 :::
 
-## Install with custom Recovery
+## Install with Custom Recovery
 
-Prerequisite: Your device must have a custom Recovery, such as TWRP; if not or only official Recovery is available, use another method.
+Prerequisite: Your device must have a Custom Recovery, such as TWRP; if there is no custom recovery available for your device, use another method.
 
-Step:
+Steps:
 
-1. From the [Release page](https://github.com/tiann/KernelSU/releases) of KernelSU, download the zip package starting with AnyKernel3 that matches your phone version; for example, the phone kernel version is `android12-5.10. 66`, then you should download the file `AnyKernel3-android12-5.10.66_yyyy-MM.zip` (where `yyyy` is the year and `MM` is the month).
+1. From the [Release page](https://github.com/tiann/KernelSU/releases) of KernelSU, download the zip package starting with `AnyKernel3` that matches your phone version; for example, if the device's kernel version is `android12-5.10. 66`, then you should download the `AnyKernel3-android12-5.10.66_yyyy-MM.zip` file (where `yyyy` is the year and `MM` is the month).
-2. Reboot the phone into TWRP.
+2. Reboot the device into TWRP.
-3. Use adb to put AnyKernel3-*.zip into the phone /sdcard and choose to install it in the TWRP GUI; or you can directly `adb sideload AnyKernel-*.zip` to install.
+3. Use adb to place AnyKernel3-*.zip into the device's `/sdcard` location and choose to install it in the TWRP GUI; or you can directly run `adb sideload AnyKernel-*.zip` to install.
 
-PS. This method is suitable for any installation (not limited to initial installation or subsequent upgrades), as long as you use TWRP.
+P.S. This method is suitable for any installation (not limited to initial installation or subsequent upgrades), as long as you're using TWRP.
 
 ## Other methods
 
-In fact, all these installation methods have only one main idea, which is to **replace the original kernel for the one provided by KernelSU**; as long as this can be achieved, it can be installed; for example, the following are other possible methods.
+In fact, all of these installation methods have only one main idea, which is to **replace the original kernel for the one provided by KernelSU**; as long as this can be achieved, it can be installed; for example, the following are other possible methods.
 
-1. First install Magisk, get root privileges through Magisk and then use the kernel flasher to flash in the AnyKernel zip from KernelSU.
+1. First install Magisk, get root privileges through Magisk and then use the kernel flasher to flash in the AnyKernel3 zip from KernelSU.
-2. Use some flashing toolkit on PCs to flash in the kernel provided KernelSU.
+2. Use any flashing toolkit on PC to flash the kernel provided by KernelSU.
 
-But if it doesn't work, please try `magiskboot` way.
+However, if it doesn't work, please try `magiskboot` approach.

website/docs/guide/module-webui.md

@@ -24,7 +24,7 @@ If your page contains CSS and JavaScript, you need to place it in this directory
 
 ## JavaScript API
 
-If it is just a display page, it is no different from a normal web page. More importantly, KernelSU provides a series of system API that allow you to implement the unique functions of the module.
+If it is just a display page, it is no different from a normal web page. More importantly, KernelSU provides a series of system API that allows you to implement the unique functions of the module.
 
 KernelSU provides a JavaScript library and [publishes it on npm](https://www.npmjs.com/package/kernelsu), which you can use in the JavaScript code of your web pages.
 
@@ -38,11 +38,11 @@ const { errno, stdout } = exec("getprop ro.product.model");
 
 For another example, you can make the web page display full screen, or display a toast.
 
-[API documentation](https://www.npmjs.com/package/kernelsu)
+[API documentation](https://www.npmjs.com/package/kernelsu).
 
 If you find that the existing API does not meet your needs or is inconvenient to use, you are welcome to give us suggestions [here](https://github.com/tiann/KernelSU/issues)!
 
 ## Some tips
 
-1. You can use `localStorage` normally to store some data, but it will be lost after the Manager App is uninstalled. If you need to save persistently, you can write data to some directory yourself.
+1. You can use `localStorage` normally to store some data, but it will be lost after the Manager App is uninstalled. If you need to save persistently, you can write data to a custom directory yourself.
-2. For simple pages, I recommend you use [parceljs](https://parceljs.org/) for packaging. It requires zero configuration and is very convenient to use. However, if you are a front-end master or have your own preferences, then just choose one you like!
+2. For simple pages, I recommend you use [parceljs](https://parceljs.org/) for packaging. It requires zero configuration and is very convenient to use. However, if you are a front-end master or have your own preferences, then just choose the one you like!

website/docs/guide/module.md

@@ -6,20 +6,20 @@ The module mechanism of KernelSU is almost the same as that of Magisk. If you ar
 
 ## WebUI
 
-KernelSU's modules support displaying interfaces and interacting with users, please refer to the [WebUI documentation](module-webui.md).
+KernelSU's modules support displaying interfaces and interacting with users. For more, please refer to [WebUI documentation](module-webui.md).
 
 ## Busybox
 
-KernelSU ships with a feature complete BusyBox binary (including full SELinux support). The executable is located at `/data/adb/ksu/bin/busybox`. KernelSU's BusyBox supports runtime toggle-able "ASH Standalone Shell Mode". What this standalone mode means is that when running in the `ash` shell of BusyBox, every single command will directly use the applet within BusyBox, regardless of what is set as `PATH`. For example, commands like `ls`, `rm`, `chmod` will **NOT** use what is in `PATH` (in the case of Android by default it will be `/system/bin/ls`, `/system/bin/rm`, and `/system/bin/chmod` respectively), but will instead directly call internal BusyBox applets. This makes sure that scripts always run in a predictable environment and always have the full suite of commands no matter which Android version it is running on. To force a command _not_ to use BusyBox, you have to call the executable with full paths.
+KernelSU ships with a feature-complete BusyBox binary (including full SELinux support). The executable is located at `/data/adb/ksu/bin/busybox`. KernelSU's BusyBox supports runtime toggle-able "ASH Standalone Shell Mode". What this standalone mode means is that when running in the `ash` shell of BusyBox, every single command will directly use the applet within BusyBox, regardless of what is set as `PATH`. For example, commands like `ls`, `rm`, `chmod` will **NOT** use what is in `PATH` (in the case of Android by default it will be `/system/bin/ls`, `/system/bin/rm`, and `/system/bin/chmod` respectively), but will instead directly call internal BusyBox applets. This makes sure that scripts always run in a predictable environment and always have the full suite of commands no matter which Android version it is running on. To force a command _not_ to use BusyBox, you have to call the executable with full paths.
 
 Every single shell script running in the context of KernelSU will be executed in BusyBox's `ash` shell with standalone mode enabled. For what is relevant to 3rd party developers, this includes all boot scripts and module installation scripts.
 
 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 internally use) 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
 
@@ -99,10 +99,10 @@ author=<string>
 description=<string>
 ```
 
-- `id` has to match this regular expression: `^[a-zA-Z][a-zA-Z0-9._-]+$`<br>
+- `id` has to match this regular expression: `^[a-zA-Z][a-zA-Z0-9._-]+$` .<br>
-  ex: ✓ `a_module`, ✓ `a.module`, ✓ `module-101`, ✗ `a module`, ✗ `1_module`, ✗ `-a-module`<br>
+  Example: ✓ `a_module`, ✓ `a.module`, ✓ `module-101`, ✗ `a module`, ✗ `1_module`, ✗ `-a-module`<br>
   This is the **unique identifier** of your module. You should not change it once published.
-- `versionCode` has to be an **integer**. This is used to compare versions
+- `versionCode` has to be an **integer**. This is used to compare versions.
 - Others that weren't mentioned above can be any **single line** string.
 - Make sure to use the `UNIX (LF)` line break type and not the `Windows (CR+LF)` or `Macintosh (CR)`.
 
@@ -177,12 +177,12 @@ module.zip
 ```
 
 :::warning
-KernelSU module is NOT supported to be installed in custom recovery!!
+KernelSU module is NOT supported to be installed via a custom recovery!!
 :::
 
 ### Customization
 
-If you need to customize the module installation process, optionally you can create a script in the installer named `customize.sh`. This script will be _sourced_ (not executed!) by the module installer script after all files are extracted and default permissions and secontext are applied. This is very useful if your module require additional setup based on the device ABI, or you need to set special permissions/secontext for some of your module files.
+If you need to customize the module installation process, optionally you can create a script in the installer named `customize.sh`. This script will be _sourced_ (not executed!) by the module installer script after all files are extracted and default permissions and secontext are applied. This is very useful if your module requires additional setup based on the device ABI, or you need to set special permissions/secontext for some of your module files.
 
 If you would like to fully control and customize the installation process, declare `SKIPUNZIP=1` in `customize.sh` to skip all default installation steps. By doing so, your `customize.sh` will be responsible to install everything by itself.
 
@@ -191,16 +191,16 @@ The `customize.sh` script runs in KernelSU's BusyBox `ash` shell with "Standalon
 #### Variables
 
 - `KSU` (bool): a variable to mark that the script is running in the KernelSU environment, and the value of this variable will always be true. You can use it to distinguish between KernelSU and Magisk.
-- `KSU_VER` (string): the version string of current installed KernelSU (e.g. `v0.4.0`)
+- `KSU_VER` (string): the version string of currently installed KernelSU (e.g. `v0.4.0`).
-- `KSU_VER_CODE` (int): the version code of current installed KernelSU in userspace (e.g. `10672`)
+- `KSU_VER_CODE` (int): the version code of currently installed KernelSU in userspace (e.g. `10672`).
-- `KSU_KERNEL_VER_CODE` (int): the version code of current installed KernelSU in kernel space (e.g. `10672`)
+- `KSU_KERNEL_VER_CODE` (int): the version code of currently installed KernelSU in kernel space (e.g. `10672`).
-- `BOOTMODE` (bool): always be `true` in KernelSU
+- `BOOTMODE` (bool): always be `true` in KernelSU.
-- `MODPATH` (path): the path where your module files should be installed
+- `MODPATH` (path): the path where your module files should be installed.
-- `TMPDIR` (path): a place where you can temporarily store files
+- `TMPDIR` (path): a place where you can temporarily store files.
-- `ZIPFILE` (path): your module's installation zip
+- `ZIPFILE` (path): your module's installation zip.
-- `ARCH` (string): the CPU architecture of the device. Value is either `arm`, `arm64`, `x86`, or `x64`
+- `ARCH` (string): the CPU architecture of the device. Value is either `arm`, `arm64`, `x86`, or `x64`.
-- `IS64BIT` (bool): `true` if `$ARCH` is either `arm64` or `x64`
+- `IS64BIT` (bool): `true` if `$ARCH` is either `arm64` or `x64`.
-- `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
 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.
@@ -234,28 +234,28 @@ set_perm_recursive <directory> <owner> <group> <dirpermission> <filepermission>
 
 ## Boot scripts
 
-In KernelSU, scripts are divided into two types based on their running mode: post-fs-data mode and late_start service mode:
+In KernelSU, scripts are divided into two types based on their running mode: post-fs-data mode and late_start service mode.
 
 - post-fs-data mode
   - This stage is BLOCKING. The boot process is paused before execution is done, or 10 seconds have passed.
   - Scripts run before any modules are mounted. This allows a module developer to dynamically adjust their modules before it gets mounted.
-  - This stage happens before Zygote is started, which pretty much means everything in Android
+  - This stage happens before Zygote is started, which pretty much means everything in Android.
   - **WARNING:** using `setprop` will deadlock the boot process! Please use `resetprop -n <prop_name> <prop_value>` instead.
   - **Only run scripts in this mode if necessary.**
 - late_start service mode
   - This stage is NON-BLOCKING. Your script runs in parallel with the rest of the booting process.
   - **This is the recommended stage to run most scripts.**
 
-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
-  - 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`)
   - 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
-  - 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.
 
 All boot scripts will run in KernelSU's BusyBox `ash` shell with "Standalone Mode" enabled.

website/docs/guide/rescue-from-bootloop.md

@@ -1,6 +1,6 @@
 # Rescue from bootloop
 
-When flashing a device, we may encounter situations where the device becomes "bricked". In theory, if you only use fastboot to flash the boot partition or install unsuitable modules that cause the device to fail to boot, then this can be restored by appropriate operations. This document aims to provide some emergency methods to help you recover from a "bricked" device.
+When flashing a device, we may encounter situations when the device becomes "bricked". In theory, if you only use fastboot to flash the boot partition or install incompatible modules that cause the device to fail to boot, then this can be restored by appropriate operations. This document aims to provide some emergency methods to help you recover from a "bricked" state.
 
 ## Brick by flashing boot partition
 
@@ -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
+1. AB update.
-2. Rescue by pressing Volume Down
+2. Rescue by pressing Volume Down.
 
 #### AB update
 
@@ -44,7 +44,7 @@ The built-in safe mode is implemented in the kernel, so there is no possibility
 
 ### Malicious modules
 
-If the above methods cannot rescue your device, it is highly likely that the module you installed has malicious operations or has damaged your device through other means. In this case, there are only two suggestions:
+If the above methods cannot rescue your device, it is very likely that the module you installed has malicious operations or has damaged your device through other means. In this case, there are only two suggestions:
 
 1. Wipe the data and flash the official system.
 2. Consult the after-sales service.

website/docs/guide/what-is-kernelsu.md

@@ -1,6 +1,6 @@
 # What is KernelSU?
 
-KernelSU is a root solution for Android GKI devices, it works in kernel mode and grant root permission to userspace application directly in kernel space.
+KernelSU is a root solution for Android GKI devices, it works in kernel mode and grants root permission to userspace applications directly in kernel space.
 
 ## Features