update translation from website (#974)
This commit is contained in:
igor
GitHub
@@ -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 raiz. 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 shell ADB 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 `10.000` a `19.999` representam apps comuns.
|
||||
|
||||
:::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.
|
||||
@@ -22,7 +22,7 @@ Aqui, o UID mencionado não é o mesmo que o conceito de múltiplos usuários ou
|
||||
|
||||
Cada app pode ter vários grupos, com o GID representando o grupo principal, que geralmente corresponde ao UID. Outros grupos são conhecidos como grupos suplementares. Certas permissões são controladas por meio de grupos, como permissões de acesso à rede ou acesso Bluetooth.
|
||||
|
||||
Por exemplo, se executarmos o comando `id` no shell ADB, a saída pode ser semelhante a esta:
|
||||
Por exemplo, se executarmos o comando `id` no ADB shell, a saída pode ser semelhante a esta:
|
||||
|
||||
```sh
|
||||
oriole:/ $ id
|
||||
@@ -31,13 +31,13 @@ uid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input),1007(log),1011(ad
|
||||
|
||||
Aqui, o UID é `2000` e o GID (ID do grupo primário) também é `2000`. Além disso, pertence a vários grupos suplementares, como `inet` (indicando a capacidade de criar soquetes `AF_INET` e `AF_INET6`) e `sdcard_rw` (indicando permissões de leitura/gravação para o cartão SD).
|
||||
|
||||
O Perfil Raiz do KernelSU permite a personalização do UID, GID e grupos para o processo raiz após a execução de `su`. Por exemplo, o Perfil Raiz de um app raiz pode definir seu UID como `2000`, o que significa que ao usar `su`, as permissões reais do app estão no nível do shell ADB. O grupo `inet` pode ser removido, evitando que o comando `su` acesse a rede.
|
||||
O Perfil Raiz do KernelSU permite a personalização do UID, GID e grupos para o processo raiz após a execução de `su`. Por exemplo, o Perfil Raiz de um app raiz pode definir seu UID como `2000`, o que significa que ao usar `su`, as permissões reais do app estão no nível do ADB shell. O grupo `inet` pode ser removido, evitando que o comando `su` acesse a rede.
|
||||
|
||||
:::tip Observação
|
||||
:::tip OBSERVAÇÃO
|
||||
O Perfil do Aplicativo controla apenas as permissões do processo root após usar `su`; ele não controla as permissões do próprio app. Se um app solicitou permissão de acesso à rede, ele ainda poderá acessar a rede mesmo sem usar `su`. Remover o grupo `inet` de `su` apenas impede que `su` acesse a rede.
|
||||
:::
|
||||
|
||||
O Perfil Raiz é aplicado no kernel e não depende do comportamento voluntário de apps root, ao contrário da troca de usuários ou grupos através do `su`, a concessão da permissão `su` depende inteiramente do usuário e não do desenvolvedor.
|
||||
O Perfil Raiz é aplicado no kernel e não depende do comportamento voluntário de apps root, ao contrário da troca de usuários ou grupos por meio do `su`, a concessão da permissão `su` depende inteiramente do usuário e não do desenvolvedor.
|
||||
|
||||
### Capacidades
|
||||
|
||||
@@ -51,7 +51,7 @@ Cada capacidade representa um ou mais privilégios. Por exemplo, `CAP_DAC_READ_S
|
||||
|
||||
O Perfil Raiz do KernelSU permite a personalização das Capacidades do processo raiz após a execução de `su`, conseguindo assim conceder parcialmente "permissões de root". Ao contrário do UID e GID mencionados acima, certos apps root exigem um UID de `0` após usar `su`. Nesses casos, limitar as capacidades deste usuário root com UID `0` pode restringir suas operações permitidas.
|
||||
|
||||
:::tip Forte Recomendação
|
||||
:::tip FORTE RECOMENDAÇÃO
|
||||
Capacidade do Linux [documentação oficial](https://man7.org/linux/man-pages/man7/capabilities.7.html) fornece explicações detalhadas das habilidades representadas por cada capacidade. Se você pretende customizar Capacidades, é altamente recomendável que você leia este documento primeiro.
|
||||
:::
|
||||
|
||||
@@ -64,7 +64,7 @@ O SELinux pode ser executado em dois modos globais:
|
||||
1. Modo permissivo: Os eventos de negação são registrados, mas não aplicados.
|
||||
2. Modo de aplicação: Os eventos de negação são registrados e aplicados.
|
||||
|
||||
:::warning Aviso
|
||||
:::warning AVISO
|
||||
Os sistemas Android modernos dependem fortemente do SELinux para garantir a segurança geral do sistema. É altamente recomendável não usar nenhum sistema personalizado executado em "modo permissivo", pois não oferece vantagens significativas em relação a um sistema completamente aberto..
|
||||
:::
|
||||
|
||||
@@ -96,7 +96,7 @@ Por exemplo, se você conceder permissão root a um usuário shell ADB (que é u
|
||||
1. A primeira execução `su` está sujeita à aplicação do Perfil do Aplicativo e mudará para UID `2000` (adb shell) em vez de `0` (root).
|
||||
2. A segunda execução `su`, como o UID é `2000` e você concedeu acesso root ao UID `2000` (adb shell) na configuração, o app obterá privilégios de root completos.
|
||||
|
||||
:::warning Observação
|
||||
:::warning OBSERVAÇÃO
|
||||
Este comportamento é totalmente esperado e não é um bug. Portanto, recomendamos o seguinte:
|
||||
|
||||
Se você realmente precisa conceder permissões de root ao ADB (por exemplo, como desenvolvedor), não é aconselhável alterar o UID para `2000` ao configurar o Perfil Raiz. Usar `1000` (sistema) seria uma escolha melhor.
|
||||
@@ -113,6 +113,6 @@ Além disso, a interface de configurações do gerenciador KernelSU fornece uma
|
||||
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 de 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 de módulo (agindo como uma "lista negra").
|
||||
|
||||
:::informações
|
||||
:::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 Zygisksu, podem usar essa opção para determinar se o descarregamento do módulo é necessário.
|
||||
:::
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
Primeiro, seus dispositivos devem ser capazes de desbloquear o bootloader. Se não puder, então não há suporte.
|
||||
|
||||
Em seguida, instale o app gerenciador KernelSU em seu dispositivo e abra-o, se mostrar `Unsupported` então seu dispositivo não pode ser suportado imediatamente, mas você pode construir a fonte do kernel e integrar o KernelSU para fazê-lo funcionar ou usar [dispositivos de suporte não oficial](unofficially-support-devices).
|
||||
Em seguida, instale o app gerenciador KernelSU em seu dispositivo e abra-o, se mostrar `Sem suporte` então seu dispositivo não pode ser suportado imediatamente, mas você pode construir a fonte do kernel e integrar o KernelSU para fazê-lo funcionar ou usar [dispositivos de suporte não oficial](unofficially-support-devices).
|
||||
|
||||
## O KernelSU precisa desbloquear o Bootloader?
|
||||
|
||||
@@ -60,7 +60,7 @@ A versão do Kernel não tem nada a ver com a versão do Android, se você preci
|
||||
Não existe agora (talvez no futuro), mas há muitas maneiras de mudar manualmente para o namespace de montagem global, como:
|
||||
|
||||
1. `nsenter -t 1 -m sh` para obter um shell no namespace de montagem global.
|
||||
2. adicione `nsenter --mount=/proc/1/ns/mnt` ao comando que você deseja executar, o comando será executado no namespace de montagem global. O KernelSU também está [usando desta forma](https://github.com/tiann/KernelSU/blob/77056a710073d7a5f7ee38f9e77c9fd0b3256576/manager/app/src/main/java/me/weishu/kernelsu/ui/util/KsuCli.kt#L115)
|
||||
2. Adicione `nsenter --mount=/proc/1/ns/mnt` ao comando que você deseja executar, o comando será executado no namespace de montagem global. O KernelSU também está [usando desta forma](https://github.com/tiann/KernelSU/blob/77056a710073d7a5f7ee38f9e77c9fd0b3256576/manager/app/src/main/java/me/weishu/kernelsu/ui/util/KsuCli.kt#L115)
|
||||
|
||||
## Eu sou GKI1.0, posso usar isso?
|
||||
|
||||
|
||||
@@ -32,7 +32,7 @@ Por exemplo, precisamos construir a imagem do kernel aarch64:
|
||||
LTO=thin BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
|
||||
```
|
||||
|
||||
Não se esqueça de adicionar o sinalizador `LTO=thin`, caso contrário a compilação poderá falhar se a memória do seu computador for inferior a 24 Gb.
|
||||
Não se esqueça de adicionar o sinalizador `LTO=thin`, caso contrário a compilação poderá falhar se a memória do seu computador for inferior a 24GB.
|
||||
|
||||
A partir do Android 13, o kernel é construído pelo `bazel`:
|
||||
|
||||
@@ -44,13 +44,13 @@ tools/bazel build --config=fast //common:kernel_aarch64_dist
|
||||
|
||||
Se você conseguir construir o kernel com sucesso, então construir o KernelSU é muito fácil. Selecione qualquer um executado no diretório raiz de origem do kernel:
|
||||
|
||||
- Tag mais recente(estável)
|
||||
- Tag mais recente (estável)
|
||||
|
||||
```sh
|
||||
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -
|
||||
```
|
||||
|
||||
- branch principal(dev)
|
||||
- branch principal (dev)
|
||||
|
||||
```sh
|
||||
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s main
|
||||
@@ -62,4 +62,4 @@ curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh
|
||||
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s v0.5.2
|
||||
```
|
||||
|
||||
E então reconstrua o kernel e você obterá uma imagem do kernel com KernelSU!
|
||||
E então reconstrua o kernel e você obterá uma imagem do kernel com KernelSU!
|
||||
@@ -21,7 +21,7 @@ Primeiro, adicione o KernelSU à árvore de origem do kernel:
|
||||
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -
|
||||
```
|
||||
|
||||
Então, você deve verificar se *kprobe* está habilitado na configuração do seu kernel, se não estiver, adicione estas configurações a ele:
|
||||
Então, você deve verificar se *kprobe* está ativado na configuração do seu kernel, se não estiver, adicione estas configurações a ele:
|
||||
|
||||
```
|
||||
CONFIG_KPROBES=y
|
||||
@@ -35,7 +35,7 @@ Se você descobrir que o KPROBES ainda não está ativado, você pode tentar ati
|
||||
|
||||
Mas se você encontrar um loop de inicialização quando o KernelSU integrado, talvez *kprobe esteja quebrado em seu kernel*, você deve corrigir o bug do kprobe ou usar o segundo caminho.
|
||||
|
||||
:::tip Como verificar se o kprobe está quebrado?
|
||||
:::tip COMO VERIFICAR SE O KPROBE ESTÁ 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.
|
||||
:::
|
||||
@@ -52,13 +52,14 @@ Primeiro, adicione o KernelSU à árvore de origem do kernel:
|
||||
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -
|
||||
```
|
||||
|
||||
- branch principal(dev)
|
||||
- branch principal (dev)
|
||||
|
||||
```sh
|
||||
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s main
|
||||
```
|
||||
|
||||
- Selecione a tag(Como v0.5.2)
|
||||
- Selecione a tag (Como v0.5.2)
|
||||
|
||||
-
|
||||
```sh
|
||||
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s v0.5.2
|
||||
@@ -218,10 +219,10 @@ index 2ff887661237..e758d7db7663 100644
|
||||
return -EINVAL;
|
||||
```
|
||||
|
||||
Para ativar o SafeMode integrado do KernelSU, você também deve modificar `input_handle_event` em `drivers/input/input.c`:
|
||||
Para ativar o Modo de Segurança integrado do KernelSU, você também deve modificar `input_handle_event` em `drivers/input/input.c`:
|
||||
|
||||
:::dica
|
||||
É altamente recomendável habilitar este recurso, é muito útil para evitar bootloops!
|
||||
É altamente recomendável ativar este recurso, é muito útil para evitar bootloops!
|
||||
:::
|
||||
|
||||
```diff
|
||||
@@ -248,4 +249,4 @@ index 45306f9ef247..815091ebfca4 100755
|
||||
add_input_randomness(type, code, value);
|
||||
```
|
||||
|
||||
Finalmente, construa seu kernel novamente, o KernelSU deve funcionar bem.
|
||||
Finalmente, construa seu kernel novamente, e então, o KernelSU deve funcionar bem.
|
||||
|
||||
@@ -4,26 +4,26 @@
|
||||
|
||||
Baixe o app gerenciador KernelSU em [Lançamentos do GitHub](https://github.com/tiann/KernelSU/releases) ou [Coolapk market](https://www.coolapk.com/apk/me.weishu.kernelsu), e instale-o no seu dispositivo:
|
||||
|
||||
- Se o app mostrar `Unsupported`, significa que **Você deve compilar o kernel sozinho**, o KernelSU não fornecerá e nunca fornecerá uma imagem de inicialização para você atualizar.
|
||||
- Se o app mostrar `Not installed`, então seus dispositivos são oficialmente suportados pelo KernelSU.
|
||||
- Se o app mostrar `Sem suporte`, significa que **Você deve compilar o kernel sozinho**, o KernelSU não fornecerá e nunca fornecerá uma imagem de inicialização para você atualizar.
|
||||
- Se o app mostrar `Não instalado`, então seus dispositivos são oficialmente suportados pelo KernelSU.
|
||||
|
||||
:::informações
|
||||
Para dispositivos mostrando `Unsupported`, aqui está um [Dispositivos com suporte não oficial](unofficially-support-devices.md), você mesmo pode compilar o kernel.
|
||||
Para dispositivos mostrando `Sem suporte`, aqui está um [Dispositivos com suporte não oficial](unofficially-support-devices.md), você mesmo pode compilar o kernel.
|
||||
:::
|
||||
|
||||
## Backup stock boot.img
|
||||
## Backup padrão boot.img
|
||||
|
||||
Antes de atualizar, você deve primeiro fazer backup do seu stock boot.img. Se você encontrar algum bootloop, você sempre pode restaurar o sistema voltando para a inicialização de fábrica usando o fastboot.
|
||||
Antes de atualizar, você deve primeiro fazer backup do seu boot.img padrão. Se você encontrar algum bootloop, você sempre pode restaurar o sistema voltando para o boot de fábrica usando o fastboot.
|
||||
|
||||
::: aviso
|
||||
Piscar 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 telefone, se necessário.
|
||||
:::
|
||||
|
||||
## Conhecimento necessário
|
||||
|
||||
### ADB e fastboot
|
||||
|
||||
Por padrão, você usará as ferramentas ADB e fastboot neste tutorial, portanto, se você não as conhece, recomendamos usar um mecanismo de pesquisa para aprender sobre elas primeiro.
|
||||
Por padrão, você usará as ferramentas ADB e fastboot neste tutorial, portanto, se você não as conhece, recomendamos pesquisar para aprender sobre elas primeiro.
|
||||
|
||||
### KMI
|
||||
|
||||
@@ -47,26 +47,26 @@ Observe que o SubLevel na versão do kernel não faz parte do KMI! Isso signific
|
||||
|
||||
Por favor, observe: **A versão do kernel e a versão do Android não são necessariamente iguais!**
|
||||
|
||||
Se você descobrir que a versão do seu kernel é `android12-5.10.101`, mas a versão do seu sistema Android é Android 13 ou outra; não se surpreenda, pois o número da versão do sistema Android não é necessariamente igual ao número da versão do kernel Linux; O número da versão do kernel Linux geralmente é consistente com a versão do sistema Android que acompanha o **dispositivo quando ele é enviado**. Se o sistema Android for atualizado posteriormente, a versão do kernel geralmente não será alterada. Se você precisar atualizar, **consulte sempre a versão do kernel!!**
|
||||
Se você descobrir que a versão do seu kernel é `android12-5.10.101`, mas a versão do seu sistema Android é Android 13 ou outra; não se surpreenda, pois o número da versão do sistema Android não é necessariamente igual ao número da versão do kernel Linux; O número da versão do kernel Linux geralmente é consistente com a versão do sistema Android que acompanha o **dispositivo quando ele é enviado**. Se o sistema Android for atualizado posteriormente, a versão do kernel geralmente não será alterada. Se você precisar atualizar, **por favor, consulte sempre a versão do kernel!!**
|
||||
|
||||
## Introdução
|
||||
|
||||
Existem vários métodos de instalação do KernelSU, cada um adequado para um cenário diferente, portanto escolha conforme necessário.
|
||||
|
||||
1. Instale com Recovery personalizado (por exemplo, TWRP)
|
||||
2. Instale com um aplicativo kernel flash, como Franco Kernel Manager
|
||||
3. Instale com fastboot usando boot.img fornecido por KernelSU
|
||||
1. Instalar com Recovery personalizado (por exemplo, TWRP)
|
||||
2. Instalar com um app kernel flash, como Franco Kernel Manager
|
||||
3. Instalar com fastboot usando boot.img fornecido por KernelSU
|
||||
4. Repare o boot.img manualmente e instale-o
|
||||
|
||||
## Instalar com recuperação personalizada
|
||||
## Instalar com Recovery personalizado
|
||||
|
||||
Pré-requisito: Seu dispositivo deve ter um Recovery personalizada, como TWRP; se não ou apenas a Recovery oficial estiver disponível, use outro método.
|
||||
Pré-requisito: Seu dispositivo deve ter um Recovery personalizado, como TWRP; se não ou apenas o Recovery oficial estiver disponível, use outro método.
|
||||
|
||||
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).
|
||||
2. Reinicie o telefone no TWRP.
|
||||
3. Use adb para colocar AnyKernel3-*.zip no telefone /sdcard e escolha instalá-lo na GUI TWRP; ou você pode diretamente `adb sideload AnyKernel-*.zip` para instalar.
|
||||
3. Use 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.
|
||||
|
||||
PS. Este método é adequado para qualquer instalação (não limitado à instalação inicial ou atualizações subsequentes), desde que você use TWRP.
|
||||
|
||||
@@ -97,7 +97,7 @@ O KernelSU fornece um boot.img genérico para dispositivos GKI e você deve libe
|
||||
|
||||
Você pode baixar o boot.img em [Lançamento do GitHub](https://github.com/tiann/KernelSU/releases), por favor, observe que você deve usar a versão correta do boot.img. Por exemplo, se o seu dispositivo exibe o kernel `android12-5.10.101` , você precisa baixar `android-5.10.101_yyyy-MM.boot-<format>.img`. (Mantenha o KMI consistente!)
|
||||
|
||||
Onde `<formato>` se refere ao formato de compactação do kernel do seu boot.img oficial, verifique o formato de compactação do kernel do seu boot.img original, você deve usar o formato correto, por exemplo. `lz4`, `gz`; se você usar um formato de compactação incorreto, poderá encontrar bootloop.
|
||||
Onde `<format>` se refere ao formato de compactação do kernel do seu boot.img oficial, verifique o formato de compactação do kernel do seu boot.img original, você deve usar o formato correto, por exemplo. `lz4`, `gz`; se você usar um formato de compactação incorreto, poderá encontrar bootloop.
|
||||
|
||||
::: informações
|
||||
1. Você pode usar o magiskboot para obter o formato de compactação da sua inicialização original; é claro que você também pode perguntar a outras crianças 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.
|
||||
@@ -105,7 +105,7 @@ Onde `<formato>` se refere ao formato de compactação do kernel do seu boot.img
|
||||
3. Para dispositivos Pixel, siga as instruções abaixo.
|
||||
:::
|
||||
|
||||
### flash boot.img para o dispositivo
|
||||
### Flash boot.img para o dispositivo
|
||||
|
||||
Use `adb` para conectar seu dispositivo, execute `adb reboot bootloader` para entrar no modo fastboot e use este comando para atualizar o KernelSU:
|
||||
|
||||
@@ -117,7 +117,7 @@ fastboot flash boot boot.img
|
||||
Se o seu dispositivo suportar `fastboot boot`, você pode primeiro usar `fastboot boot boot.img` para tentar usar o boot.img para inicializar o sistema primeiro. Se algo inesperado acontecer, reinicie-o novamente para inicializar.
|
||||
:::
|
||||
|
||||
### reniciar
|
||||
### Reniciar
|
||||
|
||||
Após a conclusão do flash, você deve reiniciar o dispositivo:
|
||||
|
||||
@@ -127,14 +127,14 @@ fastboot reboot
|
||||
|
||||
## Corrigir boot.img manualmente
|
||||
|
||||
Para alguns dispositivos, o formato boot.img não é tão comum, como `lz4`, `gz` e descompactado; o mais típico é Pixel, seu formato boot.img é compactado `lz4_legacy`, ramdisk pode ser `gz` também pode ser compactado `lz4_legacy`; neste momento, se você atualizar 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` também pode ser compactado `lz4_legacy`; neste momento, se você atualizar 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.
|
||||
|
||||
Geralmente existem dois métodos de patch:
|
||||
|
||||
1. [Android-Image-Kitchen](https://forum.xda-developers.com/t/tool-android-image-kitchen-unpack-repack-kernel-ramdisk-win-android-linux-mac.2073775/)
|
||||
2. [magiskboot](https://github.com/topjohnwu/Magisk/releases)
|
||||
|
||||
Entre eles, o Android-Image-Kitchen é adequado para operação no PC e o magiskboot precisa da cooperação do telefone celular.
|
||||
Entre eles, o Android-Image-Kitchen é adequado para operação no PC e o magiskboot precisa da cooperação do telefone.
|
||||
|
||||
### Preparação
|
||||
|
||||
@@ -165,5 +165,5 @@ Entre eles, o Android-Image-Kitchen é adequado para operação no PC e o magisk
|
||||
|
||||
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.
|
||||
|
||||
1. Primeiro instale o Magisk, obtenha privilégios de root através do Magisk e então use o flasher do kernel para atualizar no zip AnyKernel do KernelSU.
|
||||
1. Primeiro instale o Magisk, obtenha privilégios de root através do Magisk e então use o kernel flasher para atualizar no zip AnyKernel do KernelSU.
|
||||
2. Use algum kit de ferramentas de atualização em PCs para atualizar no kernel fornecido KernelSU.
|
||||
|
||||
@@ -2,22 +2,22 @@
|
||||
|
||||
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 é comumente conhecido como "sem sistema".
|
||||
|
||||
O mecanismo do 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ó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).
|
||||
|
||||
## Busybox
|
||||
|
||||
O KernelSU vem com um recurso binário BusyBox completo (incluindo suporte completo a 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 _não_ a 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 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.
|
||||
|
||||
Cada script de shell executado no contexto do KernelSU será executado no shell `ash` do BusyBox com o modo autônomo habilitado. Para o que é relevante para desenvolvedores terceirizados, isso inclui todos os scripts de inicialização e scripts de instalação de módulos.
|
||||
Cada script de 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 este recurso de “Modo Autônomo” fora do KernelSU, existem 2 maneiras de habilitá-lo:
|
||||
Para aqueles que desejam usar este 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>`
|
||||
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 em modo autônomo, a opção 1 é o método preferido (e é isso que o KernelSU e o gerenciador KernelSU usam internamente), pois as variáveis de ambiente são herdadas para os processos filhos.
|
||||
Para garantir que todos os shells `sh` subsequentes executados também sejam executados em modo autônomo, a opção 1 é o método preferido (e é isso que o KernelSU e o gerenciador KernelSU usam internamente), pois as variáveis de ambiente são herdadas para os subprocesso.
|
||||
|
||||
::: tip diferença com Magisk
|
||||
::: tip Diferença com Magisk
|
||||
|
||||
O BusyBox do KernelSU agora está usando o arquivo binário compilado diretamente do projeto Magisk. **Obrigado ao Magisk!** Portanto, você não precisa se preocupar com problemas de compatibilidade entre scripts BusyBox no Magisk e KernelSU porque eles são exatamente iguais!
|
||||
:::
|
||||
@@ -31,42 +31,42 @@ Um módulo KernelSU é uma pasta colocada em `/data/adb/modules` com a estrutura
|
||||
├── .
|
||||
├── .
|
||||
|
|
||||
├── $MODID <--- The folder is named with the ID of the module
|
||||
├── $MODID <--- A pasta é nomeada com o ID do módulo
|
||||
│ │
|
||||
│ │ *** Module Identity ***
|
||||
│ │ *** Identidade do Módulo ***
|
||||
│ │
|
||||
│ ├── module.prop <--- This file stores the metadata of the module
|
||||
│ ├── module.prop <--- Este arquivo armazena os metadados do módulo
|
||||
│ │
|
||||
│ │ *** Main Contents ***
|
||||
│ │ *** Conteúdo Principal ***
|
||||
│ │
|
||||
│ ├── system <--- This folder will be mounted if skip_mount does not exist
|
||||
│ ├── system <--- Esta pasta será montada se skip_mount não existir
|
||||
│ │ ├── ...
|
||||
│ │ ├── ...
|
||||
│ │ └── ...
|
||||
│ │
|
||||
│ │ *** Status Flags ***
|
||||
│ │ *** Sinalizadores de Status ***
|
||||
│ │
|
||||
│ ├── skip_mount <--- If exists, KernelSU will NOT mount your system folder
|
||||
│ ├── disable <--- If exists, the module will be disabled
|
||||
│ ├── remove <--- If exists, the module will be removed next reboot
|
||||
│ ├── skip_mount <--- Se existir, o KernelSU NÃO montará sua pasta de sistema
|
||||
│ ├── disable <--- Se existir, o módulo será desabilitado
|
||||
│ ├── remove <--- Se existir, o módulo será removido na próxima reinicialização
|
||||
│ │
|
||||
│ │ *** Optional Files ***
|
||||
│ │ *** Arquivos Opcionais ***
|
||||
│ │
|
||||
│ ├── post-fs-data.sh <--- This script will be executed in post-fs-data
|
||||
│ ├── post-mount.sh <--- This script will be executed in post-mount
|
||||
│ ├── service.sh <--- This script will be executed in late_start service
|
||||
│ ├── boot-completed.sh <--- This script will be executed on boot completed
|
||||
| ├── uninstall.sh <--- This script will be executed when KernelSU removes your module
|
||||
│ ├── system.prop <--- Properties in this file will be loaded as system properties by resetprop
|
||||
│ ├── sepolicy.rule <--- Additional custom sepolicy rules
|
||||
│ ├── 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
|
||||
│ ├── 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
|
||||
│ │
|
||||
│ │ *** Auto Generated, DO NOT MANUALLY CREATE OR MODIFY ***
|
||||
│ │ *** Gerado Automaticamente, NÃO CRIE OU MODIFIQUE MANUALMENTE ***
|
||||
│ │
|
||||
│ ├── vendor <--- A symlink to $MODID/system/vendor
|
||||
│ ├── product <--- A symlink to $MODID/system/product
|
||||
│ ├── system_ext <--- A symlink to $MODID/system/system_ext
|
||||
│ ├── vendor <--- Um link simbólico para $MODID/system/vendor
|
||||
│ ├── product <--- Um link simbólico para $MODID/system/product
|
||||
│ ├── system_ext <--- Um link simbólico para $MODID/system/system_ext
|
||||
│ │
|
||||
│ │ *** Any additional files / folders are allowed ***
|
||||
│ │ *** Quaisquer arquivos/pastas adicionais são permitidos ***
|
||||
│ │
|
||||
│ ├── ...
|
||||
│ └── ...
|
||||
@@ -78,8 +78,8 @@ Um módulo KernelSU é uma pasta colocada em `/data/adb/modules` com a estrutura
|
||||
├── .
|
||||
```
|
||||
|
||||
::: tip diferença com Magisk
|
||||
KernelSU não possui suporte integrado para o Zygisk, portanto não há conteúdo relacionado ao Zygisk no módulo. No entanto, você pode usar [ZygiskOnKernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU) para suportar módulos Zygisk. Neste caso, o conteúdo do módulo Zygisk é idêntico ao suportado pelo Magisk.
|
||||
::: tip Diferença com Magisk
|
||||
O KernelSU não possui suporte integrado para o Zygisk, portanto não há conteúdo relacionado ao Zygisk no módulo. No entanto, você pode usar [ZygiskOnKernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU) para suportar módulos Zygisk. Neste caso, o conteúdo do módulo Zygisk é idêntico ao suportado pelo Magisk.
|
||||
:::
|
||||
|
||||
### module.prop
|
||||
@@ -108,11 +108,11 @@ Por favor, leia a seção [Scripts de inicialização](#boot-scripts) para enten
|
||||
|
||||
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.
|
||||
|
||||
::: 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 em KernelSU, esse valor será definido como verdadeiro.
|
||||
::: 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 em KernelSU, esse valor será definido como `true`.
|
||||
:::
|
||||
|
||||
### `system` diretório
|
||||
### 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:
|
||||
|
||||
@@ -121,7 +121,7 @@ O conteúdo deste diretório será sobreposto à partição /system do sistema u
|
||||
|
||||
Se você deseja excluir um arquivo ou pasta no diretório original do sistema, você precisa criar um arquivo com o mesmo nome do arquivo/pasta no diretório do módulo usando `mknod filename c 0 0`. Dessa forma, o sistema overlayfs irá automaticamente "branquear" este arquivo como se ele tivesse sido excluído (a partição /system não foi realmente alterada).
|
||||
|
||||
Você também pode declarar uma variável chamada `REMOVE` contendo uma lista de diretórios em `customize.sh` para executar operações de remoção, e KernelSU executará automaticamente `mknod <TARGET> c 0 0` nos diretórios correspondentes do módulo. Por exemplo:
|
||||
Você também pode declarar uma variável chamada `REMOVE` contendo uma lista de diretórios em `customize.sh` para executar operações de remoção, e o KernelSU executará automaticamente `mknod <TARGET> c 0 0` nos diretórios correspondentes do módulo. Por exemplo:
|
||||
|
||||
```sh
|
||||
REMOVE="
|
||||
@@ -130,20 +130,22 @@ 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`; e `/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).
|
||||
|
||||
Você pode declarar uma variável chamada `REPLACE` em seu arquivo `customize.sh`, que inclui uma lista de diretórios a serem substituídos, e KernelSU executará automaticamente as operações correspondentes em seu diretório de módulo. Por exemplo:
|
||||
Você pode declarar uma variável chamada `REPLACE` em seu arquivo `customize.sh`, que inclui uma lista de diretórios a serem substituídos, e o KernelSU executará automaticamente as operações correspondentes em seu diretório de módulo. Por exemplo:
|
||||
|
||||
```sh
|
||||
REPLACE="
|
||||
/system/app/YouTube
|
||||
/system/app/Bloatware
|
||||
"
|
||||
```
|
||||
|
||||
Esta lista criará automaticamente os diretórios `$MODPATH/system/app/YouTube` e `$MODPATH/system/app/Bloatware` e, em seguida, executará `setfattr -n Trusted.overlay.opaque -v e $MODPATH/system/app/ YouTube` e `setfattr -n Trusted.overlay.opaque -v e $MODPATH/system/app/Bloatware`. Após o módulo entrar em vigor, `/system/app/YouTube` e `/system/app/Bloatware` serão substituídos por diretórios vazios.
|
||||
Esta lista criará automaticamente os diretórios `$MODPATH/system/app/YouTube` e `$MODPATH/system/app/Bloatware` e, em seguida, executará `setfattr -n trusted.overlay.opaque -v y $MODPATH/system/app/YouTube` e `setfattr -n trusted.overlay.opaque -v y $MODPATH/system/app/Bloatware`. Após o módulo entrar em vigor, `/system/app/YouTube` e `/system/app/Bloatware` serão substituídos por diretórios vazios.
|
||||
|
||||
::: tip diferença com Magisk
|
||||
::: tip Diferença com Magisk
|
||||
|
||||
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.
|
||||
:::
|
||||
@@ -152,7 +154,7 @@ Se você estiver interessado em overlayfs, é recomendável ler a [documentaçã
|
||||
|
||||
### system.prop
|
||||
|
||||
Este arquivo segue o mesmo formato de `build.prop`. Cada linha é composta por `[chave]=[valor]`.
|
||||
Este arquivo segue o mesmo formato de `build.prop`. Cada linha é composta por `[key]=[value]`.
|
||||
|
||||
### sepolicy.rule
|
||||
|
||||
@@ -165,24 +167,24 @@ Um instalador de módulo KernelSU é um módulo KernelSU empacotado em um arquiv
|
||||
```txt
|
||||
module.zip
|
||||
│
|
||||
├── customize.sh <--- (Optional, more details later)
|
||||
│ This script will be sourced by update-binary
|
||||
├── customize.sh <--- (Opcional, mais detalhes posteriormente)
|
||||
│ Este script será fornecido por update-binary
|
||||
├── ...
|
||||
├── ... /* The rest of module's files */
|
||||
├── ... /* O resto dos arquivos do módulo */
|
||||
│
|
||||
```
|
||||
|
||||
:::aviso
|
||||
O módulo KernelSU NÃO é compatível para instalação no recovery personalizado!!
|
||||
O módulo KernelSU **NÃO** é compatível para instalação no recovery personalizado!
|
||||
:::
|
||||
|
||||
### Costumização
|
||||
|
||||
Se 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/segundo contexto 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/segundo contexto 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.
|
||||
|
||||
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
|
||||
|
||||
@@ -196,35 +198,35 @@ O script `customize.sh` é executado no shell BusyBox `ash` do KernelSU com o "M
|
||||
- `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`
|
||||
- `IS64BIT` (bool): `true` se `$ARCH` for `arm64` ou `x64`
|
||||
- `API` (int): o nível da API (versão 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)
|
||||
|
||||
::: aviso
|
||||
No KernelSU, MAGISK_VER_CODE é sempre 25200 e MAGISK_VER é sempre v25.2. Por favor, não use essas duas variáveis para determinar se ele está sendo executado no KernelSU ou não.
|
||||
No KernelSU, `MAGISK_VER_CODE` é sempre `25200` e `MAGISK_VER` é sempre `v25.2`. Por favor, não use essas duas variáveis para determinar se ele está sendo executado no KernelSU ou não.
|
||||
:::
|
||||
|
||||
#### Funções
|
||||
|
||||
```txt
|
||||
ui_print <msg>
|
||||
print <msg> to console
|
||||
Avoid using 'echo' as it will not display in custom recovery's console
|
||||
imprima <msg> no console
|
||||
Evite usar 'echo', pois ele não será exibido no console de recuperação personalizado
|
||||
|
||||
abort <msg>
|
||||
print error message <msg> to console and terminate the installation
|
||||
Avoid using 'exit' as it will skip the termination cleanup steps
|
||||
imprima mensagem de erro <msg> para consolar e encerrar a instalação
|
||||
Evite usar 'exit', pois isso irá pular as etapas de limpeza de encerramento
|
||||
|
||||
set_perm <target> <owner> <group> <permission> [context]
|
||||
if [context] is not set, the default is "u:object_r:system_file:s0"
|
||||
this function is a shorthand for the following commands:
|
||||
se [context] não estiver definido, o padrão é "u:object_r:system_file:s0"
|
||||
esta função é uma abreviação para os seguintes comandos:
|
||||
chown owner.group target
|
||||
chmod permission target
|
||||
chcon context target
|
||||
|
||||
set_perm_recursive <directory> <owner> <group> <dirpermission> <filepermission> [context]
|
||||
if [context] is not set, the default is "u:object_r:system_file:s0"
|
||||
for all files in <directory>, it will call:
|
||||
set_perm file owner group filepermission context
|
||||
for all directories in <directory> (including itself), it will call:
|
||||
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
|
||||
para todos os diretórios em <directory> (including itself), ele vai ligar:
|
||||
set_perm dir owner group dirpermission context
|
||||
```
|
||||
|
||||
@@ -244,14 +246,14 @@ No KernelSU, os scripts são divididos em dois tipos com base em seu modo de exe
|
||||
|
||||
No KernelSU, os scripts de inicialização são divididos em dois tipos com base no local de armazenamento: scripts gerais e scripts de módulo:
|
||||
|
||||
- Scripts Gerais
|
||||
- Colocado em `/data/adb/post-fs-data.d`, `/data/adb/service.d`, `/data/adb/post-mount.d` ou `/data/adb/boot- concluído.d`
|
||||
- Scripts gerais
|
||||
- Colocado em `/data/adb/post-fs-data.d`, `/data/adb/service.d`, `/data/adb/post-mount.d` ou `/data/adb/boot-completed.d`
|
||||
- Somente executado se o script estiver definido como executável (`chmod +x script.sh`)
|
||||
- Os scripts em `post-fs-data.d` são executados no modo post-fs-data e os scripts em `service.d` são executados no modo de serviço late_start.
|
||||
- Os módulos **NÃO** devem adicionar scripts gerais durante a instalação
|
||||
- Scripts de Módulo
|
||||
- Scripts de módulo
|
||||
- Colocado na própria pasta do módulo
|
||||
- Executado apenas se o módulo estiver habilitado
|
||||
- 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, `post-mount.sh` é executado em overlayfs montado.
|
||||
|
||||
Todos os scripts de inicialização serão executados no shell BusyBox `ash` do KernelSU com o "Modo Autônomo" ativado.
|
||||
|
||||
@@ -1,8 +1,8 @@
|
||||
# Resgate do bootloop
|
||||
|
||||
Ao atualizar um dispositivo, podemos encontrar situações em que o dispositivo fica "emparedado". Em teoria, se você usar o fastboot apenas para atualizar a partição de boot ou instalar módulos inadequados que causam falha na inicialização do dispositivo, isso poderá ser restaurado por meio de operações apropriadas. Este documento tem como objetivo fornecer alguns métodos de emergência para ajudá-lo a se recuperar de um dispositivo "bloqueado".
|
||||
Ao atualizar um dispositivo, podemos encontrar situações em que o dispositivo fica "bricked". Em teoria, se você usar o fastboot apenas para atualizar a partição de boot ou instalar módulos inadequados que causam falha na inicialização do dispositivo, isso poderá ser restaurado por meio de operações apropriadas. Este documento tem como objetivo fornecer alguns métodos de emergência para ajudá-lo a se recuperar de um dispositivo "bricked".
|
||||
|
||||
## Bloqueio por piscar partição boot
|
||||
## Brick por flashear partição boot
|
||||
|
||||
No KernelSU, as seguintes situações podem causar bloqueio de inicialização ao atualizar a partição boot:
|
||||
|
||||
@@ -10,41 +10,41 @@ No KernelSU, as seguintes situações podem causar bloqueio de inicialização a
|
||||
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.
|
||||
|
||||
Não importa qual seja a situação, você pode recuperar **atualizando a stock boot image**. Portanto, no início do tutorial de instalação, recomendamos fortemente que você faça backup de seu boot padrão antes de atualizar. 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.
|
||||
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 atualizar. 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.
|
||||
|
||||
## Bloqueio por módulos
|
||||
## Brick por módulos
|
||||
|
||||
A instalação de módulos pode ser uma causa mais comum de bloqueio do seu dispositivo, mas devemos avisá-lo seriamente: **Não instale módulos de fontes desconhecidas**! Como os módulos têm privilégios de root, eles podem causar danos irreversíveis ao seu dispositivo!
|
||||
A instalação de módulos pode ser uma causa mais comum de brick do seu dispositivo, mas devemos avisá-lo seriamente: **Não instale módulos de fontes desconhecidas**! Como os módulos têm privilégios de root, eles podem causar danos irreversíveis ao seu dispositivo!
|
||||
|
||||
### Módulos normais
|
||||
|
||||
Se você atualizou um módulo que foi comprovadamente seguro, mas faz com que seu dispositivo não inicialize, então esta situação é facilmente recuperável no KernelSU sem qualquer preocupação. KernelSU possui mecanismos integrados para resgatar seu dispositivo, incluindo o seguinte:
|
||||
Se você atualizou um módulo que foi comprovadamente seguro, mas faz com que seu dispositivo não inicialize, então esta situação é facilmente recuperável no KernelSU sem qualquer preocupação. O KernelSU possui mecanismos integrados para recuperar seu dispositivo, incluindo o seguinte:
|
||||
|
||||
1. Atualização AB
|
||||
2. Resgate pressionando o botão de diminuir volume
|
||||
2. Recupere pressionando o botão de diminuir volume
|
||||
|
||||
#### Atualização AB
|
||||
|
||||
As atualizações do módulo KernelSU inspiram-se no mecanismo de atualização AB do sistema Android usado em atualizações OTA. Se você instalar um novo módulo ou atualizar um existente, isso não modificará diretamente o arquivo do módulo usado atualmente. Em vez disso, todos os módulos serão integrados em outra imagem de atualização. Depois que o sistema for reiniciado, ele tentará começar a usar esta imagem de atualização. Se o sistema Android inicializar com sucesso, os módulos serão realmente atualizados.
|
||||
|
||||
Portanto, o método mais simples e comumente usado para resgatar seu dispositivo é **forçar uma reinicialização**. Se você não conseguir iniciar o sistema após atualizar um módulo, você pode pressionar e segurar o botão liga/desliga por mais de 10 segundos e o sistema será reinicializado automaticamente; após a reinicialização, ele retornará ao estado anterior à atualização do módulo e os módulos atualizados anteriormente serão desativados automaticamente.
|
||||
Portanto, o método mais simples e comumente usado para recuperar seu dispositivo é **forçar uma reinicialização**. Se você não conseguir iniciar o sistema após atualizar um módulo, você pode pressionar e segurar o botão liga/desliga por mais de 10 segundos e o sistema será reinicializado automaticamente; após a reinicialização, ele retornará ao estado anterior à atualização do módulo e os módulos atualizados anteriormente serão desativados automaticamente.
|
||||
|
||||
#### Resgate pressionando o botão de diminuir volume
|
||||
#### Recupere pressionando o botão de diminuir volume
|
||||
|
||||
Se as atualizações AB ainda não resolverem o problema, você pode tentar usar o **Modo de segurança**. No Modo de Segurança, todos os módulos estão desabilitados.
|
||||
Se as atualizações AB ainda não resolverem o problema, você pode tentar usar o **Modo de Segurança**. No Modo de Segurança, todos os módulos estão desabilitados.
|
||||
|
||||
Existem duas maneiras de entrar no modo de segurança:
|
||||
Existem duas maneiras de entrar no Modo de Segurança:
|
||||
|
||||
1. O Modo de Segurança integrado de alguns sistemas; alguns sistemas possuem um Modo de Segurança integrado que pode ser acessado pressionando longamente o botão de diminuir volume, enquanto outros (como MIUI) podem ativar o Modo de Segurança no Recovery. Ao entrar no Modo de Segurança do sistema, o KernelSU também entrará no Modo de Segurança e desativará automaticamente os módulos.
|
||||
1. O Modo de Segurança integrado de alguns sistemas; alguns sistemas possuem um Modo de Segurança integrado que pode ser acessado pressionando longamente o botão de diminuir volume, enquanto outros (como a MIUI) podem ativar o Modo de Segurança no Recovery. Ao entrar no Modo de Segurança do sistema, o KernelSU também entrará no Modo de Segurança e desativará automaticamente os módulos.
|
||||
2. O Modo de Segurança integrado do KernelSU; o método de operação é **pressionar a tecla de diminuir volume continuamente por mais de três vezes** após a primeira tela de inicialização. Observe que é um comunicado à imprensa, um comunicado à imprensa, um comunicado à imprensa, não pressione e segure.
|
||||
|
||||
Após entrar no Modo de Segurança, todos os módulos na página de módulos do Gerenciador KernelSU são desabilitados, mas você pode executar operações de "desinstalação" para desinstalar quaisquer módulos que possam estar causando problemas.
|
||||
|
||||
O modo de segurança integrado é implementado no kernel, portanto não há possibilidade de perder eventos importantes devido à interceptação. No entanto, para kernels não GKI, a integração manual do código pode ser necessária e você pode consultar a documentação oficial para obter orientação.
|
||||
O Modo de Segurança integrado é implementado no kernel, portanto não há possibilidade de perder eventos importantes devido à interceptação. No entanto, para kernels não GKI, a integração manual do código pode ser necessária e você pode consultar a documentação oficial para obter orientação.
|
||||
|
||||
### Módulos maliciosos
|
||||
|
||||
Se os métodos acima não conseguirem recuperar seu dispositivo, é altamente provável que o módulo que você instalou tenha operações maliciosas ou tenha danificado seu dispositivo por outros meios. Neste caso, existem apenas duas sugestões:
|
||||
|
||||
1. Limpe os dados e atualize o sistema oficial.
|
||||
1. Limpe os dados e instale o sistema oficial.
|
||||
2. Consulte o serviço pós-venda.
|
||||
|
||||
@@ -1,15 +1,15 @@
|
||||
# Dispositivos não oficialmente suportados
|
||||
# Dispositivos com suporte não oficial
|
||||
|
||||
::: aviso
|
||||
Nesta página, existem kernels para dispositivos não GKI que suportam KernelSU mantidos por outros desenvolvedores.
|
||||
Nesta página, existem kernels para dispositivos não GKI que suportam o KernelSU mantidos por outros desenvolvedores.
|
||||
:::
|
||||
|
||||
::: aviso
|
||||
Esta página é apenas para você encontrar o código-fonte correspondente ao seu dispositivo. **NÃO** significa que o código-fonte foi revisado por _KernelSU Developers_. Você deve usá-lo por sua própria conta e risco.
|
||||
Esta página é apenas para você encontrar o código-fonte correspondente ao seu dispositivo, **NÃO** significa que o código-fonte foi revisado pelos desenvolvedores do KernelSU. Você deve usá-lo por sua própria conta e risco.
|
||||
:::
|
||||
|
||||
<script setup>
|
||||
import data from '../repos.json'
|
||||
import data from '../../repos.json'
|
||||
</script>
|
||||
|
||||
<table>
|
||||
@@ -27,4 +27,4 @@ import data from '../repos.json'
|
||||
<td>{{ repo.devices }}</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</table>
|
||||
|
||||
@@ -4,13 +4,13 @@ O KernelSU é uma solução root para dispositivos Android GKI, funciona no modo
|
||||
|
||||
## Características
|
||||
|
||||
A principal característica do KernelSU é que ele é **baseado em kernel**. KernelSU funciona no modo kernel, portanto pode fornecer uma interface de kernel que nunca tivemos antes. Por exemplo, podemos adicionar um ponto de interrupção de hardware a qualquer processo no modo kernel; Podemos acessar a memória física de qualquer processo sem que ninguém perceba; Podemos interceptar qualquer syscall no espaço do kernel; etc.
|
||||
A principal característica do KernelSU é que ele é **baseado em kernel**. O KernelSU funciona no modo kernel, portanto pode fornecer uma interface de kernel que nunca tivemos antes. Por exemplo, podemos adicionar um ponto de interrupção de hardware a qualquer processo no modo kernel; Podemos acessar a memória física de qualquer processo sem que ninguém perceba; Podemos interceptar qualquer syscall no espaço do kernel; etc.
|
||||
|
||||
E também, o KernelSU fornece um sistema de módulos via overlayfs, que permite carregar seu plugin personalizado no sistema. Ele também fornece um mecanismo para modificar arquivos na partição `/system`.
|
||||
|
||||
## Como usar
|
||||
|
||||
Consulte: [Instalação](installation)
|
||||
Por favor, consulte: [Instalação](installation)
|
||||
|
||||
## Como construir
|
||||
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
---
|
||||
layout: home
|
||||
title: Uma solução raiz baseada em kernel para Android
|
||||
title: Uma solução root baseada em kernel para Android
|
||||
|
||||
hero:
|
||||
name: KernelSU
|
||||
text: Uma solução raiz baseada em kernel para Android
|
||||
text: Uma solução root baseada em kernel para Android
|
||||
tagline: ""
|
||||
image:
|
||||
src: /logo.png
|
||||
@@ -21,9 +21,8 @@ features:
|
||||
- title: Baseado em kernel
|
||||
details: KernelSU está funcionando no modo kernel Linux, tem mais controle sobre os apps do espaço do usuário.
|
||||
- title: Controle de acesso à lista de permissões
|
||||
details: Somente apps que recebem permissão de root podem acessar `su`, outros apps não podem perceber su.
|
||||
details: Somente apps que recebem permissão de root podem acessar su, outros apps não podem perceber su.
|
||||
- title: Permissão de root restrita
|
||||
details: KernelSU permite que você personalize o uid, gid, grupos, recursos e regras SELinux do su. Tranque o poder raiz em uma gaiola.
|
||||
details: KernelSU permite que você personalize o uid, gid, grupos, recursos e regras SELinux do su. Tranque o poder root em uma gaiola.
|
||||
- title: Módulo e Código aberto
|
||||
details: KernelSU suporta modificação /system sem sistema por overlayfs e é de código aberto sob GPL-3.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user