ARQUITECTURA DE ANDROID

Resumen
Android es una pila de software de código abierto basado en Linux desarrollado
inicialmente para dispositivos móviles y posteriormente hacia otros instrumentos. Es
desarrollado por el conglomerado de empresas: Open Handset Alliance, el cual
encabeza Google.
La arquitectura de este sistema operativo está compuesta por cuatro capas; la
primera de ellas es un kernel basado en Linux, le siguen las bibliotecas entre las
que se encuentran las básicas correspondientes a la máquina virtual, se encuentra
el marco de aplicaciones o framework y finalmente las aplicaciones.
A continuación, se presentan los cuatro tipos de capas:

1. Kernel de Linux:
Linux es un núcleo mayormente libre semejante al núcleo de Unix. Linux es uno de
los principales ejemplos de software libre y de código abierto. Linux está licenciado
bajo la GPL v2 salvo el hecho que tiene blobs binarios no libres y la mayor parte del
software incluido en el paquete que se distribuye en su sitio web es software libre.
Está desarrollado por colaboradores de todo el mundo. El desarrollo del día a día
tiene lugar en la Linux Kernel Mailing List Archive.
El núcleo Linux fue concebido por el entonces estudiante de ciencias de la
computación finlandés Linus Torvalds en 1991. Linux consiguió rápidamente
desarrolladores y usuarios que adoptaron códigos de otros proyectos de software
libre para usarlos con el nuevo núcleo de sistema. A día de hoy miles de
programadores de todo el mundo contribuyen en su desarrollo.
Linux es multiprogramado, dispone de memoria virtual, gestión de memoria,
conectividad en red y permite bibliotecas compartidas. Linux es multiplataforma y es
portable a cualquier arquitectura siempre y cuando esta disponga de una versión de
GCC compatible.

La parte de un sistema operativo que se ejecuta sin privilegios o en espacio de

usuario es la biblioteca del lenguaje C, que provee el entorno de tiempo de ejecución,
y una serie de programas o herramientas que permiten la administración y uso del
núcleo y proveer servicios al resto de programas en espacio de usuario, formando
junto con el núcleo el sistema operativo.
En un sistema con núcleo monolítico como Linux la biblioteca de lenguaje C
consiste en una abstracción de acceso al núcleo. Algunas bibliotecas como la
biblioteca de GNU proveen funcionalidad adicional para facilitar la vida del
programador y usuario o mejorar el rendimiento de los programas.
Actualmente Linux es un núcleo monolítico híbrido. Los controladores de dispositivos y
las extensiones del núcleo normalmente se ejecutan en un espacio privilegiado
conocido como anillo 0 (ring 0), con acceso irrestricto al hardware, aunque algunos se
ejecutan en espacio de usuario. A diferencia de los núcleos monolíticos tradicionales,
los controladores de dispositivos y las extensiones al núcleo se pueden cargar y
descargar fácilmente como módulos, mientras el sistema continúa funcionando sin
interrupciones. A diferencia de los núcleos monolíticos tradicionales, los
controladores también pueden ser pre-volcados (detenidos momentáneamente por
actividades más importantes) bajo ciertas condiciones. Esta habilidad fue agregada
para gestionar correctamente interrupciones de hardware y para mejorar el soporte de
multiprocesamiento simétrico.

El hecho de que Linux no fuera desarrollado siguiendo el diseño de un micronúcleo

(diseño que, en aquella época, era considerado el más apropiado para un núcleo
por muchos teóricos informáticos), fue motivo de una famosa y acalorada discusión
entre Linus Torvalds y Andrew S. Tanenbaum.
En Linux existe un sistema de archivos que carga y contiene todos los directorios,
redes, programas, particiones, dispositivos, etc. que el sistema sabe reconocer, o por lo
menos, identificar. Este sistema de ficheros y directorios tiene como base al carácter
(/); ese mismo carácter sirve también para demarcar los directorios, como, por
ejemplo: "/home/usuario/imagen.jpg".
Es práctica común en el sistema de ficheros de Linux, utilizar varias sub-jerarquías
de directorios, según las diferentes funciones y estilos de utilización de los archivos.
Estos directorios pueden clasificarse en:
 Estáticos: Contiene archivos que no cambian sin la intervención del
administrador (root), sin embargo, pueden ser leídos por cualquier otro
usuario. (/bin, /sbin, /opt, /boot, /usr/bin...)
 Dinámicos: Contiene archivos que son cambiantes, y pueden leerse y
