website: enhanced english/portuguese translation (#2427)
Enhanced english/portuguese translation for better fluency, grammar, clarity, and text accuracy.
This commit is contained in:
igor
GitHub
@@ -10,13 +10,13 @@ Para apps comuns sem privilégios root, o Perfil do Aplicativo pode controlar o
|
||||
|
||||
### 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 sistemas Linux possuem dois conceitos: usuários e grupos. Cada usuário possui um ID de usuário (UID) e 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 root. 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 grupos com GID 0 são chamados de grupos root. O grupo de usuários root geralmente tem os privilégios mais altos no sistema.
|
||||
|
||||
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 `10000` a `19999` representam apps comuns.
|
||||
No caso do sistema Android, cada app funciona como um usuário separado (exceto em casos de UID compartilhado) e recebe um UID exclusivo. Por exemplo, `0` representa o usuário root, `1000` representa `system`, `2000` ao ADB shell e os UIDs de `10000` a `19999` são atribuídos a apps comuns.
|
||||
|
||||
:::info INFORMAÇÕES
|
||||
::: info INFORMAÇÕES
|
||||
Aqui, o UID mencionado não é o mesmo que o conceito de múltiplos usuários ou perfis de trabalho no sistema Android. Os perfis de trabalho são, na verdade, implementados particionando o intervalo UID. Por exemplo, 10000-19999 representa o usuário principal, enquanto 110000-119999 representa um perfil de trabalho. Cada app comum entre eles possui seu próprio UID exclusivo.
|
||||
:::
|
||||
|
||||
@@ -31,10 +31,10 @@ 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 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.
|
||||
O Perfil root do KernelSU permite personalizar o 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`, o que significa que, ao usar `su`, as permissões reais do app estão no nível do ADB shell. Além disso, o grupo `inet` pode ser removido, evitando que o comando `su` tenha acesso à 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.
|
||||
::: tip OBSERVAÇÃO
|
||||
O Perfil do Aplicativo controla apenas as permissões do processo root após usar `su` e não afeta as permissões do próprio app. Se um app solicitou permissão para acessar a 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 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.
|
||||
@@ -47,11 +47,11 @@ Para realizar verificações de permissão, as implementações tradicionais do
|
||||
|
||||
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.
|
||||
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 a capacidade `CAP_DAC_READ_SEARCH` ou superiores, isso significa que mesmo sendo root, ele não pode ler arquivos à vontade.
|
||||
|
||||
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 "privilégios 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`, concedendo assim "privilégios root" de forma parcial. 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 as operações que ele pode realizar.
|
||||
|
||||
:::tip FORTE RECOMENDAÇÃO
|
||||
::: tip FORTE RECOMENDAÇÃO
|
||||
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 as capacidade, é altamente recomendável que você leia este documento primeiro.
|
||||
:::
|
||||
|
||||
@@ -64,8 +64,8 @@ O SELinux pode ser executado em dois modos globais:
|
||||
1. Modo permissivo: Os eventos de negação são registrados, mas não aplicados.
|
||||
2. Modo de aplicação: Os eventos de negação são registrados e aplicados.
|
||||
|
||||
:::warning AVISO
|
||||
Os sistemas Android modernos dependem fortemente do SELinux para garantir a segurança geral do sistema. É altamente recomendável não usar nenhum sistema personalizado executado em "Modo permissivo", pois não oferece vantagens significativas em relação a um sistema completamente aberto.
|
||||
::: warning AVISO
|
||||
Os sistemas Android modernos dependem fortemente do SELinux para garantir a segurança geral do sistema. É altamente recomendável não usar nenhum sistema personalizado executado em "Modo permissivo", pois ele não oferece vantagens significativas em relação a um sistema completamente aberto.
|
||||
:::
|
||||
|
||||
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:
|
||||
@@ -74,9 +74,9 @@ Explicar o conceito completo do SELinux é complexo e está além do objetivo de
|
||||
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 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 os privilégios 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, possibilitando um controle refinado sobre os privilégios 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 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:
|
||||
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, esse 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 esse domínio:
|
||||
|
||||
```sh
|
||||
type app1
|
||||
@@ -91,12 +91,12 @@ Observe que a regra `allow app1 * * *` é usada apenas para fins de demonstraç
|
||||
|
||||
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 o UID 2000 (o UID do usuário ADB shell), o app pode obter acesso root completo ao executar 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 root completo.
|
||||
1. A primeira execução de `su` será sujeita ao Perfil do Aplicativo, e mudará para o UID `2000` (ADB shell) em vez de `0` (root).
|
||||
2. A segunda execução de `su`, como o UID é `2000` e você concedeu acesso root ao UID `2000` (ADB shell) na configuração, o app obterá privilégios root completo.
|
||||
|
||||
:::warning OBSERVAÇÃO
|
||||
::: warning OBSERVAÇÃO
|
||||
Este comportamento é totalmente esperado e não é um bug. Portanto, recomendamos o seguinte:
|
||||
|
||||
Se você realmente precisa conceder privilégios 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.
|
||||
@@ -106,13 +106,13 @@ Se você realmente precisa conceder privilégios root ao ADB (por exemplo, como
|
||||
|
||||
### 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ódulos".
|
||||
O KernelSU fornece um mecanismo sem sistema para modificar partições do sistema, obtido através da montagem do OverlayFS. No entanto, alguns apps podem ser sensíveis a esse comportamento. Nesse caso, podemos descarregar módulos montados nesses apps configurando a opção "Desmontar módulos".
|
||||
|
||||
Além disso, a interface de configurações do gerenciador do 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:
|
||||
Além disso, a interface de configurações do gerenciador do KernelSU oferece a opção "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:
|
||||
|
||||
1. Mantenha a opção "Desmontar módulos por padrão" e desative individualmente a opção "Desmontar módulos" no Perfil do Aplicativo para apps que exigem carregamento do módulo (agindo como uma "lista de permissões").
|
||||
2. Desative a opção "Desmontar módulos por padrão" e ative individualmente a opção "Desmontar módulos" no Perfil do Aplicativo para apps que exigem descarregamento do módulo (agindo como uma "lista negra").
|
||||
1. Manter a opção "Desmontar módulos por padrão" ativada e desative individualmente a opção "Desmontar módulos" no Perfil do Aplicativo para apps que exigem o carregamento do módulo (agindo como uma "lista de permissões").
|
||||
2. Desativar a opção "Desmontar módulos por padrão" e ativar individualmente a opção "Desmontar módulos" no Perfil do Aplicativo para apps que exigem o descarregamento do módulo (agindo como uma "lista negra").
|
||||
|
||||
:::info INFORMAÇÕES
|
||||
Em dispositivos que utilizam a versão do kernel 5.10 e superior, o kernel realiza qualquer ação adicional do descarregamento de módulos. No entanto, para dispositivos que executam versões do kernel abaixo de 5.10, essa opção é apenas uma opção de configuração e o próprio KernelSU não executa nenhuma ação. Se você quiser usar a opção "Desmontar módulos" em versões do kernel anteriores a 5.10 você precisa portar a função `path_umount` em `fs/namespace.c`, você pode obter mais informações no final da página [Como integrar o KernelSU para kernels não GKI](https://kernelsu.org/pt_BR/guide/how-to-integrate-for-non-gki.html). Alguns módulos, como ZygiskNext, também podem usar essa opção para determinar se o descarregamento do módulo é necessário.
|
||||
::: info INFORMAÇÕES
|
||||
Em dispositivos que utilizam a versão do kernel 5.10 ou superior, o kernel realiza qualquer ação adicional do descarregamento de módulos. No entanto, para dispositivos que executam versões do kernel abaixo de 5.10, essa opção é apenas uma opção de configuração e o próprio KernelSU não executa nenhuma ação. Se você quiser usar a opção "Desmontar módulos" em versões do kernel anteriores a 5.10, é necessário portar a função `path_umount` em `fs/namespace.c`. Você pode obter mais informações no final da página [Integração para dispositivos não-GKI](https://kernelsu.org/pt_BR/guide/how-to-integrate-for-non-gki.html). Alguns módulos, como ZygiskNext, também podem usar essa opção para determinar se o descarregamento do módulo é necessário.
|
||||
:::
|
||||
|
||||
@@ -1,28 +1,28 @@
|
||||
# Diferenças com Magisk
|
||||
|
||||
Embora existam muitas semelhanças entre os módulos KernelSU e os módulos Magisk, existem inevitavelmente algumas diferenças devido aos seus mecanismos de implementação completamente diferentes. Se você deseja que seu módulo seja executado no Magisk e no KernelSU, você deve entender essas diferenças.
|
||||
Embora os módulos do KernelSU e do Magisk tenham muitas semelhanças, existem inevitavelmente algumas diferenças devido aos seus mecanismos de implementação completamente diferentes. Se você deseja que seu módulo funcione tanto no Magisk quanto no KernelSU, é essencial compreender essas diferenças.
|
||||
|
||||
## 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 é praticamente o mesmo.
|
||||
- Diretório de instalação do módulo: Ambos estão localizados em `/data/adb/modules`.
|
||||
- Sem sistema: Ambos suportam a modificação de `/system` de forma 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
|
||||
|
||||
Antes de entender as diferenças, você precisa saber diferenciar se o seu módulo está rodando no KernelSU ou Magisk. Você pode usar a variável de ambiente `KSU` para diferenciá-la em todos os locais onde você pode executar os scripts do módulo (`customize.sh`, `post-fs-data.sh`, `service.sh`). No KernelSU, esta variável de ambiente será definida como `true`.
|
||||
Antes de entender as diferenças, é importante saber como identificar se o seu módulo está sendo executado no KernelSU ou no Magisk. Você pode usar a variável de ambiente `KSU` para diferenciá-lo em todos os locais onde você pode executar os scripts do módulo (`customize.sh`, `post-fs-data.sh`, `service.sh`). No KernelSU, essa variável de ambiente será definida como `true`.
|
||||
|
||||
Aqui estão algumas diferenças:
|
||||
|
||||
- Os módulos KernelSU não podem ser instalados no modo Recovery.
|
||||
- Os módulos KernelSU não têm suporte integrado para Zygisk (mas você pode usar módulos Zygisk através do [ZygiskNext](https://github.com/Dr-TSNG/ZygiskNext).
|
||||
- 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 módulos KernelSU não oferece suporte nativo ao Zygisk, mas você pode usar módulos Zygisk através do [ZygiskNext](https://github.com/Dr-TSNG/ZygiskNext).
|
||||
- O método para substituir ou excluir arquivos nos módulos do KernelSU é completamente diferente do Magisk. O KernelSU não suporta o método `.replace`. Em vez disso, você deve criar um arquivo com o comando `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!**
|
||||
- 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.
|
||||
- O KernelSU não suporta arquivos `.replace`, mas oferece suporte às variáveis `REMOVE` e `REPLACE` para remover ou substituir arquivos e pastas.
|
||||
- O KernelSU adiciona o estágio `boot-completed` para executar scripts após a inicialização ser concluída.
|
||||
- O KernelSU adiciona o estágio `post-mount` para executar scripts após o OverlayFS ser montado.
|
||||
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
Primeiro, seu dispositivo deve ser capaz de desbloquear o bootloader. Se não, então não há suporte.
|
||||
|
||||
Em seguida, instale o gerenciador do KernelSU em seu dispositivo e abra-o, se mostrar `Sem suporte` então seu dispositivo não pode ser suportado imediatamente, mas você pode compilar a fonte do kernel e integrar o KernelSU para fazê-lo funcionar ou usar [Dispositivos com suporte não oficial](unofficially-support-devices).
|
||||
Em seguida, instale o gerenciador do KernelSU no seu dispositivo e abra-o. Se aparecer `Sem suporte` então seu dispositivo não pode ser suportado imediatamente. No entanto, você pode compilar a fonte do kernel e integrar o KernelSU para fazê-lo funcionar ou usar [Dispositivos com suporte não oficial](unofficially-support-devices).
|
||||
|
||||
## Para usar o KernelSU precisa desbloquear o bootloader?
|
||||
|
||||
@@ -24,15 +24,15 @@ KernelSU não tem suporte integrado ao Zygisk, mas você pode usar [ZygiskNext](
|
||||
|
||||
## KernelSU é compatível com o Magisk?
|
||||
|
||||
O sistema de módulos do KernelSU está em conflito com a montagem mágica do Magisk, se houver algum módulo ativado no KernelSU, então todo o Magisk não funcionaria.
|
||||
O sistema de módulos do KernelSU está em conflito com a montagem mágica do Magisk. Se houver algum módulo ativado no KernelSU, todo o Magisk deixará de funcionar.
|
||||
|
||||
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.
|
||||
No entanto, se você usar apenas o `su` do KernelSU, ele funcionará bem com o Magisk. O KernelSU modifica o `kernel`, enquanto o Magisk modifica o `ramdisk`, permitindo que ambos trabalhem juntos.
|
||||
|
||||
## KernelSU substituirá 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.
|
||||
Acreditamos 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 oferece suporte a dispositivos não GKI?
|
||||
## KernelSU oferece suporte a dispositivos não-GKI?
|
||||
|
||||
É 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.
|
||||
|
||||
@@ -45,15 +45,15 @@ Achamos que não e esse não é o nosso objetivo. O Magisk é bom o suficiente p
|
||||
|
||||
## KernelSU suporta kernel antigo?
|
||||
|
||||
É possível, o KernelSU é portado para o kernel 4.14 agora, para o kernel mais antigo, você precisa portar manualmente e PRs são sempre bem-vindas!
|
||||
É possível, o KernelSU é portado para o kernel 4.14 agora. Para kernels mais antigo, você precisa portar manualmente e PRs são sempre bem-vindas!
|
||||
|
||||
## Como integrar o KernelSU para um kernel antigo?
|
||||
|
||||
Por favor, consulte a guia [Como integrar o KernelSU para kernels não GKI](how-to-integrate-for-non-gki).
|
||||
Por favor, verifique o guia [Integração para dispositivos não-GKI](how-to-integrate-for-non-gki).
|
||||
|
||||
## Por que a minha versão do Android é 13 e o kernel mostra “android12-5.10”?
|
||||
## Por que a minha versão do Android é 13 e o kernel mostra "android12-5.10"?
|
||||
|
||||
A versão do Kernel não tem nada a ver com a versão do Android, se você precisar fazer o flash do kernel, use sempre a versão do kernel, a versão do Android não é tão importante.
|
||||
A versão do Kernel não tem nada a ver com a versão do Android. Se você precisar fazer o flash do kernel, use sempre a versão do kernel, a versão do Android não é tão importante.
|
||||
|
||||
## Eu sou GKI 1.0, posso usar isso?
|
||||
|
||||
@@ -69,10 +69,10 @@ Claro. Mas o KernelSU não tem suporte a hosts integrados, você pode instalar [
|
||||
|
||||
## Por que existe um enorme arquivo de 1 TB?
|
||||
|
||||
O arquivo `modules.img` de 1 TB é um arquivo de imagem de disco, **não se preocupe com seu tamanho**, é um tipo especial de arquivo conhecido como [arquivo esparso](https://en.wikipedia.org/wiki/Sparse_file), seu tamanho real é apenas o tamanho do módulo que você usa e diminuirá dinamicamente após você excluir o módulo. Na verdade, ele não ocupa 1 TB de espaço em disco (seu celular pode não ter tanto espaço).
|
||||
O arquivo `modules.img` de 1 TB é um arquivo de imagem de disco. **Não se preocupe com seu tamanho**; ele é um tipo especial de arquivo conhecido como [arquivo esparso](https://en.wikipedia.org/wiki/Sparse_file). Seu tamanho real é apenas o tamanho do módulo que você usa e diminuirá dinamicamente após a exclusão do módulo. Na verdade, ele não ocupa 1 TB de espaço em disco (seu celular pode não ter tanto espaço).
|
||||
|
||||
Se você estiver realmente insatisfeito com o tamanho deste arquivo, você pode usar o comando `resize2fs -M` para torná-lo seu tamanho real, mas o módulo pode não funcionar corretamente neste momento e não forneceremos nenhum suporte para isso.
|
||||
Se você realmente se incomodar com o tamanho desse arquivo, você pode usar o comando `resize2fs -M` para ajustá-lo ao tamanho real. Porém, o módulo pode não funcionar corretamente nesse caso, e não forneceremos suporte para isso.
|
||||
|
||||
## Por que meu dispositivo mostra o tamanho de armazenamento errado?
|
||||
|
||||
Certos dispositivos usam métodos não padrão para calcular o tamanho de armazenamento do dispositivo, potencialmente levando a cálculos de armazenamento imprecisos em apps e menus do sistema, especialmente ao lidar com arquivos esparsos de 1 TB. Embora esse problema pareça ser específico para os dispositivos Samsung, afetando apenas apps e serviços da Samsung, é essencial observar que a discrepância está principalmente no tamanho total do armazenamento, e o cálculo do espaço livre permanece preciso.
|
||||
Certos dispositivos usam métodos não padrão para calcular o tamanho de armazenamento do dispositivo, o que pode levar a cálculos imprecisos nos apps e menus do sistema, especialmente ao lidar com arquivos esparsos de 1 TB. Embora esse problema pareça ser específico para os dispositivos Samsung, afetando principalmente os apps e serviços da Samsung, é importante observar que a discrepância está principalmente no tamanho total do armazenamento, enquanto o cálculo do espaço livre permanece preciso.
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Como compilar o KernelSU?
|
||||
# Como compilar
|
||||
|
||||
Primeiro, você deve ler a documentação oficial do Android para compilação do kernel:
|
||||
|
||||
@@ -6,7 +6,7 @@ Primeiro, você deve ler a documentação oficial do Android para compilaçã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 [Integração para dispositivos não-GKI](how-to-integrate-for-non-gki).
|
||||
:::
|
||||
|
||||
## Compilar 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 compilação exclusivamente, você pode usar o manifesto para fazer uma compilação re-preduzível. Você deve baixar o arquivo de manifesto em [Builds de versão de imagem genérica do kernel (GKI)](https://source.android.com/docs/core/architecture/kernel/gki-release-builds).
|
||||
O arquivo `<kernel_manifest.xml>` é um manifesto que pode determinar exclusivamente uma compilação, permitindo que você a torne reprodutível. Para isso, você deve baixar o arquivo de manifesto em [Builds de versão de imagem genérica do kernel (GKI)](https://source.android.com/docs/core/architecture/kernel/gki-release-builds).
|
||||
|
||||
### Construir
|
||||
|
||||
@@ -40,7 +40,7 @@ A partir do Android 13, o kernel é compilado pelo `bazel`:
|
||||
tools/bazel build --config=fast //common:kernel_aarch64_dist
|
||||
```
|
||||
|
||||
:::info INFORMAÇÕES
|
||||
::: info INFORMAÇÕES
|
||||
Para alguns kernel do Android 14, para fazer o Wi-Fi/Bluetooth funcionar, pode ser necessário remover todas as exportações protegidas pelo GKI:
|
||||
|
||||
```sh
|
||||
@@ -50,7 +50,7 @@ rm common/android/abi_gki_protected_exports_*
|
||||
|
||||
## Compilar o kernel com KernelSU
|
||||
|
||||
Se você conseguir compilar o kernel com sucesso, adicionar suporte ao KernelSU a ele será relativamente fácil. Na raiz do diretório de origem do kernel, execute qualquer uma das opções listadas abaixo:
|
||||
Se você conseguir compilar o kernel com sucesso, adicionar suporte ao KernelSU será relativamente simples. Na raiz do diretório de origem do kernel, execute qualquer uma das opções listadas abaixo:
|
||||
|
||||
::: code-group
|
||||
|
||||
@@ -68,4 +68,4 @@ curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh
|
||||
|
||||
:::
|
||||
|
||||
E então reconstrua o kernel e você obterá uma imagem do kernel com KernelSU!
|
||||
Então, reconstrua o kernel e você obterá uma imagem do kernel com o KernelSU!
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
# Como integrar o KernelSU para kernels não GKI?
|
||||
# Integração para dispositivos não-GKI
|
||||
|
||||
O KernelSU pode ser integrado em kernels não GKI e foi portado para 4.14 e versões anteriores.
|
||||
O KernelSU pode ser integrado a 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 universal de construí-lo, portanto não podemos fornecer o boot.img não GKI. Mas você mesmo pode compilar o kernel com o KernelSU integrado.
|
||||
Devido à fragmentação dos kernels não-GKI, não temos um método universal para construí-lo, portanto, não podemos fornecer o boot.img não-GKI. No entanto, você pode compilar o kernel com o KernelSU integrado por conta própria.
|
||||
|
||||
Primeiro, você deve ser capaz de compilar 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.
|
||||
Primeiro, você deve ser capaz de compilar 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 para o seu dispositivo.
|
||||
|
||||
Se você puder compilar um kernel inicializável, existem duas maneiras de integrar o KernelSU ao código-fonte do kernel:
|
||||
|
||||
@@ -21,11 +21,11 @@ Primeiro, adicione o KernelSU à árvore de origem do kernel:
|
||||
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s v0.9.5
|
||||
```
|
||||
|
||||
:::info INFORMAÇÕES
|
||||
[KernelSU 1.0 e versões posteriores não suportam mais kernels não GKI](https://github.com/tiann/KernelSU/issues/1705). A última versão suportada é a `v0.9.5`, por favor, certifique-se de usar a versão correta.
|
||||
::: info INFORMAÇÕES
|
||||
[KernelSU 1.0 e versões posteriores não suportam mais kernels não-GKI](https://github.com/tiann/KernelSU/issues/1705). A última versão suportada é a `v0.9.5`, portanto, certifique-se de usar a versão correta.
|
||||
:::
|
||||
|
||||
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. Caso não esteja, adicione estas configurações a ele:
|
||||
|
||||
```txt
|
||||
CONFIG_KPROBES=y
|
||||
@@ -33,25 +33,23 @@ CONFIG_HAVE_KPROBES=y
|
||||
CONFIG_KPROBE_EVENTS=y
|
||||
```
|
||||
|
||||
E agora, quando você recompilar seu kernel, o KernelSU deve funcionar bem.
|
||||
Agora, ao recompilar seu kernel, o KernelSU deve funcionar corretamente.
|
||||
|
||||
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.
|
||||
Se você descobrir que o KPROBES ainda não está ativado, pode tentar ativar `CONFIG_MODULES`. Se isso não resolver, use `make menuconfig` para procurar outras dependências do KPROBES.
|
||||
|
||||
Mas se você entrar em um bootloop quando o KernelSU for integrado, pode ser porque o **kprobe esteja quebrado em seu kernel**, o que significa que você deve corrigir o bug do kprobe ou usar outra maneira.
|
||||
|
||||
:::tip COMO VERIFICAR SE O KPROBE ESTÁ QUEBRADO?
|
||||
Porém, se você entrar em um bootloop após integrar o KernelSU, isso pode indicar que o **kprobe está quebrado no seu kernel**, o que significa que você precisará corrigir o bug do kprobe ou usar outra maneira.
|
||||
|
||||
::: tip COMO VERIFICAR SE O KPROBE ESTÁ QUEBRADO?
|
||||
Comente `ksu_enable_sucompat()` e `ksu_enable_ksud()` em `KernelSU/kernel/ksu.c`, se o dispositivo inicializar normalmente, então o kprobe pode estar quebrado.
|
||||
:::
|
||||
|
||||
:::info COMO FAZER COM QUE O RECURSO DE DESMONTAR MÓDULOS FUNCIONE NO PRÉ-GKI?
|
||||
|
||||
Se o seu kernel for inferior a 5.9, você deve portar `path_umount` para `fs/namespace.c`. Isso é necessário para que o recurso de quantidade do módulo funcione. Se você não portar `path_umount`, o recurso "Desmontar módulos" não funcionará. Você pode obter mais informações sobre como conseguir isso no final desta página.
|
||||
::: info COMO FAZER COM QUE O RECURSO DE DESMONTAR MÓDULOS FUNCIONE NO PRÉ-GKI?
|
||||
Se o seu kernel for inferior a 5.9, você deve portar `path_umount` para `fs/namespace.c`. Isso é necessário para que o recurso "Desmontar módulos" funcione corretamente. Caso você não porte `path_umount`, o recurso "Desmontar módulos" não funcionará. Você pode obter mais informações sobre como conseguir isso no final desta página.
|
||||
:::
|
||||
|
||||
## Modifique manualmente a fonte do kernel
|
||||
|
||||
Se o kprobe não funcionar no seu kernel (pode ser um bug do upstream ou do kernel abaixo de 4.8), então você pode tentar o seguinte:
|
||||
Se o kprobe não funcionar no seu kernel (isso pode ser causado por um bug no upstream ou do kernel abaixo de 4.8), então você pode tentar o seguinte:
|
||||
|
||||
Primeiro, adicione o KernelSU à árvore de origem do kernel:
|
||||
|
||||
@@ -59,14 +57,14 @@ Primeiro, adicione o KernelSU à árvore de origem do kernel:
|
||||
curl -LSs "https://raw.githubusercontent.com/tiann/KernelSU/main/kernel/setup.sh" | bash -s v0.9.5
|
||||
```
|
||||
|
||||
Tenha em mente que em alguns dispositivos, seu defconfig pode estar em `arch/arm64/configs` ou em outros casos `arch/arm64/configs/vendor/your_defconfig`. Para qualquer defconfig que você estiver usando, certifique-se de ativar `CONFIG_KSU` com `y` para ativa-lo ou `n` para desativa-lo. Por exemplo, caso você opte por ativa-lo, seu defconfig deverá conter a seguinte string:
|
||||
Tenha em mente que, em alguns dispositivos, seu defconfig pode estar localizado em `arch/arm64/configs` ou em outros casos pode estar em `arch/arm64/configs/vendor/your_defconfig`. Independentemente do defconfig que você estiver usando, certifique-se de ativar `CONFIG_KSU` com `y` para ativa-lo ou `n` para desativa-lo. Por exemplo, se optar por ativá-lo, seu defconfig deverá conter a seguinte linha:
|
||||
|
||||
```txt
|
||||
# KernelSU
|
||||
CONFIG_KSU=y
|
||||
```
|
||||
|
||||
Em seguida, adicione chamadas do KernelSU à fonte do kernel. Aqui estão alguns patches para referência:
|
||||
Em seguida, adicione chamadas do KernelSU à fonte do kernel. Abaixo estão alguns patches para referência:
|
||||
|
||||
::: code-group
|
||||
|
||||
@@ -258,9 +256,9 @@ index 2ff887661237..e758d7db7663 100644
|
||||
|
||||
### Modo de Segurança
|
||||
|
||||
Para ativar o Modo de Segurança integrado do KernelSU, você também deve modificar a função `input_handle_event` em `drivers/input/input.c`:
|
||||
Para ativar o Modo de Segurança integrado do KernelSU, você deve modificar a função `input_handle_event` em `drivers/input/input.c`:
|
||||
|
||||
:::tip DICA
|
||||
::: tip DICA
|
||||
É altamente recomendável ativar este recurso, é muito útil para evitar bootloops!
|
||||
:::
|
||||
|
||||
@@ -291,8 +289,8 @@ index 45306f9ef247..815091ebfca4 100755
|
||||
add_input_randomness(type, code, value);
|
||||
```
|
||||
|
||||
:::info ENTRANDO NO MODO DE SEGURANÇA ACIDENTALMENTE?
|
||||
Se você estiver usando a integração manual e não desabilitar `CONFIG_KPROBES`, o usuário poderá acionar o Modo de Segurança pressionando o botão de diminuir volume após a inicialização! Portanto, se estiver usando a integração manual, você precisa desabilitar `CONFIG_KPROBES`!
|
||||
::: info ENTRANDO NO MODO DE SEGURANÇA ACIDENTALMENTE?
|
||||
Se você estiver usando a integração manual e não desativar `CONFIG_KPROBES`, o usuário poderá acionar o Modo de Segurança pressionando o botão de diminuir volume após a inicialização! Portanto, se estiver usando a integração manual, é necessário desativar `CONFIG_KPROBES`!
|
||||
:::
|
||||
|
||||
### Falha ao executar `pm` no terminal?
|
||||
@@ -376,4 +374,4 @@ Você pode fazer com que o recurso "Desmontar módulos" funcione em kernels pré
|
||||
* Isto é importante para filesystems que usam dispositivos bloqueados sem nome.
|
||||
```
|
||||
|
||||
Finalmente, construa seu kernel novamente, e então, o KernelSU deve funcionar bem.
|
||||
Finalmente, compile seu kernel novamente e o KernelSU deverá funcionar corretamente.
|
||||
|
||||
@@ -2,21 +2,21 @@
|
||||
|
||||
## Verifique se o seu dispositivo é compatível
|
||||
|
||||
Baixe o gerenciador do KernelSU em [GitHub Releases](https://github.com/tiann/KernelSU/releases), e instale-o no seu dispositivo:
|
||||
Baixe o gerenciador do KernelSU em [GitHub Releases](https://github.com/tiann/KernelSU/releases) 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á um boot.img para você instalar.
|
||||
- Se o app mostrar `Sem suporte`, significa que **você precisará compilar o kernel por conta própria**. O KernelSU não fornecerá e nunca fornecerá um arquivo boot.img para você instalar.
|
||||
- Se o app mostrar `Não instalado`, então seu dispositivo é oficialmente suportado pelo KernelSU.
|
||||
|
||||
::: info INFORMAÇÕES
|
||||
Para dispositivos mostrando `Sem suporte`, aqui está os [Dispositivos com suporte não oficial](unofficially-support-devices.md). Você mesmo pode compilar o kernel.
|
||||
Para dispositivos que mostram `Sem suporte`, você pode conferir a lista de [Dispositivos com suporte não oficial](unofficially-support-devices.md). Você mesmo pode compilar o kernel.
|
||||
:::
|
||||
|
||||
## Backup padrão do boot.img
|
||||
|
||||
Antes de fazer o flash, você deve primeiro fazer backup de seu boot.img padrão. Se você encontrar algum bootloop, você sempre pode restaurar o sistema voltando para o boot padrão de fábrica usando o fastboot.
|
||||
Antes de fazer o flash, é essencial que você faça o backup do seu boot.img padrão. Se encontrar algum bootloop, você sempre pode restaurar o sistema voltando ao boot padrão 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 dispositivo, se necessário.
|
||||
O flash pode causar perda de dados. Certifique-se de executar esta etapa bem antes de prosseguir para a próxima! Se necessário, também é recomendável fazer backup de todos os dados do seu dispositivo.
|
||||
:::
|
||||
|
||||
## Conhecimento necessário
|
||||
@@ -45,9 +45,9 @@ Observe que o SubLevel na versão do kernel não faz parte do KMI! Isso signific
|
||||
|
||||
### Nível do patch de segurança {#security-patch-level}
|
||||
|
||||
Dispositivos Android mais recentes podem ter mecanismos anti-rollback que não permitem flashar um boot.img com um nível do patch de segurança antigo. Por exemplo, se o kernel do seu dispositivo for `5.10.101-android12-9-g30979850fc20`, o patch de segurança será `2023-11`, mesmo se você atualizar o kernel correspondente ao KMI do kernel, se o nível do patch de segurança for anterior a `2023-11` (como `2023-06`), então isso pode causar bootloop.
|
||||
Dispositivos Android mais recentes podem ter mecanismos anti-rollback que impedem o flash de um boot.img com um nível de patch de segurança antigo. Por exemplo, se o kernel do seu dispositivo for `5.10.101-android12-9-g30979850fc20`, o patch de segurança será `2023-11`, mesmo se você atualizar o kernel correspondente ao KMI do kernel, se o nível do patch de segurança for anterior a `2023-11` (como `2023-06`), isso pode causar um bootloop.
|
||||
|
||||
Portanto, os kernels com os níveis do patch de segurança mais recentes são preferidos para manter a correspondência com o KMI.
|
||||
Portanto, kernels com os níveis de patch de segurança mais recentes são preferidos para manter a compatibilidade com o KMI.
|
||||
|
||||
### Versão do kernel vs Versão do Android
|
||||
|
||||
@@ -57,19 +57,19 @@ Se você descobrir que a versão do seu kernel é `android12-5.10.101`, mas a ve
|
||||
|
||||
## Introdução
|
||||
|
||||
Desde a versão [0.9.0](https://github.com/tiann/KernelSU/releases/tag/v0.9.0), KernelSU suporta dois modos de execução em dispositivos GKI:
|
||||
Desde a versão [0.9.0](https://github.com/tiann/KernelSU/releases/tag/v0.9.0), o KernelSU suporta dois modos de execução em dispositivos GKI:
|
||||
|
||||
1. `GKI`: Substitua o kernel original do dispositivo pelo **Generic Kernel Image** (GKI) fornecido pelo KernelSU.
|
||||
1. `GKI`: Substitue o kernel original do dispositivo pelo **Generic Kernel Image** (GKI) fornecido pelo KernelSU.
|
||||
2. `LKM`: Carregue o **Loadable Kernel Module** (LKM) no kernel do dispositivo sem substituir o kernel original.
|
||||
|
||||
Esses dois modos são adequados para diferentes cenários e você pode escolher de acordo com suas necessidades.
|
||||
Esses dois modos são adequados para diferentes cenários, e você pode escolher o mais adequado conforme suas necessidades.
|
||||
|
||||
### Modo GKI {#gki-mode}
|
||||
|
||||
No modo GKI, o kernel original do dispositivo será substituído pela imagem genérica do kernel fornecida pelo KernelSU. As vantagens do modo GKI são:
|
||||
|
||||
1. Forte universalidade, adequada para a maioria dos dispositivos. Por exemplo, a Samsung ativou dispositivos KNOX e o modo LKM não pode funcionar. Existem também alguns dispositivos modificados de nicho que só podem usar o modo GKI.
|
||||
2. Pode ser usado sem depender de firmware oficial e não há necessidade de esperar por atualizações oficiais de firmware, desde que o KMI seja consistente, ele pode ser usado.
|
||||
1. Forte universalidade, adequada para a maioria dos dispositivos. Por exemplo, a Samsung ativou dispositivos KNOX, e o modo LKM não pode funcionar. Existem também alguns dispositivos modificados de nicho que só podem usar o modo GKI.
|
||||
2. Pode ser usado sem depender de firmware oficial, e não há necessidade de esperar por atualizações oficiais de firmware, desde que o KMI seja consistente, ele pode ser usado.
|
||||
|
||||
### Modo LKM {#lkm-mode}
|
||||
|
||||
@@ -77,10 +77,10 @@ No modo LKM, o kernel original do dispositivo não será substituído, mas o mó
|
||||
|
||||
1. Não substituirá o kernel original do dispositivo. Se você tiver os requisitos especiais para o kernel original do dispositivo ou quiser usar o KernelSU enquanto usa um kernel de terceiros, poderá usar o modo LKM.
|
||||
2. É mais conveniente atualizar o OTA. Ao atualizar o KernelSU, você pode instalá-lo diretamente no gerenciador sem flashar manualmente. Após o sistema OTA, você pode instalá-lo diretamente no segundo slot sem flashar manualmente.
|
||||
3. Adequado para alguns cenários especiais, por exemplo, o LKM também pode ser carregado com privilégios root temporários. Como não é necessário substituir a partição boot, ele não acionará o AVB e não causará o bloqueio do dispositivo.
|
||||
4. O LKM pode ser desinstalado temporariamente. Se você deseja desativar temporariamente o acesso root, você pode desinstalar o LKM, este processo não requer o flash de partições, nem mesmo a reinicialização do dispositivo. Se quiser ativar o root novamente, basta reiniciar o dispositivo.
|
||||
3. Adequado para alguns cenários especiais. Por exemplo, o LKM também pode ser carregado com privilégios root temporários. Como não é necessário substituir a partição boot, ele não acionará o AVB e não causará o bloqueio do dispositivo.
|
||||
4. O LKM pode ser desinstalado temporariamente. Se você deseja desativar temporariamente o acesso root, você pode desinstalar o LKM. Este processo não requer o flash de partições, nem mesmo a reinicialização do dispositivo. Se quiser ativar o root novamente, basta reiniciar o dispositivo.
|
||||
|
||||
:::tip COEXISTÊNCIA DE DOIS MODOS
|
||||
::: tip COEXISTÊNCIA DE DOIS MODOS
|
||||
Após abrir o gerenciador, você pode ver o modo atual do dispositivo na página inicial. Observe que a prioridade do modo GKI é maior que a do LKM. Por exemplo, se você usar o kernel GKI para substituir o kernel original e usar LKM para corrigir o kernel GKI, o LKM será ignorado e o dispositivo sempre será executado no modo GKI.
|
||||
:::
|
||||
|
||||
@@ -94,19 +94,19 @@ Se o seu aparelho for um celular, recomendamos que você priorize o modo LKM. Se
|
||||
|
||||
Para usar o modo LKM, você precisa obter o firmware oficial e corrigi-lo com base no firmware oficial. Se você usar um kernel de terceiros, poderá usar o `boot.img` do kernel de terceiros como firmware oficial.
|
||||
|
||||
Existem muitas maneiras de obter o firmware oficial. Se o seu dispositivo suportar `fastboot boot`, então recomendamos **o método mais recomendado e o mais simples** que é usar `fastboot boot` para inicializar temporariamente o kernel GKI fornecido pelo KernelSU, depois instalar o gerenciador e, finalmente, instalá-lo diretamente no gerenciador. Este método não exige que você baixe manualmente o firmware oficial, nem extraia manualmente o boot.
|
||||
Existem muitas maneiras de obter o firmware oficial. Se o seu dispositivo suportar `fastboot boot`, então recomendamos **o método mais simples e indicado**, que consiste em usar `fastboot boot` para inicializar temporariamente o kernel GKI fornecido pelo KernelSU, depois instalar o gerenciador e, finalmente, instalá-lo diretamente pelo gerenciador. Este método não exige o download manual do firmware oficial nem a extração manual do boot.
|
||||
|
||||
Se o seu dispositivo não suportar `fastboot boot`, pode ser necessário baixar manualmente o pacote de firmware oficial e extrair o boot dele.
|
||||
|
||||
Ao contrário do modo GKI, o modo LKM modificará o `ramdisk`, portanto, em dispositivos com Android 13, ele precisa corrigir a partição `init_boot` em vez da partição `boot`, enquanto isso, o modo GKI sempre opera a partição `boot`.
|
||||
Ao contrário do modo GKI, o modo LKM modifica o `ramdisk`. Portanto, em dispositivos com Android 13, ele precisa corrigir a partição `init_boot` em vez da partição `boot`, enquanto o modo GKI sempre opera sobre a partição `boot`.
|
||||
|
||||
### Use o gerenciador
|
||||
|
||||
Abra o gerenciador, clique no ícone de instalação no canto superior direito e diversas opções aparecerão:
|
||||
|
||||
1. Selecione e corrija um arquivo. Se o seu dispositivo não tiver privilégios root, você pode escolher esta opção e, em seguida, selecionar seu firmware oficial, o gerenciador irá corrigi-lo automaticamente. Você só precisa flashar este arquivo corrigido para obter privilégios root permanentemente.
|
||||
2. Instale diretamente. Se o seu dispositivo já estiver rooteado, você pode escolher esta opção, o gerenciador obterá automaticamente as informações do seu dispositivo e, em seguida, corrigirá o firmware oficial e irá fazer o flash automaticamente. Você pode considerar usar `fastboot boot` e o kernel GKI do KernelSU para obter root temporário e instalar o gerenciador, e então usar esta opção. Esta também é a principal forma de atualizar o KernelSU.
|
||||
3. Instale em outra partição. Se o seu dispositivo suportar partição A/B, você pode escolher esta opção, o gerenciador irá corrigir automaticamente o firmware oficial e, em seguida, instalá-lo em outra partição. Este método é adequado para dispositivos após o OTA, você pode instalá-lo diretamente em outra partição após o OTA e, em seguida, reiniciar o dispositivo.
|
||||
1. Selecione um arquivo. Se o seu dispositivo não tiver privilégios root, você pode escolher esta opção e, em seguida, selecionar o seu firmware oficial. O gerenciador corrigirá automaticamente o firmware. Após isso, basta fazer o flash deste arquivo corrigido para obter privilégios root permanentemente.
|
||||
2. Instalação direta. Se o seu dispositivo já estiver rooteado, você pode escolher esta opção. O gerenciador obterá automaticamente as informações do seu dispositivo, corrigirá o firmware oficial e realizará o flash automaticamente. Você também pode usar o comando `fastboot boot` junto com o kernel GKI do KernelSU para obter root temporário e instalar o gerenciador, e então usar esta opção. Esta também é a principal forma de atualizar o KernelSU.
|
||||
3. Instalar no slot inativo. Se o seu dispositivo suportar partição A/B, você pode escolher esta opção. O gerenciador corrigirá automaticamente o firmware oficial e o instalará em outra partição. Esse método é adequado para dispositivos após o OTA, você pode instalá-lo diretamente em outra partição após o OTA e, em seguida, reiniciar o dispositivo.
|
||||
|
||||
### Use a linha de comando
|
||||
|
||||
@@ -123,21 +123,21 @@ Patch boot ou imagens init_boot para aplicar o KernelSU
|
||||
Uso: ksud boot-patch [OPTIONS]
|
||||
|
||||
Opções:
|
||||
-b, --boot <BOOT> Caminho da imagem boot, se não for especificado, tentará encontrar a imagem boot automaticamente
|
||||
-k, --kernel <KERNEL> Caminho da imagem do kernel para substituir
|
||||
-m, --module <MODULE> O caminho do módulo LKM a ser substituído, se não for especificado, usará o integrado
|
||||
-b, --boot <BOOT> Caminho da imagem boot. Se não especificado, tentará encontrar a imagem boot automaticamente
|
||||
-k, --kernel <KERNEL> Caminho da imagem do kernel a ser substituída
|
||||
-m, --module <MODULE> Caminho do módulo LKM a ser substituído. Se não especificado, usará o módulo integrado
|
||||
-i, --init <INIT> init a ser substituído
|
||||
-u, --ota Usará outro slot quando a imagem boot não for especificada
|
||||
-u, --ota Usará outro slot se a imagem boot não for especificada
|
||||
-f, --flash Flash para a partição boot após o patch
|
||||
-o, --out <OUT> Caminho de saída, se não for especificado, usará o diretório atual
|
||||
--magiskboot <MAGISKBOOT> Caminho do magiskboot, se não for especificado, usará um integrado
|
||||
--kmi <KMI> A versão do KMI, se especificada, usará o KMI especificado
|
||||
-o, --out <OUT> Caminho de saída. Se não especificado, usará o diretório atual
|
||||
--magiskboot <MAGISKBOOT> Caminho do magiskboot. Se não especificado, usará a versão integrada
|
||||
--kmi <KMI> Versão do KMI. Se especificada, usará o KMI indicado
|
||||
-h, --help Imprimir ajuda
|
||||
```
|
||||
|
||||
Algumas opções que precisam ser explicadas:
|
||||
|
||||
1. A opção `--magiskboot` pode especificar o caminho do magiskboot. Se não for especificado, o ksud irá procurá-lo nas variáveis de ambiente. Se você não sabe como obter o magiskboot, você pode verificar [aqui](#patch-boot-image).
|
||||
1. A opção `--magiskboot` pode especificar o caminho do magiskboot. Se não for especificado, o ksud irá procurá-lo nas variáveis de ambiente. Se você não souber como obter o magiskboot, você pode verificar [aqui](#patch-boot-image).
|
||||
2. A opção `--kmi` pode especificar a versão do `KMI`. Se o nome do kernel do seu dispositivo não seguir a especificação KMI, você poderá especificá-lo através desta opção.
|
||||
|
||||
O uso mais comum é:
|
||||
@@ -150,10 +150,10 @@ ksud boot-patch -b <boot.img> --kmi android13-5.10
|
||||
|
||||
Existem vários métodos de instalação para o modo GKI, cada um adequado para um cenário diferente, portanto escolha conforme necessário.
|
||||
|
||||
1. Instalar com fastboot usando o boot.img fornecido pelo KernelSU
|
||||
2. Instalar com um app kernel flash, como o Kernel Flasher
|
||||
3. Corrigir boot.img manualmente e instala-lo
|
||||
4. Instalar com Recovery personalizado (por exemplo, TWRP)
|
||||
1. Instalar com fastboot usando o boot.img fornecido pelo KernelSU.
|
||||
2. Instalar com um app kernel flash, como o [Kernel Flasher](https://github.com/capntrips/KernelFlasher/releases).
|
||||
3. Corrigir manualmente o boot.img e instalá-lo.
|
||||
4. Instalar com Recovery personalizado (por exemplo, TWRP).
|
||||
|
||||
## Instalar com o boot.img fornecido pelo KernelSU
|
||||
|
||||
@@ -161,15 +161,15 @@ Se o `boot.img` do seu dispositivo usa um formato de compactação comumente usa
|
||||
|
||||
### Encontre o boot.img adequado
|
||||
|
||||
O KernelSU fornece um boot.img genérico para dispositivos GKI e você deve flashar o boot.img para a partição boot do dispositivo.
|
||||
O KernelSU fornece um boot.img genérico para dispositivos GKI, e você deve fazer o flash do boot.img na 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. Se você não sabe qual arquivo baixar, leia atentamente a descrição do [KMI](#kmi) e [Nível do patch de segurança](#security-patch-level) neste documento.
|
||||
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. Se você não sabe qual arquivo baixar, leia atentamente a descrição do [KMI](#kmi) e [Nível do patch de segurança](#security-patch-level) neste documento.
|
||||
|
||||
Normalmente, existem três arquivos de inicialização em formatos diferentes no mesmo KMI e nível do patch de segurança. Eles são todos iguais, exceto pelo formato de compactação do kernel. Por favor, verifique o formato de compactação do kernel de seu boot.img original. Você deve usar o formato correto, como `lz4` ou `gz`. Se você usar um formato de compactação incorreto, poderá encontrar bootloop após flashar o boot.img.
|
||||
Normalmente, existem três arquivos de inicialização em formatos diferentes para o mesmo KMI e nível de patch de segurança. Eles são idênticos, exceto pelo formato de compactação do kernel. Por favor, verifique o formato de compactação do kernel de seu boot.img original. Você deve usar o formato correto, como `lz4` ou `gz`. Se você usar um formato de compactação incorreto, poderá encontrar bootloop após o flash do boot.img.
|
||||
|
||||
::: info FORMATO DE COMPACTAÇÃO DO BOOT.IMG
|
||||
1. Você pode usar o magiskboot para obter o formato de compactação de seu boot original; alternativamente, você também pode solicitá-lo a membros/desenvolvedores da comunidade 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 do seu boot.img original. Alternativamente, você também pode perguntar a membros ou desenvolvedores da comunidade que possuam o mesmo modelo de 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. Dispositivos Xiaomi geralmente usam `gz` ou `uncompressed`.
|
||||
3. Para dispositivos Pixel, siga as instruções abaixo:
|
||||
:::
|
||||
|
||||
@@ -198,13 +198,15 @@ fastboot reboot
|
||||
Etapa:
|
||||
|
||||
1. Baixe o ZIP AnyKernel3. Se você não sabe qual arquivo baixar, leia atentamente a descrição do [KMI](#kmi) e [Nível do patch de segurança](#security-patch-level) neste documento.
|
||||
2. Abra o app Kernel Flasher (conceda as permissões de root necessárias) e use o ZIP AnyKernel3 fornecido para fazer o flash.
|
||||
2. Abra o app Kernel Flasher, conceda as permissões de root necessárias e use o ZIP AnyKernel3 fornecido para fazer o flash.
|
||||
|
||||
Dessa forma, é necessário que o app Kernel Flasher tenha privilégios root. Você pode usar os seguintes métodos para conseguir isso:
|
||||
|
||||
1. Seu dispositivo está rooteado. Por exemplo, você instalou o KernelSU e deseja atualizar para a versão mais recente ou fez o root por meio de outros métodos (como Magisk).
|
||||
2. Se o seu dispositivo não estiver rooteado, mas suportar o método de inicialização temporária como `fastboot boot boot.img`, você pode usar a imagem GKI fornecida pelo KernelSU para inicializar temporariamente o seu dispositivo, obter privilégios root temporário e, em seguida, usar o Kernel Flasher para obter privilégios root permanente.
|
||||
|
||||
Aqui estão alguns apps que podem ser usados para realizar o flash do kernel:
|
||||
|
||||
1. [Kernel Flasher](https://github.com/capntrips/KernelFlasher/releases)
|
||||
2. [Franco Kernel Manager](https://play.google.com/store/apps/details?id=com.franco.kernel)
|
||||
3. [Ex Kernel Manager](https://play.google.com/store/apps/details?id=flar2.exkernelmanager)
|
||||
@@ -213,14 +215,14 @@ Observação: Este método é mais conveniente ao atualizar o KernelSU e pode se
|
||||
|
||||
## Corrigir boot.img manualmente {#patch-boot-image}
|
||||
|
||||
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` e também pode ser compactado `lz4_legacy`. Atualmente, se você flashar diretamente o boot.img fornecido pelo KernelSU, o dispositivo 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`. Um exemplo típico é o Pixel, cujo boot.img é compactado no formato `lz4_legacy`, enquanto o ramdisk pode estar em `gz` ou também comprimido em `lz4_legacy`. Atualmente, se você flashar diretamente o boot.img fornecido pelo KernelSU, o dispositivo pode não conseguir inicializar. Nesse caso, é necessário corrigir manualmente o boot.img para conseguir isso.
|
||||
|
||||
É sempre recomendado usar `magiskboot` para corrigir imagens, existem duas maneiras:
|
||||
|
||||
1. [magiskboot](https://github.com/topjohnwu/Magisk/releases)
|
||||
2. [magiskboot_build](https://github.com/ookiineko/magiskboot_build/releases/tag/last-ci)
|
||||
|
||||
A versão oficial do `magiskboot` só pode rodar em dispositivos Android, se você quiser rodar no PC, você pode tentar a segunda opção.
|
||||
A versão oficial do `magiskboot` só pode ser executada em dispositivos Android, se você quiser rodar no PC, você pode tentar a segunda opção.
|
||||
|
||||
::: tip DICA
|
||||
Android-Image-Kitchen não é recomendado por enquanto, porque ele não lida corretamente com os metadados de inicialização (como o nível do patch de segurança). Portanto, pode não funcionar em alguns dispositivos.
|
||||
@@ -238,8 +240,8 @@ Android-Image-Kitchen não é recomendado por enquanto, porque ele não lida cor
|
||||
2. Renomeie o `Magisk-*(versão).apk` para `Magisk-*.zip` e descompacte-o.
|
||||
3. Envie `Magisk-*/lib/arm64-v8a/libmagiskboot.so` para o seu dispositivo por ADB: `adb push Magisk-*/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 ADB shell e no diretório cd `/data/local/tmp/`, em seguida, `chmod +x magiskboot`.
|
||||
6. Entre no ADB shell 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.
|
||||
5. Entre no ADB shell e execute o diretório `cd /data/local/tmp/`, em seguida, `chmod +x magiskboot`.
|
||||
6. Entre no ADB shell e execute o 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` executando o comando: `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.
|
||||
|
||||
@@ -262,7 +264,7 @@ Pré-requisito: Seu dispositivo deve ter um Recovery personalizado, como TWRP. S
|
||||
|
||||
Etapas:
|
||||
|
||||
1. Em [GitHub Releases](https://github.com/tiann/KernelSU/releases), baixe o pacote ZIP começando com AnyKernel3 que corresponde à versão do seu dispositivo. Por exemplo, a versão do kernel do dispositivo é `android12-5.10. 66`, então você deve baixar o arquivo `AnyKernel3-android12-5.10.66_yyyy-MM.zip` (onde `yyyy` é o ano e `MM` é o mês).
|
||||
1. Em [GitHub Releases](https://github.com/tiann/KernelSU/releases), baixe o pacote ZIP começando com AnyKernel3 que corresponde à versão do seu dispositivo. Por exemplo, a versão do kernel do dispositivo é `android12-5.10.66`, então você deve baixar o arquivo `AnyKernel3-android12-5.10.66_yyyy-MM.zip` (onde `yyyy` é o ano e `MM` é o mês).
|
||||
2. Reinicie o dispositivo no TWRP.
|
||||
3. Use o ADB para colocar AnyKernel3-*.zip no dispositivo em `/sdcard` e escolha instalá-lo na interface do TWRP, ou você pode diretamente executar `adb sideload AnyKernel-*.zip` para instalar.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Módulo WebUI
|
||||
|
||||
Além de executar scripts de inicialização e modificar arquivos do sistema, os módulos do KernelSU também suportam a exibição de interfaces da UI e a interação com os usuários.
|
||||
Além de executar scripts de inicialização e modificar arquivos do sistema, os módulos do KernelSU também suportam a exibição de interfaces da UI e à interação direta com os usuários.
|
||||
|
||||
O módulo pode escrever páginas HTML + CSS + JavaScript através de qualquer tecnologia web. O gerenciador do KernelSU exibirá essas páginas através do WebView. Ele também fornece algumas APIs para interagir com o sistema, como executar comandos shell.
|
||||
|
||||
@@ -16,7 +16,7 @@ Os arquivos de recursos da web devem ser colocados no subdiretório `webroot` do
|
||||
`-- index.html
|
||||
```
|
||||
|
||||
:::warning AVISO
|
||||
::: warning AVISO
|
||||
Ao instalar o módulo, KernelSU definirá automaticamente as permissões e o contexto do SELinux deste diretório. Se você não sabe o que está fazendo, não defina você mesmo as permissões deste diretório!
|
||||
:::
|
||||
|
||||
@@ -24,9 +24,9 @@ Se sua página contém CSS e JavaScript, você também precisa colocá-la neste
|
||||
|
||||
## API JavaScript
|
||||
|
||||
Se for apenas uma página de exibição, não será diferente de uma página web normal. Mais importante ainda, KernelSU fornece uma série de APIs de sistema que permitem implementar as funções exclusivas do módulo.
|
||||
Se for apenas uma página de exibição, ela funcionará como uma página web comum. No entanto, o mais importante é que o KernelSU oferece uma série de APIs de sistema, permitindo a implementação de funções exclusivas do módulo.
|
||||
|
||||
KernelSU fornece uma biblioteca JavaScript e publica-a no [npm](https://www.npmjs.com/package/kernelsu), que você pode usar no código JavaScript de suas páginas da web.
|
||||
O KernelSU disponibiliza uma biblioteca JavaScript, que está publicada no [npm](https://www.npmjs.com/package/kernelsu) e pode ser usada no código JavaScript das suas páginas web.
|
||||
|
||||
Por exemplo, você pode executar um comando shell para obter uma configuração específica ou modificar uma propriedade:
|
||||
|
||||
@@ -44,5 +44,5 @@ Se você achar que a API existente não atende às suas necessidades ou é incon
|
||||
|
||||
## Algumas dicas
|
||||
|
||||
1. Você pode usar `localStorage` normalmente para armazenar alguns dados, mas eles serão perdidos após a desinstalação do app gerenciador. Se precisar salvar persistentemente, você mesmo pode gravar os dados em algum diretório.
|
||||
2. Para páginas simples, recomendo que você use [parceljs](https://parceljs.org/) para o empacotamento. Não requer configuração do zero e é muito conveniente de usar. Porém, se você é um mestre do front-end ou tem suas próprias preferências, basta escolher o que você gosta!
|
||||
1. Você pode usar `localStorage` normalmente para armazenar alguns dados, mas tenha em mente que eles serão perdidos caso o app gerenciador seja desinstalado. Se precisar de armazenamento persistente, será necessário gravar os dados manualmente em algum diretório.
|
||||
2. Para páginas simples, recomendamos o uso do [parceljs](https://parceljs.org/) para empacotamento. Ele não exige configuração inicial e é extremamente prático de usar. No entanto, se você é um especialista em front-end ou possui suas próprias preferências, sinta-se à vontade para usar a ferramenta de sua escolha!
|
||||
|
||||
@@ -1,12 +1,12 @@
|
||||
# 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 é 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. Esse mecanismo é conhecido como "sem sistema".
|
||||
|
||||
O mecanismo de módulos do KernelSU é quase o mesmo do Magisk. Se você está familiarizado com o desenvolvimento de módulos Magisk, o desenvolvimento de módulos KernelSU é muito semelhante. Você pode pular a introdução dos módulos abaixo e só precisa ler [Diferenças com Magisk](difference-with-magisk.md).
|
||||
O mecanismo de módulos do KernelSU é quase o mesmo do Magisk. Se você já 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ças com Magisk](difference-with-magisk.md).
|
||||
|
||||
## WebUI
|
||||
|
||||
Os módulos do KernelSU suportam a exibição de interfaces e a interação com os usuários. Para mais, consulte a [documentação do WebUI](module-webui.md).
|
||||
Os módulos do KernelSU suportam a exibição de interfaces e a interação com os usuários. Para mais detalhes, consulte a [documentação do WebUI](module-webui.md).
|
||||
|
||||
## BusyBox
|
||||
|
||||
@@ -22,7 +22,6 @@ Para aqueles que desejam usar o recurso Modo Autônomo fora do KernelSU, existem
|
||||
Para garantir que todos os shells `sh` subsequentes executados também sejam executados no Modo Autônomo, a opção 1 é o método preferido (e é isso que o KernelSU e o gerenciador do KernelSU usam internamente), pois as variáveis de ambiente são herdadas para os subprocesso.
|
||||
|
||||
::: tip DIFERENÇAS COM MAGISK
|
||||
|
||||
O BusyBox do KernelSU agora está usando o arquivo binário compilado diretamente do projeto Magisk. **Obrigado ao Magisk!** Portanto, você não precisa se preocupar com problemas de compatibilidade entre scripts BusyBox no Magisk e KernelSU porque eles são exatamente iguais!
|
||||
:::
|
||||
|
||||
@@ -61,6 +60,7 @@ Um módulo KernelSU é uma pasta colocada em `/data/adb/modules` com a estrutura
|
||||
│ ├── service.sh <--- Este script será executado no serviço late_start
|
||||
│ ├── boot-completed.sh <--- Este script será executado na inicialização concluída
|
||||
| ├── uninstall.sh <--- Este script será executado quando o KernelSU remover seu módulo
|
||||
| ├── action.sh <--- Este script será executado quando o usuário clicar no botão Ação no KernelSU
|
||||
│ ├── system.prop <--- As propriedades neste arquivo serão carregadas como propriedades do sistema por resetprop
|
||||
│ ├── sepolicy.rule <--- Regras adicionais do sepolicy personalizadas
|
||||
│ │
|
||||
@@ -150,7 +150,6 @@ REPLACE="
|
||||
Esta lista criará automaticamente os diretórios `$MODPATH/system/app/YouTube` e `$MODPATH/system/app/Bloatware` e, em seguida, executará `setfattr -n trusted.overlay.opaque -v y $MODPATH/system/app/YouTube` e `setfattr -n trusted.overlay.opaque -v y $MODPATH/system/app/Bloatware`. Após o módulo entrar em vigor, `/system/app/YouTube` e `/system/app/Bloatware` serão substituídos por diretórios vazios.
|
||||
|
||||
::: tip DIFERENÇAS COM MAGISK
|
||||
|
||||
O mecanismo sem sistema do KernelSU é implementado através do OverlayFS do kernel, enquanto o Magisk atualmente usa montagem mágica (montagem de ligação). Os dois métodos de implementação têm diferenças significativas, mas o objetivo final é o mesmo: modificar os arquivos /system sem modificar fisicamente a partição /system.
|
||||
:::
|
||||
|
||||
@@ -239,11 +238,11 @@ set_perm_recursive <directory> <owner> <group> <dirpermission> <filepermission>
|
||||
No KernelSU, os scripts são divididos em dois tipos com base em seu modo de execução: modo post-fs-data e modo de serviço late_start.
|
||||
|
||||
- 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.
|
||||
- Esta etapa está BLOQUEANDO. O processo de inicialização é pausado antes da conclusão da execução ou após 10 segundos.
|
||||
- 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.
|
||||
- **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.**
|
||||
- **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**.
|
||||
@@ -273,7 +272,8 @@ load kernel:
|
||||
- Modo GKI: kernel GKI com KernelSU integrado
|
||||
- Modo LKM: kernel stock
|
||||
...
|
||||
1. kernel exec init (logotipo oem na tela):
|
||||
|
||||
1. kernel exec init (logo OEM na tela):
|
||||
- Modo GKI: stock init
|
||||
- Modo LKM: exec ksuinit, insmod kernelsu.ko, exec stock init
|
||||
mount /dev, /dev/pts, /proc, /sys, etc.
|
||||
@@ -284,7 +284,7 @@ early-init -> init -> late_init
|
||||
early-fs
|
||||
start vold
|
||||
fs
|
||||
montar /vendor, /system, /persist, etc.
|
||||
mount /vendor, /system, /persist, etc.
|
||||
post-fs-data
|
||||
*verificação do modo de segurança
|
||||
*executar scripts gerais em post-fs-data.d/
|
||||
@@ -304,7 +304,8 @@ load_all_props_action
|
||||
start-service logd, console, vold, etc.
|
||||
class_start main
|
||||
start-service adb, netd (iptables), zygote, etc.
|
||||
2. kernel2user init (animação da rom na tela, inicie pelo serviço bootanim)
|
||||
|
||||
2. kernel2user init (animação da ROM na tela, inicie pelo serviço bootanim)
|
||||
*executar scripts gerais em service.d/
|
||||
*executar scripts de módulo service.sh
|
||||
*definir adereços para resetprop sem a opção -p
|
||||
@@ -315,6 +316,7 @@ iniciar apps do sistema (início automático)
|
||||
inicialização completa (transmitir evento ACTION_BOOT_COMPLETED)
|
||||
*executar scripts gerais em boot-completed.d/
|
||||
*executar scripts de módulo boot-completed.sh
|
||||
|
||||
3. Operável pelo usuário (tela de bloqueio)
|
||||
insira a senha para descriptografar /data/data
|
||||
*conjunto real de adereços para resetprop com opção -p
|
||||
|
||||
@@ -1,20 +1,20 @@
|
||||
# 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 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, podem ocorrer 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 pode ser restaurado por meio de operações apropriadas. Este documento tem como objetivo fornecer alguns métodos de emergência para ajudá-lo a recuperar um dispositivo "bloqueado".
|
||||
|
||||
## Bloqueio por flashar partição boot
|
||||
|
||||
No KernelSU, as seguintes situações podem causar bloqueio de inicialização ao flashar a partição boot:
|
||||
|
||||
1. Você flashou uma imagem boot no formato errado. Por exemplo, se o formato de boot do seu dispositivo for `gz`, mas você flashou uma imagem no formato `lz4`, o dispositivo não será capaz de inicializar.
|
||||
2. Seu dispositivo precisa desativar a verificação AVB para inicializar corretamente (geralmente exigindo a limpeza de todos os dados do dispositivo).
|
||||
1. Você flashou uma imagem boot no formato errado. Por exemplo, se o formato de boot do seu dispositivo for `gz`, mas você flashou uma imagem no formato `lz4`, o dispositivo não inicializá.
|
||||
2. Seu dispositivo precisa desativar a verificação AVB para inicializar corretamente, o que geralmente exige a limpeza de todos os dados do dispositivo.
|
||||
3. Seu kernel tem alguns bugs ou não é adequado para o flash do seu dispositivo.
|
||||
|
||||
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 fazer o flash. Se você não fez backup, poderá obter o boot original de fábrica de outros usuários com o mesmo dispositivo que você ou do firmware oficial.
|
||||
Não importa qual seja a situação, você pode recuperar **flashando a imagem de boot padrão**. Portanto, no início do guia de instalação, recomendamos fortemente que você faça backup de seu boot padrão antes de realizar o flash. Se você não fez backup, poderá obter o boot original de fábrica de outros usuários com o mesmo dispositivo ou do firmware oficial.
|
||||
|
||||
## 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 root, eles podem causar danos irreversíveis ao seu dispositivo!
|
||||
A instalação de módulos pode ser uma das causas mais comuns de bloqueio do seu dispositivo, mas devemos alertá-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
|
||||
|
||||
@@ -25,26 +25,26 @@ Se você instalou um módulo que foi comprovadamente seguro, mas faz com que seu
|
||||
|
||||
#### Atualização AB
|
||||
|
||||
As atualizações do módulo KernelSU inspiram-se no mecanismo de atualização AB do sistema Android usado em atualizações OTA. Se você instalar um novo módulo ou atualizar um existente, isso não modificará diretamente o arquivo do módulo usado atualmente. Em vez disso, todos os módulos serão integrados em outra imagem de atualização. Depois que o sistema for reiniciado, ele tentará começar a usar esta imagem de atualização. Se o sistema Android inicializar com sucesso, os módulos serão realmente atualizados.
|
||||
As atualizações do módulo KernelSU são baseadas no mecanismo de atualização AB do sistema Android usado em atualizações OTA. Quando você instala um novo módulo ou atualiza um existente, isso não modifica diretamente o arquivo do módulo atualmente em uso. Em vez disso, todos os módulos são integrados em uma nova imagem de atualização. Após o sistema ser reiniciado, ele tentará iniciar usando essa nova imagem de atualização. Se o sistema Android inicializar com sucesso, os módulos serão efetivamente 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 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.
|
||||
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, pode pressionar e segurar o botão liga/desliga por mais de 10 segundos, e o sistema será reiniciado automaticamente. Após a reinicialização, ele retornará ao estado anterior à atualização do módulo, e os módulos atualizados serão desativados automaticamente.
|
||||
|
||||
#### Recupere pressionando o botão de diminuir volume
|
||||
|
||||
Se a Atualização AB ainda não resolveu o problema, você pode tentar usar o **Modo de Segurança**. No Modo de Segurança, todos os módulos estão desativados.
|
||||
Se a Atualização AB ainda não resolveu o problema, você pode tentar usar o **Modo de Segurança**. Nesse modo, todos os módulos são desativados.
|
||||
|
||||
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.
|
||||
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. Em outros sistemas (como o HyperOS), o Modo de Segurança pode ser ativado a partir do Recovery. Ao entrar no Modo de Segurança do sistema, o KernelSU também entrará nesse modo e desativará automaticamente os módulos.
|
||||
2. O Modo de Segurança integrado do KernelSU: Nesse caso, o método é **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 do KernelSU são desativados, mas você pode executar as 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 Módulos do gerenciador do KernelSU serão desativados. Porém, você ainda pode realizar a operação de "desinstalação" para desinstalar quaisquer módulos que possam estar causando problemas.
|
||||
|
||||
O Modo de Segurança integrado é implementado no kernel, portanto não há possibilidade de perder eventos importantes devido à interceptação. No entanto, para kernels não GKI, a integração manual do código pode ser necessária e você pode consultar a documentação oficial para obter orientação.
|
||||
O Modo de Segurança integrado é implementado no kernel, portanto não há possibilidade de perder eventos importantes devido à interceptação. No entanto, para kernels não-GKI, pode ser necessária uma integração manual do código. Para isso, consulte a documentação oficial para orientações.
|
||||
|
||||
### Módulos maliciosos
|
||||
|
||||
Se os métodos acima não conseguirem recuperar seu dispositivo, é muito provável que o módulo que você instalou tenha operações maliciosas ou tenha danificado seu dispositivo por outros meios. Neste caso, existem apenas duas sugestões:
|
||||
Se os métodos acima não conseguirem recuperar seu dispositivo, é muito provável que o módulo que você instalou tenha operações maliciosas ou tenha danificado seu dispositivo de outra forma. Nesse caso, há apenas duas sugestões:
|
||||
|
||||
1. Limpar os dados e instalar o sistema oficial.
|
||||
2. Consultar o serviço pós-venda.
|
||||
|
||||
@@ -1,11 +1,11 @@
|
||||
# Dispositivos com suporte não oficial
|
||||
|
||||
::: warning AVISO
|
||||
Nesta página, existem kernels para dispositivos não GKI que suportam o KernelSU mantidos por outros desenvolvedores.
|
||||
Nesta página, existem kernels para dispositivos não-GKI que suportam o KernelSU mantidos por outros desenvolvedores.
|
||||
:::
|
||||
|
||||
::: warning AVISO
|
||||
Esta página é apenas para você encontrar o código-fonte correspondente ao seu dispositivo, **NÃO** significa que o código-fonte foi revisado pelos desenvolvedores do KernelSU. Você deve usá-lo por sua própria conta e risco.
|
||||
Esta página é destinada apenas para ajudá-lo a encontrar o código-fonte correspondente ao seu dispositivo. **NÃO** significa que o código-fonte foi revisado pelos desenvolvedores do KernelSU. Você deve usá-lo por sua própria conta e risco.
|
||||
:::
|
||||
|
||||
<script setup>
|
||||
|
||||
@@ -4,7 +4,7 @@ O KernelSU é uma solução root para dispositivos Android GKI, funciona no modo
|
||||
|
||||
## Características
|
||||
|
||||
A principal característica do KernelSU é que ele é **baseado em kernel**. O KernelSU funciona no modo kernel, portanto pode fornecer uma interface de kernel que nunca tivemos antes. Por exemplo, podemos adicionar um ponto de interrupção de hardware a qualquer processo no modo kernel, podemos acessar a memória física de qualquer processo sem que ninguém perceba, podemos interceptar qualquer syscall no espaço do kernel, etc.
|
||||
A principal característica do KernelSU é que ele é baseado em kernel. O KernelSU funciona no modo kernel, portanto pode fornecer uma interface de kernel que nunca tivemos antes. Por exemplo, é possível adicionar pontos de interrupção de hardware a qualquer processo no modo kernel, acessar a memória física de qualquer processo de forma invisível, interceptar qualquer chamada de sistema (syscall) no espaço do kernel, entre outras funcionalidades.
|
||||
|
||||
E também, o KernelSU fornece um sistema de módulos via OverlayFS, que permite carregar seu plugin personalizado no sistema. Ele também fornece um mecanismo para modificar arquivos na partição `/system`.
|
||||
|
||||
@@ -14,7 +14,7 @@ Por favor, consulte: [Instalação](installation)
|
||||
|
||||
## Como compilar o KernelSU?
|
||||
|
||||
Por favor, consulte: [Como compilar?](how-to-build)
|
||||
Por favor, consulte: [Como compilar](how-to-build)
|
||||
|
||||
## Discussão
|
||||
|
||||
|
||||
Reference in New Issue
Block a user