Guias de módulo

O ShizuSU 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 ShizuSU é quase o mesmo do Magisk. Se você já está familiarizado com o desenvolvimento de módulos Magisk, o desenvolvimento de módulos ShizuSU é muito semelhante. Você pode pular a introdução dos módulos abaixo e só precisa ler Diferenças com Magisk.

SISTEMA DE MÓDULOS BASEADO EM MAGIC MOUNT

O sistema de módulos do ShizuSU é baseado no Magic Mount (do SukiSU-Ultra); não é necessário instalar metamodule para montar o diretório system. Módulos que modificam arquivos /system funcionam imediatamente. Veja Sistema de Módulos: Magic Mount.

Módulos de kernel KPM

Os KernelPatch Modules (KPM) permitem carregar módulos diretamente no nível do kernel, ideais para modificações e melhorias avançadas do kernel. O ShizuSU tem suporte total a KPM (portado do Apatch). Para usar KPM, habilite CONFIG_KPM=y ao compilar o kernel.

WebUI

Os módulos do ShizuSU suportam a exibição de interfaces e a interação com os usuários. Para mais detalhes, consulte a documentação do WebUI.

Configuração de Módulo

O ShizuSU fornece um sistema de configuração integrado que permite que os módulos armazenem configurações de chave-valor persistentes ou temporárias. Para mais detalhes, consulte a documentação de Configuração de Módulo.

BusyBox

O ShizuSU 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 ShizuSU suporta "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 em 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 shell executado no contexto do ShizuSU será executado no shell ash do BusyBox com o Modo Autônomo ativado. Para o que é relevante para desenvolvedores terceirizados, isso inclui todos os scripts de inicialização e scripts de instalação de módulos.

Para aqueles que desejam usar o recurso Modo Autônomo fora do ShizuSU, existem 2 maneiras de ativá-los:

Definir a variável de ambiente ASH_STANDALONE como 1.
Exemplo: ASH_STANDALONE=1 /data/adb/ksu/bin/busybox sh <script>
Alternar com opções de linha de comando:
/data/adb/ksu/bin/busybox sh -o standalone <script>

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 ShizuSU e o gerenciador do ShizuSU usam internamente), pois as variáveis de ambiente são herdadas para os subprocesso.

DIFERENÇAS COM MAGISK

O BusyBox do ShizuSU 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 ShizuSU porque eles são exatamente iguais!

Módulos ShizuSU

Um módulo ShizuSU é uma pasta colocada em /data/adb/modules com a estrutura abaixo:

txt

/data/adb/modules
├── .
├── .
|
├── $MODID                  <--- A pasta é nomeada com o ID do módulo
│   │
│   │      *** Identidade do módulo ***
│   │
│   ├── module.prop         <--- Este arquivo armazena os metadados do módulo
│   │
│   │      *** Conteúdo principal ***
│   │
│   ├── system              <--- Esta pasta será montada se skip_mount não existir
│   │   ├── ...
│   │   ├── ...
│   │   └── ...
│   │
│   │      *** Sinalizadores de status ***
│   │
│   ├── skip_mount          <--- Se existir, o ShizuSU não montará sua pasta de sistema
│   ├── disable             <--- Se existir, o módulo será desativado
│   ├── remove              <--- Se existir, o módulo será removido na próxima reinicialização
│   │
│   │      *** Arquivos opcionais ***
│   │
│   ├── post-fs-data.sh     <--- Este script será executado em post-fs-data
│   ├── post-mount.sh       <--- Este script será executado em post-mount
│   ├── 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 ShizuSU remover seu módulo
|   ├── action.sh           <--- Este script será executado quando o usuário clicar no botão Ação no ShizuSU
│   ├── system.prop         <--- As propriedades neste arquivo serão carregadas como propriedades do sistema por resetprop
│   ├── sepolicy.rule       <--- Regras adicionais do sepolicy personalizadas
│   ├── initrc/             <--- Arquivos .rc neste diretório serão injetados no init.rc no boot
│   │   ├── myservice.rc
│   │   └── ...
│   │
│   │      *** Gerado automaticamente, NÃO CRIE OU MODIFIQUE MANUALMENTE ***
│   │
│   ├── vendor              <--- Um link simbólico para $MODID/system/vendor
│   ├── product             <--- Um link simbólico para $MODID/system/product
│   ├── system_ext          <--- Um link simbólico para $MODID/system/system_ext
│   │
│   │      *** Quaisquer arquivos/pastas adicionais são permitidos ***
│   │
│   ├── ...
│   └── ...
|
├── another_module
│   ├── .
│   └── .
├── .
├── .

