Android - Arquitectura

Todas las distribuciones de Android siguen la misma arquitectura (para mantener la compatibilidad de aplicaciones).

1. Bootloader

   Los dispositivos ARM tienen una característica; dependen de una implementación externa para tener un bootloader funcional.

   De esta manera nos podemos encontrar diferentes bootloaders dependiendo del fabricante, cada uno tiene su propia implementación. Sumale que al ser propietarios, la mayoría son de código cerrado, sin documentaciones y de extrema dificultad para acceder (es parte del firmware embebido).

   El bootloader es el encargado de (en este orden); ver e inicializar la memoria, verificar que los certificados del sistema operativo Android sean del fabricante (que está intrinsicamente relacionado al uso de UEFI y el bloqueo OEM), verificar las particiones “boot”, “dtbo”, “init_boot” y “recovery”, verificar si existen actualizaciones aplicar en el sistema o si al fallar el sistema (o si el usuario mantiene los botones correctos) debe iniciar el modo recovery.

   Por último, carga las imágenes de inicio; “boot.img”, “vendor_boot.img”, “init_boot.img” y otras imágenes propietarias del fabricante. Al igual que que u-boot, grub, lilo y demás cargadores carga el kernel y el “initramfs” en memoria.

   A partir de Android 12 el bootloader soporta pasar configuraciones al kernel para modificar el inicio por defecto.

   En el archivo; system/core/mkbootimg/bootimg.h está la configuración de inicio.

   En sistemas Android hablamos del modo “fasboot” cuando podemos interactuar con el bootloader. Sus estados son “LOCKED” ó “UNLOCKED”, dependiendo uno u otro va impedir la instalación de otro SO o no (respectivamente). Por defecto en encuentra en modo “LOCKED”, permitiendo cargar una distribución Android firmada digitalmente por el fabricante. Ese certificado digital es lo que se conoce como “Root of Trust”, y en el dispositivo solamente se encuentra la parte pública de esa llave, el fabricante se queda con la privada. Algunos dispositivos permiten que el usuario indique su propia llave, pero no es la norma.

2. Kernel

   Utilizan el kernel Linux con algunas modificaciones para alivianar el mismo.

   Android posee de forma nativa habilitado SELinux (Security Enhanced Linux), entre otros componentes a nivel de kernel.

3. Android ART / Dalvik

   Tanto Dalvik como ART (Android Runtime) son entornos de ejecución (véase, presenta y contiene todo para que aplicaciones se puedan ejecutar apropiadamente arriba) que se utilizan para hacer andar las aplicaciones en el sistema operativo.

   Desde hace un tiempo ART ya remplaza a Dalvik.

   Como ART y Dalvik usan Java para funcionar, ocurria un problema; como Java (no confundir con JavaScript, son dos cosas diferentes) es un lenguaje interpretado, cada vez que la aplicación se iniciaba había que esperar a que la aplicación se compile para luego poder ejecutarla (lo que se conoce como “JIT”: “just-in-time”) cuando se usaba Dalvik. Esto no es así con el uso de ART, en donde se usa un esquema de “AOT”; “ahead-of-time” que compila la aplicación apenas es instalada en el dispositivo.

   Así mismo ART trae mejoras en rendimiento, el recolector de basura (característica de los lenguajes interpretados), depuración de la aplicación, etc. Y empezó a estar disponible a partir de Android 4.4.

   Dalvik usa archivos “.dex” cuando la aplicación es compilada e iniciada (“DEX”; “Dalvik EXecutable”). El archivo APK contiene un solo archivo “dex” llamado “classes.dex”, por temas de compatibilidad esto se mantiene en ART.

   Dalvik usa archivos “.odex” cuando cachea (véase; procesar y almacenar cosas que no cambian) la aplicación, para hacer más rápido su inicio. Muchas veces esto también se usaba para segmentar la aplicación hasta tal punto que sí o sí parte de la misma estaba solamente en el archivo “.odex”, haciendo tremendamente dificil su ingenieria inversa ya que se tenía que realizar el proceso inverso y empaquetar todo correctamente dentro del apk. Esto no se mantiene en ART, si no que utiliza el formato ejecutable nativo del kernel Linux; “ELF”: “Executable and Linkable Format” el cual permite una mayor optimización en muchos sentidos (la librería estándar, las dependencias externas, el “LTO”: “Link Time Optimization”, etc) y un menor consumo de recursos en todo sentido.

   Copyright; Wikipedia

   Si hasta ahora vas entendiendo te darás cuenta de una cosa si queres realizar ingeniería inversa a un programa; como desde Android 4.4 KitKat se usa principalmente ART vas a tener que urgar en el apk los archivos “dex” y tener conocimiento de Java o Kotlin para poder entender que hace la aplicación leyendo el código.