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

website: update translation (#1473)

Browse Source
This commit is contained in:
igor
2024-03-18 22:53:45 -03:00
committed by GitHub
parent 053fce61c0
commit 7f73827658
9 changed files with 84 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -42,7 +42,7 @@ comment out `ksu_enable_sucompat()` and `ksu_enable_ksud()` in `KernelSU/kernel/
:::info How to get module umount feature working on pre-GKI? :::info How to get module umount feature working on pre-GKI?
If your kernel is older than 5.9, you should backport ```path_umount``` to ```fs/namespace.c```. This is required to get module umount feature working. If you don't backport ```path_umount```, module umount feature won't work. You can get more info on how to achieve this at the end of this page. If your kernel is older than 5.9, you should backport `path_umount` to `fs/namespace.c`. This is required to get module umount feature working. If you don't backport `path_umount`, module umount feature won't work. You can get more info on how to achieve this at the end of this page.
::: :::
## Manually modify the kernel source ## Manually modify the kernel source

10
website/docs/pt_BR/guide/app-profile.md
View File

@@ -106,13 +106,13 @@ Se você realmente precisa conceder permissões de root ao ADB (por exemplo, com
### Desmontar módulos ### Desmontar módulos
O KernelSU fornece um mecanismo sem sistema para modificar partições do sistema, obtido através da montagem de OverlayFS. No entanto, alguns apps podem ser sensíveis a esse comportamento. Assim, podemos descarregar módulos montados nesses apps configurando a opção “desmontar módulos”. O KernelSU fornece um mecanismo sem sistema para modificar partições do sistema, obtido através da montagem de OverlayFS. No entanto, alguns apps podem ser sensíveis a esse comportamento. Assim, podemos descarregar módulos montados nesses apps configurando a opção "Desmontar módulos".
Além disso, a interface de configurações do gerenciador KernelSU fornece uma opção para "desmontar módulos por padrão". Por padrão, essa opção está **ativada**, o que significa que o KernelSU ou alguns módulos descarregarão módulos para este app, a menos que configurações adicionais sejam aplicadas. Se você não preferir esta configuração ou se ela afetar determinados apps, você terá as seguintes opções: Além disso, a interface de configurações do gerenciador KernelSU fornece uma opção para "Desmontar módulos por padrão". Por padrão, essa opção está **ativada**, o que significa que o KernelSU ou alguns módulos descarregarão módulos para este app, a menos que configurações adicionais sejam aplicadas. Se você não preferir esta configuração ou se ela afetar determinados apps, você terá as seguintes opções:
1. Mantenha a opção "desmontar módulos por padrão" e desative individualmente a opção "desmontar módulos" no Perfil do Aplicativo para apps que exigem carregamento do módulo (agindo como uma "lista de permissões"). 1. Mantenha a opção "Desmontar módulos por padrão" e desative individualmente a opção "Desmontar módulos" no Perfil do Aplicativo para apps que exigem carregamento do módulo (agindo como uma "lista de permissões").
2. Desative a opção "desmontar módulos por padrão" e ative individualmente a opção "desmontar módulos" no Perfil do Aplicativo para apps que exigem descarregamento do módulo (agindo como uma "lista negra"). 2. Desative a opção "Desmontar módulos por padrão" e ative individualmente a opção "Desmontar módulos" no Perfil do Aplicativo para apps que exigem descarregamento do módulo (agindo como uma "lista negra").
:::info INFORMAÇÕES :::info INFORMAÇÕES
Em dispositivos que utilizam kernel versão 5.10 e superior, o kernel realiza o descarregamento dos módulos. No entanto, para dispositivos que executam versões de kernel abaixo de 5.10, essa opção é apenas uma opção de configuração e o próprio KernelSU não executa nenhuma ação. Alguns módulos, como ZygiskNext, podem usar essa opção para determinar se o descarregamento do módulo é necessário. Em dispositivos que utilizam a versão do kernel 5.10 e superior, o kernel realiza qualquer ação adicional do descarregamento de módulos. No entanto, para dispositivos que executam versões do kernel abaixo de 5.10, essa opção é apenas uma opção de configuração e o próprio KernelSU não executa nenhuma ação. Se você quiser usar a opção "Desmontar módulos" em versões do kernel anteriores a 5.10 você precisa portar a função `path_umount` em `fs/namespace.c`, você pode obter mais informações no final da página [Como integrar o KernelSU para kernels não GKI](https://kernelsu.org/pt_BR/guide/how-to-integrate-for-non-gki.html). Alguns módulos, como ZygiskNext, também podem usar essa opção para determinar se o descarregamento do módulo é necessário.
::: :::

2
website/docs/pt_BR/guide/difference-with-magisk.md
View File

@@ -4,7 +4,7 @@ Embora existam muitas semelhanças entre os módulos KernelSU e os módulos Magi
## Semelhanças ## Semelhanças
- Formato de arquivo do módulo: ambos usam o formato zip para organizar os módulos, e o formato dos módulos é quase o mesmo. - Formato de arquivo do módulo: ambos usam o formato ZIP para organizar os módulos, e o formato dos módulos é quase o mesmo.
- Diretório de instalação do módulo: ambos localizados em `/data/adb/modules`. - Diretório de instalação do módulo: ambos localizados em `/data/adb/modules`.
- Sem sistema: ambos suportam a modificação de `/system` de maneira sem sistema por meio de módulos. - Sem sistema: ambos suportam a modificação de `/system` de maneira sem sistema por meio de módulos.
- post-fs-data.sh: o tempo de execução e a semântica são exatamente os mesmos. - post-fs-data.sh: o tempo de execução e a semântica são exatamente os mesmos.

2
website/docs/pt_BR/guide/faq.md
View File

@@ -63,7 +63,7 @@ GKI1 é completamente diferente do GKI2, você deve compilar o kernel sozinho.
Não recomendamos que você modifique a partição do sistema diretamente. Você deve usar [Guias de módulo](module.md) para modificá-lo sem sistema. Se você insiste em fazer isso, verifique [magisk_overlayfs](https://github.com/HuskyDG/magic_overlayfs). Não recomendamos que você modifique a partição do sistema diretamente. Você deve usar [Guias de módulo](module.md) para modificá-lo sem sistema. Se você insiste em fazer isso, verifique [magisk_overlayfs](https://github.com/HuskyDG/magic_overlayfs).
## O KernelSU pode modificar hosts? Como posso usar AdAway? ## KernelSU pode modificar hosts? Como posso usar AdAway?
Claro. Mas o KernelSU não tem suporte a hosts integrados, você pode instalar [systemless-hosts](https://github.com/symbuzzer/systemless-hosts-KernelSU-module) para fazer isso. Claro. Mas o KernelSU não tem suporte a hosts integrados, você pode instalar [systemless-hosts](https://github.com/symbuzzer/systemless-hosts-KernelSU-module) para fazer isso.

2
website/docs/pt_BR/guide/how-to-build.md
View File

@@ -20,7 +20,7 @@ repo init -m manifest.xml
repo sync repo sync
``` ```
O `<kernel_manifest.xml>` é um arquivo de manifesto que pode determinar uma construção exclusivamente, você pode usar o manifesto para fazer uma construção re-preduzível. Você deve baixar o arquivo de manifesto em [compilações de lançamento do Google GKI](https://source.android.com/docs/core/architecture/kernel/gki-release-builds). O `<kernel_manifest.xml>` é um arquivo de manifesto que pode determinar uma construção exclusivamente, você pode usar o manifesto para fazer uma construção re-preduzível. Você deve baixar o arquivo de manifesto em [Builds de versão de imagem genérica do kernel (GKI)](https://source.android.com/docs/core/architecture/kernel/gki-release-builds).
### Construir ### Construir

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

@@ -13,7 +13,7 @@ Se você puder construir um kernel inicializável, existem duas maneiras de inte
## Integrar com kprobe ## Integrar com kprobe
O KernelSU usa kprobe para fazer ganchos de kernel, se o kprobe funcionar bem em seu kernel, é recomendado usar desta forma. O KernelSU usa kprobe para fazer ganchos do kernel, se o kprobe funcionar bem em seu kernel, é recomendado usar desta forma.
Primeiro, adicione o KernelSU à árvore de origem do kernel: Primeiro, adicione o KernelSU à árvore de origem do kernel:
@@ -40,6 +40,11 @@ Mas se você entrar em um bootloop quando o KernelSU for integrado, talvez o **k
Comente `ksu_enable_sucompat()` e `ksu_enable_ksud()` em `KernelSU/kernel/ksu.c`, se o dispositivo inicializar normalmente, então o kprobe pode estar quebrado. Comente `ksu_enable_sucompat()` e `ksu_enable_ksud()` em `KernelSU/kernel/ksu.c`, se o dispositivo inicializar normalmente, então o kprobe pode estar quebrado.
::: :::
:::info COMO FAZER COM QUE O RECURSO DE DESMONTAR MÓDULOS FUNCIONE NO PRÉ-GKI?
Se o seu kernel for inferior a 5.9, você deve portar `path_umount` para `fs/namespace.c`. Isso é necessário para que o recurso de quantidade do módulo funcione. Se você não portar `path_umount`, o recurso "Desmontar módulos" não funcionará. Você pode obter mais informações sobre como conseguir isso no final desta página.
:::
## Modifique manualmente a fonte do kernel ## Modifique manualmente a fonte do kernel
Se o kprobe não funcionar no seu kernel (pode ser um bug do upstream ou do kernel abaixo de 4.8), então você pode tentar desta forma: Se o kprobe não funcionar no seu kernel (pode ser um bug do upstream ou do kernel abaixo de 4.8), então você pode tentar desta forma:
@@ -62,14 +67,14 @@ curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh
::: :::
Tenha em mente que em alguns dispositivos, seu defconfig pode estar em `arch/arm64/configs` ou em outros casos `arch/arm64/configs/vendor/your_defconfig`. Por exemplo, em seu defconfig, habilite `CONFIG_KSU` com y para habilitar ou n para desabilitar. Seu caminho será algo como: Tenha em mente que em alguns dispositivos, seu defconfig pode estar em `arch/arm64/configs` ou em outros casos `arch/arm64/configs/vendor/your_defconfig`. Por exemplo, em seu defconfig, habilite `CONFIG_KSU` com **y** para habilitar ou **n** para desabilitar. Seu caminho será algo como:
`arch/arm64/configs/...` `arch/arm64/configs/...`
``` ```
# KernelSU # KernelSU
CONFIG_KSU=y CONFIG_KSU=y
``` ```
Em seguida, adicione chamadas KernelSU à fonte do kernel. Aqui estão alguns patches para referência: Em seguida, adicione chamadas do KernelSU à fonte do kernel. Aqui estão alguns patches para referência:
::: code-group ::: code-group
@@ -292,6 +297,55 @@ index 45306f9ef247..815091ebfca4 100755
add_input_randomness(type, code, value); add_input_randomness(type, code, value);
``` ```
### Como fazer backport de path_umount
Você pode fazer com que o recurso "Desmontar módulos" funcione em kernels pré-GKI fazendo backport manualmente do `path_umount` da versão 5.9. Você pode usar este patch como referência:
```diff
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -1739,6 +1739,39 @@ static inline bool may_mandlock(void)
}
#endif
+static int can_umount(const struct path *path, int flags)
+{
+ struct mount *mnt = real_mount(path->mnt);
+
+ if (flags & ~(MNT_FORCE | MNT_DETACH | MNT_EXPIRE | UMOUNT_NOFOLLOW))
+ return -EINVAL;
+ if (!may_mount())
+ return -EPERM;
+ if (path->dentry != path->mnt->mnt_root)
+ return -EINVAL;
+ if (!check_mnt(mnt))
+ return -EINVAL;
+ if (mnt->mnt.mnt_flags & MNT_LOCKED) /* Check optimistically */
+ return -EINVAL;
+ if (flags & MNT_FORCE && !capable(CAP_SYS_ADMIN))
+ return -EPERM;
+ return 0;
+}
+
+int path_umount(struct path *path, int flags)
+{
+ struct mount *mnt = real_mount(path->mnt);
+ int ret;
+
+ ret = can_umount(path, flags);
+ if (!ret)
+ ret = do_umount(mnt, flags);
+
+ /* não devemos chamar path_put() pois isso limparia mnt_expiry_mark */
+ dput(path->dentry);
+ mntput_no_expire(mnt);
+ return ret;
+}
/*
* Agora o umount pode lidar com pontos de montagem e também com dispositivos bloqueados.
* Isto é importante para filesystems que usam dispositivos bloqueados sem nome.
```
Finalmente, construa seu kernel novamente, e então, o KernelSU deve funcionar bem. Finalmente, construa seu kernel novamente, e então, o KernelSU deve funcionar bem.
:::info ENTRANDO NO MODO DE SEGURANÇA ACIDENTALMENTE? :::info ENTRANDO NO MODO DE SEGURANÇA ACIDENTALMENTE?

20
website/docs/pt_BR/guide/installation.md
View File

@@ -34,7 +34,7 @@ Especificamente, para dispositivos GKI, o formato da versão do kernel deve ser
```txt ```txt
KernelRelease := KernelRelease :=
Version.PatchLevel.SubLevel-AndroidRelease-KmiGeneration-suffix Version.PatchLevel.SubLevel-AndroidRelease-KmiGeneration-suffix
w .x .y -zzz -k -something w .x .y -zzz -k -alguma coisa
``` ```
`w.x-zzz-k` é a versão KMI. Por exemplo, se a versão do kernel de um dispositivo for `5.10.101-android12-9-g30979850fc20`, então seu KMI será `5.10-android12-9`. Teoricamente, ele pode inicializar normalmente com outros kernels KMI. `w.x-zzz-k` é a versão KMI. Por exemplo, se a versão do kernel de um dispositivo for `5.10.101-android12-9-g30979850fc20`, então seu KMI será `5.10-android12-9`. Teoricamente, ele pode inicializar normalmente com outros kernels KMI.
@@ -72,9 +72,9 @@ Se o `boot.img` do seu dispositivo usa um formato de compactação comumente usa
O KernelSU fornece um boot.img genérico para dispositivos GKI e você deve flashar o boot.img para a partição boot do dispositivo. O KernelSU fornece um boot.img genérico para dispositivos GKI e você deve flashar o boot.img para a partição boot do dispositivo.
Você pode baixar o boot.img em [GitHub Release](https://github.com/tiann/KernelSU/releases), por favor, observe que você deve usar a versão correta do boot.img. Se você não sabe qual arquivo baixar, leia atentamente a descrição de [KMI](#kmi) e [Nível do patch de segurança](#security-patch-level) neste documento. Você pode baixar o boot.img em [GitHub Release](https://github.com/tiann/KernelSU/releases), por favor, observe que você deve usar a versão correta do boot.img. Se você não sabe qual arquivo baixar, leia atentamente a descrição do [KMI](#kmi) e [Nível do patch de segurança](#security-patch-level) neste documento.
Normalmente, existem três arquivos de inicialização em formatos diferentes no mesmo KMI e nível do patch de segurança. Eles são todos iguais, exceto pelo formato de compactação do kernel. Por favor, verifique o formato de compactação do kernel de seu boot.img original. Você deve usar o formato correto, como `lz4`, `gz`. Se você usar um formato de compactação incorreto, poderá encontrar bootloop após flashar o boot.img. Normalmente, existem três arquivos de inicialização em formatos diferentes no mesmo KMI e nível do patch de segurança. Eles são todos iguais, exceto pelo formato de compactação do kernel. Por favor, verifique o formato de compactação do kernel de seu boot.img original. Você deve usar o formato correto, como `lz4` ou `gz`. Se você usar um formato de compactação incorreto, poderá encontrar bootloop após flashar o boot.img.
::: info INFORMAÇÕES ::: info INFORMAÇÕES
1. Você pode usar o magiskboot para obter o formato de compactação de seu boot original; é claro que você também pode perguntar a outras pessoas mais experientes com o mesmo modelo do seu dispositivo. Além disso, o formato de compactação do kernel geralmente não muda, portanto, se você inicializar com êxito com um determinado formato de compactação, poderá tentar esse formato mais tarde. 1. Você pode usar o magiskboot para obter o formato de compactação de seu boot original; é claro que você também pode perguntar a outras pessoas mais experientes com o mesmo modelo do seu dispositivo. Além disso, o formato de compactação do kernel geralmente não muda, portanto, se você inicializar com êxito com um determinado formato de compactação, poderá tentar esse formato mais tarde.
@@ -106,13 +106,13 @@ fastboot reboot
Etapa: Etapa:
1. Baixe o zip AnyKernel3. Se você não sabe qual arquivo baixar, leia atentamente a descrição de [KMI](#kmi) e [Nível do patch de segurança](#security-patch-level) neste documento. 1. Baixe o zip AnyKernel3. Se você não sabe qual arquivo baixar, leia atentamente a descrição do [KMI](#kmi) e [Nível do patch de segurança](#security-patch-level) neste documento.
2. Abra o app Kernel Flash (conceda as permissões de root necessárias) e use o zip AnyKernel3 fornecido para fazer o flash. 2. Abra o app Kernel Flasher (conceda as permissões de root necessárias) e use o ZIP AnyKernel3 fornecido para fazer o flash.
Dessa forma, é necessário que o app Kernel Flasher tenha permissões root. Você pode usar os seguintes métodos para conseguir isso: Dessa forma, é necessário que o app Kernel Flasher tenha permissões root. Você pode usar os seguintes métodos para conseguir isso:
1. Seu dispositivo está rooteado. Por exemplo, você instalou o KernelSU e deseja atualizar para a versão mais recente ou fez o root por meio de outros métodos (como Magisk). 1. Seu dispositivo está rooteado. Por exemplo, você instalou o KernelSU e deseja atualizar para a versão mais recente ou fez o root por meio de outros métodos (como Magisk).
2. Se o seu telefone não estiver rooteado, mas o telefone suportar o método de inicialização temporária de `fastboot boot boot.img`, você pode usar a imagem GKI fornecida pelo KernelSU para inicializar temporariamente o seu dispositivo, obter permissões de root temporária e, em seguida, usar o Kernel Flasher para obter privilégios de root permanente. 2. Se o seu telefone não estiver rooteado, mas o telefone suportar o método de inicialização temporária como `fastboot boot boot.img`, você pode usar a imagem GKI fornecida pelo KernelSU para inicializar temporariamente o seu dispositivo, obter permissões de root temporária e, em seguida, usar o Kernel Flasher para obter privilégios de root permanente.
1. [Kernel Flasher](https://github.com/capntrips/KernelFlasher/releases) 1. [Kernel Flasher](https://github.com/capntrips/KernelFlasher/releases)
2. [Franco Kernel Manager](https://play.google.com/store/apps/details?id=com.franco.kernel) 2. [Franco Kernel Manager](https://play.google.com/store/apps/details?id=com.franco.kernel)
@@ -138,7 +138,7 @@ Android-Image-Kitchen não é recomendado agora, porque ele não lida corretamen
### Preparação ### 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 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).
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). 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. 3. Descompacte o pacote AnyKernel3 e obtenha o arquivo `Image`, que é o arquivo do kernel do KernelSU.
### Usando o magiskboot em dispositivos Android {#using-magiskboot-on-Android-devices} ### Usando o magiskboot em dispositivos Android {#using-magiskboot-on-Android-devices}
@@ -171,11 +171,11 @@ Pré-requisito: Seu dispositivo deve ter um Recovery personalizado, como TWRP. S
Etapa: Etapa:
1. Na [página de lançamento](https://github.com/tiann/KernelSU/releases) do KernelSU, baixe o pacote zip começando com AnyKernel3 que corresponde à versão do seu telefone; por exemplo, a versão do kernel do telefone é `android12-5.10. 66`, então você deve baixar o arquivo `AnyKernel3-android12-5.10.66_yyyy-MM.zip` (onde `yyyy` é o ano e `MM` é o mês). 1. Em [GitHub Releases](https://github.com/tiann/KernelSU/releases), baixe o pacote ZIP começando com AnyKernel3 que corresponde à versão do seu telefone. Por exemplo, a versão do kernel do telefone é `android12-5.10. 66`, então você deve baixar o arquivo `AnyKernel3-android12-5.10.66_yyyy-MM.zip` (onde `yyyy` é o ano e `MM` é o mês).
2. Reinicie o telefone no TWRP. 2. Reinicie o telefone no TWRP.
3. Use o adb para colocar AnyKernel3-*.zip no telefone /sdcard e escolha instalá-lo na interface do TWRP; ou você pode diretamente `adb sideload AnyKernel-*.zip` para instalar. 3. Use o ADB para colocar AnyKernel3-*.zip no telefone em /sdcard e escolha instalá-lo na interface do TWRP, ou você pode diretamente `adb sideload AnyKernel-*.zip` para instalar.
PS. Este método é adequado para qualquer instalação (não limitado à instalação inicial ou atualizações subsequentes), desde que você use TWRP. PS. 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 ## Outros métodos

4
website/docs/pt_BR/guide/module-webui.md
View File

@@ -17,7 +17,7 @@ Os arquivos de recursos da web devem ser colocados no subdiretório `webroot` do
``` ```
:::warning AVISO :::warning AVISO
Ao instalar o módulo, KernelSU definirá automaticamente as permissões e o contexto SELinux deste diretório. Se você não sabe o que está fazendo, não defina você mesmo as permissões deste diretório! Ao instalar o módulo, KernelSU definirá automaticamente as permissões e o contexto do SELinux deste diretório. Se você não sabe o que está fazendo, não defina você mesmo as permissões deste diretório!
::: :::
Se sua página contém CSS e JavaScript, você também precisa colocá-la neste diretório. Se sua página contém CSS e JavaScript, você também precisa colocá-la neste diretório.
@@ -26,7 +26,7 @@ Se sua página contém CSS e JavaScript, você também precisa colocá-la neste
Se for apenas uma página de exibição, não será diferente de uma página da web normal. Mais importante ainda, KernelSU fornece uma série de APIs de sistema que permitem implementar as funções exclusivas do módulo. Se for apenas uma página de exibição, não será diferente de uma página da web normal. Mais importante ainda, KernelSU fornece uma série de APIs de sistema que permitem implementar as funções exclusivas do módulo.
KernelSU fornece uma biblioteca JavaScript e [publica-a no npm](https://www.npmjs.com/package/kernelsu), que você pode usar no código JavaScript de suas páginas da web. KernelSU fornece uma biblioteca JavaScript e publica-a no [npm](https://www.npmjs.com/package/kernelsu), que você pode usar no código JavaScript de suas páginas da web.
Por exemplo, você pode executar um comando shell para obter uma configuração específica ou modificar uma propriedade: Por exemplo, você pode executar um comando shell para obter uma configuração específica ou modificar uma propriedade:

12
website/docs/pt_BR/guide/module.md
View File

@@ -6,7 +6,7 @@ O mecanismo de módulo do KernelSU é quase o mesmo do Magisk. Se você está fa
## WebUI ## WebUI
Os módulos do KernelSU suportam a exibição de interfaces e a interação com os usuários, consulte a [documentação WebUI](module-webui.md). Os módulos do KernelSU suportam a exibição de interfaces e a interação com os usuários, consulte a [documentação do WebUI](module-webui.md).
## BusyBox ## BusyBox
@@ -134,7 +134,7 @@ REMOVE="
" "
``` ```
A lista acima irá executar `mknod $MODPATH/system/app/YouTube c 0 0` e `mknod $MODPATH/system/app/Bloatware c 0 0`; e `/system/app/YouTube` e `/system/app/Bloatware` serão removidos após o módulo entrar em vigor. A lista acima irá executar `mknod $MODPATH/system/app/YouTube c 0 0` e `mknod $MODPATH/system/app/Bloatware c 0 0`, `/system/app/YouTube` e `/system/app/Bloatware` serão removidos após o módulo entrar em vigor.
Se você deseja substituir um diretório no sistema, você precisa criar um diretório com o mesmo caminho no diretório do módulo e, em seguida, definir o atributo `setfattr -n trusted.overlay.opaque -v y <TARGET>` para este diretório. Desta forma, o sistema OverlayFS substituirá automaticamente o diretório correspondente no sistema (sem alterar a partição /system). Se você deseja substituir um diretório no sistema, você precisa criar um diretório com o mesmo caminho no diretório do módulo e, em seguida, definir o atributo `setfattr -n trusted.overlay.opaque -v y <TARGET>` para este diretório. Desta forma, o sistema OverlayFS substituirá automaticamente o diretório correspondente no sistema (sem alterar a partição /system).
@@ -162,11 +162,11 @@ Este arquivo segue o mesmo formato de `build.prop`. Cada linha é composta por `
### sepolicy.rule ### sepolicy.rule
Se o seu módulo exigir alguns patches adicionais de sepolicy, adicione essas regras a este arquivo. Cada linha neste arquivo será tratada como uma declaração de política. Se o seu módulo exigir alguns patches adicionais do sepolicy, adicione essas regras a este arquivo. Cada linha neste arquivo será tratada como uma declaração de política.
## Instalador do módulo ## Instalador do módulo
Um instalador do módulo KernelSU é um módulo KernelSU empacotado em um arquivo zip que pode ser atualizado no app gerenciador KernelSU. O instalador do módulo KernelSU mais simples é apenas um módulo KernelSU compactado como um arquivo zip. Um instalador do módulo KernelSU é um módulo KernelSU empacotado em um arquivo ZIP que pode ser atualizado no app gerenciador do KernelSU. O instalador do módulo KernelSU mais simples é apenas um módulo KernelSU compactado como um arquivo ZIP.
```txt ```txt
module.zip module.zip
@@ -184,7 +184,7 @@ O módulo KernelSU **NÃO** é compatível para instalação no Recovery persona
### Personalização ### 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 API 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. 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.
@@ -199,7 +199,7 @@ O script `customize.sh` é executado no shell BusyBox `ash` do KernelSU com o "M
- `BOOTMODE` (bool): sempre seja `true` no KernelSU. - `BOOTMODE` (bool): sempre seja `true` no KernelSU.
- `MODPATH` (path): o caminho onde os arquivos do seu módulo devem ser instalados. - `MODPATH` (path): o caminho onde os arquivos do seu módulo devem ser instalados.
- `TMPDIR` (path): um lugar onde você pode armazenar arquivos temporariamente. - `TMPDIR` (path): um lugar onde você pode armazenar arquivos temporariamente.
- `ZIPFILE` (path): zip de instalação do seu módulo. - `ZIPFILE` (path): ZIP de instalação do seu módulo.
- `ARCH` (string): a arquitetura da CPU do dispositivo. O valor é `arm`, `arm64`, `x86` ou `x64`. - `ARCH` (string): a arquitetura da CPU do dispositivo. O valor é `arm`, `arm64`, `x86` ou `x64`.
- `IS64BIT` (bool): `true` se `$ARCH` for `arm64` ou `x64`. - `IS64BIT` (bool): `true` se `$ARCH` for `arm64` ou `x64`.
- `API` (int): o nível da API (versão do Android) do dispositivo (por exemplo: `23` para Android 6.0). - `API` (int): o nível da API (versão do Android) do dispositivo (por exemplo: `23` para Android 6.0).