Arquitectura del S.O Android

Arquitectura del S.O Android.

Android es un sistema operativo creado para ser independiente de cualquier tipo de arquitectura de hardware en los dispositivos móviles. Esta característica hace que sea tan atractivo ante los fabricantes y desarrolladores.

Adicionalmente su portabilidad, flexibilidad y seguridad les da ese toque de simpatía a las personas interesadas en los sistemas de código abierto.

La arquitectura de Android debe ser estudiada antes de comenzar a programar.

Modelo de capas en la arquitectura de Android.

Android está construido con una arquitectura de 4 capas o niveles relacionados entre sí. A continuación veremos un diagrama ilustrativo extraído del libro Learning Android escrito por Marko Gargenta y Masumi Nakamura:

El diagrama indica que la estructura de Android se encuentra construida sobre el Kernel de Linux. Luego hay una capa de Librerías relacionadas con una estructura administradora en Tiempo de ejecución. En el siguiente nivel encontramos un Framework de apoyo para construcción de aplicaciones y posteriormente vemos a la capa de Aplicaciones.

Kernel de Linux.

Android está construido sobre el núcleo de Linux, pero se ha modificado dramáticamente para adaptarse a dispositivos móviles. Esta elección está basada en la excelente potabilidad, flexibilidad y seguridad que Linux presenta. Recuerda que el Kernel de Linux está bajo la licencia GPL, así que en consecuencia Android también.

Capa de librerías o capa nativa.

En esta capa se encuentran partes como la HAL, librerías nativas, demonios, las herramientas de consola y manejadores en tiempo de ejecución. Veamos un poco el propósito de estos conceptos:

• Hardware Abstraction Layer (HAL): Este componente es aquel que permite la independencia del hardware. Quiere decir que Android está construido para ejecutarse en cualquier dispositivo móvil sin importar su arquitectura física. El HAL actúa como una arquitectura genérica que representa a todos los posibles tipos de hardware existentes en el mercado. Aunque por el momento no hay estándares de construcción en el hardware de dispositivos móviles, el HAL permite que cada fabricante ajuste sus preferencias para que Android sea funcional sobre su tecnología.
• Librerías nativas: Aquí encontramos interfaces de código abierto como OpenGL para el renderizado de gráficos 3D, SQLite para la gestión de bases de datos, WebKit para el renderizado de los browsers, etc. También librerías para soportar los servicios del sistema como  Wifi, posicionamiento, telefonía, y muchos más.
• Demonios (Daemons): Los demonios son códigos que se ejecutan para ayudar a un servicio del sistema. Por ejemplo cuando se requiere instalar o actualizar una aplicación, el demonio de instalación “installd” es ejecutado para administrar todo el proceso. O cuando los desarrolladores vamos a ejecutar en modo de depuración nuestro teléfono desde un PC, se ejecuta un demonio llamado adbd(Android Debug Bridge Daemon) para auxiliar a dicho proceso.
• Consola: Al igual que otros sistemas operativos, Android permite que empleemos comandos de línea para la ejecución de procesos del sistema o explorar el sistema operativo.
• Manejadores en tiempo de ejecución: Si bien las aplicaciones Android están escritas en lenguaje Java y son traducidas a bytecodes, estas no son interpretadas por la Máquina virtual de Java.  Android tiene su propia máquina virtual interpretadora de bytecodes llamada Dalvik. Esta herramienta fue diseñada para ser flexible ante el diseño de hardware de un dispositivo móvil. Además JVM no es de licencia GPL, así que Google decidió generar su propia herramienta.

¿Cómo funciona Dalvik?

Dalvik no cambia nada en el proceso de compilación, sencillamente interviene al final como receptor de un archivo ejecutable producto de una recopilación de los archivos .class de java.

Recuerda las fases de la construcción de una aplicación Java. El primer paso es generar el código fuente (arhivos .java), luego este es traducido por el Java Compiler (javac) y obtenemos un fichero tipo byte code (archivos .class). Finalmente la máquina virtual de Java (JVM) interpreta en tiempo real este archivo y la aplicación es ejecutada.

La ejecución de Dalvik es ingeniosa, simplemente espera que javac traduzca la aplicación a byte codes, cuando están listos los archivos, estos son compilados por el compilador Dex. Esta herramienta traduce los byte codes de java a un estilo de byte codes nativos que serán convertidos a un ejecutable .dex. Finalmente este archivo es ejecutado por una instancia de Dalvik VM.

A continuación se muestra un diagrama comparativo de ambos procesos:

