website: update translation (#1377)

This commit is contained in:
igor
2024-02-25 11:48:22 -03:00
committed by GitHub
parent bf71ff133c
commit 56dbc980f4
4 changed files with 58 additions and 5 deletions

View File

@@ -0,0 +1,48 @@
# Módulo WebUI
Além de executar scripts de inicialização e modificar arquivos do sistema, os módulos do KernelSU também suportam a exibição de interfaces da UI e a interação com os usuários.
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
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:
```txt
tree .
.
|-- module.prop
`-- webroot
`-- index.html
```
:::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!
:::
Se sua página contém CSS e JavaScript, você também precisa colocá-la neste diretório.
## API JavaScript
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.
Por exemplo, você pode executar um comando shell para obter uma configuração específica ou modificar uma propriedade:
```javascript
import { exec } from 'kernelsu';
const { errno, stdout } = exec("getprop ro.product.model");
```
Para outro exemplo, você pode fazer com que a página da web seja exibida em tela inteira ou exibir um dica.
[Documentação da API](https://www.npmjs.com/package/kernelsu)
Se você achar que a API existente não atende às suas necessidades ou é inconveniente de usar, fique à vontade para nos dar sugestões [aqui](https://github.com/tiann/KernelSU/issues)!
## Algumas dicas
1. Você pode usar `localStorage` normalmente para armazenar alguns dados, mas eles serão perdidos após a desinstalação do app gerenciador. Se precisar salvar persistentemente, você mesmo pode gravar os dados em algum diretório.
2. Para páginas simples, recomendo que você use [parceljs](https://parceljs.org/) para empacotamento. Não requer configuração do zero e é muito conveniente de usar. Porém, se você é um mestre front-end ou tem suas próprias preferências, basta escolher o que você gosta!

View File

@@ -4,6 +4,10 @@ O KernelSU fornece um mecanismo de módulo que consegue modificar o diretório d
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).
## 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).
## 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.