DIFERENÇAS COM MAGISK

O ShizuSU 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 ZygiskNext para suportar módulos Zygisk. Neste caso, o conteúdo do módulo Zygisk é idêntico ao suportado pelo Magisk.

module.prop

module.prop é um arquivo de configuração para um módulo. No ShizuSU, se um módulo não contiver este arquivo, ele não será reconhecido como um módulo. O formato deste arquivo é o seguinte:

txt

id=<string>
name=<string>
version=<string>
versionCode=<int>
author=<string>
description=<string>
updateJson=<url> (opcional)
actionIcon=<path> (opcional)
webuiIcon=<path> (opcional)

id deve corresponder a esta expressão regular: ^[a-zA-Z][a-zA-Z0-9._-]+$
Exemplo: ✓ a_module, ✓ a.module, ✓ module-101, ✗ a module, ✗ 1_module, ✗ -a-module
Este é o identificador exclusivo do seu módulo. Você não deve alterá-lo depois de publicado.
versionCode deve ser um número inteiro. Isso é usado para comparar versões.
Outros que não foram mencionados acima podem ser qualquer string de linha única.
Certifique-se de usar o tipo de quebra de linha UNIX (LF) e não o Windows (CR+LF) ou Macintosh (CR).
actionIcon e webuiIcon são caminhos de imagem opcionais usados como ícones padrão para o atalho de ação do módulo e o atalho WebUI do módulo no aplicativo gerenciador. Esses caminhos devem ser relativos ao diretório raiz do módulo. Por exemplo, actionIcon=icon/icon.png será resolvido como <MODDIR>/icon/icon.png.

DESCRIÇÃO DINÂMICA

O campo description pode ser substituído dinamicamente em tempo de execução usando o sistema de configuração de módulos. Veja Substituindo a Descrição do Módulo para detalhes.

Shell scripts

Por favor, leia a seção Scripts de inicialização para entender a diferença entre post-fs-data.sh e service.sh. Para a maioria dos desenvolvedores de módulos, service.sh deve ser bom o suficiente se você precisar apenas executar um script de inicialização. Se precisar executar o script após a inicialização ser concluída, use boot-completed.sh. Se você quiser fazer algo após a montagem dos módulos, use post-mount.sh.

