A memória não inicializada em C e C++ é uma causa comum de problemas de confiabilidade, bugs de segurança de memória e vazamentos de informações. Para evitar esses problemas, o Android inicializa o máximo de memória possível.
Zero memória de espaço de usuário inicializada
Desde o Android 12, a memória da pilha é inicializada com zero em todos os códigos nativos da plataforma (incluindo JNI) e a memória heap é inicializada com zero em todos os processos nativos da plataforma (como netd ), mas não no zygote ou em aplicativos.
É altamente recomendável que aplicativos próprios e de terceiros criados com o NDK usem o sinalizador do compilador -ftrivial-auto-var-init=zero para inicializar com zero suas variáveis locais de pilha. O compilador otimiza qualquer zeragem desnecessária. Por exemplo, quando uma variável local é inicializada explicitamente (como int x = 123; a variável x é inicializada apenas uma vez). Se o programa tiver um buffer de pilha grande em um ponto de acesso de desempenho, o desenvolvedor poderá desabilitar a inicialização usando um atributo do compilador:
__attribute__((__uninitialized__)) char buf[BUFSIZ]; Os aplicativos também podem optar pela inicialização zero do heap usando o atributo de manifesto android:nativeHeapZeroInitialized . Alternativamente, a inicialização zero do heap pode ser controlada em tempo de execução com:
int mallopt(M_BIONIC_ZERO_INIT, level)Onde o nível é 0 ou 1.
Memória de kernel inicializada zero
A pilha e o heap do kernel são inicializados com zero para kernels GKI, o que é fortemente recomendado pelo CDD .
Para inicialização da pilha, o GKI usa a configuração CONFIG_INIT_STACK_ALL_ZERO , que resulta na construção do kernel usando o sinalizador do compilador -ftrivial-auto-var-init=zero . Para inicialização de heap, o GKI usa CONFIG_INIT_ON_ALLOC_DEFAULT_ON , que faz com que todas as alocações de heap de página, SLAB e SLUB sejam inicializadas com zero quando são criadas. Esta opção é efetivamente semelhante a passar init_on_alloc=1 como uma opção de inicialização do kernel.
Relatório de erros
Nossas ferramentas geram relatórios de bugs detalhados que contêm informações adicionais para ajudar na depuração. O rastreamento de pilha adicional de alocação e desalocação ajuda a entender melhor o ciclo de vida de uma determinada alocação e leva a bugs de segurança de memória causadores de raiz muito mais rapidamente.
Durante o desenvolvimento, os fornecedores devem monitorar a presença de bugs verificando /data/tombstones e logcat em busca de falhas nativas. Para obter mais informações sobre depuração de código nativo do Android, consulte as informações aqui .