diff --git a/docs/README_PT-BR.md b/docs/README_PT-BR.md index c3fbe9fb..c9c3e5f4 100644 --- a/docs/README_PT-BR.md +++ b/docs/README_PT-BR.md @@ -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. diff --git a/website/docs/pt_BR/guide/app-profile.md b/website/docs/pt_BR/guide/app-profile.md index af45f261..719ef10d 100644 --- a/website/docs/pt_BR/guide/app-profile.md +++ b/website/docs/pt_BR/guide/app-profile.md @@ -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 diff --git a/website/docs/pt_BR/guide/difference-with-magisk.md b/website/docs/pt_BR/guide/difference-with-magisk.md index ed919997..798b5021 100644 --- a/website/docs/pt_BR/guide/difference-with-magisk.md +++ b/website/docs/pt_BR/guide/difference-with-magisk.md @@ -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. diff --git a/website/docs/pt_BR/guide/faq.md b/website/docs/pt_BR/guide/faq.md index c74d3dce..af7627a8 100644 --- a/website/docs/pt_BR/guide/faq.md +++ b/website/docs/pt_BR/guide/faq.md @@ -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! diff --git a/website/docs/pt_BR/guide/how-to-build.md b/website/docs/pt_BR/guide/how-to-build.md index e4df9b17..0c8e19f2 100644 --- a/website/docs/pt_BR/guide/how-to-build.md +++ b/website/docs/pt_BR/guide/how-to-build.md @@ -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 `` é 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! \ No newline at end of file +E então reconstrua o kernel e você obterá uma imagem do kernel com KernelSU! diff --git a/website/docs/pt_BR/guide/how-to-integrate-for-non-gki.md b/website/docs/pt_BR/guide/how-to-integrate-for-non-gki.md index ea56e2e4..c9fd9073 100644 --- a/website/docs/pt_BR/guide/how-to-integrate-for-non-gki.md +++ b/website/docs/pt_BR/guide/how-to-integrate-for-non-gki.md @@ -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 ``` diff --git a/website/docs/pt_BR/guide/installation.md b/website/docs/pt_BR/guide/installation.md index 0739db74..54668302 100644 --- a/website/docs/pt_BR/guide/installation.md +++ b/website/docs/pt_BR/guide/installation.md @@ -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-.img`. (Mantenha o KMI consistente!) -Onde `` 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 `` 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. diff --git a/website/docs/pt_BR/guide/module.md b/website/docs/pt_BR/guide/module.md index 7459ad6f..908863ce 100644 --- a/website/docs/pt_BR/guide/module.md +++ b/website/docs/pt_BR/guide/module.md @@ -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`
Exemplo: `ASH_STANDALONE=1 /data/adb/ksu/bin/busybox sh