diff --git a/docs/README_PT-BR.md b/docs/README_PT-BR.md index fc9b81e0..c1fc6fae 100644 --- a/docs/README_PT-BR.md +++ b/docs/README_PT-BR.md @@ -2,7 +2,7 @@ # KernelSU -Uma solução raiz baseada em kernel para dispositivos Android. +Uma solução root baseada em kernel para dispositivos Android. ## Características @@ -10,7 +10,7 @@ Uma solução raiz baseada em kernel para dispositivos Android. 2. Sistema modular baseado em overlayfs. -3. [Perfil do Aplicativo](https://kernelsu.org/guide/app-profile.html): Tranque o poder raiz em uma gaiola. +3. [Perfil do Aplicativo](https://kernelsu.org/pt_BR/guide/app-profile.html): Tranque o poder root em uma gaiola. ## Estado de Compatibilidade @@ -21,9 +21,9 @@ WSA, ChromeOS e Android baseado em contêiner também deve funcionar com o Kerne E as ABIs atualmente suportadas são: `arm64-v8a` e `x86_64` ## Uso - - [Instrução de instalação](https://kernelsu.org/guide/installation.html) - - [Como construir?](https://kernelsu.org/guide/how-to-build.html) - - [Site Oficial](https://kernelsu.org/) + - [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) + - [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. @@ -36,7 +36,7 @@ Para traduzir o KernelSU para o seu idioma ou melhorar uma tradução existente, - Os arquivos no diretório `kernel` são [GPL-2](https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html) -- Todas as outras partes, exceto o diretório `kernel`, são [GPL-3](https://www.gnu.org/licenses/gpl-3.0.html) +- Todas as outras partes, exceto o diretório `kernel` são [GPL-3](https://www.gnu.org/licenses/gpl-3.0.html) ## Créditos diff --git a/website/docs/pt_BR/guide/app-profile.md b/website/docs/pt_BR/guide/app-profile.md index 3ded7b01..af45f261 100644 --- a/website/docs/pt_BR/guide/app-profile.md +++ b/website/docs/pt_BR/guide/app-profile.md @@ -16,7 +16,7 @@ Os usuários com UID 0 são conhecidos como usuários root e os grupos com GID 0 No caso do sistema Android, cada app é um usuário separado (excluindo cenários de UID compartilhados) com um UID exclusivo. Por exemplo, `0` representa o usuário root, `1000` representa `system`, `2000` representa o ADB shell e UIDs variando de `10.000` a `19.999` representam apps comuns. -:::informações +:::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,7 +31,7 @@ uid=2000(shell) gid=2000(shell) groups=2000(shell),1004(input),1007(log),1011(ad Aqui, o UID é `2000` e o GID (ID do grupo primário) também é `2000`. Além disso, pertence a vários grupos suplementares, como `inet` (indicando a capacidade de criar soquetes `AF_INET` e `AF_INET6`) e `sdcard_rw` (indicando permissões de leitura/gravação para o cartão SD). -O Perfil Raiz do KernelSU permite a personalização do UID, GID e grupos para o processo raiz após a execução de `su`. Por exemplo, o Perfil Raiz de um app raiz pode definir seu UID como `2000`, o que significa que ao usar `su`, as permissões reais do app estão no nível do ADB shell. O grupo `inet` pode ser removido, evitando que o comando `su` acesse a rede. +O Perfil Raiz do KernelSU permite a personalização do UID, GID e grupos para o processo 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. @@ -47,7 +47,7 @@ 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 habilitadas e desabilitadas 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 de `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 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. @@ -57,7 +57,7 @@ Capacidade do Linux [documentação oficial](https://man7.org/linux/man-pages/ma ### SELinux -SELinux é um poderoso mecanismo de Controle de Acesso Obrigatório (MAC). Ele opera com base no princípio de **negação padrão**: qualquer ação não explicitamente permitida é negada. +SELinux é um poderoso mecanismo do Controle de Acesso Obrigatório (MAC). Ele opera com base no princípio de **negação padrão**: qualquer ação não explicitamente permitida é negada. O SELinux pode ser executado em dois modos globais: @@ -65,16 +65,16 @@ O SELinux pode ser executado em dois modos globais: 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.. +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. ::: -Explicar o conceito completo do SELinux é complexo e está além do escopo deste documento. Recomenda-se primeiro entender seu funcionamento através dos seguintes recursos: +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) 3. [ArchLinux: SELinux](https://wiki.archlinux.org/title/SELinux) -O Perfil Raiz do KernelSU permite a personalização do contexto SELinux do processo raiz 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 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. 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: @@ -85,13 +85,13 @@ typeattribute app1 mlstrustedsubject allow app1 * * * ``` -Observe que a regra `allow app1 * * *` é usada apenas para fins de demonstração. Na prática, esta regra não deve ser utilizada extensivamente, pois não difere muito do modo permissivo. +Observe que a regra `allow app1 * * *` é usada apenas para fins de demonstração. Na prática, esta regra não deve ser utilizada extensivamente, pois não difere muito do Modo permissivo. ### 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. -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 shell ADB) , 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 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: 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. @@ -99,20 +99,20 @@ Por exemplo, se você conceder permissão root a um usuário shell ADB (que é u :::warning OBSERVAÇÃO Este comportamento é totalmente esperado e não é um bug. Portanto, recomendamos o seguinte: -Se você realmente precisa conceder permissões de root ao ADB (por exemplo, como desenvolvedor), não é aconselhável alterar o UID para `2000` ao configurar o Perfil Raiz. Usar `1000` (sistema) seria uma escolha melhor. +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. ::: ## Perfil não Raiz ### Desmontar Módulos -O KernelSU fornece um mecanismo sem sistema para modificar partições do sistema, obtido através da montagem overlayfs. No entanto, alguns apps podem ser sensíveis a esse comportamento. Assim, podemos descarregar módulos montados nesses apps configurando a opção “desmontar módulo”. +O KernelSU fornece um mecanismo sem sistema para modificar partições do sistema, obtido através da montagem de overlayfs. No entanto, alguns apps podem ser sensíveis a esse comportamento. Assim, podemos descarregar módulos montados nesses apps configurando a opção “desmontar módulo”. Além disso, a interface de configurações do gerenciador KernelSU fornece uma opção para "desmontar módulos por padrão". Por padrão, essa opção está **ativada**, o que significa que o KernelSU ou alguns módulos descarregarão módulos para este app, a menos que configurações adicionais sejam aplicadas. Se você não preferir esta configuração ou se ela afetar determinados apps, você terá as seguintes opções: -1. Mantenha a opção "desmontar módulos por padrão" e desative individualmente a opção "desmontar módulos" no Perfil do Aplicativo para apps que exigem carregamento de módulo (agindo como uma "lista de permissões"). -2. Desative a opção "desmontar módulos por padrão" e ative individualmente a opção "desmontar módulos" no Perfil do Aplicativo para apps que exigem descarregamento de módulo (agindo como uma "lista negra"). +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"). -:::INFORMAÇÕES +:::info INFORMAÇÕES Em dispositivos que utilizam kernel versão 5.10 e superior, o kernel realiza o descarregamento dos módulos. No entanto, para dispositivos que executam versões de kernel abaixo de 5.10, essa opção é apenas uma opção de configuração e o próprio KernelSU não executa nenhuma ação. Alguns módulos, como Zygisksu, podem usar essa opção para determinar se o descarregamento do módulo é necessário. ::: diff --git a/website/docs/pt_BR/guide/difference-with-magisk.md b/website/docs/pt_BR/guide/difference-with-magisk.md index 7d882053..ed919997 100644 --- a/website/docs/pt_BR/guide/difference-with-magisk.md +++ b/website/docs/pt_BR/guide/difference-with-magisk.md @@ -11,17 +11,17 @@ Embora existam muitas semelhanças entre os módulos KernelSU e os módulos Magi - 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" habilitado em ambos os casos +- 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 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, 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`. 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 [ZygiskOnKernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU). -- O método para substituir ou excluir arquivos nos módulos KernelSU é completamente diferente do Magisk. 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. +- 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. diff --git a/website/docs/pt_BR/guide/faq.md b/website/docs/pt_BR/guide/faq.md index adece27a..c74d3dce 100644 --- a/website/docs/pt_BR/guide/faq.md +++ b/website/docs/pt_BR/guide/faq.md @@ -49,7 +49,7 @@ Achamos que não e esse não é o nosso objetivo. Magisk é bom o suficiente par ## Como integrar o KernelSU para o kernel antigo? -Por favor, consulte [guia](how-to-integrate-for-non-gki) +Por favor, consulte a guia [Como integrar o KernelSU para kernels não GKI](how-to-integrate-for-non-gki) ## Por que minha versão do Android é 13 e o kernel mostra “android12-5.10”? diff --git a/website/docs/pt_BR/guide/hidden-features.md b/website/docs/pt_BR/guide/hidden-features.md new file mode 100644 index 00000000..25ae2c1f --- /dev/null +++ b/website/docs/pt_BR/guide/hidden-features.md @@ -0,0 +1,7 @@ +# Recursos ocultos + +## .ksurc + +Por padrão, `/system/bin/sh` carrega `/system/etc/mkshrc`. + +Você pode fazer su carregar um arquivo rc personalizado criando um arquivo `/data/adb/ksu/.ksurc`. diff --git a/website/docs/pt_BR/guide/how-to-build.md b/website/docs/pt_BR/guide/how-to-build.md index ad32e175..e4df9b17 100644 --- a/website/docs/pt_BR/guide/how-to-build.md +++ b/website/docs/pt_BR/guide/how-to-build.md @@ -5,8 +5,8 @@ Primeiro, você deve ler a documentação oficial do Android para construção d 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) -::: aviso -Esta página é para dispositivos GKI, se você usa um kernel antigo, consulte [como integrar o KernelSU para kernel antigo](how-to-integrate-for-non-gki) +::: 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 @@ -24,7 +24,7 @@ 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) first. +Por favor, verifique os [documentos oficiais](https://source.android.com/docs/setup/build/building-kernels) primeiro. Por exemplo, precisamos construir a imagem do kernel aarch64: 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 8e486170..ea56e2e4 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 @@ -37,7 +37,7 @@ Mas se você encontrar um loop de inicialização quando o KernelSU integrado, t :::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. +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. ::: ## Modifique manualmente a fonte do kernel @@ -221,7 +221,7 @@ index 2ff887661237..e758d7db7663 100644 Para ativar o Modo de Segurança integrado do KernelSU, você também deve modificar `input_handle_event` em `drivers/input/input.c`: -:::dica +:::tip DICA É altamente recomendável ativar este recurso, é muito útil para evitar bootloops! ::: diff --git a/website/docs/pt_BR/guide/installation.md b/website/docs/pt_BR/guide/installation.md index 111daee9..f9e0ab7e 100644 --- a/website/docs/pt_BR/guide/installation.md +++ b/website/docs/pt_BR/guide/installation.md @@ -2,20 +2,20 @@ ## Verifique se o seu dispositivo é compatível -Baixe o app gerenciador KernelSU em [Lançamentos do GitHub](https://github.com/tiann/KernelSU/releases) ou [Coolapk market](https://www.coolapk.com/apk/me.weishu.kernelsu), e instale-o no seu dispositivo: +Baixe o app gerenciador KernelSU em [GitHub Releases](https://github.com/tiann/KernelSU/releases) ou [Coolapk market](https://www.coolapk.com/apk/me.weishu.kernelsu), e instale-o no seu dispositivo: -- Se o app mostrar `Sem suporte`, significa que **Você deve compilar o kernel sozinho**, o KernelSU não fornecerá e nunca fornecerá uma imagem de inicialização para você atualizar. +- Se o app mostrar `Sem suporte`, significa que **Você deve compilar o kernel sozinho**, o KernelSU não fornecerá e nunca fornecerá uma boot image para você atualizar. - Se o app mostrar `Não instalado`, então seus dispositivos são oficialmente suportados pelo KernelSU. -:::informações -Para dispositivos mostrando `Sem suporte`, aqui está um [Dispositivos com suporte não oficial](unofficially-support-devices.md), você mesmo pode compilar o kernel. +::: 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. ::: ## Backup padrão 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. -::: aviso +::: 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. ::: @@ -39,7 +39,7 @@ w .x .y -zzz -k -something `w.x-zzz-k` é a versão KMI. Por exemplo, se a versão do kernel de um dispositivo for `5.10.101-android12-9-g30979850fc20`, então seu KMI será `5.10-android12-9`; teoricamente, ele pode inicializar normalmente com outros kernels KMI. -::: dica +::: tip DICA Observe que o SubLevel na versão do kernel não faz parte do KMI! Isso significa que `5.10.101-android12-9-g30979850fc20` tem o mesmo KMI que `5.10.137-android12-9-g30979850fc20`! ::: @@ -99,7 +99,7 @@ Você pode baixar o boot.img em [Lançamento do GitHub](https://github.com/tiann Onde `` se refere ao formato de compactação do kernel do seu boot.img oficial, verifique o formato de compactação do kernel do seu boot.img original, você deve usar o formato correto, por exemplo. `lz4`, `gz`; se você usar um formato de compactação incorreto, poderá encontrar bootloop. -::: informações +::: info INFORMAÇÕES 1. Você pode usar o magiskboot para obter o formato de compactação da sua inicialização original; é claro que você também pode perguntar a outras crianças mais experientes com o mesmo modelo do seu dispositivo. Além disso, o formato de compactação do kernel geralmente não muda; portanto, se você inicializar com êxito com um determinado formato de compactação, poderá tentar esse formato mais tarde. 2. Os dispositivos Xiaomi geralmente usam `gz` ou **uncompressed**. 3. Para dispositivos Pixel, siga as instruções abaixo. @@ -113,7 +113,7 @@ Use `adb` para conectar seu dispositivo, execute `adb reboot bootloader` para en fastboot flash boot boot.img ``` -::: informações +::: 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. ::: @@ -152,7 +152,7 @@ Entre eles, o Android-Image-Kitchen é adequado para operação no PC e o magisk ### Usando magiskboot -1. Baixe o Magisk mais recente em [Página de lançamento](https://github.com/topjohnwu/Magisk/releases) +1. Baixe o Magisk mais recente em [GitHub Releases](https://github.com/topjohnwu/Magisk/releases) 2. Renomeie o Magisk-*.apk para Magisk-vesion.zip e descompacte-o. 3. Envie `Magisk-v25.2/lib/arm64-v8a/libmagiskboot.so` para o seu dispositivo por adb: `adb push Magisk-v25.2/lib/arm64-v8a/libmagiskboot.so /data/local/tmp/magiskboot` 4. Envie stock boot.img e Image em AnyKernel3 para o seu dispositivo. diff --git a/website/docs/pt_BR/guide/module.md b/website/docs/pt_BR/guide/module.md index 2d60fb66..22a00dad 100644 --- a/website/docs/pt_BR/guide/module.md +++ b/website/docs/pt_BR/guide/module.md @@ -17,7 +17,7 @@ Para aqueles que desejam usar este recurso “Modo Autônomo” fora do KernelSU Para garantir que todos os shells `sh` subsequentes executados também sejam executados em modo autônomo, a opção 1 é o método preferido (e é isso que o KernelSU e o gerenciador KernelSU usam internamente), pois as variáveis ​​de ambiente são herdadas para os subprocesso. -::: tip Diferença com Magisk +::: tip DIFERENÇA COM MAGISK O BusyBox do KernelSU agora está usando o arquivo binário compilado diretamente do projeto Magisk. **Obrigado ao Magisk!** Portanto, você não precisa se preocupar com problemas de compatibilidade entre scripts BusyBox no Magisk e KernelSU porque eles são exatamente iguais! ::: @@ -78,7 +78,7 @@ Um módulo KernelSU é uma pasta colocada em `/data/adb/modules` com a estrutura ├── . ``` -::: tip Diferença com Magisk +::: tip DIFERENÇA COM MAGISK O KernelSU não possui suporte integrado para o Zygisk, portanto não há conteúdo relacionado ao Zygisk no módulo. No entanto, você pode usar [ZygiskOnKernelSU](https://github.com/Dr-TSNG/ZygiskOnKernelSU) para suportar módulos Zygisk. Neste caso, o conteúdo do módulo Zygisk é idêntico ao suportado pelo Magisk. ::: @@ -108,8 +108,8 @@ Por favor, leia a seção [Scripts de inicialização](#boot-scripts) para enten Em todos os scripts do seu módulo, use `MODDIR=${0%/*}` para obter o caminho do diretório base do seu módulo; **NÃO** codifique o caminho do seu módulo em scripts. -::: tip Diferença com Magisk -Você pode usar a variável de ambiente `KSU` para determinar se um script está sendo executado no KernelSU ou Magisk. Se estiver executando em KernelSU, esse valor será definido como `true`. +::: tip DIFERENÇA COM MAGISK +Você pode usar a variável de ambiente `KSU` para determinar se um script está sendo executado no KernelSU ou Magisk. Se estiver executando no KernelSU, esse valor será definido como `true`. ::: ### Diretório `system` @@ -145,7 +145,7 @@ 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ça com Magisk +::: tip DIFERENÇA COM MAGISK O mecanismo sem sistema do KernelSU é implementado através do overlayfs do kernel, enquanto o Magisk atualmente usa montagem mágica (montagem de ligação). Os dois métodos de implementação têm diferenças significativas, mas o objetivo final é o mesmo: modificar os arquivos /system sem modificar fisicamente a partição /system. ::: @@ -160,9 +160,9 @@ Este arquivo segue o mesmo formato de `build.prop`. Cada linha é composta por ` Se o seu módulo exigir alguns patches adicionais de sepolicy, adicione essas regras a este arquivo. Cada linha neste arquivo será tratada como uma declaração de política. -## Instalador de módulo +## Instalador do módulo -Um instalador de módulo KernelSU é um módulo KernelSU empacotado em um arquivo zip que pode ser atualizado no app gerenciador KernelSU. O instalador de módulo KernelSU mais simples é apenas um módulo KernelSU compactado como um arquivo zip. +Um instalador do módulo KernelSU é um módulo KernelSU empacotado em um arquivo zip que pode ser atualizado no app gerenciador KernelSU. O instalador do módulo KernelSU mais simples é apenas um módulo KernelSU compactado como um arquivo zip. ```txt module.zip @@ -174,8 +174,8 @@ module.zip │ ``` -:::aviso -O módulo KernelSU **NÃO** é compatível para instalação no recovery personalizado! +::: warning AVISO +O módulo KernelSU **NÃO** é compatível para instalação no Recovery personalizado! ::: ### Costumização @@ -200,7 +200,7 @@ O script `customize.sh` é executado no shell BusyBox `ash` do KernelSU com o "M - `IS64BIT` (bool): `true` se `$ARCH` for `arm64` ou `x64` - `API` (int): o nível da API (versão do Android) do dispositivo (por exemplo, `23` para Android 6.0) -::: aviso +::: warning AVISO No KernelSU, `MAGISK_VER_CODE` é sempre `25200` e `MAGISK_VER` é sempre `v25.2`. Por favor, não use essas duas variáveis ​​para determinar se ele está sendo executado no KernelSU ou não. ::: diff --git a/website/docs/pt_BR/guide/unofficially-support-devices.md b/website/docs/pt_BR/guide/unofficially-support-devices.md index be7880eb..63a34bf0 100644 --- a/website/docs/pt_BR/guide/unofficially-support-devices.md +++ b/website/docs/pt_BR/guide/unofficially-support-devices.md @@ -1,10 +1,10 @@ # Dispositivos com suporte não oficial -::: aviso +::: warning AVISO Nesta página, existem kernels para dispositivos não GKI que suportam o KernelSU mantidos por outros desenvolvedores. ::: -::: aviso +::: 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. ::: diff --git a/website/docs/pt_BR/guide/what-is-kernelsu.md b/website/docs/pt_BR/guide/what-is-kernelsu.md index 3ae3ad61..e217ca84 100644 --- a/website/docs/pt_BR/guide/what-is-kernelsu.md +++ b/website/docs/pt_BR/guide/what-is-kernelsu.md @@ -14,7 +14,7 @@ Por favor, consulte: [Instalação](installation) ## Como construir -[Como construir](how-to-build) +[Como construir o KernelSU](how-to-build) ## Discussão