La memoria no inicializada en C y C++ es una causa común de problemas de confiabilidad, errores de seguridad de la memoria y fugas de información. Para evitar estos problemas, Android inicializa la mayor cantidad de memoria posible.
Cero memoria de espacio de usuario inicializada
Desde Android 12, la memoria de pila se inicializa en cero en todos los códigos nativos de la plataforma (incluido JNI) y la memoria de almacenamiento dinámico se inicializa en cero en todos los procesos nativos de la plataforma (como netd ), pero no en el zygote ni en las aplicaciones.
Se recomienda enfáticamente que las aplicaciones propias y de terceros creadas con el NDK usen el indicador del compilador -ftrivial-auto-var-init=zero para inicializar a cero sus variables locales de pila. El compilador optimiza cualquier reducción a cero que no sea necesaria. Por ejemplo, cuando una variable local se inicializa explícitamente (por ejemplo, int x = 123; la variable x se inicializa solo una vez). Si el programa tiene un búfer de pila grande en un punto de acceso de rendimiento, el desarrollador puede deshabilitar la inicialización usando un atributo del compilador:
__attribute__((__uninitialized__)) char buf[BUFSIZ]; Las aplicaciones también pueden optar por la inicialización de pila cero mediante el atributo de manifiesto android:nativeHeapZeroInitialized . Alternativamente, la inicialización del montón cero se puede controlar en tiempo de ejecución con:
int mallopt(M_BIONIC_ZERO_INIT, level)Donde el nivel es 0 o 1.
Cero memoria del kernel inicializada
La pila y el montón del kernel se inicializan en cero para los kernels GKI, lo cual es muy recomendado por el CDD .
Para la inicialización de la pila, GKI usa la configuración CONFIG_INIT_STACK_ALL_ZERO , lo que resulta en la construcción del kernel usando el indicador del -ftrivial-auto-var-init=zero . Para la inicialización del montón, GKI usa CONFIG_INIT_ON_ALLOC_DEFAULT_ON , que hace que todas las asignaciones de montón de páginas, SLAB y SLUB se inicialicen en cero cuando se crean. Esta opción es similar a pasar init_on_alloc=1 como una opción de tiempo de arranque del núcleo.
Informes de errores
Nuestras herramientas generan informes de errores perspicaces que contienen información adicional para ayudar con la depuración. El seguimiento adicional de la pila de asignación y desasignación ayuda a comprender mejor el ciclo de vida de una asignación dada y conduce a errores de seguridad de la memoria que causan la raíz mucho más rápido.
Durante el desarrollo, los proveedores deben monitorear la presencia de errores revisando /data/tombstones y logcat para fallas nativas. Para obtener más información sobre la depuración del código nativo de Android, consulte la información aquí .