Aunque el proceso añade unos cuantos pasos más, no debes preocuparte por ello, ya que esta tarea se le delega a la herramienta Gradle.

Google ha anunciado que Dalvik VM será reemplazada por una nueva máquina virtual llamada ART (Android Runtime) en su nueva versión Android L. Por el momento no nos preocuparemos por esta situación, pero es un dato muy importante a tener en cuenta.

Framework Para Aplicaciones.

Esta es la capa que nos interesa a los desarrolladores, ya que en ella encontramos todas las librerías Java que necesitamos para programar nuestras aplicaciones. Los paquetes con más preponderancia son los android.*, en ellos se alojan todas las características necesarias para construir una aplicación Android.

No obstante es posible acceder a clases como java.utils.*, java.net.* , etc. Aunque hay librerías Java excluidas como la java.awt.* y java.swing.*.

En esta capa también encontraremos manejadores, servicios y proveedores de contenido que soportaran la comunicación de nuestra aplicación con el ecosistema de Android.

Capa De Aplicaciones.

Es la última instancia de funcionamiento de Android. Se centra en la ejecución, comunicación y estabilidad de las aplicaciones preinstaladas por el fabricante o las que nosotros vamos a construir. A ella acceden todos los usuarios Android debido a su alto nivel de compresión y simplicidad.

¿Qué tipo de archivo tienen las aplicaciones para Android?

El resultado del proceso de construcción es un archivo comprimido con formato .APK (Android Applicacion Package). Y dentro encontraremos los siguientes componentes:

• Archivo Android Manifest: Este archivo es la definición de todas las características principales que tendrá nuestra aplicación al ejecutarse en un dispositivo móvil. Con características me refiero a los bloques que posee la aplicación, los permisos, su versión, las versiones previas soportadas, las dimensiones de la pantalla, etc.
• Archivo classes.dex: Este será el fichero compilado preparado para ejecutarse en la Máquina Virtual Dalvik.
• La carpeta Resources: Aquí encontramos todos los archivos externos que usamos para construir nuestro proyecto, como por ejemplo nuestros iconos, audio, archivos planos de texto, los archivos .xml de diseño, etc.
• Librerías nativas: El archivo .APK también contiene aquellas librerías de las cuales depende la aplicación.
• Carpeta META-INF: En ella se guardan archivos que corresponden a las Firmas Digitales de tu aplicación. Con esta especificación puedes indicar que tú eres el creador y dueño de la aplicación, además debes indicar tu ID de desarrollador para ser reconocido y autenticado en procesos de comercialización (Google es muy riguroso en este tema).

El sistema automatizado de construcción Gradle y Android Studio.

Gradle es una herramienta para automatizar el compilado, empaquetado, testeo y liberación de aplicaciones que se basen en la JVM. Como te dije antes, ha sido creado para expandir el uso de javac.

Cuando me refiero a “automatizar” significa que podemos programar nuestras propias condiciones de construcción. Esto es posible a través de Scripting mediante DSL (Domain-Specific-Language), un lenguaje claro y especializado, con énfasis en configurar y construir aplicaciones con Gradle.

DSL permite generar una compilación basada en tareas programadas y relacionadas entre sí, reduciendo la complejidad de dependencias y automatizando labores frecuentes. Su sencillez permite dar instrucciones de manera declarativa e intuitiva al programador.

¿Qué ventajas tiene utilizar Gradle?

• Una de las mayores ventajas es que le entrega el poder del flujo de construcción al programador. Esto quiero decir que decidimos el orden de ejecución de tareas. Asimismo podríamos elegir que archivos compilar primero, cuando detener la compilación, establecer condiciones para que se recompile o no el código y muchas situaciones más.
• Ejecuciones incrementales: El poder de esta característica le ahorra al programador gran cantidad de tiempo de espera. Al haber construcciones incrementales podemos decidir hasta qué punto queremos que se compile nuestra aplicación, es decir, si no es necesario compilar una parte del código debido a la ausencia de errores, entonces se procede a compilar la sección que aún no ha sido probada.
• Múltiples versiones: Gradle permite que construyamos varias versiones de nuestra aplicación. Por ejemplo, si deseas construir tu aplicación para Jelly Beans y para Kitkat entonces solo debes especificar que el proyecto tendrá dos variantes de empaquetado, configurando la versión del SKDusada para cada versión.
• La ejecución y las pruebas se pueden realizar en un mismo proyecto.
• Ejecución en paralelo de tareas: Puedes ejecutar tareas en hilos diferentes para optimizar el proceso de construcción.