website: update translation (#1653)
This commit is contained in:
igor
GitHub
@@ -2,7 +2,7 @@
|
||||
|
||||
O KernelSU fornece um mecanismo de módulo que consegue modificar o diretório do sistema enquanto mantém a integridade da partição do sistema. Este mecanismo é conhecido como "sem sistema".
|
||||
|
||||
O mecanismo de módulo do KernelSU é quase o mesmo do Magisk. Se você está familiarizado com o desenvolvimento de módulos Magisk, o desenvolvimento de módulos KernelSU é muito semelhante. Você pode pular a introdução dos módulos abaixo e só precisa ler [Diferença com Magisk](difference-with-magisk.md).
|
||||
O mecanismo de módulos do KernelSU é quase o mesmo do Magisk. Se você está familiarizado com o desenvolvimento de módulos Magisk, o desenvolvimento de módulos KernelSU é muito semelhante. Você pode pular a introdução dos módulos abaixo e só precisa ler [Diferença com Magisk](difference-with-magisk.md).
|
||||
|
||||
## WebUI
|
||||
|
||||
@@ -10,13 +10,13 @@ Os módulos do KernelSU suportam a exibição de interfaces e a interação com
|
||||
|
||||
## BusyBox
|
||||
|
||||
O KernelSU vem com um recurso binário BusyBox completo (incluindo suporte completo ao SELinux). O executável está localizado em `/data/adb/ksu/bin/busybox`. O BusyBox do KernelSU suporta o "ASH Standalone Shell Mode" alternável em tempo de execução. O que este Modo Autônomo significa é que ao executar no shell `ash` do BusyBox, cada comando usará diretamente o miniaplicativo dentro do BusyBox, independentemente do que estiver definido como `PATH`. Por exemplo, comandos como `ls`, `rm`, `chmod` **NÃO** usarão o que está em `PATH` (no caso do Android por padrão será `/system/bin/ls`, `/system/bin/rm` e `/system/bin/chmod` respectivamente), mas em vez disso chamará diretamente os miniaplicativos internos do BusyBox. Isso garante que os scripts sempre sejam executados em um ambiente previsível e sempre tenham o conjunto completo de comandos, independentemente da versão do Android em que estão sendo executados. Para forçar um comando a **NÃO** usar o BusyBox, você deve chamar o executável com caminhos completos.
|
||||
O KernelSU vem com um recurso binário BusyBox completo (incluindo suporte completo ao SELinux). O executável está localizado em `/data/adb/ksu/bin/busybox`. O BusyBox do KernelSU suporta "ASH Standalone Shell Mode" alternável em tempo de execução. O que este Modo Autônomo significa é que ao executar no shell `ash` do BusyBox, cada comando usará diretamente o miniaplicativo dentro do BusyBox, independentemente do que estiver definido em `PATH`. Por exemplo, comandos como `ls`, `rm`, `chmod` **NÃO** usarão o que está em `PATH` (no caso do Android, por padrão será `/system/bin/ls`, `/system/bin/rm` e `/system/bin/chmod` respectivamente), mas em vez disso chamará diretamente os miniaplicativos internos do BusyBox. Isso garante que os scripts sempre sejam executados em um ambiente previsível e sempre tenham o conjunto completo de comandos, independentemente da versão do Android em que estão sendo executados. Para forçar um comando a **NÃO** usar o BusyBox, você deve chamar o executável com caminhos completos.
|
||||
|
||||
Cada script shell executado no contexto do KernelSU será executado no shell `ash` do BusyBox com o Modo Autônomo ativado. Para o que é relevante para desenvolvedores terceirizados, isso inclui todos os scripts de inicialização e scripts de instalação de módulos.
|
||||
|
||||
Para aqueles que desejam usar o recurso “Modo Autônomo” fora do KernelSU, existem 2 maneiras de ativá-los:
|
||||
Para aqueles que desejam usar o recurso Modo Autônomo fora do KernelSU, existem 2 maneiras de ativá-los:
|
||||
|
||||
1. Defina a variável de ambiente `ASH_STANDALONE` como `1`.<br>Exemplo: `ASH_STANDALONE=1 /data/adb/ksu/bin/busybox sh <script>`
|
||||
1. Definir a variável de ambiente `ASH_STANDALONE` como `1`.<br>Exemplo: `ASH_STANDALONE=1 /data/adb/ksu/bin/busybox sh <script>`
|
||||
2. Alternar com opções de linha de comando:<br>`/data/adb/ksu/bin/busybox sh -o standalone <script>`
|
||||
|
||||
Para garantir que todos os shells `sh` subsequentes executados também sejam executados no Modo Autônomo, a opção 1 é o método preferido (e é isso que o KernelSU e o gerenciador do KernelSU usam internamente), pois as variáveis de ambiente são herdadas para os subprocesso.
|
||||
@@ -50,19 +50,19 @@ Um módulo KernelSU é uma pasta colocada em `/data/adb/modules` com a estrutura
|
||||
│ │
|
||||
│ │ *** Sinalizadores de status ***
|
||||
│ │
|
||||
│ ├── skip_mount <--- Se existir, o KernelSU NÃO montará sua pasta de sistema
|
||||
│ ├── disable <--- Se existir, o módulo será desabilitado
|
||||
│ ├── skip_mount <--- Se existir, o KernelSU não montará sua pasta de sistema
|
||||
│ ├── disable <--- Se existir, o módulo será desativado
|
||||
│ ├── remove <--- Se existir, o módulo será removido na próxima reinicialização
|
||||
│ │
|
||||
│ │ *** Arquivos opcionais ***
|
||||
│ │
|
||||
│ ├── post-fs-data.sh <--- Este script será executado em post-fs-data
|
||||
│ ├── post-mount.sh <--- Este script será executado em post-mount
|
||||
│ ├── service.sh <--- Este script será executado no late_start service
|
||||
│ ├── service.sh <--- Este script será executado no serviço late_start
|
||||
│ ├── boot-completed.sh <--- Este script será executado na inicialização concluída
|
||||
| ├── uninstall.sh <--- Este script será executado quando o KernelSU remover seu módulo
|
||||
│ ├── system.prop <--- As propriedades neste arquivo serão carregadas como propriedades do sistema por resetprop
|
||||
│ ├── sepolicy.rule <--- Regras adicionais de sepolicy personalizadas
|
||||
│ ├── sepolicy.rule <--- Regras adicionais do sepolicy personalizadas
|
||||
│ │
|
||||
│ │ *** Gerado automaticamente, NÃO CRIE OU MODIFIQUE MANUALMENTE ***
|
||||
│ │
|
||||
@@ -102,7 +102,7 @@ description=<string>
|
||||
- `id` deve corresponder a esta expressão regular: `^[a-zA-Z][a-zA-Z0-9._-]+$`<br>
|
||||
Exemplo: ✓ `a_module`, ✓ `a.module`, ✓ `module-101`, ✗ `a module`, ✗ `1_module`, ✗ `-a-module`<br>
|
||||
Este é o **identificador exclusivo** do seu módulo. Você não deve alterá-lo depois de publicado.
|
||||
- `versionCode` deve ser um **número inteiro**. Isso é usado para comparar versões
|
||||
- `versionCode` deve ser um **número inteiro**. Isso é usado para comparar versões.
|
||||
- Outros que não foram mencionados acima podem ser qualquer string de **linha única**.
|
||||
- Certifique-se de usar o tipo de quebra de linha `UNIX (LF)` e não o `Windows (CR+LF)` ou `Macintosh (CR)`.
|
||||
|
||||
@@ -110,7 +110,7 @@ description=<string>
|
||||
|
||||
Por favor, leia a seção [Scripts de inicialização](#scripts-de-inicializacao) para entender a diferença entre `post-fs-data.sh` e `service.sh`. Para a maioria dos desenvolvedores de módulos, `service.sh` deve ser bom o suficiente se você precisar apenas executar um script de inicialização. Se precisar executar o script após a inicialização ser concluída, use `boot-completed.sh`. Se você quiser fazer algo após montar OverlayFS, use `post-mount.sh`.
|
||||
|
||||
Em todos os scripts do seu módulo, use `MODDIR=${0%/*}` para obter o caminho do diretório base do seu módulo, **NÃO** codifique o caminho do seu módulo em scripts.
|
||||
Em todos os scripts do seu módulo, use `MODDIR=${0%/*}` para obter o caminho do diretório base do seu módulo, **NÃO** codifique o caminho do seu módulo nos scripts.
|
||||
|
||||
::: tip DIFERENÇA COM MAGISK
|
||||
Você pode usar a variável de ambiente `KSU` para determinar se um script está sendo executado no KernelSU ou Magisk. Se estiver executando no KernelSU, esse valor será definido como `true`.
|
||||
@@ -118,7 +118,7 @@ Você pode usar a variável de ambiente `KSU` para determinar se um script está
|
||||
|
||||
### Diretório `system`
|
||||
|
||||
O conteúdo deste diretório será sobreposto à partição /system do sistema usando OverlayFS após a inicialização do sistema. Isso significa que:
|
||||
O conteúdo deste diretório será sobreposto à partição `/system` do sistema usando OverlayFS após a inicialização do sistema. Isso significa que:
|
||||
|
||||
1. Arquivos com o mesmo nome daqueles no diretório correspondente no sistema serão substituídos pelos arquivos deste diretório.
|
||||
2. Pastas com o mesmo nome daquelas no diretório correspondente no sistema serão mescladas com as pastas neste diretório.
|
||||
@@ -154,7 +154,7 @@ Esta lista criará automaticamente os diretórios `$MODPATH/system/app/YouTube`
|
||||
O mecanismo sem sistema do KernelSU é implementado através do OverlayFS do kernel, enquanto o Magisk atualmente usa montagem mágica (montagem de ligação). Os dois métodos de implementação têm diferenças significativas, mas o objetivo final é o mesmo: modificar os arquivos /system sem modificar fisicamente a partição /system.
|
||||
:::
|
||||
|
||||
Se você estiver interessado em OverlayFS, é recomendável ler a [documentação sobre OverlayFS](https://docs.kernel.org/filesystems/overlayfs.html) do Kernel Linux.
|
||||
Se você estiver interessado em OverlayFS, é recomendável ler a [documentação sobre OverlayFS](https://docs.kernel.org/filesystems/overlayfs.html) do kernel Linux.
|
||||
|
||||
### system.prop
|
||||
|
||||
@@ -166,7 +166,7 @@ Se o seu módulo exigir alguns patches adicionais do sepolicy, adicione essas re
|
||||
|
||||
## 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 do 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 gerenciador do KernelSU. O instalador do módulo KernelSU mais simples é apenas um módulo KernelSU compactado como um arquivo ZIP.
|
||||
|
||||
```txt
|
||||
module.zip
|
||||
@@ -188,15 +188,15 @@ Se você precisar personalizar o processo de instalação do módulo, opcionalme
|
||||
|
||||
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.
|
||||
|
||||
O script `customize.sh` é executado no shell BusyBox `ash` do KernelSU com o "Modo Autônomo" ativado. As seguintes variáveis e funções estão disponíveis:
|
||||
O script `customize.sh` é executado no shell BusyBox `ash` do KernelSU com o Modo Autônomo ativado. As seguintes variáveis e funções estão disponíveis:
|
||||
|
||||
#### Variáveis
|
||||
|
||||
- `KSU` (bool): uma variável para marcar que o script está sendo executado no ambiente KernelSU, e o valor desta variável sempre será `true`. Você pode usá-lo para distinguir entre KernelSU e Magisk.
|
||||
- `KSU_VER` (string): a string da versão do KernelSU atualmente instalado (por exemplo, `v0.4.0`).
|
||||
- `KSU_VER` (string): a string da versão do KernelSU atualmente instalado (por exemplo: `v0.4.0`).
|
||||
- `KSU_VER_CODE` (int): o código da versão do KernelSU atualmente instalado no espaço do usuário (por exemplo: `10672`).
|
||||
- `KSU_KERNEL_VER_CODE` (int): o código da versão do KernelSU atualmente instalado no espaço do kernel (por exemplo: `10672`).
|
||||
- `BOOTMODE` (bool): sempre seja `true` no KernelSU.
|
||||
- `BOOTMODE` (bool): sempre será `true` no KernelSU.
|
||||
- `MODPATH` (path): o caminho onde os arquivos do seu módulo devem ser instalados.
|
||||
- `TMPDIR` (path): um lugar onde você pode armazenar arquivos temporariamente.
|
||||
- `ZIPFILE` (path): ZIP de instalação do seu módulo.
|
||||
@@ -213,7 +213,7 @@ No KernelSU, `MAGISK_VER_CODE` é sempre `25200` e `MAGISK_VER` é sempre `v25.2
|
||||
```txt
|
||||
ui_print <msg>
|
||||
imprima <msg> no console
|
||||
Evite usar 'echo', pois ele não será exibido no console de recuperação personalizado
|
||||
Evite usar 'echo', pois ele não será exibido no console de recovery personalizado
|
||||
|
||||
abort <msg>
|
||||
imprima mensagem de erro <msg> para consolar e encerrar a instalação
|
||||
@@ -229,7 +229,7 @@ set_perm <target> <owner> <group> <permission> [context]
|
||||
set_perm_recursive <directory> <owner> <group> <dirpermission> <filepermission> [context]
|
||||
se [context] não está definido, o padrão é "u:object_r:system_file:s0"
|
||||
para todos os arquivos em <directory>, ele chamará:
|
||||
contexto de permissão de arquivo do grupo proprietário do arquivo set_perm
|
||||
set_perm arquivo proprietário do grupo filepermission
|
||||
para todos os diretórios em <directory> (including itself), ele vai ligar:
|
||||
set_perm dir owner group dirpermission context
|
||||
```
|
||||
@@ -258,6 +258,6 @@ No KernelSU, os scripts de inicialização são divididos em dois tipos com base
|
||||
- Scripts de módulo
|
||||
- Colocado na própria pasta do módulo.
|
||||
- Executado apenas se o módulo estiver ativado.
|
||||
- `post-fs-data.sh` é executado no modo post-fs-data, `service.sh` é executado no modo de serviço late_start, `boot-completed.sh` é executado na inicialização concluída e `post-mount.sh` é executado em OverlayFS montado.
|
||||
- `post-fs-data.sh` é executado no modo post-fs-data, `service.sh` é executado no modo de serviço late_start, `boot-completed.sh` é executado na inicialização concluída e `post-mount.sh` é executado no OverlayFS montado.
|
||||
|
||||
Todos os scripts de inicialização serão executados no shell BusyBox `ash` do KernelSU com o "Modo Autônomo" ativado.
|
||||
Todos os scripts de inicialização serão executados no shell BusyBox `ash` do KernelSU com o Modo Autônomo ativado.
|
||||
|
||||
Reference in New Issue
Block a user