From a634ec2bfcc8f49ab4e7a04fdb677c778243f1ea Mon Sep 17 00:00:00 2001 From: igor <134963561+igormiguell@users.noreply.github.com> Date: Fri, 13 Dec 2024 01:22:07 -0300 Subject: [PATCH] website: update translation (#2226) --- website/docs/.vitepress/locales/en.ts | 2 +- website/docs/guide/app-profile.md | 30 ++++---- website/docs/guide/difference-with-magisk.md | 6 +- website/docs/guide/faq.md | 6 +- website/docs/guide/hidden-features.md | 2 +- website/docs/guide/how-to-build.md | 12 ++-- .../guide/how-to-integrate-for-non-gki.md | 8 +-- website/docs/guide/installation.md | 68 +++++++++---------- website/docs/guide/module-webui.md | 6 +- website/docs/guide/module.md | 20 +++--- website/docs/guide/rescue-from-bootloop.md | 8 +-- website/docs/guide/what-is-kernelsu.md | 4 +- website/docs/index.md | 14 ++-- website/docs/ja_JP/guide/module-webui.md | 2 +- website/docs/pt_BR/guide/app-profile.md | 2 +- website/docs/pt_BR/guide/installation.md | 16 ++--- website/docs/pt_BR/guide/module-webui.md | 2 +- website/docs/pt_BR/guide/module.md | 2 +- .../docs/pt_BR/guide/rescue-from-bootloop.md | 6 +- 19 files changed, 108 insertions(+), 108 deletions(-) diff --git a/website/docs/.vitepress/locales/en.ts b/website/docs/.vitepress/locales/en.ts index 7a6ed06cf62d..ebf361f3fb2e 100644 --- a/website/docs/.vitepress/locales/en.ts +++ b/website/docs/.vitepress/locales/en.ts @@ -50,7 +50,7 @@ function sidebarGuide() { { text: 'How to build?', link: '/guide/how-to-build' }, { text: 'Intergrate for non-GKI devices', link: '/guide/how-to-integrate-for-non-gki'}, { text: 'Unofficially supported devices', link: '/guide/unofficially-support-devices.md' }, - { text: 'Module Guide', link: '/guide/module.md' }, + { text: 'Module guide', link: '/guide/module.md' }, { text: 'Module WebUI', link: '/guide/module-webui.md' }, { text: 'App Profile', link: '/guide/app-profile.md' }, { text: 'Rescue from bootloop', link: '/guide/rescue-from-bootloop.md' }, diff --git a/website/docs/guide/app-profile.md b/website/docs/guide/app-profile.md index 888acb49af32..4cbad69ccf17 100644 --- a/website/docs/guide/app-profile.md +++ b/website/docs/guide/app-profile.md @@ -1,10 +1,10 @@ # App Profile -The App Profile is a mechanism provided by KernelSU for customizing the configuration of various applications. +The App Profile is a mechanism provided by KernelSU for customizing the configuration of various apps. -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 apps 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 apps while denying file access permissions, or it can grant shell permissions instead of full root access for freeze apps: **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 apps without root permissions, the App Profile can control the behavior of the kernel and module system towards these apps. 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 @@ -14,7 +14,7 @@ Linux systems have two concepts: users and groups. Each user has a user ID (UID) Users with a UID of 0 are known as root users, and groups with a GID of 0 are known as root groups. The root user group typically holds the highest system privileges. -In the case of the Android system, each app is a separate user (excluding shared UID scenarios) with a unique UID. For example, `0` represents the root user, `1000` represents `system`, `2000` represents the ADB shell, and UIDs ranging from 10000 to 19999 represent ordinary apps. +In the case of the Android system, each app is a separate user (excluding shared UID scenarios) with a unique UID. For example, `0` represents the root user, `1000` represents `system`, `2000` represents the ADB shell, and UIDs ranging from `10000` to `19999` represent ordinary apps. :::info Here, the UID mentioned is not the same as the concept of multiple users or work profiles in the Android system. Work profiles are actually implemented by partitioning the UID range. For example, 10000-19999 represents the main user, while 110000-119999 represents a work profile. Each ordinary app among them has its own unique UID. @@ -37,13 +37,13 @@ KernelSU's Root Profile allows customization of the UID, GID, and groups for the The App Profile only controls the permissions of the root process after using `su`; it does not control the permissions of the app itself. If an app has requested network access permission, it can still access the network even without using `su`. Removing the `inet` group from `su` only prevents `su` from accessing the network. ::: -Root Profile is enforced in the kernel and does not rely on the voluntary behavior of root applications, unlike switching users or groups through `su`, the granting of `su` permission is entirely up to the user rather than the developer. +Root Profile is enforced in the kernel and does not rely on the voluntary behavior of root apps, unlike switching users or groups through `su`, the granting of `su` permission is entirely up to the user rather than the developer. ### Capabilities Capabilities are a mechanism for privilege separation in Linux. -For the purpose of performing permission checks, traditional UNIX implementations distinguish two categories of processes: privileged processes (whose effective user ID is 0, referred to as superuser or root), and unprivileged processes (whose effective UID is nonzero). Privileged processes bypass all kernel permission checks, while unprivileged processes are subject to full permission checking based on the process's credentials (usually: effective UID, effective GID, and supplementary group list). +For the purpose of performing permission checks, traditional `UNIX` implementations distinguish two categories of processes: privileged processes (whose effective user ID is `0`, referred to as superuser or root), and unprivileged processes (whose effective UID is nonzero). Privileged processes bypass all kernel permission checks, while unprivileged processes are subject to full permission checking based on the process's credentials (usually: effective UID, effective GID, and supplementary group list). Starting with Linux 2.2, Linux divides the privileges traditionally associated with superuser into distinct units, known as capabilities, which can be independently enabled and disabled. @@ -91,10 +91,10 @@ Note that the `allow app1 * * *` rule is used for demonstration purposes only. I If the configuration of the Root Profile is not set properly, an escalation scenario may occur: the restrictions imposed by the Root Profile can unintentionally fail. -For example, if you grant root permission to an ADB shell user (which is a common case), and then you grant root permission to a regular application but configure its root profile with UID 2000 (which is the UID of the ADB shell user), the application can obtain full root access by executing the `su` command twice: +For example, if you grant root permission to an ADB shell user (which is a common case), and then you grant root permission to a regular app but configure its root profile with UID 2000 (which is the UID of the ADB shell user), the app can obtain full root access by executing the `su` command twice: -1. The first `su` execution is subject to the enforcement of the App Profile and will switch to UID `2000` (adb shell) instead of `0` (root). -2. The second `su` execution, since the UID is `2000`, and you have granted root access to the UID `2000` (adb shell) in the configuration, the application will gain full root privileges. +1. The first `su` execution is subject to the enforcement of the App Profile and will switch to UID `2000` (ADB shell) instead of `0` (root). +2. The second `su` execution, since the UID is `2000`, and you have granted root access to the UID `2000` (ADB shell) in the configuration, the app will gain full root privileges. :::warning Note This behavior is entirely expected and not a bug. Therefore, we recommend the following: @@ -104,15 +104,15 @@ If you genuinely need to grant root permissions to ADB (e.g., as a developer), i ## Non-Root Profile -### Umount Modules +### Umount modules -KernelSU provides a systemless mechanism for modifying system partitions, achieved through overlayfs mounting. However, some apps may be sensitive to such behavior. Thus, we can unload modules mounted on these apps by setting the "umount modules" option. +KernelSU provides a systemless mechanism for modifying system partitions, achieved through OverlayFS mounting. However, some apps may be sensitive to such behavior. Thus, we can unload modules mounted on these apps by setting the "Umount modules" option. -Additionally, the settings interface of the KernelSU manager provides a switch for "umount modules by default". By default, this switch is **enabled**, which means that KernelSU or some modules will unload modules for this app unless additional settings are applied. If you do not prefer this setting or if it affects certain apps, you have the following options: +Additionally, the settings interface of the KernelSU manager provides a switch for "Umount modules by default". By default, this switch is **enabled**, which means that KernelSU or some modules will unload modules for this app unless additional settings are applied. If you do not prefer this setting or if it affects certain apps, you have the following options: -1. Keep the switch for "umount modules by default" and individually disable the "umount modules" option in the App Profile for apps requiring module loading (acting as a "whitelist"). -2. Disable the switch for "umount modules by default" and individually enable the "umount modules" option in the App Profile for apps requiring module unloading (acting as a "blacklist"). +1. Keep the switch for "Umount modules by default" and individually disable the "Umount modules" option in the App Profile for apps requiring module loading (acting as a "whitelist"). +2. Disable the switch for "Umount modules by default" and individually enable the "Umount modules" option in the App Profile for apps requiring module unloading (acting as a "blacklist"). :::info -In devices using kernel version 5.10 and above, the kernel performs without any further action the unloading of modules. However, for devices running kernel versions below 5.10, this switch is merely a configuration option, and KernelSU itself does not take any action. If you want to be able to use the "umount modules" option in kernel versions before 5.10 you need to backport the `path_umount` function in `fs/namespace.c`, you can get more information at the end of the [How to integrate for non GKI](https://kernelsu.org/guide/how-to-integrate-for-non-gki.html#how-to-backport-path_umount) page. Some modules, such as Zygisksu, may also use this switch to determine whether module unloading is necessary. +In devices using kernel version 5.10 and above, the kernel performs without any further action the unloading of modules. However, for devices running kernel versions below 5.10, this switch is merely a configuration option, and KernelSU itself does not take any action. If you want to be able to use the "Umount modules" option in kernel versions before 5.10 you need to backport the `path_umount` function in `fs/namespace.c`, you can get more information at the end of the [How to integrate KernelSU for non-GKI kernels](https://kernelsu.org/guide/how-to-integrate-for-non-gki.html#how-to-backport-path_umount) page. Some modules, such as Zygisksu, may also use this switch to determine whether module unloading is necessary. ::: diff --git a/website/docs/guide/difference-with-magisk.md b/website/docs/guide/difference-with-magisk.md index be71543b08a0..f4b68162d0c2 100644 --- a/website/docs/guide/difference-with-magisk.md +++ b/website/docs/guide/difference-with-magisk.md @@ -6,12 +6,12 @@ Although there are many similarities between KernelSU modules and Magisk modules - 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`. -- 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. - service.sh: the execution time and semantics are exactly the same. - system.prop: 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 @@ -25,4 +25,4 @@ Here are some differences: - 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. diff --git a/website/docs/guide/faq.md b/website/docs/guide/faq.md index 76981c23fd41..04217a04d1fc 100644 --- a/website/docs/guide/faq.md +++ b/website/docs/guide/faq.md @@ -4,7 +4,7 @@ First, your devices should be able to unlock the bootloader. If it can't, then it is unsupported. -Then install KernelSU manager App to your device and open it, if it shows `Unsupported` then your device cannot be supported out of box, but you can build kernel source and integrate KernelSU to make it work or using [unofficially-support-devices](unofficially-support-devices). +Then install KernelSU manager App to your device and open it, if it shows `Unsupported` then your device cannot be supported out of box, but you can build kernel source and integrate KernelSU to make it work or using [Unofficially supported devices](unofficially-support-devices). ## Does KernelSU need to unlock Bootloader? @@ -12,7 +12,7 @@ Certainly, yes. ## Does KernelSU support modules? -Yes, check [Module Guide](module.md) please. +Yes, check [Module guide](module.md) please. ## Does KernelSU support Xposed? @@ -49,7 +49,7 @@ It is possible, KernelSU is backported to kernel 4.14 now; for older kernel, you ## How to integrate KernelSU for an older kernel? -Please refer to the following [Guide](how-to-integrate-for-non-gki). +Please refer to the following [How to integrate KernelSU for non-GKI kernels](how-to-integrate-for-non-gki) guide. ## Why my Android version is 13, and the kernel shows "android12-5.10"? diff --git a/website/docs/guide/hidden-features.md b/website/docs/guide/hidden-features.md index af365f620e72..a2682fe3359c 100644 --- a/website/docs/guide/hidden-features.md +++ b/website/docs/guide/hidden-features.md @@ -1,4 +1,4 @@ -# Hidden Features +# Hidden features ## .ksurc diff --git a/website/docs/guide/how-to-build.md b/website/docs/guide/how-to-build.md index 88b6c54cb417..ca7582e652ce 100644 --- a/website/docs/guide/how-to-build.md +++ b/website/docs/guide/how-to-build.md @@ -2,14 +2,14 @@ First, you should read the Android Official docs for kernel build: -1. [Building Kernels](https://source.android.com/docs/setup/build/building-kernels) -2. [GKI Release Builds](https://source.android.com/docs/core/architecture/kernel/gki-release-builds) +1. [Build kernels](https://source.android.com/docs/setup/build/building-kernels) +2. [GKI release builds](https://source.android.com/docs/core/architecture/kernel/gki-release-builds) ::: warning This page is for GKI devices, if you use an old kernel, please refer [How to integrate KernelSU for non-GKI kernels](how-to-integrate-for-non-gki). ::: -## Build Kernel +## Build kernel ### Sync the kernel source code @@ -20,13 +20,13 @@ repo init -m manifest.xml repo sync ``` -The `` 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 `` 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 [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, to build an aarch64 kernel image: +For example, to build an `aarch64` kernel image: ```sh LTO=thin BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh @@ -50,7 +50,7 @@ rm common/android/abi_gki_protected_exports_* ## Build Kernel with KernelSU -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: +If you are 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 diff --git a/website/docs/guide/how-to-integrate-for-non-gki.md b/website/docs/guide/how-to-integrate-for-non-gki.md index b4e6c80253f6..6ed92765eb80 100644 --- a/website/docs/guide/how-to-integrate-for-non-gki.md +++ b/website/docs/guide/how-to-integrate-for-non-gki.md @@ -59,7 +59,7 @@ 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'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: +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: ```txt # KernelSU @@ -258,7 +258,7 @@ index 2ff887661237..e758d7db7663 100644 ### Safe Mode -To enable KernelSU's built-in SafeMode, you should additionally modify `input_handle_event` function in `drivers/input/input.c`: +To enable KernelSU's built-in Safe Mode, 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 in preventing bootloops! @@ -297,7 +297,7 @@ If you use manual integration and do not disable `CONFIG_KPROBES`, then the user ### Failed to execute `pm` in terminal? -You should modify `fs/devpts/inode.c`, reference: +You should modify `fs/devpts/inode.c`. Reference: ```diff diff --git a/fs/devpts/inode.c b/fs/devpts/inode.c @@ -329,7 +329,7 @@ index 32f6f1c68..d69d8eca2 100644 ### How to backport path_umount -You can get module umount feature working on pre-GKI kernels by manually backporting `path_umount` from 5.9. You can use this patch as reference: +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: ```diff --- a/fs/namespace.c diff --git a/website/docs/guide/installation.md b/website/docs/guide/installation.md index 714704eb4453..22481abcadd0 100644 --- a/website/docs/guide/installation.md +++ b/website/docs/guide/installation.md @@ -4,11 +4,11 @@ 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 will not and never provide a boot image for you to flash. - If the app shows `Not installed`, then your devices is officially supported by KernelSU. :::info -For devices showing `Unsupported`, here is an [Unofficially-support-devices](unofficially-support-devices.md), you can compile the kernel yourself. +For devices showing `Unsupported`, here is an [Unofficially supported devices](unofficially-support-devices.md). You can compile the kernel yourself. ::: ## Backup stock boot.img @@ -16,7 +16,7 @@ For devices showing `Unsupported`, here is an [Unofficially-support-devices](uno Before flashing, you must first backup your stock boot.img. If you encounter any bootloop, you can always restore the system by flashing back to the stock factory boot using fastboot. ::: warning -Flashing may cause data loss, be sure to do this step well before proceeding to the next step!! You can also back up all the data on your phone if necessary. +Flashing may cause data loss, be sure to do this step well before proceeding to the next step! You can also back up all the data on your device if necessary. ::: ## Necessary knowledge @@ -27,7 +27,7 @@ By default, you will use ADB and fastboot tools in this tutorial, so if you don' ### KMI -Kernel Module Interface (KMI), kernel versions with the same KMI are **compatible** This is what "general" means in GKI; conversely, if the KMI is different, then these kernels are not compatible with each other, and flashing a kernel image with a different KMI than your device may cause a bootloop. +Kernel Module Interface (KMI), kernel versions with the same KMI are **compatible**, this is what "general" means in GKI; conversely, if the KMI is different, then these kernels are not compatible with each other, and flashing a kernel image with a different KMI than your device may cause a bootloop. Specifically, for GKI devices, the kernel version format should be as follows: @@ -53,11 +53,11 @@ Therefore, kernels with latest security patch levels are preferred for maintaini Please note: **Kernel version and Android version are not necessarily the same!** -If you find that your kernel version is `android12-5.10.101`, but your Android system version is Android 13 or other, please don't be surprised, because the version number of the Android system is not necessarily the same as the version number of the Linux kernel. The version number of the Linux kernel is generally correspondent to the version of the Android system that comes with the **device when it is shipped**. If the Android system is upgraded later, the kernel version will generally not change. So before flashing anything, **please always refer to the kernel version!** +If you find that your kernel version is `android12-5.10.101`, but your Android system version is Android 13 or other, please don't be surprised, because the version number of the Android system is not necessarily the same as the version number of the Linux kernel. The version number of the Linux kernel is generally correspondent to the version of the Android system that comes with the **device when it is shipped**. If the Android system is upgraded later, the kernel version will generally not change. So, before flashing anything, **always refer to the kernel version!** ## Introduction -Since version `0.9.0`, KernelSU supports two running modes on GKI devices: +Since version [0.9.0](https://github.com/tiann/KernelSU/releases/tag/v0.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. @@ -77,7 +77,7 @@ In LKM mode, the original kernel of the device will not be replaced, but the loa 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 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 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 @@ -92,9 +92,9 @@ If your device is a mobile phone, we recommend that you prioritize LKM mode; if ### Get the official firmware -To use LKM mode, you need to get the official firmware and then patch it on the basis of the official firmware; if you use a third-party kernel, you can use the `boot.img` of the third-party kernel as the official firmware. +To use LKM mode, you need to get the official firmware and then patch it on the basis of the official firmware. If you use a third-party kernel, you can use the `boot.img` of the third-party kernel as the official firmware. -There are many ways to get the official firmware. If your device supports `fastboot boot`, then we recommend **the most recommended and simplest** method is to use `fastboot boot` to temporarily boot the GKI kernel provided by KernelSU, then install the manager, and finally install it directly in the manager; this method does not require you to manually download the official firmware, nor do you need to manually extract the boot. +There are many ways to get the official firmware. If your device supports `fastboot boot`, then we recommend **the most recommended and simplest** method is to use `fastboot boot` to temporarily boot the GKI kernel provided by KernelSU, then install the manager, and finally install it directly in the manager. This method does not require you to manually download the official firmware, nor do you need to manually extract the boot. 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. @@ -104,17 +104,17 @@ Unlike GKI mode, LKM mode will modify the `ramdisk`, so on devices with Android Open the manager, click the installation icon in the upper right corner, and several options will appear: -1. Select and patch a file; if your phone does not have root permissions, you can choose this option, and then select your official firmware, the manager will automatically patch it; you only need to flash this patched file to permanently obtain root permissions. -2. Install directly; if your phone is already rooted, you can choose this option, the manager will automatically get your device information, and then automatically patch the official firmware, and then flash it; you can consider using `fastboot boot` KernelSU's GKI kernel to get temporary root and install the manager, and then use this option; this is also the main way to upgrade KernelSU. -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. +1. Select and patch a file. If your device 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 device is already rooted, you can choose this option, the manager will automatically get your device information, and then automatically patch the official firmware, and then flash it; you can consider using `fastboot boot` KernelSU's GKI kernel to get temporary root and install the manager, and then use this option; this is also the main way to upgrade KernelSU. +3. Install to another partition. If your device supports A/B partition, you can choose this option, the manager will automatically patch the official firmware, and then install it to another partition; this method is suitable for devices after OTA, you can directly install it to another partition after OTA, and then restart the device. ### Use the command line -If you don’t want to use the manager, you can also use the command line to install LKM; the `ksud` tool provided by KernelSU can help you quickly patch the official firmware and then flash it. +If you do not want to use the manager, you can also use the command line to install LKM. The `ksud` tool provided by KernelSU can help you quickly patch the official firmware and then flash it. 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 options. +Usage: `ksud boot-patch` you can check the command line help for specific options. ```sh oriole:/ # ksud boot-patch -h @@ -137,7 +137,7 @@ 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 refer to [this](#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 do not 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. The most common usage is: @@ -163,14 +163,14 @@ If your device's `boot.img` uses a commonly used compression format, you can use KernelSU provides a generic boot.img for GKI devices, and you should flash the boot.img to the boot partition of the device. -You can download boot.img from [GitHub Release](https://github.com/tiann/KernelSU/releases), please note that you should use the correct version of boot.img. If you don't know which file to download, please carefully read the description of [KMI](#kmi) and [Security patch level](#security-patch-level) in this document. +You can download boot.img from [GitHub Release](https://github.com/tiann/KernelSU/releases), please note that you should use the correct version of boot.img. If you do not 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. :::info Compression format of boot.img 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 the instructions below. +2. Xiaomi devices usually use `gz` or `uncompressed`. +3. For Pixel devices, follow the instructions below: ::: ### Flash boot.img to device @@ -197,13 +197,13 @@ fastboot reboot Steps: -1. Download the AnyKernel3 zip. If you don't know which file to download, please carefully read the description of [KMI](#kmi) and [Security Patch Level](#security-patch-level) in this document. -2. Open the Kernel Flash App (grant necessary root permissions) and use the provided AnyKernel3 zip to flash. +1. Download the AnyKernel3 zip. If you do not 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. This way requires the kernel flash App to have root permissions. You can use the following methods to achieve this: 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 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. +2. If your device is not rooted, but the device 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: @@ -211,11 +211,11 @@ Some of kernel flashing apps that can be used for this: 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) -P.S. This method is more convenient when upgrading KernelSU and can be done without a computer (make a backup first!). +Note: 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 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. +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 device 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: @@ -230,15 +230,15 @@ Android-Image-Kitchen is not recommended for now, as it doesn't handle the boot ### 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). -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*). +1. Get your device'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](#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). 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` +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 run `cd /data/local/tmp/` directory, then `chmod +x magiskboot` 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. @@ -248,19 +248,19 @@ Android-Image-Kitchen is not recommended for now, as it doesn't handle the boot ### Using magiskboot on Windows/macOS/Linux PC{#using-magiskboot-on-PC} 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. +2. Prepare stock `boot.img` and `Image` in your PC. 3. Run `chmod +x magiskboot`. 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` by running the command: `mv -f Image kernel`. 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 in Linux environments normally, if you are a Linux user, you can use the 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 {#install-with-custom-recovery} -Prerequisite: Your device must have a Custom Recovery, such as TWRP; if there is no custom recovery available for your device, 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. Steps: @@ -268,13 +268,13 @@ Steps: 2. Reboot the device into TWRP. 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. -P.S. This method is suitable for any installation (not limited to initial installation or subsequent upgrades), as long as you're using TWRP. +Note: This method is suitable for any installation (not limited to initial installation or subsequent upgrades), as long as you are using TWRP. ## Other 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. +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. 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 AnyKernel3 zip from KernelSU. 2. Use any flashing toolkit on PC to flash the kernel provided by KernelSU. -However, if it doesn't work, please try `magiskboot` approach. +However, if it does not work, please try `magiskboot` approach. diff --git a/website/docs/guide/module-webui.md b/website/docs/guide/module-webui.md index 4afa5ddbd767..e26832577a82 100644 --- a/website/docs/guide/module-webui.md +++ b/website/docs/guide/module-webui.md @@ -4,7 +4,7 @@ In addition to executing boot scripts and modifying system files, KernelSU's mod The module can write HTML + CSS + JavaScript pages through any web technology. KernelSU's manager will display these pages through WebView. It also provides some APIs for interacting with the system, such as executing shell commands. -## webroot directory +## `webroot` directory Web resource files should be placed in the `webroot` subdirectory of the module root directory, and there **MUST** be a file named `index.html`, which is the module page entry. The simplest module structure containing a web interface is as follows: @@ -17,7 +17,7 @@ Web resource files should be placed in the `webroot` subdirectory of the module ``` :::warning -When installing the module, KernelSU will automatically set the permissions and SELinux context of this directory. If you don’t know what you are doing, please do not set the permissions of this directory yourself! +When installing the module, KernelSU will automatically set the permissions and SELinux context of this directory. If you do not know what you are doing, please do not set the permissions of this directory yourself! ::: If your page contains CSS and JavaScript, you need to place it in this directory as well. @@ -44,5 +44,5 @@ If you find that the existing API does not meet your needs or is inconvenient to ## 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 a custom 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 the one you like! diff --git a/website/docs/guide/module.md b/website/docs/guide/module.md index 9625d16382ca..7ad4193e2dbf 100644 --- a/website/docs/guide/module.md +++ b/website/docs/guide/module.md @@ -1,4 +1,4 @@ -# Module Guide +# 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". @@ -108,7 +108,7 @@ description= ### 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. @@ -118,12 +118,12 @@ You can use the environment variable KSU to determine if a script is running in ### `system` directory -The contents of this directory will be overlaid on top of the system's /system partition using overlayfs after the system is booted. This means that: +The contents of this directory will be overlaid on top of the system's `/system` partition using OverlayFS after the system is booted. This means that: 1. Files with the same name as those in the corresponding directory in the system will be overwritten by the files in this directory. 2. Folders with the same name as those in the corresponding directory in the system will be merged with the folders in this directory. -If you want to delete a file or folder in the original system directory, you need to create a file with the same name as the file/folder in the module directory using `mknod filename c 0 0`. This way, the overlayfs system will automatically "whiteout" this file as if it has been deleted (the /system partition is not actually changed). +If you want to delete a file or folder in the original system directory, you need to create a file with the same name as the file/folder in the module directory using `mknod filename c 0 0`. This way, the OverlayFS system will automatically "whiteout" this file as if it has been deleted (the /system partition is not actually changed). You can also declare a variable named `REMOVE` containing a list of directories in `customize.sh` to execute removal operations, and KernelSU will automatically execute `mknod c 0 0` in the corresponding directories of the module. For example: @@ -136,7 +136,7 @@ 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. -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 ` 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 ` 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: @@ -151,10 +151,10 @@ This list will automatically create the directories `$MODPATH/system/app/YouTube ::: 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. ::: -If you are interested in overlayfs, it is recommended to read the Linux Kernel's [documentation on overlayfs](https://docs.kernel.org/filesystems/overlayfs.html). +If you are interested in OverlayFS, it is recommended to read the Linux Kernel's [documentation on OverlayFS](https://docs.kernel.org/filesystems/overlayfs.html). ### system.prop @@ -166,7 +166,7 @@ If your module requires some additional sepolicy patches, please add those rules ## Module installer -A KernelSU module installer is a KernelSU module packaged in a zip file that can be flashed in the KernelSU manager APP. The simplest KernelSU module installer is just a KernelSU module packed as a zip file. +A KernelSU module installer is a KernelSU module packaged in a zip file that can be flashed in the KernelSU manager. The simplest KernelSU module installer is just a KernelSU module packed as a zip file. ```txt module.zip @@ -184,7 +184,7 @@ 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 requires 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. @@ -258,7 +258,7 @@ In KernelSU, startup scripts are divided into two types based on their storage l - Module scripts - Placed in the module's own folder. - Only executed if the module is enabled. - - `post-fs-data.sh` runs in post-fs-data mode, `service.sh` runs in late_start service mode, `boot-completed.sh` runs on boot completed, `post-mount.sh` runs on overlayfs mounted. + - `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. diff --git a/website/docs/guide/rescue-from-bootloop.md b/website/docs/guide/rescue-from-bootloop.md index 987bd13a8220..b6cec241e5d1 100644 --- a/website/docs/guide/rescue-from-bootloop.md +++ b/website/docs/guide/rescue-from-bootloop.md @@ -6,11 +6,11 @@ When flashing a device, we may encounter situations when the device becomes "bri In KernelSU, the following situations may cause boot brick when flashing the boot partition: -1. You flashed a boot image in the wrong format. For example, if your phone's boot format is `gz`, but you flashed an `lz4` format image, then the phone will not be able to boot. -2. Your phone needs to disable AVB verification in order to boot properly (usually requiring wiping all data on the phone). -3. Your kernel has some bugs or is not suitable for your phone to flash. +1. You flashed a boot image in the wrong format. For example, if your device's boot format is `gz`, but you flashed an `lz4` format image, then the device will not be able to boot. +2. Your device needs to disable AVB verification in order to boot properly (usually requiring wiping all data on the device). +3. Your kernel has some bugs or is not suitable for your device to flash. -No matter what the situation is, you can recover by **flashing the stock boot image**. Therefore, at the beginning of the installation tutorial, we strongly recommend that you back up your stock boot before flashing. If you haven't backed up, you can obtain the original factory boot from other users with the same device as you or from the official firmware. +No matter what the situation is, you can recover by **flashing the stock boot image**. Therefore, at the beginning of the installation tutorial, we strongly recommend that you back up your stock boot before flashing. If you have not backed up, you can obtain the original factory boot from other users with the same device as you or from the official firmware. ## Brick by modules diff --git a/website/docs/guide/what-is-kernelsu.md b/website/docs/guide/what-is-kernelsu.md index 1cd8ab7ec33c..0d8b358bd24f 100644 --- a/website/docs/guide/what-is-kernelsu.md +++ b/website/docs/guide/what-is-kernelsu.md @@ -1,12 +1,12 @@ # What is KernelSU? -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. +KernelSU is a root solution for Android GKI devices, it works in kernel mode and grants root permission to userspace apps directly in kernel space. ## Features The main feature of KernelSU is it is **Kernel-based**. KernelSU works in kernel mode, so it can provide kernel interface we never had before. For example, we can add hardware breakpoint to any process in kernel mode; We can access physical memory of any process without anybody being aware of; We can intercept any syscall in kernel space; etc. -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? diff --git a/website/docs/index.md b/website/docs/index.md index b0d9474446db..d2c70c835886 100644 --- a/website/docs/index.md +++ b/website/docs/index.md @@ -11,7 +11,7 @@ hero: alt: KernelSU actions: - theme: brand - text: Get Started + text: Get started link: /guide/what-is-kernelsu - theme: alt text: View on GitHub @@ -19,10 +19,10 @@ hero: features: - title: Kernel-based - details: As the name suggests, KernelSU works under the Linux kernel giving it more control over userspace applications. - - title: Root Access Control - details: Only permitted apps may access or see `su`, all other apps are not aware of this. - - title: Customizable Root Privileges - details: KernelSU allows customization of `su`'s uid, gid, groups, capabilities, and SELinux rules, locking up root privileges. + details: As the name suggests, KernelSU works under the Linux kernel giving it more control over userspace apps. + - title: Root access control + details: Only permitted apps may access or see su, all other apps are not aware of this. + - title: Customizable root privileges + details: KernelSU allows customization of su's uid, gid, groups, capabilities, and SELinux rules, locking up root privileges. - title: Modules - details: Modules may modify /system systemlessly using overlayfs enabling great power. + details: Modules may modify /system systemlessly using OverlayFS enabling great power. diff --git a/website/docs/ja_JP/guide/module-webui.md b/website/docs/ja_JP/guide/module-webui.md index 15a3b8f16a16..8148f79d86bb 100644 --- a/website/docs/ja_JP/guide/module-webui.md +++ b/website/docs/ja_JP/guide/module-webui.md @@ -4,7 +4,7 @@ KernelSU のモジュールは、ブートスクリプトの実行やシステ モジュールは、任意の Web 技術を通じて HTML + CSS + JavaScript のページを作成することができます。KernelSU のマネージャーは WebView を通じてこれらのページを表示します。また、シェルコマンドの実行など、システムと対話するためのいくつかのAPIを提供しています。 -## webroot ディレクトリ +## `webroot` ディレクトリ Web リソースファイルは、モジュールのルートディレクトリの `webroot` サブディレクトリに置かれるべきであり、`index.html` という名前のファイルが必ず存在しなければなりません。これがモジュールページのエントリです。Web インターフェイスを含む最もシンプルなモジュール構造は以下の通りです： diff --git a/website/docs/pt_BR/guide/app-profile.md b/website/docs/pt_BR/guide/app-profile.md index 53e6c3e1bf45..14bf08894bb6 100644 --- a/website/docs/pt_BR/guide/app-profile.md +++ b/website/docs/pt_BR/guide/app-profile.md @@ -14,7 +14,7 @@ Os sistemas Linux possuem dois conceitos: usuários e grupos. Cada usuário poss Os usuários com UID 0 são conhecidos como usuários root e os grupos com GID 0 são conhecidos como grupos root. O grupo de usuários root normalmente possui os privilégios de sistema mais altos. -No caso do sistema Android, cada app é um usuário separado (excluindo cenários de UID compartilhados) com um UID exclusivo. Por exemplo, `0` representa o usuário root, `1000` representa `system`, `2000` representa o ADB shell e UIDs variando de `10.000` a `19.999` representam apps comuns. +No caso do sistema Android, cada app é um usuário separado (excluindo cenários de UID compartilhados) com um UID exclusivo. Por exemplo, `0` representa o usuário root, `1000` representa `system`, `2000` representa o ADB shell e UIDs variando de `10000` a `19999` representam apps comuns. :::info INFORMAÇÕES Aqui, o UID mencionado não é o mesmo que o conceito de múltiplos usuários ou perfis de trabalho no sistema Android. Os perfis de trabalho são, na verdade, implementados particionando o intervalo UID. Por exemplo, 10000-19999 representa o usuário principal, enquanto 110000-119999 representa um perfil de trabalho. Cada app comum entre eles possui seu próprio UID exclusivo. diff --git a/website/docs/pt_BR/guide/installation.md b/website/docs/pt_BR/guide/installation.md index 7ab241b9ca59..afe700e45f9b 100644 --- a/website/docs/pt_BR/guide/installation.md +++ b/website/docs/pt_BR/guide/installation.md @@ -16,7 +16,7 @@ Para dispositivos mostrando `Sem suporte`, aqui está os [Dispositivos com supor Antes de fazer o flash, você deve primeiro fazer backup de seu boot.img padrão. Se você encontrar algum bootloop, você sempre pode restaurar o sistema voltando para o boot padrão de fábrica usando o fastboot. ::: warning AVISO -Flashar pode causar perda de dados, certifique-se de executar esta etapa bem antes de prosseguir para a próxima! Você também pode fazer backup de todos os dados do seu telefone, se necessário. +Flashar pode causar perda de dados, certifique-se de executar esta etapa bem antes de prosseguir para a próxima! Você também pode fazer backup de todos os dados do seu dispositivo, se necessário. ::: ## Conhecimento necessário @@ -104,8 +104,8 @@ Ao contrário do modo GKI, o modo LKM modificará o `ramdisk`, portanto, em disp 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, 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. +1. Selecione e corrija um arquivo. Se o seu dispositivo 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 dispositivo 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. ### Use a linha de comando @@ -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} -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. +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 dispositivo 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: @@ -228,7 +228,7 @@ Android-Image-Kitchen não é recomendado por enquanto, porque ele não lida cor ### Preparação -1. Obtenha o boot.img padrão do telefone. Você pode obtê-lo com os fabricantes do seu dispositivo. Talvez você precise do [payload-dumper-go](https://github.com/ssut/payload-dumper-go). +1. Obtenha o boot.img padrão do dispositivo. Você pode obtê-lo com os fabricantes do seu dispositivo. Talvez você precise do [payload-dumper-go](https://github.com/ssut/payload-dumper-go). 2. Baixe o arquivo ZIP AnyKernel3 fornecido pelo KernelSU que corresponde à versão KMI do seu dispositivo. Você pode consultar [Instalar com Recovery personalizado](#install-with-custom-recovery). 3. Descompacte o pacote AnyKernel3 e obtenha o arquivo `Image`, que é o arquivo do kernel do KernelSU. @@ -262,15 +262,15 @@ Pré-requisito: Seu dispositivo deve ter um Recovery personalizado, como TWRP. S 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 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. +1. Em [GitHub Releases](https://github.com/tiann/KernelSU/releases), baixe o pacote ZIP começando com AnyKernel3 que corresponde à versão do seu dispositivo. 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 dispositivo no TWRP. 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. ## Outros métodos -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. 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 AnyKernel3 do KernelSU. 2. Use algum kit de ferramentas de flash em PC para flashar no kernel fornecido pelo KernelSU. diff --git a/website/docs/pt_BR/guide/module-webui.md b/website/docs/pt_BR/guide/module-webui.md index fe59f606d462..f573d26f01a3 100644 --- a/website/docs/pt_BR/guide/module-webui.md +++ b/website/docs/pt_BR/guide/module-webui.md @@ -4,7 +4,7 @@ Além de executar scripts de inicialização e modificar arquivos do sistema, os O módulo pode escrever páginas HTML + CSS + JavaScript através de qualquer tecnologia web. O gerenciador do KernelSU exibirá essas páginas através do WebView. Ele também fornece algumas APIs para interagir com o sistema, como executar comandos shell. -## Diretório webroot +## Diretório `webroot` Os arquivos de recursos da web devem ser colocados no subdiretório `webroot` do diretório raiz do módulo, e **DEVE** haver um arquivo chamado `index.html`, que é a entrada da página do módulo. A estrutura do módulo mais simples contendo uma interface web é a seguinte: diff --git a/website/docs/pt_BR/guide/module.md b/website/docs/pt_BR/guide/module.md index f9081aacf394..28619c8e819c 100644 --- a/website/docs/pt_BR/guide/module.md +++ b/website/docs/pt_BR/guide/module.md @@ -184,7 +184,7 @@ O módulo KernelSU **NÃO** é compatível para instalação no Recovery persona ### Personalização -Se você precisar personalizar o processo de instalação do módulo, opcionalmente você pode criar um script no instalador chamado `customize.sh`. Este script será **sourced** (não executado) pelo script do instalador do módulo depois que todos os arquivos forem extraídos e as permissões padrão e o contexto secundário forem aplicados. Isso é muito útil se o seu módulo exigir configuração adicional com base na API do dispositivo ou se você precisar definir permissões/secontext especiais para alguns dos arquivos do seu módulo. +Se você precisar personalizar o processo de instalação do módulo, opcionalmente você pode criar um script no instalador chamado `customize.sh`. Este script será **sourced** (não executado) pelo script do instalador do módulo depois que todos os arquivos forem extraídos e as permissões padrão e o contexto secundário forem aplicados. Isso é muito útil se o seu módulo exigir configuração adicional com base na ABI do dispositivo ou se você precisar definir permissões/secontext especiais para alguns dos arquivos do seu módulo. Se você quiser controlar e personalizar totalmente o processo de instalação, declare `SKIPUNZIP=1` em `customize.sh` para pular todas as etapas de instalação padrão. Ao fazer isso, seu `customize.sh` será responsável por instalar tudo sozinho. diff --git a/website/docs/pt_BR/guide/rescue-from-bootloop.md b/website/docs/pt_BR/guide/rescue-from-bootloop.md index cc223005d5eb..87ea1982be50 100644 --- a/website/docs/pt_BR/guide/rescue-from-bootloop.md +++ b/website/docs/pt_BR/guide/rescue-from-bootloop.md @@ -6,9 +6,9 @@ Ao atualizar um dispositivo, podemos encontrar situações em que o dispositivo No KernelSU, as seguintes situações podem causar bloqueio de inicialização ao flashar a partição boot: -1. Você flashou uma imagem boot no formato errado. Por exemplo, se o formato de boot do seu telefone for `gz`, mas você flashou uma imagem no formato `lz4`, o telefone não será capaz de inicializar. -2. Seu telefone precisa desativar a verificação AVB para inicializar corretamente (geralmente exigindo a limpeza de todos os dados do telefone). -3. Seu kernel tem alguns bugs ou não é adequado para o flash do seu telefone. +1. Você flashou uma imagem boot no formato errado. Por exemplo, se o formato de boot do seu dispositivo for `gz`, mas você flashou uma imagem no formato `lz4`, o dispositivo não será capaz de inicializar. +2. Seu dispositivo precisa desativar a verificação AVB para inicializar corretamente (geralmente exigindo a limpeza de todos os dados do dispositivo). +3. Seu kernel tem alguns bugs ou não é adequado para o flash do seu dispositivo. Não importa qual seja a situação, você pode recuperar **flashando a imagem de boot padrão**. Portanto, no início do tutorial de instalação, recomendamos fortemente que você faça backup de seu boot padrão antes de fazer o flash. Se você não fez backup, poderá obter o boot original de fábrica de outros usuários com o mesmo dispositivo que você ou do firmware oficial.