Em todos os scripts do seu módulo, use MODDIR=${0%/*} para obter o caminho do diretório base do seu módulo, NÃO codifique o caminho do seu módulo nos scripts.

DIFERENÇAS COM MAGISK

Você pode usar a variável de ambiente KSU para determinar se um script está sendo executado no ShizuSU ou Magisk. Se estiver executando no ShizuSU, esse valor será definido como true.

Diretório `system`

O conteúdo deste diretório será sobreposto à partição /system do sistema usando Magic Mount (bind mount) após a inicialização do sistema. Isso significa que:

Arquivos com o mesmo nome daqueles no diretório correspondente no sistema serão substituídos pelos arquivos deste diretório.
Pastas com o mesmo nome daquelas no diretório correspondente no sistema serão mescladas com as pastas neste diretório.

Se você deseja excluir um arquivo ou pasta no diretório original do sistema, você pode declarar uma variável REMOVE contendo uma lista de diretórios em customize.sh. O ShizuSU ocultará esses arquivos via Magic Mount (a partição /system não é realmente alterada).

REMOVE="
/system/app/YouTube
/system/app/Bloatware
"

/system/app/YouTube e /system/app/Bloatware serão ocultados após o módulo entrar em vigor.

Se você deseja substituir um diretório no sistema, você pode declarar uma variável REPLACE em customize.sh. O ShizuSU fará bind mount de um diretório vazio sobre o caminho de destino, substituindo-o por completo (sem alterar a partição /system).

REPLACE="
/system/app/YouTube
/system/app/Bloatware
"

/system/app/YouTube e /system/app/Bloatware serão substituídos por diretórios vazios após o módulo entrar em vigor.

DIFERENÇAS COM MAGISK

O KernelSU oficial usa um mecanismo OverlayFS (metamodule) para modificações systemless, enquanto o ShizuSU, baseado no SukiSU-Ultra, usa Magic Mount (bind mount), como o Magisk. Ambas as abordagens têm o mesmo objetivo: modificar os arquivos /system sem modificar fisicamente a partição /system. O ShizuSU usa apenas Magic Mount — não existem dois sistemas de módulos. Veja Sistema de Módulos: Magic Mount.

system.prop

Este arquivo segue o mesmo formato de build.prop. Cada linha é composta por [key]=[value].

sepolicy.rule

Se o seu módulo exigir alguns patches adicionais do sepolicy, adicione essas regras a este arquivo. Cada linha neste arquivo será tratada como uma declaração de política.

Injeção de initrc

O ShizuSU fornece um mecanismo para injetar diretivas RC customizadas do Android Init no init.rc do sistema. Isso permite que os módulos registrem serviços Android customizados, definam gatilhos de propriedade ou executem outras ações de linguagem Init sem modificar a partição do sistema.

Durante a inicialização, o módulo do kernel ShizuSU intercepta as chamadas de sistema read() e fstat(). Quando o processo init do Android lê /system/etc/init/hw/init.rc, o ShizuSU adiciona de forma transparente o conteúdo RC customizado ao final do arquivo. O processo init analisa essas diretivas injetadas exatamente como o conteúdo original do init.rc.

No lado do espaço do usuário, o ksud concatena todos os arquivos .rc de módulos habilitados em um único arquivo modules.rc, armazenado na partição /metadata. Este arquivo é regenerado automaticamente sempre que o estado de um módulo muda (instalar, habilitar, desabilitar, desinstalar, etc.).

Arquivos initrc do módulo

Crie um subdiretório initrc/ no diretório do seu módulo e coloque seus arquivos .rc lá:

txt

/data/adb/modules/<MODID>/
├── initrc/
│   ├── myservice.rc
│   └── another.rc
└── ...

TIP

Os arquivos devem ter uma extensão .rc.
Contanto que o módulo esteja habilitado, todos os arquivos .rc no diretório initrc/ serão incluídos (permissão de execução não é necessária).
Os arquivos são processados em ordem alfabética de nome de arquivo dentro do diretório, e os módulos são processados em ordem alfabética de ID do módulo.

Arquivos initrc gerais

Além de arquivos RC no nível do módulo, você pode colocar arquivos .rc no diretório global:

txt

/data/adb/initrc.d/
├── myservice.rc
└── another.rc

Arquivos initrc gerais requerem permissão de execução

Diferente do diretório initrc/ do módulo, arquivos em /data/adb/initrc.d/ devem ter permissões de execução para serem incluídos. Arquivos .rc não executáveis serão ignorados silenciosamente.

Arquivos initrc.d/ gerais são processados antes de quaisquer arquivos RC de módulo.

Exemplo

Aqui está um exemplo de arquivo .rc que registra um serviço Android customizado:

service myservice /data/adb/modules/mymodule/bin/myservice
    user root
    group root
    disabled
    seclabel u:r:ksu:s0

on property:sys.boot_completed=1
    start myservice

Se este arquivo for colocado em /data/adb/modules/mymodule/initrc/myservice.rc, ele registrará um serviço chamado myservice na inicialização e o iniciará quando sys.boot_completed=1 for alcançado.

Atualização Manual

Você pode acionar manualmente a regeneração do modules.rc com o seguinte comando (as alterações entram em vigor na próxima inicialização):

ksud initrc refresh

TIP

A injeção de initrc acontece extremamente cedo no processo de inicialização (quando o init lê o init.rc), antes do post-fs-data e de quaisquer scripts de módulo serem executados.
O conteúdo RC injetado é tratado pelo init como parte do init.rc original, suportando toda a sintaxe da linguagem Android Init (definições de serviço, gatilhos, configurações de propriedades, etc.).
A injeção de initrc não está disponível no modo late-load, pois os ganchos de chamada do sistema não são instalados nesse modo.
A injeção de RC do módulo pode ser desabilitada passando o parâmetro --no-custom-rc ao aplicar patch na imagem com o ksud.

Instalador do módulo

Um instalador do módulo ShizuSU é um módulo ShizuSU empacotado em um arquivo ZIP que pode ser atualizado no gerenciador do ShizuSU. O instalador do módulo ShizuSU mais simples é apenas um módulo ShizuSU compactado como um arquivo ZIP.

txt

module.zip
│
├── customize.sh                       <--- (Opcional, mais detalhes posteriormente)
│                                           Este script será fornecido por update-binary
├── ...
├── ...  /* O resto dos arquivos do módulo */
│

AVISO

O módulo ShizuSU NÃO é compatível para instalação no Recovery personalizado!

Personalização

Se você precisar personalizar o processo de instalação do módulo, opcionalmente você pode criar um script no instalador chamado customize.sh. Este script será sourced (não executado) pelo script do instalador do módulo depois que todos os arquivos forem extraídos e as permissões padrão e o contexto secundário forem aplicados. Isso é muito útil se o seu módulo exigir configuração adicional com base na ABI do dispositivo ou se você precisar definir permissões/secontext especiais para alguns dos arquivos do seu módulo.

Se você quiser controlar e personalizar totalmente o processo de instalação, declare SKIPUNZIP=1 em customize.sh para pular todas as etapas de instalação padrão. Ao fazer isso, seu customize.sh será responsável por instalar tudo sozinho.

O script customize.sh é executado no shell BusyBox ash do ShizuSU com o Modo Autônomo ativado. As seguintes variáveis e funções estão disponíveis:

Variáveis

KSU (bool): uma variável para marcar que o script está sendo executado no ambiente ShizuSU, e o valor desta variável sempre será true. Você pode usá-lo para distinguir entre ShizuSU e Magisk.
KSU_VER (string): a string da versão do ShizuSU atualmente instalado (ex.: v0.4.0).
KSU_VER_CODE (int): o código da versão do ShizuSU atualmente instalado no espaço do usuário (ex.: 10672).
KSU_KERNEL_VER_CODE (int): o código da versão do ShizuSU atualmente instalado no espaço do kernel (ex.: 10672).
BOOTMODE (bool): sempre será true no ShizuSU.
MODPATH (path): o caminho onde os arquivos do seu módulo devem ser instalados.
TMPDIR (path): um lugar onde você pode armazenar arquivos temporariamente.
ZIPFILE (path): ZIP de instalação do seu módulo.
ARCH (string): a arquitetura da CPU do dispositivo. O valor é arm, arm64, x86 ou x64.
IS64BIT (bool): true se $ARCH for arm64 ou x64.
API (int): o nível da API (versão do Android) do dispositivo (ex.: 23 para Android 6.0).
KSU_UAPI_VER (int): a versão UAPI do espaço do usuário do ShizuSU (ksud) (ex.: 2). Esta versão é incrementada quando há alterações que quebram a compatibilidade no driver do kernel, e pode ser usada pelos módulos para verificar compatibilidade.
KSU_RUNTIME_MODE (string): o modo de execução atual do ShizuSU. Os valores possíveis são built-in (modo GKI, compilado no kernel), lkm (carregado como módulo do kernel na inicialização) ou late-load (carregado como módulo do kernel após a inicialização).
KSU_LATE_LOAD (int?): se o ShizuSU foi carregado tardiamente após a inicialização, esta variável é definida como 1; caso contrário, não é definida.

AVISO

No ShizuSU, 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 ShizuSU ou não.

Funções

txt

ui_print <msg>
    imprima <msg> no console
    Evite usar 'echo', pois ele não será exibido no console de recovery personalizado

abort <msg>
    imprima mensagem de erro <msg> para consolar e encerrar a instalação
    Evite usar 'exit', pois isso irá pular as etapas de limpeza de encerramento

set_perm <target> <owner> <group> <permission> [context]
    se [context] não estiver definido, o padrão é "u:object_r:system_file:s0"
    esta função é uma abreviação para os seguintes comandos:
       chown owner.group target
       chmod permission target
       chcon context target

set_perm_recursive <directory> <owner> <group> <dirpermission> <filepermission> [context]
    se [context] não está definido, o padrão é "u:object_r:system_file:s0"
    para todos os arquivos em <directory>, ele chamará:
       set_perm arquivo proprietário do grupo filepermission
    para todos os diretórios em <directory> (incluindo ele mesmo), ele vai ligar:
       set_perm dir owner group dirpermission context

Scripts de inicialização

No ShizuSU, 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 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.
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.

No ShizuSU, os scripts de inicialização são divididos em dois tipos com base no local de armazenamento: scripts gerais e scripts de módulo.

Scripts gerais
- Colocado em /data/adb/post-fs-data.d, /data/adb/service.d, /data/adb/post-mount.d ou /data/adb/boot-completed.d.
- Somente executado se o script estiver definido como executável (chmod +x script.sh).
- Os scripts em post-fs-data.d são executados no modo post-fs-data e os scripts em service.d são executados no modo de serviço late_start.
- Os módulos NÃO devem adicionar scripts gerais durante a instalação.
Scripts de módulo
- Colocado na própria pasta do módulo.
- Executado apenas se o módulo estiver ativado.
- post-fs-data.sh é executado no modo post-fs-data, service.sh é executado no modo de serviço late_start, boot-completed.sh é executado na inicialização concluída e post-mount.sh é executado quando a montagem dos módulos é concluída.

Todos os scripts de inicialização serão executados no shell BusyBox ash do ShizuSU com o Modo Autônomo ativado.

Explicação do processo de scripts de inicialização

A seguir está o processo de inicialização relevante para o Android (algumas partes foram omitidas), que inclui a operação do ShizuSU (com asteriscos iniciais) e pode ajudá-lo a entender melhor o propósito desses scripts de módulo:

txt

0. Bootloader (nada nesta tela)
load patched boot.img
load kernel:
    - Modo GKI: kernel GKI com ShizuSU integrado
    - Modo LKM: kernel stock
...

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.
property-init -> read default props
read init.rc
  *initrc injection: Kernel hook appends ShizuSU core RC and module modules.rc to init.rc
...
early-init -> init -> late_init
early-fs
   start vold
fs
  mount /vendor, /system, /persist, etc.
post-fs-data
  *verificação do modo de segurança
  *executar scripts gerais em post-fs-data.d/
  *carregar sepolicy.rule
  *montar tmpfs
  *executar scripts de módulo post-fs-data.sh
    **(Zygisk)./bin/zygisk-ptrace64 monitor
  *(pré)carregamento de system.prop (igual a resetprop -n)
  *remontar módulos em /system
  *executar scripts gerais em post-mount.d/
  *executar scripts de módulo post-mount.sh
zygote-start
load_all_props_action
  *executar resetprop (defina adereços reais para resetprop com a opção -n)
... -> boot
  class_start core
    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)
