Sobre os processos do Zigoto

O Zigoto é um processo no sistema operacional Android que atua como a raiz de todos os processos do sistema e do app com a mesma interface binária de aplicativo (ABI, na sigla em inglês).

Em dispositivos modernos, como o Pixel 7 e versões mais recentes, há um processo de Zigoto de 64 bits. Além disso, há o Zigoto do WebView para a ABI principal, que é um Zigoto especializado que contém bibliotecas e recursos específicos para processos que executam WebViews.

Confira as tarefas que o Zigoto realiza:

  1. O daemon init gera o processo do Zigoto quando o SO Android é inicializado. Em alguns sistemas de arquitetura dupla, dois processos do Zigoto (um de 64 bits e outro de 32 bits) são gerados. Esta página aborda apenas sistemas de arquitetura única.

  2. O Zigoto pode gerar imediatamente processos chamados processos de app não especializados (USAP, na sigla em inglês) ou esperar para gerar processos conforme necessário pelos aplicativos. A primeira opção precisa ser ativada por uma propriedade do sistema ou um comando do Android Debug Bridge. Para mais informações sobre como configurar o Zigoto para gerar processos imediatamente, consulte Ativar o pool de processos de app não especializados .

    • Se o pool de USAP estiver ativado no seu dispositivo:

      1. O servidor do sistema usa um soquete de domínio Unix para se conectar a um USAP disponível em um pool. O servidor do sistema solicita que o USAP seja pré-configurado para uso do aplicativo, mudando o ID do processo (PID), o cgroup e outras informações.
      2. Quando o USAP termina a pré-configuração, ele responde ao servidor do sistema com o PID.
      3. Quando um aplicativo ocupa um desses USAPs, ele não faz mais parte do pool. Quando o pool atinge um ou menos USAPs, o Zigoto o reabastece com novos USAPs.

    • Se o Zigoto gerar processos usando avaliação lenta:

      1. O servidor do sistema recebe um comando de que um app precisa de um processo.
      2. O servidor do sistema usa um soquete de domínio Unix para enviar um comando ao Zigoto apropriado.
      3. O Zigoto bifurca o processo e muda o PID, o cgroup e outras informações.
      4. Quando o processo é concluído, ele envia o PID de volta ao Zigoto, que o transmite de volta ao servidor do sistema.

Ativar o pool de USAP

Para ativar o uso do pool de USAP, faça uma destas ações:

  • Defina a propriedade do sistema dalvik.vm.usap_pool_enabled como true em /build/make/target/product/runtime_libart.mk.

  • Execute este comando:

    adb shell am broadcast -a \"com.google.android.gms.phenotype.FLAG_OVERRIDE\" --es package \"com.google.android.platform.runtime_native\" --es user \"\*\" --esa flags \"usap_pool_enabled\" --esa values \"true\" --esa types \"string\" com.google.android.gms

Quando esse recurso está ativado, cada Zigoto mantém um pool de processos bifurcados que executam as partes independentes do aplicativo do processo de inicialização.

Resolver problemas do Zigoto

Esta seção contém soluções para problemas relacionados ao Zigoto.

O Zigoto está falhando

Se o dispositivo não for reinicializado corretamente e seus registros ou relatórios de falhas mostrarem problemas com o Zigoto, é provável que você tenha feito uma mudança recente que causa falhas no initd ou no servidor do sistema. Corrigir o código deve resolver o problema.

Negações do SELinux ou falhas de E/S

O Zigoto é específico sobre a higiene do descritor do arquivo em limites de processo. Quando os descritores de arquivo estão presentes no momento da bifurcação, mas não em uma lista de permissões, usamos uma chamada do sistema dup para /dev/null para evitar que os descritores de arquivo armazenados em cache sejam usados involuntariamente para acessar arquivos recém-abertos.

Se você estiver fazendo mudanças na estrutura que incluem a tentativa de carregar recursos no Zigoto e estiver recebendo negações do SELinux ou falhas de E/S:

  • Para descritores de arquivo sem nome, inclua-os no vetor fds_to_ignore quando Restat for chamado.

  • Para descritores de arquivo nomeados:

    1. Edite WORKING_DIRECTORY/frameworks/base/core/jni/fd_utils.cpp.
    2. Adicione o caminho à lista de permissões para arquivos abertos.