Escuchamos hablar mucho de Android y de sus partes, pero ¿de verdad las conoces? A continuación vamos a hacer un repaso desde el kernel hasta las aplicaciones para ver que partes tiene nuestro androide por dentro. Comprender su estructura nos ayuda a comprender cambios que se realizan en ella y las modificaciones a través de ROMs.

Con cada versión de Android nos preguntamos que tienen los fabricantes que cambiar y porque tardan tanto. Con cada ROM que vemos nos encontramos términos rarísimos como «kernel». ¿Qué es el Kernel? Vamos con calma a ver todo esto, pero eso si, todo está escrito para que sea entendido por una mayoría, no te lleves las manos a la cabeza si algo no alcanza tu alto nivel de conocimiento.

La arquitectura de Android, capas en vez de ladrillos

La imagen que encabeza estas lineas es como el faro que nos marca el camino en este artículo. Todo se basa en ello así que pon a trabajar tu memoria fotográfica o el scroll para subir a echarle un vistazo. En ella se muestran las diferentes capas de la arquitectura de Android como Sistema Operativo.

Puede entenderse de manera que una capa superior tiene acceso a todas las que están por debajo, siendo el kernel la parte que menos accede, pues solo interactúa con el hardware y la que más, las aplicaciones que utilizan el resto del sistema.

Linux Kernel

Como seguramente habrás escuchado, Android está basado en Linux, que a su vez está basado en UNIX. Es algo común, pues hasta macOS se basa en UNIX. En el otro lado se encuentra Windows que ahora basa su kernel en el de Windows NT.

El Kernel gobierna el hardware gracias a los drivers de los componentes.

El Kernel es la parte que gobierna al hardware, donde se encuentran los drivers de cada componente. Desde los drivers del procesador y la cámara hasta los del acelerómetro o la brújula. Al contrario de como podemos hacer en Windows, en Android un usuario no puede instalar sus propios drivers sin cambiar el sistema.

Esto supone un problema para la idea de teléfono modular, pues cada módulo que existiera para ese móvil tendría que existir su driver por lo que requeriría de una actualización por módulo lanzado además de que todos los móviles acabarían viendo crecer el espacio del sistema, pues una actualización te pondría el driver aunque no compraras el modulo. Para hacer esta idea realidad habría que cambiar varias cosas en la forma de funcionar de Android en conjunto.

Al tener los drivers del hardware es la parte que traduce lo que detecta éste o bien que le dice que hacer en cada ocasión. Sobre lo que sería un Kernel Linux normal, Android añade algunas funciones como los wake locks que gestionan de una manera agresiva la memoria en uso o el Binder IPC del que luego hablaremos.

HAL: Hardware Abstraction Layer

Android tiene en su interior HAL, pero no a HAL 9000, así que no hay de que preocuparse. Es más, gracias a esta parte disponemos de una plataforma tan abierta en cuanto a hardware con efectos mínimos para los desarrolladores tanto del sistema como de aplicaciones.

HAL es la capa que traduce lo que pide el driver (hardware) a lo que envía el sistema.

HAL, Hardware Abstraction Layer o en español, capa de abstracción de hardware trabaja sobre el Kernel de tal manera que permite al sistema trabajar siempre con las mismas «instrucciones» aunque el hardware cambie. La HAL se encarga de convertir las instrucciones que piden los drivers a una serie de instrucciones genéricas para Android.

De esta manera, por ejemplo, para encender la pantalla android le dirá «enciende la pantalla» al HAL, pero en un móvil el driver pedirá «enciende la pantalla amoled hd73649» y en otro «pantalla encender ahora». El fabricante debe especificar en el HAL cual es la orden de «enciende la pantalla» que pide el driver en el kernel.

Sistema Android

Aquí llega lo fuerte. Ya disponemos del hardware, tenemos también los drivers para controlarlo y tenemos HAL para controlarlo en cualquier dispositivo sin tener que cambiar la forma de hacerlo. ¡Ya podemos darle un corazón a nuestro androide! En sí, un cerebro pues en esta capa se encuentra el sistema Android.