*executar scripts gerais em service.d/
*executar scripts de módulo service.sh
*definir adereços para resetprop sem a opção -p
  **(Zygisk) hook zygote (iniciar o zygiskd)
  **(Zygisk) montar zygisksu/module.prop
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
iniciar apps de usuário (início automático)

Se você estiver interessado na linguagem de inicialização do Android, é recomendável ler sua documentação.

Modo late-load

Além do fluxo de inicialização padrão descrito acima, o ShizuSU suporta um modo late-load para cenários de LKM (Loadable Kernel Module). Neste modo, o módulo do kernel ShizuSU é carregado após o sistema ter sido totalmente iniciado, em vez de durante o processo init.

Quando o late-load acontece?

O late-load é acionado executando o comando ksud late-load. Este comando:

Detecta a versão KMI atual e carrega o kernelsu.ko correspondente dos recursos incorporados.
Realiza a inicialização do módulo (regras SELinux, lista de permissões, features, etc.) que normalmente aconteceria durante a inicialização.

Como o sistema já está totalmente em execução, certos mecanismos de tempo de inicialização estão indisponíveis ou são desnecessários.

Diferenças em relação à inicialização padrão

Comportamento	Inicialização padrão	Modo late-load
Módulo do kernel carregado pelo init (PID 1)	Sim	Não (carregado após inicialização)
Hooks kprobe do ksud (execve/read/fstat/input)	Sim	Ignorado
Detecção de modo seguro (tecla de volume)	Sim	Sempre desativado
Captura de log de inicialização (logcat/dmesg)	Sim	Ignorado
Verificação de coexistência com Magisk	Sim	Ignorado
Evento `post-fs-data` reportado ao kernel	Sim	Ignorado
Evento `boot-completed` reportado ao kernel	Sim	Definido diretamente durante init
Scripts `post-fs-data.sh` / `post-fs-data.d/`	Sim	Substituído pelo estágio `late-load`
Carregamento de `system.prop`	Sim	Sim
Montagem de módulos Magic Mount	Sim	Sim
Scripts `post-mount.sh` / `post-mount.d/`	Sim	Sim
Scripts `service.sh` / `service.d/`	Sim	Sim
Scripts `boot-completed.sh` / `boot-completed.d/`	Sim	Sim
Variável de ambiente `KSU_LATE_LOAD`	Não definida	Definida como `1`
Flag de info do kernel `0x4`	Não definida	Definida