escribirse (algunos solo por su respectivo usuario y el root). Contienen
configuraciones, documentos, etc. Para estos directorios, es recomendable
una copia de seguridad con frecuencia, o mejor aún, deberían ser montados
en una partición aparte en el mismo disco, como, por ejemplo, montar el
directorio /home en otra partición del mismo disco, independiente de la
partición principal del sistema; de esta forma, puede repararse el sistema sin
afectar o borrar los documentos de los usuarios. (/var/mail, /var/spool,
/var/run, /var/lock, /home...)
 Compartidos: Contiene archivos que se pueden encontrar en un ordenador y
utilizarse en otro, o incluso compartirse entre usuarios.
 Restringidos: Contiene ficheros que no se pueden compartir, solo son
modificables por el administrador. (/etc, /boot, /var/run, /var/lock...)

Algunas tareas del Kernel es la de gestionar los diferentes recursos del

dispositivo {energía, memoria, etc.} y del sistema operativo {procesos, red, entre
otros}.
 Linux Kernel
1. Display Driver 6. USB Driver
2. Camera Driver 7. KeyPad Driver
3. Bluetooth Driver 8. WIFI Driver
4. Flash Memory Driver 9. AUDIO Drivers
5. Bender {IPC} 10. Power Management

2. Bibliotecas:
La siguiente capa que se sitúa justo con el kernel la componen las bibliotecas
nativas de Android, estas están escritas en C o C++ y compiladas para la
arquitectura hardware especifica en cada dispositivo. Normalmente están hechas
por el fabricante que también se encarga de instalarlas en el dispositivo antes de
ponerlo en el mercado. El objetivo de las bibliotecas es proporcionar funcionalidad a
las aplicaciones para tareas que se repiten con frecuencias, evitando codificarlas
cada vez y garantizando que las tareas se lleven a cabo de manera más eficiente.
Estas bibliotecas se ofrecen a los desarrolladores a través del marco de trabajo de
aplicaciones de Android; algunas son: System C library {implementación biblioteca
C estándar}, bibliotecas de medios, bibliotecas de gráficos, 3D, SQLite, FreeType,
WebKit {navegador}, SSL {cifrado de comunicaciones}.

Estas son algunas bibliotecas que se incluyen habitualmente:

 Gestor de superficies {Surface Manager}: se encarga de componer
imágenes que se muestran en la pantalla a partir de capas graficas 2D y 3D.
Cada vez que la aplicación pretende “dibujar” algo en al pantalla, la biblioteca
no lo hace directamente sobre ella. En vez de eso, realiza los cambios en
imágenes {mapas de bits} que almacena en memoria y que después combina
 para formar la imagen final que se envía a la pantalla. Esto permite realizar
con facilidad diversos efectos: superposición de elementos, transparencias,
transiciones, animaciones, etc.

 SLG {Scalable Graphics Library}: desarrollada por Sika {empresa adquirida

por Google en 2005} y utilizada tanto en Android como en Chrome
{navegador web de Google}, se encarga de representar elementos en dos
dimensiones. Ese es el motor grafico 2D de Android.

 OpenGL ES {OpenGL for Embedded Systems}: motor grafico 3D basado

en las APIs {Application Program Interface}4 de OpenGL ES 1.0, 1.1 {desde
la versión 1.6 de Android} y 2.0 {desde la versión 2.2 de Android}. Utiliza
aceleración hardware {si el teléfono la proporciona} o un motor software
altamente optimizado {según Google} cuando no la hay.

 Bibliotecas multimedia: basadas en OpenCORE, permiten visualizar,

reproducir e incluso grabar numerosos formatos de imagen, video y audio
como JPG, GIF, PNG, MPEG4, AVC {H.264}. MP3, AAC o AMR.

 WebKit: motor web utilizado por el navegador {tanto como aplicación

independiente como embebido en otras aplicaciones}. Es el mismo motor que
utilizar Google Chrome y Safari {el navegador de Apple, tanto en Mac como
en el iPhone}.

 SSL {Secure Sockets Layer}: proporciona seguridad al acceder a Internet

por medio de criptografía.

 FreeType: permite mostrar fuentes tipográficas, tanto basadas en mapas de

bits como vectoriales.

 SQLite: motor de base datos relacionales, disponible para todas las

aplicaciones.

 Biblioteca C de sistema {libc}: esta basada en la implementación de Berkerly

