fix typos in website (#1023)
This commit is contained in:
igor
GitHub
@@ -2,17 +2,17 @@
|
||||
|
||||
O Perfil do Aplicativo é um mecanismo fornecido pelo KernelSU para personalizar a configuração de vários apps.
|
||||
|
||||
Para apps com permissões de root (ou seja, capazes de usar `su`), o Perfil do Aplicativo também pode ser chamado de Perfil Raiz. Ele permite a customização das regras `uid`, `gid`, `groups`, `capabilities` e `SELinux` do comando `su`, restringindo assim os privilégios do usuário root. Por exemplo, ele pode conceder permissões de rede apenas para apps de firewall enquanto nega permissões de acesso a arquivos, ou pode conceder permissões de shell em vez de acesso root completo para apps congelados: **mantendo o poder confinado com o princípio do menor privilégio.**
|
||||
Para apps com permissões de root (ou seja, capazes de usar `su`), o Perfil do Aplicativo também pode ser chamado de Perfil Root. Ele permite a customização das regras `uid`, `gid`, `groups`, `capabilities` e `SELinux` do comando `su`, restringindo assim os privilégios do usuário root. Por exemplo, ele pode conceder permissões de rede apenas para apps de firewall enquanto nega permissões de acesso a arquivos, ou pode conceder permissões de shell em vez de acesso root completo para apps congelados: **mantendo o poder confinado com o princípio do menor privilégio.**
|
||||
|
||||
Para apps comuns sem permissões de root, o Perfil do Aplicativo pode controlar o comportamento do kernel e do sistema de módulos em relação a esses apps. Por exemplo, pode determinar se as modificações resultantes dos módulos devem ser abordadas. O kernel e o sistema de módulos podem tomar decisões com base nesta configuração, como realizar operações semelhantes a "ocultar"
|
||||
|
||||
## Perfil Raiz
|
||||
## Perfil Root
|
||||
|
||||
### UID, GID e Grupos
|
||||
|
||||
Os sistemas Linux possuem dois conceitos: usuários e grupos. Cada usuário possui um ID de usuário (UID) e um usuário pode pertencer a vários grupos, cada um com seu próprio ID de grupo (GID). Esses IDs são usados para identificar usuários no sistema e determinar quais recursos do sistema eles podem acessar.
|
||||
|
||||
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.
|
||||
Os usuários com UID 0 são conhecidos como usuários root e os grupos com GID 0 são conhecidos como grupos root. O grupo de usuários root normalmente possui os privilégios de sistema mais altos.
|
||||
|
||||
No caso do sistema Android, cada app é um usuário separado (excluindo cenários de UID compartilhados) com um UID exclusivo. Por exemplo, `0` representa o usuário root, `1000` representa `system`, `2000` representa o ADB shell e UIDs variando de `10.000` a `19.999` representam apps comuns.
|
||||
|
||||
@@ -31,33 +31,33 @@ 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 root após a execução de `su`. Por exemplo, o Perfil Raiz de um app root 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.
|
||||
O Perfil Root do KernelSU permite a personalização do UID, GID e grupos para o processo root após a execução de `su`. Por exemplo, o Perfil Root de um app root pode definir seu UID como `2000`, 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
|
||||
O Perfil do Aplicativo controla apenas as permissões do processo root após usar `su`, e 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 por meio do `su`, a concessão da permissão `su` depende inteiramente do usuário e não do desenvolvedor.
|
||||
O Perfil Root é 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 de `su`, a concessão da permissão `su` depende inteiramente do usuário e não do desenvolvedor.
|
||||
|
||||
### Capacidades
|
||||
|
||||
As capacidades são um mecanismo para separação de privilégios no Linux.
|
||||
|
||||
Para realizar verificações de permissão, as implementações tradicionais do `UNIX` distinguem duas categorias de processos: processos privilegiados (cujo ID de usuário efetivo é `0`, referido como superusuário ou root) e processos sem privilégios (cujo UID efetivo é diferente de zero). Os processos privilegiados ignoram todas as verificações de permissão do kernel, enquanto os processos não privilegiados estão sujeitos à verificação completa de permissão com base nas credenciais do processo (Geralmente: UID efetivo, GID efetivo e lista de grupos suplementares).
|
||||
Para realizar verificações de permissão, as implementações tradicionais do `UNIX` distinguem duas categorias de processos: processos privilegiados (cujo ID de usuário efetivo é `0`, referido como superusuário ou root) e processos sem privilégios (cujo UID efetivo é diferente de zero). Os processos privilegiados ignoram todas as verificações de permissão do kernel, enquanto os processos não privilegiados estão sujeitos à verificação completa de permissão com base nas credenciais do processo (geralmente: UID efetivo, GID efetivo e lista de grupos suplementares).
|
||||
|
||||
A partir do Linux 2.2, o Linux divide os privilégios tradicionalmente associados ao superusuário em unidades distintas, conhecidas como capacidades, que podem ser ativadas e desativadas de forma independente.
|
||||
|
||||
Cada capacidade representa um ou mais privilégios. Por exemplo, `CAP_DAC_READ_SEARCH` representa a capacidade de ignorar verificações de permissão para leitura de arquivos, bem como permissões de leitura e execução de diretório. Se um usuário com um UID efetivo `0` (usuário root) não tiver recursos `CAP_DAC_READ_SEARCH` ou superiores, isso significa que mesmo sendo root, ele não pode ler arquivos à vontade.
|
||||
|
||||
O Perfil Raiz do KernelSU permite a personalização das capacidades do processo root 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.
|
||||
O Perfil Root do KernelSU permite a personalização das capacidades do processo root 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
|
||||
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.
|
||||
A [documentação oficial](https://man7.org/linux/man-pages/man7/capabilities.7.html) da Capacidade do Linux fornece explicações detalhadas das habilidades representadas por cada Capacidade. Se você pretende customizar Capacidades, é altamente recomendável que você leia este documento primeiro.
|
||||
:::
|
||||
|
||||
### SELinux
|
||||
|
||||
SELinux é um poderoso mecanismo do Controle de Acesso Obrigatório (MAC). Ele opera com base no princípio de **negação padrão**: qualquer ação não explicitamente permitida é negada.
|
||||
SELinux é um poderoso mecanismo do Controle de Acesso Obrigatório (MAC). Ele opera com base no princípio de **negação padrão**. Qualquer ação não explicitamente permitida é negada.
|
||||
|
||||
O SELinux pode ser executado em dois modos globais:
|
||||
|
||||
@@ -89,9 +89,9 @@ Observe que a regra `allow app1 * * *` é usada apenas para fins de demonstraç
|
||||
|
||||
### Escalação
|
||||
|
||||
Se a configuração do Perfil Root não estiver definida corretamente, poderá ocorrer um cenário de escalonamento: as restrições impostas pelo Perfil Root poderão falhar involuntariamente.
|
||||
Se a configuração do Perfil Root não estiver definida corretamente, poderá ocorrer um cenário de escalação. As restrições impostas pelo Perfil Root poderão falhar involuntariamente.
|
||||
|
||||
Por exemplo, se você conceder permissão root a um usuário ADB shell (que é um caso comum) e, em seguida, conceder permissão root a um app normal, mas configurar seu perfil root com UID 2000 (que é o UID do usuário ADB shell), o app pode obter acesso root completo executando o comando `su` duas vezes:
|
||||
Por exemplo, se você conceder permissão root a um usuário ADB shell (que é um caso comum) e, em seguida, conceder permissão root a um app normal, mas configurar seu Perfil Root com UID 2000 (que é o UID do usuário ADB shell), o app pode obter acesso root completo executando o comando `su` duas vezes:
|
||||
|
||||
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égio de root completo.
|
||||
@@ -99,14 +99,14 @@ Por exemplo, se você conceder permissão root a um usuário ADB shell (que é u
|
||||
:::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 Root. Usar `1000` (sistema) seria uma melhor escolha.
|
||||
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 Root. Usar `1000` (system) seria uma melhor escolha.
|
||||
:::
|
||||
|
||||
## Perfil não Root
|
||||
|
||||
### 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ódulo”.
|
||||
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:
|
||||
|
||||
|
||||
@@ -4,14 +4,14 @@ Embora existam muitas semelhanças entre os módulos KernelSU e os módulos Magi
|
||||
|
||||
## 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
|
||||
- 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
|
||||
- post-fs-data.sh: o tempo de execução e a semântica são exatamente os mesmos
|
||||
- service.sh: o tempo de execução e a semântica são exatamente os mesmos
|
||||
- system.prop: completamente o mesmo
|
||||
- sepolicy.rule: completamente o mesmo
|
||||
- BusyBox: os scripts são executados no BusyBox com o "Modo Autônomo" ativado em ambos os casos
|
||||
- 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`.
|
||||
- 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.
|
||||
- service.sh: o tempo de execução e a semântica são exatamente os mesmos.
|
||||
- system.prop: completamente o mesmo.
|
||||
- sepolicy.rule: completamente o mesmo.
|
||||
- BusyBox: os scripts são executados no BusyBox com o "Modo Autônomo" ativado em ambos os casos.
|
||||
|
||||
## Diferenças
|
||||
|
||||
|
||||
@@ -2,21 +2,21 @@
|
||||
|
||||
## KernelSU oferece suporte ao meu dispositivo?
|
||||
|
||||
Primeiro, seus dispositivos devem ser capazes de desbloquear o bootloader. Se não puder, então não há suporte.
|
||||
Primeiro, seu dispositivo deve ser capaz de desbloquear o bootloader. Se não, então não há suporte.
|
||||
|
||||
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).
|
||||
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 com suporte não oficial](unofficially-support-devices).
|
||||
|
||||
## KernelSU precisa desbloquear o Bootloader?
|
||||
|
||||
Certamente, sim
|
||||
Certamente, sim.
|
||||
|
||||
## KernelSU suporta módulos?
|
||||
|
||||
Sim, mas está na versão inicial, pode apresentar bugs. Aguarde até que fique estável
|
||||
Sim, mas está na versão inicial, pode apresentar bugs. Por favor, aguarde até que fique estável.
|
||||
|
||||
## KernelSU suporta Xposed?
|
||||
|
||||
Sim, [Dreamland](https://github.com/canyie/Dreamland) e [TaiChi](https://taichi.cool) funcionam agora. Para o LSPosed, você pode fazer funcionar usando [ZygiskOnKernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU)
|
||||
Sim, [Dreamland](https://github.com/canyie/Dreamland) e [TaiChi](https://taichi.cool) funcionam agora. Para o LSPosed, você pode fazer funcionar usando [ZygiskOnKernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU).
|
||||
|
||||
## KernelSU suporta Zygisk?
|
||||
|
||||
@@ -26,22 +26,22 @@ KernelSU não tem suporte integrado ao Zygisk, mas você pode usar [ZygiskOnKern
|
||||
|
||||
O sistema de módulos do KernelSU está em conflito com a montagem mágica do Magisk, se houver algum módulo habilitado no KernelSU, então todo o Magisk não funcionaria.
|
||||
|
||||
Mas se você usar apenas o `su` do KernelSU, então funcionará bem com o Magisk: KernelSU modifica o `kernel` e o Magisk modifica o `ramdisk`, eles podem trabalhar juntos.
|
||||
Mas se você usar apenas o `su` do KernelSU, então funcionará bem com o Magisk. KernelSU modifica o `kernel` e o Magisk modifica o `ramdisk`, eles podem trabalhar juntos.
|
||||
|
||||
## KernelSU substituirá o Magisk?
|
||||
|
||||
Achamos que não e esse não é o nosso objetivo. Magisk é bom o suficiente para solução raiz do espaço do usuário e terá uma vida longa. O objetivo do KernelSU é fornecer uma interface de kernel aos usuários, não substituindo o Magisk.
|
||||
Achamos que não e esse não é o nosso objetivo. O Magisk é bom o suficiente para solução root do espaço do usuário e terá uma longa vida. O objetivo do KernelSU é fornecer uma interface de kernel aos usuários, não substituindo o Magisk.
|
||||
|
||||
## KernelSU pode oferecer suporte a dispositivos não GKI?
|
||||
|
||||
É possível. Mas você deve baixar o código-fonte do kernel e integrar o KernelSU à árvore de código-fonte e compilar o kernel você mesmo.
|
||||
É possível. Mas você deve baixar o código-fonte do kernel e integrar o KernelSU à árvore do código-fonte e compilar o kernel você mesmo.
|
||||
|
||||
## KernelSU pode oferecer suporte a dispositivos abaixo do Android 12?
|
||||
|
||||
É o kernel do dispositivo que afeta a compatibilidade do KernelSU e não tem nada a ver com a versão do Android. A única restrição é que os dispositivos lançados com Android 12 devem ser kernel 5.10+ (dispositivos GKI). Então:
|
||||
|
||||
1. Os dispositivos lançados com Android 12 devem ser compatíveis.
|
||||
2. Dispositivos com kernel antigo (alguns dispositivos Android 12 também têm kernel antigo) são compatíveis (você mesmo deve construir o kernel)
|
||||
2. Dispositivos com kernel antigo (alguns dispositivos Android 12 também têm o kernel antigo) são compatíveis (você mesmo deve construir o kernel).
|
||||
|
||||
## KernelSU pode suportar kernel antigo?
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@ Primeiro, você deve ler a documentação oficial do Android para construção d
|
||||
2. [Builds de versão de imagem genérica do kernel (GKI)](https://source.android.com/docs/core/architecture/kernel/gki-release-builds)
|
||||
|
||||
::: warning AVISO
|
||||
Esta página é para dispositivos GKI, se você usa um kernel antigo, consulte [Como integrar o KernelSU para kernels não GKI](how-to-integrate-for-non-gki)
|
||||
Esta página é para dispositivos GKI, se você usa um kernel antigo, consulte [Como integrar o KernelSU para kernels não GKI](how-to-integrate-for-non-gki).
|
||||
:::
|
||||
|
||||
## Construir o kernel
|
||||
@@ -20,7 +20,7 @@ repo init -m manifest.xml
|
||||
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 [compilações de lançamento do Google GKI](https://source.android.com/docs/core/architecture/kernel/gki-release-builds).
|
||||
|
||||
### Construir
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
O KernelSU pode ser integrado em kernels não GKI e foi portado para 4.14 e versões anteriores.
|
||||
|
||||
Devido à fragmentação de kernels não GKI, não temos uma maneira uniforme de construí-lo, portanto não podemos fornecer boot images não GKI. Mas você mesmo pode construir o kernel com o KernelSU integrado.
|
||||
Devido à fragmentação de kernels não GKI, não temos uma maneira uniforme de construí-lo, portanto não podemos fornecer imagens boot não GKI. Mas você mesmo pode construir o kernel com o KernelSU integrado.
|
||||
|
||||
Primeiro, você deve ser capaz de construir um kernel inicializável a partir do código-fonte do kernel. Se o kernel não for de código aberto, será difícil executar o KernelSU no seu dispositivo.
|
||||
|
||||
@@ -13,7 +13,7 @@ Se você puder construir um kernel inicializável, existem duas maneiras de inte
|
||||
|
||||
## 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 de kernel, se o kprobe funcionar bem em seu kernel, é recomendado usar desta forma.
|
||||
|
||||
Primeiro, adicione o KernelSU à árvore de origem do kernel:
|
||||
|
||||
@@ -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 o *kprobe* está ativado na configuração do seu kernel, se não estiver, adicione estas configurações a ele:
|
||||
Então, você deve verificar se o kprobe está ativado na configuração do seu kernel, se não estiver, adicione estas configurações a ele:
|
||||
|
||||
```
|
||||
CONFIG_KPROBES=y
|
||||
@@ -33,7 +33,7 @@ E construa seu kernel novamente, KernelSU deve funcionar bem.
|
||||
|
||||
Se você descobrir que o KPROBES ainda não está ativado, você pode tentar ativar `CONFIG_MODULES`. (Se ainda assim não surtir efeito, use `make menuconfig` para procurar outras dependências do KPROBES)
|
||||
|
||||
Mas se você encontrar em um bootloop quando o KernelSU for integrado, talvez o **kprobe esteja quebrado em seu kernel**, você deve corrigir o bug do kprobe ou usar o segundo caminho.
|
||||
Mas se você entrar em um bootloop quando o KernelSU for integrado, talvez o **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?
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
Baixe o app gerenciador KernelSU em [GitHub Releases](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 `Sem suporte`, significa que **você deve compilar o kernel sozinho**, o KernelSU não fornecerá e nunca fornecerá uma boot image para você atualizar.
|
||||
- Se o app mostrar `Sem suporte`, significa que **você deve compilar o kernel sozinho**, o KernelSU não fornecerá e nunca fornecerá uma boot image para você instalar.
|
||||
- Se o app mostrar `Não instalado`, então seu dispositivo é oficialmente suportado pelo KernelSU.
|
||||
|
||||
::: info INFORMAÇÕES
|
||||
@@ -37,7 +37,7 @@ Version.PatchLevel.SubLevel-AndroidRelease-KmiGeneration-suffix
|
||||
w .x .y -zzz -k -something
|
||||
```
|
||||
|
||||
`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.
|
||||
|
||||
::: tip DICA
|
||||
Observe que o SubLevel na versão do kernel não faz parte do KMI! Isso significa que `5.10.101-android12-9-g30979850fc20` tem o mesmo KMI que `5.10.137-android12-9-g30979850fc20`!
|
||||
@@ -60,7 +60,7 @@ Existem vários métodos de instalação do KernelSU, cada um adequado para um c
|
||||
|
||||
## Instalar com Recovery personalizado
|
||||
|
||||
Pré-requisito: Seu dispositivo deve ter um Recovery personalizado, como TWRP; se apenas o Recovery oficial estiver disponível, use outro método.
|
||||
Pré-requisito: Seu dispositivo deve ter um Recovery personalizado, como TWRP. Se apenas o Recovery oficial estiver disponível, use outro método.
|
||||
|
||||
Etapa:
|
||||
|
||||
@@ -72,7 +72,7 @@ PS. Este método é adequado para qualquer instalação (não limitado à instal
|
||||
|
||||
## Instalar com Kernel Flasher
|
||||
|
||||
Pré-requisito: Seu dispositivo deve estar rooteado. Por exemplo, você instalou o Magisk para obter root ou instalou uma versão antiga do KernelSU e precisa atualizar para outra versão do KernelSU; se o seu dispositivo não estiver rooteado, tente outros métodos.
|
||||
Pré-requisito: Seu dispositivo deve estar rooteado. Por exemplo, você instalou o Magisk para obter root ou instalou uma versão antiga do KernelSU e precisa atualizar para outra versão do KernelSU. Se o seu dispositivo não estiver rooteado, tente outros métodos.
|
||||
|
||||
Etapa:
|
||||
|
||||
@@ -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 [GitHub Release](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 `<format>` se refere ao formato de compactação do kernel do seu boot.img oficial, por favor, verifique o formato de compactação do kernel de 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, por favor, verifique o formato de compactação do kernel de 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.
|
||||
|
||||
::: 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.
|
||||
@@ -127,7 +127,7 @@ fastboot reboot
|
||||
|
||||
## Corrigir boot.img manualmente
|
||||
|
||||
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ê fleshar 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ê fleshar 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:
|
||||
|
||||
@@ -138,7 +138,7 @@ Entre eles, o Android-Image-Kitchen é adequado para operação no PC e o magisk
|
||||
|
||||
### Preparação
|
||||
|
||||
1. Obtenha o boot.img padrão do telefone; você pode obtê-lo com os fabricantes do seu dispositivo, você pode precisar 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, você pode precisar 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*).
|
||||
3. Descompacte o pacote AnyKernel3 e obtenha o arquivo `Image`, que é o arquivo do kernel do KernelSU.
|
||||
|
||||
@@ -152,13 +152,13 @@ Entre eles, o Android-Image-Kitchen é adequado para operação no PC e o magisk
|
||||
|
||||
### Usando o magiskboot
|
||||
|
||||
1. Baixe o Magisk mais recente em [GitHub Releases](https://github.com/topjohnwu/Magisk/releases)
|
||||
1. Baixe o Magisk mais recente em [GitHub Releases](https://github.com/topjohnwu/Magisk/releases).
|
||||
2. Renomeie o Magisk-*.apk para Magisk-vesion.zip e descompacte-o.
|
||||
3. Envie `Magisk-v25.2/lib/arm64-v8a/libmagiskboot.so` para o seu dispositivo por adb: `adb push Magisk-v25.2/lib/arm64-v8a/libmagiskboot.so /data/local/tmp/magiskboot`
|
||||
3. Envie `Magisk-v25.2/lib/arm64-v8a/libmagiskboot.so` para o seu dispositivo por adb: `adb push Magisk-v25.2/lib/arm64-v8a/libmagiskboot.so /data/local/tmp/magiskboot`.
|
||||
4. Envie o boot.img padrão e Image em AnyKernel3 para o seu dispositivo.
|
||||
5. Entre no diretório adb shell e cd `/data/local/tmp/` e, em seguida, `chmod +x magiskboot`
|
||||
5. Entre no diretório adb shell e cd `/data/local/tmp/` e, em seguida, `chmod +x magiskboot`.
|
||||
6. Entre no shell adb e no diretório cd `/data/local/tmp/`, execute `./magiskboot unpack boot.img` para descompactar `boot.img`, você obterá um arquivo `kernel`, este é o seu kernel padrão.
|
||||
7. Substitua `kernel` por `Image`: `mv -f Image kernel`
|
||||
7. Substitua `kernel` por `Image`: `mv -f Image kernel`.
|
||||
8. Execute `./magiskboot repack boot.img` para reembalar o boot.img, e você obterá um arquivo `new-boot.img`, faça o flash deste arquivo para o dispositivo por fastboot.
|
||||
|
||||
## Outros métodos
|
||||
|
||||
@@ -4,18 +4,18 @@ 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).
|
||||
|
||||
## Busybox
|
||||
## 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 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 ativado. 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 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:
|
||||
|
||||
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 subprocesso.
|
||||
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 KernelSU usam internamente), pois as variáveis de ambiente são herdadas para os subprocesso.
|
||||
|
||||
::: tip DIFERENÇA COM MAGISK
|
||||
|
||||
@@ -104,7 +104,7 @@ description=<string>
|
||||
|
||||
### Shell scripts
|
||||
|
||||
Por favor, leia a seção [Scripts de inicialização](#boot-scripts) 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`.
|
||||
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.
|
||||
|
||||
@@ -180,7 +180,7 @@ O módulo KernelSU **NÃO** é compatível para instalação no Recovery persona
|
||||
|
||||
### Personalização
|
||||
|
||||
Se você precisar personalizar o processo de instalação do módulo, opcionalmente você pode criar um script no instalador chamado `customize.sh`. Este script será **sourced** (não executado!) pelo script do instalador do módulo depois que todos os arquivos forem extraídos e as permissões padrão e o contexto secundário forem aplicados. Isso é muito útil se o seu módulo exigir configuração adicional com base na API do dispositivo ou se você precisar definir permissões/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 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.
|
||||
|
||||
@@ -189,16 +189,16 @@ O script `customize.sh` é executado no shell BusyBox `ash` do KernelSU com o "M
|
||||
#### 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_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
|
||||
- `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
|
||||
- `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 do Android) do dispositivo (por exemplo: `23` para Android 6.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.
|
||||
- `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.
|
||||
- `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 do Android) do dispositivo (por exemplo: `23` para Android 6.0).
|
||||
|
||||
::: warning 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.
|
||||
@@ -237,23 +237,23 @@ No KernelSU, os scripts são divididos em dois tipos com base em seu modo de exe
|
||||
- modo post-fs-data
|
||||
- Esta etapa está BLOQUEANDO. O processo de inicialização é pausado antes da execução ser concluída ou 10 segundos se passaram.
|
||||
- Os scripts são executados antes de qualquer módulo ser montado. Isso permite que um desenvolvedor de módulo ajuste dinamicamente seus módulos antes de serem montados.
|
||||
- Este estágio acontece antes do início do Zygote, o que significa praticamente tudo no Android
|
||||
- Este estágio acontece antes do início do Zygote, o que significa praticamente tudo no Android.
|
||||
- **AVISO:** Usar `setprop` irá bloquear o processo de inicialização! Por favor, use `resetprop -n <prop_name> <prop_value>` em vez disso.
|
||||
- **Execute scripts neste modo apenas se necessário.**
|
||||
- modo de serviço late_start
|
||||
- Esta etapa é SEM BLOQUEIO. Seu script é executado em paralelo com o restante do processo de inicialização.
|
||||
- **Este é o estágio recomendado para executar a maioria dos scripts.**
|
||||
- **Este é o estágio recomendado para executar a maioria dos scripts**.
|
||||
|
||||
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-completed.d`
|
||||
- Somente executado se o script estiver definido como executável (`chmod +x script.sh`)
|
||||
- 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
|
||||
- Os módulos **NÃO** devem adicionar scripts gerais durante a instalação.
|
||||
- Scripts de módulo
|
||||
- Colocado na própria pasta do módulo
|
||||
- Executado apenas se o módulo estiver ativado
|
||||
- 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.
|
||||
|
||||
Todos os scripts de inicialização serão executados no shell BusyBox `ash` do KernelSU com o "Modo Autônomo" ativado.
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# Resgate do bootloop
|
||||
|
||||
Ao atualizar um dispositivo, podemos encontrar situações em que o dispositivo fica "bloqueado". 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 "bloqueado". Em teoria, se você usar o fastboot apenas para atualizar a partição 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".
|
||||
|
||||
## Bloqueio por flashear partição boot
|
||||
## Bloqueio por fleshear partição boot
|
||||
|
||||
No KernelSU, as seguintes situações podem causar bloqueio de inicialização ao atualizar a partição boot:
|
||||
No KernelSU, as seguintes situações podem causar bloqueio de inicialização ao fleshear a partição boot:
|
||||
|
||||
1. Você atualizou uma imagem boot no formato errado. Por exemplo, se o formato de boot do seu telefone for `gz`, mas você atualizou uma imagem no formato `lz4`, o telefone não será capaz de inicializar.
|
||||
2. Seu telefone precisa desativar a verificação AVB para inicializar corretamente (geralmente exigindo a limpeza de todos os dados do telefone).
|
||||
@@ -14,11 +14,11 @@ Não importa qual seja a situação, você pode recuperar **fleshando a imagem d
|
||||
|
||||
## Bloqueio 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 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 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. O KernelSU possui mecanismos integrados para recuperar seu dispositivo, incluindo o seguinte:
|
||||
Se você instalou 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. Recupere pressionando o botão de diminuir volume
|
||||
@@ -27,16 +27,16 @@ Se você atualizou um módulo que foi comprovadamente seguro, mas faz com que se
|
||||
|
||||
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 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.
|
||||
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 instalar 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.
|
||||
|
||||
#### 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:
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user