Ordem de execução dos scripts

No modo late-load, a ordem de execução dos scripts é:

txt

ksud late-load:
  1. Carregar kernelsu.ko (se ainda não carregado)
  2. Extrair binários, processar atualizações de módulos, carregar regras SELinux, inicializar features
  3. Executar scripts late-load.d/ e scripts late-load dos módulos (bloqueante)
  4. Carregar system.prop (resetprop -n)
  5. Executar montagem de módulos Magic Mount
  6. Executar scripts post-mount.d/ e post-mount.sh dos módulos (bloqueante)
  7. Executar scripts service.d/ e service.sh dos módulos (não bloqueante)
  8. Executar scripts boot-completed.d/ e boot-completed.sh dos módulos (não bloqueante)

Scripts específicos do late-load

Módulos podem fornecer um script late-load.sh que é executado apenas no modo late-load, como substituto do post-fs-data.sh. Este script é executado antes da montagem dos módulos, similar ao post-fs-data.sh no fluxo padrão.

Além disso, scripts gerais podem ser colocados em /data/adb/late-load.d/ para serem executados neste estágio.

Detectando o modo late-load nos scripts

Módulos podem detectar o modo late-load verificando a variável de ambiente KSU_LATE_LOAD:

if [ "$KSU_LATE_LOAD" = "1" ]; then
    # Executando no modo late-load
    echo "Late-load mode detected"
