mirror of
https://github.com/tiann/KernelSU.git
synced 2025-02-20 11:43:32 +08:00
fix website translations and improve grammar (#1004)
This commit is contained in:
igor
GitHub
parent
7d3c50ef0a
commit
1bdddb13ce
@ -14,19 +14,19 @@ Uma solução root baseada em kernel para dispositivos Android.
|
||||
|
||||
## Estado de Compatibilidade
|
||||
|
||||
O KernelSU suporta oficialmente dispositivos Android GKI 2.0 (com kernel 5.10+), kernels antigos (4.14+) também são compatíveis, mas você mesmo precisa construir o kernel.
|
||||
O KernelSU oferece suporte oficial a dispositivos Android GKI 2.0 (kernel 5.10+). Kernels mais antigos (4.14+) também são compatíveis, mas o kernel terá que ser construído manualmente.
|
||||
|
||||
WSA, ChromeOS e Android baseado em contêiner também deve funcionar com o KernelSU integrado.
|
||||
Com isso, WSA, ChromeOS e Android baseado em contêiner são todos suportados.
|
||||
|
||||
E as ABIs atualmente suportadas são: `arm64-v8a` e `x86_64`
|
||||
Atualmente, apenas `arm64-v8a` e `x86_64` são suportados.
|
||||
|
||||
## Uso
|
||||
- [Instrução de instalação](https://kernelsu.org/pt_BR/guide/installation.html)
|
||||
- [Como construir?](https://kernelsu.org/pt_BR/guide/how-to-build.html)
|
||||
- [Instalação](https://kernelsu.org/pt_BR/guide/installation.html)
|
||||
- [Como construir o KernelSU?](https://kernelsu.org/pt_BR/guide/how-to-build.html)
|
||||
- [Site oficial](https://kernelsu.org/pt_BR/)
|
||||
|
||||
## Tradução
|
||||
Para traduzir o KernelSU para o seu idioma ou melhorar uma tradução existente, use o [Weblate](https://hosted.weblate.org/engage/kernelsu/), por favor.
|
||||
Para ajudar a traduzir o KernelSU ou melhorar as traduções existentes, use o [Weblate](https://hosted.weblate.org/engage/kernelsu/), por favor.
|
||||
|
||||
## Discussão
|
||||
|
||||
@ -41,6 +41,6 @@ Para traduzir o KernelSU para o seu idioma ou melhorar uma tradução existente,
|
||||
## Créditos
|
||||
|
||||
- [kernel-assisted-superuser](https://git.zx2c4.com/kernel-assisted-superuser/about/): a ideia do KernelSU.
|
||||
- [Magisk](https://github.com/topjohnwu/Magisk): a poderosa ferramenta raiz.
|
||||
- [Magisk](https://github.com/topjohnwu/Magisk): a poderosa ferramenta root.
|
||||
- [genuine](https://github.com/brevent/genuine/): validação de assinatura apk v2.
|
||||
- [Diamorphine](https://github.com/m0nad/Diamorphine): algumas habilidades de rootkit.
|
||||
|
||||
@ -34,7 +34,7 @@ Aqui, o UID é `2000` e o GID (ID do grupo primário) também é `2000`. Além d
|
||||
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.
|
||||
|
||||
:::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 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.
|
||||
@ -43,13 +43,13 @@ O Perfil Raiz é aplicado no kernel e não depende do comportamento voluntário
|
||||
|
||||
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 habilitadas e desabilitadas de forma independente.
|
||||
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 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.
|
||||
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.
|
||||
|
||||
:::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.
|
||||
@ -71,12 +71,12 @@ Os sistemas Android modernos dependem fortemente do SELinux para garantir a segu
|
||||
Explicar o conceito completo do SELinux é complexo e está além do objetivo deste documento. Recomenda-se primeiro entender seu funcionamento através dos seguintes recursos:
|
||||
|
||||
1. [Wikipédia](https://en.wikipedia.org/wiki/Security-Enhanced_Linux)
|
||||
2. [Red Hat: O que é SELinux?](https://www.redhat.com/en/topics/linux/what-is-selinux)
|
||||
2. [Red Hat: O que é SELinux?](https://www.redhat.com/pt-br/topics/linux/what-is-selinux)
|
||||
3. [ArchLinux: SELinux](https://wiki.archlinux.org/title/SELinux)
|
||||
|
||||
O Perfil Raiz do KernelSU permite a personalização do contexto SELinux do processo root após a execução de `su`. Regras específicas de controle de acesso podem ser definidas para este contexto para permitir um controle refinado sobre as permissões de root.
|
||||
O Perfil Root do KernelSU permite a personalização do contexto SELinux do processo root após a execução de `su`. Regras específicas de controle de acesso podem ser definidas para este contexto para permitir um controle refinado sobre as permissões de root.
|
||||
|
||||
Em cenários típicos, quando um app executa `su`, ele alterna o processo para um domínio SELinux com **acesso irrestrito**, como `u:r:su:s0`. Através do Perfil Raiz, este domínio pode ser mudado para um domínio personalizado, como `u:r:app1:s0`, e uma série de regras podem ser definidas para este domínio:
|
||||
Em cenários típicos, quando um app executa `su`, ele alterna o processo para um domínio SELinux com **acesso irrestrito**, como `u:r:su:s0`. Através do Perfil Root, este domínio pode ser mudado para um domínio personalizado, como `u:r:app1:s0`, e uma série de regras podem ser definidas para este domínio:
|
||||
|
||||
```sh
|
||||
type app1
|
||||
@ -89,20 +89,20 @@ Observe que a regra `allow app1 * * *` é usada apenas para fins de demonstraç
|
||||
|
||||
### Escalação
|
||||
|
||||
Se a configuração do Perfil Raiz não estiver definida corretamente, poderá ocorrer um cenário de escalonamento: as restrições impostas pelo Perfil Raiz poderão falhar involuntariamente.
|
||||
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.
|
||||
|
||||
Por exemplo, se você conceder permissão root a um usuário shell ADB (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égios de root completos.
|
||||
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.
|
||||
|
||||
:::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 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` (sistema) seria uma melhor escolha.
|
||||
:::
|
||||
|
||||
## Perfil não Raiz
|
||||
## Perfil não Root
|
||||
|
||||
### Desmontar Módulos
|
||||
|
||||
|
||||
@ -6,7 +6,7 @@ Embora existam muitas semelhanças entre os módulos KernelSU e os módulos Magi
|
||||
|
||||
- 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
|
||||
- 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
|
||||
@ -23,6 +23,6 @@ Aqui estão algumas diferenças:
|
||||
- Os módulos KernelSU não têm suporte integrado para Zygisk (mas você pode usar módulos Zygisk através do [ZygiskOnKernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU).
|
||||
- O método para substituir ou excluir arquivos nos módulos KernelSU é completamente diferente do Magisk. O KernelSU não suporta o método `.replace`. Em vez disso, você precisa criar um arquivo com o mesmo nome `mknod filename c 0 0` para excluir o arquivo correspondente.
|
||||
- Os diretórios do BusyBox são diferentes. O BusyBox integrado no KernelSU está localizado em `/data/adb/ksu/bin/busybox`, enquanto no Magisk está em `/data/adb/magisk/busybox`. **Observe que este é um comportamento interno do KernelSU e pode mudar no futuro!**
|
||||
- KernelSU não suporta arquivos `.replace`; entretanto, KernelSU suporta as variáveis `REMOVE` e `REPLACE` para remover ou substituir arquivos e pastas.
|
||||
- KernelSU adiciona o estágio `boot-completed` para executar alguns scripts na inicialização concluída.
|
||||
- KernelSU adiciona o estágio `post-mount` para executar alguns scripts após montar overlayfs.
|
||||
- O KernelSU não suporta arquivos `.replace`, entretanto, o KernelSU suporta as variáveis `REMOVE` e `REPLACE` para remover ou substituir arquivos e pastas.
|
||||
- O KernelSU adiciona o estágio `boot-completed` para executar alguns scripts na inicialização concluída.
|
||||
- O KernelSU adiciona o estágio `post-mount` para executar alguns scripts após montar overlayfs.
|
||||
|
||||
@ -6,44 +6,44 @@ Primeiro, seus dispositivos devem ser capazes de desbloquear o bootloader. Se n
|
||||
|
||||
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?
|
||||
## KernelSU precisa desbloquear o Bootloader?
|
||||
|
||||
Certamente, sim
|
||||
|
||||
## O KernelSU suporta módulos?
|
||||
## 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. 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 [Zygisk on KernelSU](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?
|
||||
|
||||
KernelSU não tem suporte integrado ao Zygisk, mas você pode usar [Zygisk on KernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU).
|
||||
KernelSU não tem suporte integrado ao Zygisk, mas você pode usar [ZygiskOnKernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU).
|
||||
|
||||
## O KernelSU é compatível com Magisk?
|
||||
## KernelSU é compatível com Magisk?
|
||||
|
||||
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.
|
||||
|
||||
## O KernelSU substituirá o Magisk?
|
||||
## 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.
|
||||
|
||||
## O KernelSU pode oferecer suporte a dispositivos não GKI?
|
||||
## 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.
|
||||
|
||||
## O KernelSU pode oferecer suporte a dispositivos abaixo do Android 12?
|
||||
## 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)
|
||||
|
||||
## O KernelSU pode suportar kernel antigo?
|
||||
## KernelSU pode suportar kernel antigo?
|
||||
|
||||
É possível, o KernelSU é portado para o kernel 4.14 agora, para o kernel mais antigo, você precisa fazer o backport manualmente e PRs são bem-vindos!
|
||||
|
||||
|
||||
@ -2,14 +2,14 @@
|
||||
|
||||
Primeiro, você deve ler a documentação oficial do Android para construção do kernel:
|
||||
|
||||
1. [Construindo Kernels](https://source.android.com/docs/setup/build/building-kernels)
|
||||
2. [Versões de lançamento do GKI](https://source.android.com/docs/core/architecture/kernel/gki-release-builds)
|
||||
1. [Como criar kernels](https://source.android.com/docs/setup/build/building-kernels)
|
||||
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)
|
||||
:::
|
||||
|
||||
## Construir Kernel
|
||||
## Construir o kernel
|
||||
|
||||
### Sincronize o código-fonte do kernel
|
||||
|
||||
@ -24,15 +24,15 @@ O `<kernel_manifest.xml>` é um arquivo de manifesto que pode determinar uma con
|
||||
|
||||
### Construir
|
||||
|
||||
Por favor, verifique os [documentos oficiais](https://source.android.com/docs/setup/build/building-kernels) primeiro.
|
||||
Por favor, verifique [Como criar kernels](https://source.android.com/docs/setup/build/building-kernels) primeiro.
|
||||
|
||||
Por exemplo, precisamos construir a imagem do kernel aarch64:
|
||||
Por exemplo, precisamos construir a imagem do kernel `aarch64`:
|
||||
|
||||
```sh
|
||||
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 24GB.
|
||||
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.
|
||||
|
||||
A partir do Android 13, o kernel é construído pelo `bazel`:
|
||||
|
||||
@ -40,7 +40,7 @@ A partir do Android 13, o kernel é construído pelo `bazel`:
|
||||
tools/bazel build --config=fast //common:kernel_aarch64_dist
|
||||
```
|
||||
|
||||
## Construa Kernel com KernelSU
|
||||
## Construir o kernel com KernelSU
|
||||
|
||||
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:
|
||||
|
||||
@ -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!
|
||||
|
||||
@ -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 imagens de inicialização 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 boot images 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.
|
||||
|
||||
@ -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á 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 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.
|
||||
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.
|
||||
|
||||
:::tip COMO VERIFICAR SE O KPROBE ESTÁ QUEBRADO?
|
||||
|
||||
@ -60,7 +60,6 @@ curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh
|
||||
|
||||
- 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
|
||||
```
|
||||
|
||||
@ -11,12 +11,12 @@ Baixe o app gerenciador KernelSU em [GitHub Releases](https://github.com/tiann/K
|
||||
Para dispositivos mostrando `Sem suporte`, aqui está os [Dispositivos com suporte não oficial](unofficially-support-devices.md), você mesmo pode compilar o kernel.
|
||||
:::
|
||||
|
||||
## Backup padrão boot.img
|
||||
## Backup padrão do boot.img
|
||||
|
||||
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.
|
||||
Antes de fleshar, 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.
|
||||
|
||||
::: warning AVISO
|
||||
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.
|
||||
Fleshar 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
|
||||
@ -27,7 +27,7 @@ Por padrão, você usará as ferramentas ADB e fastboot neste tutorial, portanto
|
||||
|
||||
### KMI
|
||||
|
||||
Kernel Module Interface (KMI), versões de kernel com o mesmo KMI são **compatíveis** Isso é o que "geral" significa no GKI; por outro lado, se o KMI for diferente, então esses kernels não são compatíveis entre si, e atualizar uma imagem do kernel com um KMI diferente do seu dispositivo pode causar um bootloop.
|
||||
Kernel Module Interface (KMI), versões de kernel com o mesmo KMI são **compatíveis**, isso é o que "geral" significa no GKI; por outro lado, se o KMI for diferente, então esses kernels não são compatíveis entre si, e atualizar uma imagem do kernel com um KMI diferente do seu dispositivo pode causar um bootloop.
|
||||
|
||||
Especificamente, para dispositivos GKI, o formato da versão do kernel deve ser o seguinte:
|
||||
|
||||
@ -47,7 +47,7 @@ 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, **por favor, 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 fazer o flash, **por favor, consulte sempre a versão do kernel!**
|
||||
|
||||
## Introdução
|
||||
|
||||
@ -55,12 +55,12 @@ Existem vários métodos de instalação do KernelSU, cada um adequado para um c
|
||||
|
||||
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
|
||||
3. Instalar com fastboot usando o boot.img fornecido por KernelSU
|
||||
4. Repare o boot.img manualmente e instale-o
|
||||
|
||||
## Instalar com Recovery personalizado
|
||||
|
||||
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.
|
||||
Pré-requisito: Seu dispositivo deve ter um Recovery personalizado, como TWRP; se apenas o Recovery oficial estiver disponível, use outro método.
|
||||
|
||||
Etapa:
|
||||
|
||||
@ -76,7 +76,7 @@ Pré-requisito: Seu dispositivo deve estar rooteado. Por exemplo, você instalou
|
||||
|
||||
Etapa:
|
||||
|
||||
1. Baixe o zip AnyKernel3; consulte a seção *Instalando com Recovery Personalizado* para obter instruções de download.
|
||||
1. Baixe o zip AnyKernel3; consulte a seção *Instalar com Recovery personalizado* para obter instruções de download.
|
||||
2. Abra o app Kernel Flash e use o zip AnyKernel3 fornecido para fazer o flash.
|
||||
|
||||
Se você nunca usou algum app kernel flash antes, os seguintes são os mais populares.
|
||||
@ -87,21 +87,21 @@ Se você nunca usou algum app kernel flash antes, os seguintes são os mais popu
|
||||
|
||||
PS. Este método é mais conveniente ao atualizar o KernelSU e pode ser feito sem um computador (backup primeiro).
|
||||
|
||||
## Instale com boot.img fornecido por KernelSU
|
||||
## Instalar com o boot.img fornecido por KernelSU
|
||||
|
||||
Este método não requer que você tenha TWRP, nem que seu telefone tenha privilégios de root; é adequado para sua primeira instalação do KernelSU.
|
||||
|
||||
### Encontre o boot.img adequado
|
||||
|
||||
O KernelSU fornece um boot.img genérico para dispositivos GKI e você deve liberar o boot.img para a partição de inicialização do dispositivo.
|
||||
O KernelSU fornece um boot.img genérico para dispositivos GKI e você deve liberar o boot.img para a partição boot do dispositivo.
|
||||
|
||||
Você pode baixar o boot.img em [GitHub Release](https://github.com/tiann/KernelSU/releases), por favor, observe que você deve usar a versão correta do boot.img. 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 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, 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 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.
|
||||
2. Os dispositivos Xiaomi geralmente usam `gz` ou **uncompressed**.
|
||||
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.
|
||||
2. Os dispositivos Xiaomi geralmente usam `gz` ou `uncompressed`.
|
||||
3. Para dispositivos Pixel, siga as instruções abaixo.
|
||||
:::
|
||||
|
||||
@ -114,7 +114,7 @@ fastboot flash boot boot.img
|
||||
```
|
||||
|
||||
::: info INFORMAÇÕES
|
||||
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.
|
||||
Se o seu dispositivo suportar `fastboot boot`, você pode usar primeiro `fastboot boot boot.img` para tentar usar o boot.img para inicializar o sistema primeiro. Se algo inesperado acontecer, reinicie-o novamente para inicializar.
|
||||
:::
|
||||
|
||||
### Reiniciar
|
||||
@ -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ê 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ê 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,32 +138,32 @@ Entre eles, o Android-Image-Kitchen é adequado para operação no PC e o magisk
|
||||
|
||||
### Preparação
|
||||
|
||||
1. Obtenha o stock boot.img 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.
|
||||
|
||||
### Usando Android-Image-Kitchen
|
||||
### Usando o Android-Image-Kitchen
|
||||
|
||||
1. Baixe o Android-Image-Kitchen para o seu computador.
|
||||
2. Coloque o stock boot.img na pasta raiz do Android-Image-Kitchen.
|
||||
2. Coloque o boot.img padrão na pasta raiz do Android-Image-Kitchen.
|
||||
3. Execute `./unpackimg.sh boot.img` no diretório raiz do Android-Image-Kitchen, este comando descompactará o boot.img e você obterá alguns arquivos.
|
||||
4. Substitua `boot.img-kernel` no diretório `split_img` pela `Image` que você extraiu do AnyKernel3 (observe a mudança de nome para boot.img-kernel).
|
||||
5. Execute `./repackimg.sh` no diretório raiz de 在 Android-Image-Kitchen; E você obterá um arquivo chamado `image-new.img`; Atualize este boot.img por fastboot (consulte a seção anterior).
|
||||
5. Execute `./repackimg.sh` no diretório raiz de 在 Android-Image-Kitchen, e você obterá um arquivo chamado `image-new.img`. Faça o flash deste boot.img por fastboot (consulte a seção anterior).
|
||||
|
||||
### Usando magiskboot
|
||||
### Usando o magiskboot
|
||||
|
||||
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`
|
||||
4. Envie stock boot.img e Image em AnyKernel3 para o seu dispositivo.
|
||||
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`
|
||||
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`
|
||||
8. Execute `./magiskboot repack boot.img` para reembalar o boot img, e você obterá um arquivo `new-boot.img`, atualize este arquivo para o dispositivo por fastboot.
|
||||
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
|
||||
|
||||
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.
|
||||
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 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.
|
||||
1. Primeiro instale o Magisk, obtenha privilégios de root através do Magisk e então use o kernel flasher para fazer o flash no zip AnyKernel do KernelSU.
|
||||
2. Use algum kit de ferramentas de flash em PCs para fleshar no kernel fornecido pelo KernelSU.
|
||||
|
||||
@ -1,21 +1,21 @@
|
||||
# Guias de módulo
|
||||
|
||||
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 KernelSU fornece um mecanismo de módulo que consegue modificar o diretório do sistema enquanto mantém a integridade da partição do sistema. Este mecanismo é conhecido como "sem sistema".
|
||||
|
||||
O mecanismo de módulo do KernelSU é quase o mesmo do Magisk. Se você está familiarizado com o desenvolvimento de módulos Magisk, o desenvolvimento de módulos KernelSU é muito semelhante. Você pode pular a introdução dos módulos abaixo e só precisa ler [Diferença com Magisk](difference-with-magisk.md).
|
||||
|
||||
## 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 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 “Modo Autônomo” fora do KernelSU, existem 2 maneiras de ativá-los:
|
||||
Para aqueles que desejam usar o recurso “Modo Autônomo” fora do KernelSU, existem 2 maneiras de ativá-los:
|
||||
|
||||
1. Defina a variável de ambiente `ASH_STANDALONE` como `1`<br>Exemplo: `ASH_STANDALONE=1 /data/adb/ksu/bin/busybox sh <script>`
|
||||
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 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
|
||||
|
||||
@ -84,7 +84,7 @@ O KernelSU não possui suporte integrado para o Zygisk, portanto não há conte
|
||||
|
||||
### module.prop
|
||||
|
||||
module.prop é um arquivo de configuração para um módulo. No KernelSU, se um módulo não contiver este arquivo, ele não será reconhecido como um módulo. O formato deste arquivo é o seguinte:
|
||||
`module.prop` é um arquivo de configuração para um módulo. No KernelSU, se um módulo não contiver este arquivo, ele não será reconhecido como um módulo. O formato deste arquivo é o seguinte:
|
||||
|
||||
```txt
|
||||
id=<string>
|
||||
@ -96,7 +96,7 @@ description=<string>
|
||||
```
|
||||
|
||||
- `id` deve corresponder a esta expressão regular: `^[a-zA-Z][a-zA-Z0-9._-]+$`<br>
|
||||
ex: ✓ `a_module`, ✓ `a.module`, ✓ `module-101`, ✗ `a module`, ✗ `1_module`, ✗ `-a-module`<br>
|
||||
Exemplo: ✓ `a_module`, ✓ `a.module`, ✓ `module-101`, ✗ `a module`, ✗ `1_module`, ✗ `-a-module`<br>
|
||||
Este é o **identificador exclusivo** do seu módulo. Você não deve alterá-lo depois de publicado.
|
||||
- `versionCode` deve ser um **inteiro**. Isso é usado para comparar versões
|
||||
- Outros que não foram mencionados acima podem ser qualquer string de **linha única**.
|
||||
@ -106,7 +106,7 @@ description=<string>
|
||||
|
||||
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`.
|
||||
|
||||
Em todos os scripts do seu módulo, use `MODDIR=${0%/*}` para obter o caminho do diretório base do seu módulo; **NÃO** codifique o caminho do seu módulo em scripts.
|
||||
Em todos os scripts do seu módulo, use `MODDIR=${0%/*}` para obter o caminho do diretório base do seu módulo, **NÃO** codifique o caminho do seu módulo 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 no KernelSU, esse valor será definido como `true`.
|
||||
@ -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 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 API 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.
|
||||
|
||||
@ -254,6 +254,6 @@ No KernelSU, os scripts de inicialização são divididos em dois tipos com base
|
||||
- Scripts de módulo
|
||||
- Colocado na própria pasta do módulo
|
||||
- Executado apenas se o módulo estiver ativado
|
||||
- `post-fs-data.sh` é executado no modo post-fs-data, `service.sh` é executado no modo de serviço late_start, `boot-completed.sh` é executado na inicialização concluída, `post-mount.sh` é executado em overlayfs montado.
|
||||
- `post-fs-data.sh` é executado no modo post-fs-data, `service.sh` é executado no modo de serviço late_start, `boot-completed.sh` é executado na inicialização concluída e `post-mount.sh` é executado 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 "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".
|
||||
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".
|
||||
|
||||
## Brick por flashear partição boot
|
||||
## Bloqueio por flashear partição boot
|
||||
|
||||
No KernelSU, as seguintes situações podem causar bloqueio de inicialização ao atualizar a partição boot:
|
||||
|
||||
@ -10,11 +10,11 @@ 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 **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.
|
||||
Não importa qual seja a situação, você pode recuperar **fleshando 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 fleshar. 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.
|
||||
|
||||
## Brick por módulos
|
||||
## Bloqueio por módulos
|
||||
|
||||
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!
|
||||
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!
|
||||
|
||||
### Módulos normais
|
||||
|
||||
@ -31,14 +31,14 @@ Portanto, o método mais simples e comumente usado para recuperar seu dispositiv
|
||||
|
||||
#### 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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
|
||||
@ -19,10 +19,10 @@ hero:
|
||||
|
||||
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.
|
||||
- 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 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.
|
||||
details: Como o nome sugere, KernelSU funciona no kernel Linux, dando-lhe mais controle sobre os apps do espaço do usuário.
|
||||
- title: Controle de acesso root
|
||||
details: Somente apps permitidos podem acessar ou ver su, todos os outros apps não estão cientes disso.
|
||||
- title: Privilégios de root personalizáveis
|
||||
details: KernelSU permite a personalização de uid, gid, grupos, capacidades e regras SELinux do su, bloqueando privilégios de root.
|
||||
- title: Módulo
|
||||
details: Os módulos podem modificar /system sem sistema usando overlayfs permitindo grande potência.
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user