Software Distribution {BSD}, pero optimizada para sistemas Linux embebidos.
Proporciona funcionalidad básica para la ejecución de las aplicaciones.
Android RunTime ART {Entorno de Ejecución}:
En el mismo nivel están las bibliotecas de entorno de ejecución {no se considera
una capa en sí mismo, dado que también está formado por bibliotecas}, Android
incluye un set de bibliotecas base que proporcionan la mayor parte de las funciones
disponibles en las bibliotecas habituales del lenguaje Java. El componente principal
del entorno de ejecución es la máquina virtual, las aplicaciones se codifican en
Java y son compiladas en formato específico para que esta máquina virtual se
ejecute. La ventaja de esto es que las aplicaciones se compilan una única vez y de
esta forma estarán listas para distribuirse con la total garantía de que se podrán
ejecutar en cualquier dispositivo Android que disponga de la de la versión mínima
del sistema operativo que requiera la aplicación. Cabe resaltar, que la máquina
virtual Android es una variación de la máquina virtual de Java por lo que no es
compatible con el BiteCode Java.
Java se usa únicamente como lenguaje de programación y los ejecutables que se
generan con el SDK de Android tienen la extensión .dex {Dalvik que es la máquina
virtual que utiliza la plataforma para dispositivos moviles Android} que es específico
para la máquina virtual de Android y por ello no podemos correr aplicaciones en
Java en Android, ni viceversa.
Para ser un poco más claros, cuando creamos nuestra aplicación y generamos
APK, parte de ese APK son archivos .dex . Esos archivos contienen el código
fuente de nuestra aplicación, incluidas todas las bibliotecas que usamos en código
de bajo nivel diseñado para un intérprete de software: el código de bytes. Android
RunTime traduce el código de bytes escrito en archivos .dex al código de la
máquina.
 3. Marco de aplicaciones {FrameWork}:

Un marco o entorno de trabajo es lo que se conoce como framework. Se trata

de una estructura definida para desarrollar y gestionar un software, es decir, un
entorno que facilita la programación de una aplicación o software. El framework
ayuda a que el programador separe en la aplicación desarrollada, la gestión de
los datos, las operaciones, y la presentación.

Los frameworks pueden ser utilizados para programar con diferentes lenguajes
de programación, aunque bien es cierto que en general suelen especializarse en
alguno o algunos en concreto, incluyendo funciones especiales para los mismos.

La principal función u objetivo de utilizar un framework es la de disponer de un

entorno que facilite la escritura de código y el desarrollo de una aplicación. El
framework ofrece las herramientas necesarias para organizar y controlar todo el
código generado, además de permitir ser más eficientes que utilizando los
métodos tradicionales.

El uso de un framework reduce la cantidad de errores cometidos durante los

procesos de programación, facilitando las labores de los desarrolladores.

Con el uso de frameworks, los desarrolladores podrán entender fácilmente el

código de otros programadores, al seguir una estructura y organización similar.
Se trata sin duda de una herramienta indispensable en aquellos proyectos donde
trabajan diversos programadores. Cada aportación podrá ser fácilmente
revisable, adaptada o modificada por los demás componentes del grupo de
desarrollo, reduciendo el tiempo necesario para entenderla.

Ventajas de utilizar un framework

Utilizar entornos de trabajo para la programación de aplicaciones otorga una

serie de beneficios, entre los que podemos destacar:

 Automatiza procesos, evitando el tiempo perdido escribiendo código, por

ejemplo, la creación de botones o menús).
 Evita repeticiones de código y facilita la reutilización de acciones que
suelen repetirse a lo largo de cualquier programa.
  Facilita el conjunto de la programación, reforzando los buenos hábitos en
el diseño. Los frameworks suelen incluir patrones de diseño que tienen en
cuenta errores comunes o que ya han ocurrido con anterioridad.
 Reduce los costes financieros (al reducir el tiempo de desarrollo y de
entrega y optimizar los recursos).
 Facilita la tarea de los programadores que no necesitan plantear una
estructura general del software (el propio framework proporciona el
esqueleto del mismo).
 Permite realizar un trabajo colaborativo organizado y controlado.
 Reduce el tiempo de entrega de la aplicación ya que agiliza el proceso de
desarrollo y evita la duplicidad de código.
 Minimiza los errores y ofrece alternativas para solucionarlos al incorporar