A este nivel de la arquitectura nos encontramos la máquina virtual Java y las librerías del sistema.

Nos encontramos con el sistema de permisos de Android, con las librerias del sistema como OpenGL o Vulkan para gráficos, de las que tanto se habla ultimamente. También la máquina virtual de Java, en su tiempo era Dalvik pero desde Android 5.0 se migró a ART (Android RunTime). Es la que nos permite ejecutar código en lenguaje Java (el que usan la mayoría de aplicaciones).

A su vez sobre esta capa estarán las más relacionadas por las aplicaciones así que debe ser la encargada de manejar todas las API de sistema que utilizan los desarrolladores de aplicaciones. Nos encontramos el media server, la parte encargada de que las funciones multimedia del dispositivo funcionen bien, como por ejemplo de manejar el volumen o decidir que sonidos saldrán por el altavoz. También encontramos el system server que se encarga de las funciones del sistema como manejar la multitarea o las aplicaciones.

Android framework

Un framework, en español estructura o armazón, quiere decir en programación una serie de ayudas sobre las que crear contenido. En este caso, el Android framework contiene todo lo que se necesita para crear una aplicación Android.

El Android Framework es la estructura sobre la que se montan las aplicaciones Android.

Hablamos de cosas como las Activity que son las distintas pantallas de una aplicación, aspectos de la interfaz de usuario o la gestión de notificaciones. Un desarrollador de aplicaciones usará la estructura que le de el Android framework para crear su aplicación y la API del Sistema Android (la capa anterior) para dotarla de funciones. Pues puedes tener la estructura de una aplicación de reloj, pero de nada sirve si no tienes la API que te ofrece la hora actual.

Sobre esta capa ya solo existe una, las propias aplicaciones.

Binder IPC

Nos hemos dejado una cosa, el Binder. Se encuentra en el Kernel como un driver más pero no se corresponde a ningún tipo de hardware. A su vez, en la imagen que hemos mostrado al inicio aparece el Binder Proxy entre el sistema y el framework Android. ¿Qué es?

Binder es la parte encargada de relacionar los procesos de las aplicaciones con el sistema y otras capas.

IPC corresponde a Inter-Process Comunication (Comunicación interprocesos). Está basado en OpenBinder, creado por Be Inc para BeOS en 2001 pero comprado por PalmSource y usado por primera vez en Palm Cobalt OS. En 2008 se usó para Android pero reescribiéndolo desde cero para adaptarlo al máximo.

Se trata de una parte esencial para Android pues es la que permite a los procesos, las aplicaciones en ejecución, relacionarse con otros procesos de otras partes del sistema. El ejemplo más claro es que a la hora de hacer una aplicación el framework de Android nos ofrece programar que ocurra algo al crear la aplicación (onCreate()) o cuando se vuelva a abrir sin haberse cerrado (onResume()). Esto es posible gracias al Binder.

Binder relaciona los distintos procesos, en el caso de cuando se abre una aplicación, establece una comunicación entre el proceso del sistema y el de la aplicación para que la aplicación sepa que se ha abierto. Un ejemplo sencillo, pero en la práctica es bastante más complicado.

Resumiendo mucho, permite la comunicación entre capas de nuestra imagen del principio (sin bajar más allá del sistema android).

Esto tiene nuestro androide dentro

Ahora ya conoces que tiene nuestro querido androide por dentro, desde el hardware más puro que hasta lo puedes tocar hasta el software en forma de aplicaciones que usamos día a día.

Siempre va bien tener conocimientos, pues ahora que sabes un poco más de Android entenderás mejor la importancia de algunos cambios en su estructura o en las ROMs. El trabajo de un desarrollador de ROMs es gigante, es modificar y cuadrar todas estas partes al igual que los fabricantes con cada actualización.