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.
Sin memoria inicializada para el espacio de usuario
Desde Android 12, la memoria de pila no se inicializa en cero.
en el código nativo de la plataforma (incluida JNI) y la memoria de montón es cero.
Se inicializa en todos los procesos nativos de la plataforma (como netd).
pero no en zygote ni en apps.
Las apps propias y de terceros compiladas con el NDK son
Se recomienda usar la marca del compilador -ftrivial-auto-var-init=zero para inicializar en cero la pila local.
variables. El compilador optimiza para eliminar cualquier operación de cero innecesaria.
Por ejemplo, cuando una variable local se inicializa explícitamente
(por ejemplo, la variable x de int x = 123; se inicializa una sola vez).
Si el programa tiene un búfer de pila grande en un entorno
hotspot, el desarrollador puede inhabilitar la inicialización usando un compilador
atributo:
__attribute__((__uninitialized__)) char buf[BUFSIZ];
Las apps también pueden optar por la inicialización de montón cero mediante el
Atributo android:nativeHeapZeroInitialized del manifiesto.
Como alternativa, la inicialización del montón cero se puede controlar en el tiempo de ejecución
con:
int mallopt(M_BIONIC_ZERO_INIT, level)
En los casos en que el nivel es 0 o 1.
Cero memoria de kernel inicializada
La pila y el montón de kernels inicializados en cero para los kernels de GKI, lo que es eficazmente recomendadas por el CDD.
Para la inicialización de pila, GKI usa el
configuración de CONFIG_INIT_STACK_ALL_ZERO, lo que da como resultado la compilación del
con la marca del compilador -ftrivial-auto-var-init=zero.
Para la inicialización del montón, GKI usa el
CONFIG_INIT_ON_ALLOC_DEFAULT_ON, que hace que todas las páginas de montón, SLAB
y SLUB se inicializan en cero cuando se crean. Esta opción es
De manera efectiva, similar a pasar init_on_alloc=1 como un kernel
tiempo de inicio.
Informes de errores
Nuestras herramientas generan informes de errores detallados que contienen información adicional para facilitar la depuración. El seguimiento de pila adicional de asignación y desasignación ayudan a comprender mejor el ciclo de vida de una asignación determinada y generan que causan errores de seguridad de la memoria mucho más rápido.
Durante el desarrollo, los proveedores deben controlar la presencia de errores verificando
/data/tombstones y
logcat para las fallas por errores en código nativo. Para obtener más información
cómo depurar código nativo de Android, consulta la información aquí.