código ya implementado y comprobado por otros desarrolladores.
 Ayuda a estandarizar, por lo que es más sencillo utilizar código de otros
programadores (facilita el trabajo colaborativo).
 Utilizan librerías para facilitar la programación.

En algunos casos puede que el uso de un determinado framework o de cualquier

framework no sea adecuado para el proyecto. Algunos de los inconvenientes que
se pueden presentar al utilizar un framework en programación son:

 Escasez de recursos. Los frameworks consumen recursos y en el

desarrollo de aplicaciones que requieren de un alto rendimiento el uso de
un framework puede ser contraproducente.
 Periodo de aprendizaje. Dependiendo del tipo de framework, el periodo de
aprendizaje para poder utilizarlo puede llevar mayor o menor tiempo. El
tiempo suele ser un valor muy preciado para cualquier programador, por lo
que muchas veces aprender a utilizar un determinado framework no
merece la pena o no es rentable.
 Decidir cuál utilizar. Son muchas las opciones a la hora de elegir un
framework y por lo tanto puede ser complicado elegir el ideal. Quizás un
framework guste para desarrollar en un lenguaje de programación, pero no
sea tan adecuado para otro que también se utiliza.

Cómo elegir el mejor framework

A la hora de elegir el mejor framework que facilite el proceso de desarrollo de
una aplicación hay que tener en cuenta una serie de factores como:

 Lenguajes de programación que se utilizarán en el proyecto.

 Cantidad y calidad de la documentación existente sobre el framework.
 Tamaño de la comunidad de usuarios del framework (mayor comunidad,
más documentación, extras, etc.).
 Cuestiones (issues) abiertos en el repositorio GitHub.
 Problemas que puede solucionar.
 Flexibilidad, personalización y complejidad.
 Compatibilidad del framework con las otras herramientas que se utilizarán
en el proyecto.

Ejemplos de frameworks

Existen en el mercado una gran cantidad de entornos de trabajo o frameworks

para programación. Vamos a nombrar algunos frameworks populares
dependiendo del lenguaje de programación utilizado.

 Lenguaje PHP -> framework Laravel.

 Lenguaje Python -> framework Django.
 Lenguaje Javascript -> framework Express.js
 Lenguaje Java -> framework Spring MVC, Blade.
 Lenguaje Ruby -> framework -> Sinatra
 La mayoría de los componentes de esta capa son bibliotecas Java que acceden a
recursos a través de la máquina virtual Dalvik. Entre las más importantes se
encuentran las siguientes:
 Administrador de actividades {Activity Manager}: se encarga de controlar
el ciclo de vida de las actividades y la propia pila de las mismas.

 Administrador de ventanas {Windows Manager}: se encarga de organizar

lo que se muestra en pantalla, creando superficies que pueden ser
“rellenadas” por las actividades.

 Proveedor de contenidos {Content Provider}: permite encapsular un

conjunto de datos que se compartirá entre aplicaciones creando una capa de
abstracción que hace accesible dichos datos sin perder el control sobre cómo
se accede a la información. Por ejemplo, uno de los proveedores de
contenido existentes permite a las aplicaciones acceder a los contactos
almacenados en el teléfono.

 Vistas {Views}: si antes se equiparaban las actividades con las ventanas de

un sistema operativo de PC, las vistas se pueden comparar con los controles
que se suelen incluir dentro de esas ventanas. Android proporciona
numerosas vistas con las que construir las interfaces de usuario: botones,
 cuadros de texto, listas, etc. También proporciona otras más sofisticadas,
como un navegador web o un visor de Google Maps.

 Administrador de notificaciones {Notification Manager}: proporciona

servicios para notificar al usuario cuando algo requiera su atención.
Normalmente las notificaciones se realizan mostrando alerta en la barra de
estado, pero esta biblioteca también permite emitir sonidos, activar el vibrador
o hacer parpadear los LEDs del teléfono {si los tiene}.

 Administrador de paquetes {Package Manager}: las aplicaciones Android

se distribuyen en paquetes {archivos .apk} que contienen tanto los
archivos .dex como todos los recursos y archivos adicionales que necesite la
aplicación, para facilitar su descarga e instalación. Esta biblioteca permite
obtener información sobre los paquetes actualmente instalados en el
dispositivo Android, además de gestionar la instalación de nuevos paquetes.

 Administrador de telefonía {Telephony Manager}: proporciona acceso a la