fi

Isso permite que os módulos ajustem seu comportamento de acordo, por exemplo, pulando operações que só são necessárias durante a inicialização antecipada.

Conveniência de Gerenciamento de Módulos

O ShizuSU oferece vários recursos de conveniência no gerenciamento de módulos:

Backup e restauração：Backup/restauração de módulos instalados e da lista de permissões root em um toque.
Instalação em lote：Instale vários zips de módulos de uma vez; falhas individuais não interrompem o processo, sendo coletadas e relatadas ao final.
Gerenciamento em lote：Ativar, desativar, desativar todos e desinstalar todos em um toque.

Guias de módulo ​

Módulos de kernel KPM ​

WebUI ​

Configuração de Módulo ​

BusyBox ​

Módulos ShizuSU ​

module.prop ​

Shell scripts ​

Diretório system ​

system.prop ​

sepolicy.rule ​

Injeção de initrc ​

Arquivos initrc do módulo ​

Arquivos initrc gerais ​

Exemplo ​

Atualização Manual ​

Instalador do módulo ​

Personalização ​

Variáveis ​

Funções ​

Scripts de inicialização ​

Explicação do processo de scripts de inicialização ​

Modo late-load ​

Quando o late-load acontece? ​

Diferenças em relação à inicialização padrão ​

Ordem de execução dos scripts ​

Scripts específicos do late-load ​

Detectando o modo late-load nos scripts ​

Conveniência de Gerenciamento de Módulos ​

Guias de módulo

Módulos de kernel KPM

WebUI

Configuração de Módulo

BusyBox

Módulos ShizuSU

module.prop

Shell scripts

Diretório `system`

system.prop

sepolicy.rule

Injeção de initrc

Arquivos initrc do módulo

Arquivos initrc gerais

Exemplo

Atualização Manual

Instalador do módulo

Personalização

Variáveis

Funções

Scripts de inicialização

Explicação do processo de scripts de inicialização

Modo late-load

Quando o late-load acontece?

Diferenças em relação à inicialização padrão

Ordem de execução dos scripts

Scripts específicos do late-load

Detectando o modo late-load nos scripts

Conveniência de Gerenciamento de Módulos