pila hardware de telefonía del dispositivo Android, si la tiene. Permite realizar
llamadas o enviar y recibir SMS/MMS, aunque no permite reemplazar o
eliminar la actividad que se muestra cuando una llamada está en curso {por
motivos de seguridad}.

 Administrador de recursos {Resources Manager}: proporciona acceso a

todos los elementos propios de una aplicación que se incluyen directamente
en el código: cadenas de texto traducidas a diferentes idiomas, imágenes,
sonidos e incluso disposiciones de las vistas dentro de una actividad
{layouts}. Permite gestionar esos elementos fuera del código de la aplicación
y proporcionar diferentes versiones, por ejemplo, en función del idioma del
dispositivo o la resolución de pantalla que tenga.

 Administrador de ubicaciones {Location Manager}: permite determinar la

posición geográfica del dispositivo Android {usando el GPS o las redes
disponibles} y trabajar con mapas.

 Administrador de sensores {Sensor Manager}: permite gestionar todos los

sensores hardware disponibles en el dispositivo Android: acelerómetro,
giroscopio, sensor de luminosidad, sensor de campo magnético, brújula,
sensor de presión, sensor de proximidad, sensor de temperatura, etc.
  Cámara: proporciona acceso a las cámaras del dispositivo Android, tanto
para tomar fotografías como para grabar video.

 Multimedia: conjunto de bibliotecas que permiten reproducir y visualizar

audio, video e imágenes en el dispositivo.

4. Aplicaciones:
La arquitectura en una aplicación Android son como los planos de una casa cuando
queremos construirla, nos brindan la estructura base de nuestra aplicación. Lo que
nos permite tener un código mantenible a lo largo del tiempo. Así como en el plano
de una casa dividimos las secciones como cocina, sala, baños, dormitorios, etc. Así
mismo los componentes de arquitectura nos permiten dividir nuestro código en
clases. Existen muchas formas de arquitecturar una aplicación móvil, todo depende
de las necesidades de la aplicación.
Hay diferentes formas de organizar nuestro código {clases, interfases, etc.} a lo cual
le llamamos patrones de arquitectura; como por ejemplo: MVVM,MVP, MVC, etc.
Google recomienda el patrón de arquitectura MVVM para el desarrollo de
aplicaciones nativas y además ha creado una serie de librerías que nos brindan
componentes para facilitar la implementación de dicho patrón. Algunos de esos
componentes son: LifeCycle, LifeCycles Observes, ViewModel, LiveData.
Este es un patrón de arquitectura multipropósito basada en MVVM.
En este punto entran los principios de diseño de software, y uno de ellos es la
separación de responsabilidades. Nuestra aplicación debe estar dividida en
clases donde cada una tenga cierta responsabilidad. Las tres clases que se van a
utilizar son: UI Crontroller, ViewModel y LifeData.

1. UI Controller: es responsable de las tareas relacionadas a la interfaz de

usuario como mostrar vistas y capturas los eventos realizados por el usuario.
No es responsable de cálculos, ni de almacenar datos.

2. ViewModel: es el responsable de mantener los datos que el fragmento o la

actividad necesita mostrar. Los ViewModels podrían hacer simples cálculos y
transformaciones de los datos para que puedan ser mostrados en la vista
correctamente. Van a contener instancias de la clase LiveData.

3. LifeData: es una clase crucial y muy necesaria para la correcta comunicación

entre el UI Controler y el ViewModel.
Una de las razones por las que se utilizan los ViewModels es porque sobreviven a
los cambios de configuración. Las actividades y los fragmentos no sobreviven a los
cambios en la configuración.
Es importante seguir el principio de separación de responsabilidades por las
siguientes razones:
1. El código es más organizado, mantenible, “testeable y debugable”.
2. Al mantener el código en nuestros ViewModels nos permite sobrevivir a
cambios de configuración en el sistema.
3. El código es muy modular, permitiendo modificar componentes de alto nivel
sin necesidad de modificar más componentes.
4. La relación entre componentes son unidireccionales.
5. Los ViewModels nunca contienen referencias de los fragmentos o
actividades. Permitiendo reemplazar fácilmente la clase que utiliza el
ViewModel.
6. Facilita la creacion de pruebas unitarias. Debido que para poder probar
componentes Android se debe emular el FrameWork de Android. Mientras
que los View Models pueden ser probados pueden ser probados sin
necesidad de emular el FrameWork. Siendo mucho más rápidas y fáciles de
escribir.