Prof. Dr.

Jorge Domínguez Chávez

Curso de Programación Android con Java

Presentación
Este trabajo tiene como objetivo presentar el funcionamiento y las posibilidades que ofrece
el sistema operativo Android en el desarrollo de sus aplicaciones con Java.

Comenzamos por un enfoque analítico de las características básicas de Android hasta llegar
a la realización de una aplicación que ejemplos de sus funciones principales. Además, pretendemos
estimular a aquellas personas interesadas a investigar sobre la programación para móviles.

Adicionalmente, presentamos las características básicas para el desarrollo de aplicaciones

Android con el lenguaje de programación Java. Para ello es necesario el conocimiento básico del
lenguaje de programación y de la programación orientada a objetos. Sin embargo, contamos con cursos
de Java desde cero. Este trabajo se centra en entender las aplicaciones Android, y como este sistema
operativo trabaja y algunas de sus características principales.

Por medio de ejemplos prácticos revisamos las características más importantes del API de
Android, aplicado a smartphones o tablets, a su vez utilizamos el lenguaje Java, y herramientas de
desarrollo como Eclipse y el simulador, empleadas para crear rápidamente aplicaciones Android, así
como la aplicación de las distintas APIs disponibles a tal efecto.

El trabajo pretende mostrar, de una manera didáctica, el uso y potencial de esta plataforma
de desarrollo. Por esta razón, se dedica a describir los pasos necesarios para que un usuario con poca
experiencia sea capaz de desarrollar sus propias aplicaciones Android.

Programación Android con Java

¿Qué es una plataforma de software?
Una plataforma informática es un sistema que sirve como base para hacer funcionar
determinados módulos de hardware o de software con los que es compatible. Dicho sistema está
definido por un estándar alrededor del cual se determina una arquitectura de hardware y una
plataforma de software (incluyendo entornos de aplicaciones). Al definir plataformas se establecen los
tipos de arquitectura, sistema operativo, lenguaje de programación o interfaz de usuario compatibles.
 Una plataforma de desarrollo es el entorno de software común en el cual se desenvuelve la
programación de un grupo definido de aplicaciones. Comúnmente se encuentra relacionada
directamente a un sistema operativo; sin embargo, es posible encontrarla ligada a una familia de
lenguajes de programación o a una interfaz de programación de aplicaciones API1. También funciona
como sistema plataforma o multiusuario.

Una plataforma de software es un elemento básico en el desarrollo de aplicaciones

informáticas.

Mediante el marco de trabajo que proporcionan las plataformas se crea nuevo software y
que éste se ejecute sobre ellas. Ver Figura 1.

Figura 1: Arquitectura típica de

una computadora.

Las típicas plataformas de desarrollo incluyen una arquitectura de computadora, un sistema

operativo (SO), uno o más lenguajes de programación, sus correspondientes librerías e interfaces
gráficas o interfaces de usuario (user interface o UI).

Comúnmente, las plataformas son mencionadas con las API (funciones y métodos que
ofrece una biblioteca para ser utilizada por otro software como una capa de abstracción). Una
plataforma software está formada por un conjunto completo de API. Por lo general, estas plataformas
son dependientes de los sistemas operativos aunque existen otras que no lo son.

1 Interfaz de programación de aplicaciones o Application Programming Interface.

Plataforma de Desarrollo Java
Java es un lenguaje de programación de propósito general, concurrente, orientado a objetos
diseñado específicamente para tener tan pocas dependencias de implementación como fuera posible. Su
intención es permitir que los desarrolladores de aplicaciones escriban el programa una vez y lo ejecuten
en cualquier dispositivo (“codifica una vez, ejecuta muchas veces” o "write once, run anywhere"), lo
que quiere decir que el código que es ejecutado en una plataforma no tiene que ser recompilado para
correr en otra. Java es, a partir de 2012, uno de los lenguajes de programación más populares en uso,
particularmente para aplicaciones de cliente-servidor de web.

El lenguaje de programación Java fue desarrollado por James Gosling de Sun2

Microsystems (adquirida por la compañía Oracle) y publicado en 1995 como un componente
fundamental de la plataforma Java. Su sintaxis deriva en gran medida de los lenguajes C y C++, pero
tiene menos utilidades a bajo nivel que cualquiera de ellos. Las aplicaciones de Java son generalmente
compiladas a bytecode (clase Java) que se ejecuta en cualquier máquina virtual Java (JVM) sin
importar la arquitectura de la computadora subyacente.

El lenguaje Java tiene cinco objetivos principales:

1. Debería usar el paradigma de la programación orientada a objetos.

2. Debería permitir la ejecución de un mismo programa en múltiples sistemas operativos.

3. Debería incluir por defecto soporte para trabajo en red.

4. Debería diseñarse para ejecutar código en sistemas remotos de forma segura.

5. Debería ser fácil de usar y tomar lo mejor de otros lenguajes orientados a objetos, como C++.

Lo que se conoce como plataforma Java, antes Plataforma Java 2, abarca una serie de
tecnologías basada en varios conceptos:
• Un lenguaje de programación para codificar aplicaciones.

• Un conjunto de librerías que facilitan el trabajo a los programadores. Las principales API de
Java se dividen en 3 grandes bloques:
◦ Java SE: Edición Estándar (Standard Edition), antes J2SE. Dirigida a aplicaciones de
escritorio, applets, …
◦ Java EE: Edición Empresa (Enterprise Edition), antes J2EE. Enfocada en dispositivos de
consumo, con recursos limitados.
◦ Java ME: Edición Micro (Micro Edition), antes J2ME. Útil para aplicaciones empresariales
(web, distribuidas).
• Unas herramientas (JDK) para generar las aplicaciones a partir del código fuente.
2 SUN significa Stanford University.
 • Una máquina virtual para ejecutar una aplicación en cualquier computador (JVM).

Es, la portabilidad, lo que define a Java como tecnología: ejecutar una misma aplicación
en cualquier parte, en cualquier sistema operativo Windows, Linux, Mac, Unix, un teléfono móvil, un
navegador o ¡hasta un reproductor de Blu-ray!!

Esto es una cantidad increíble de equipos diferentes, ¿cómo consigue Java ser portable? El
secreto está en la máquina virtual. Ver figura 2.

Figura 2: Estructura de compilación de un

programa Java.

Un programa escrito en C o C++, es dependiente de la plataforma (procesador, sistema

operativo, etc.). Por el contrario, los programas Java se compilan en un formato intermedio
denominado bytecode. Los bytecodes no son -normalmente- ejecutables directamente por alguna
plataforma. Sin embargo, un programa especial, la máquina virtual, los traduce a código máquina
interpretable por el dispositivo sobre el que se esté ejecutando.

Por supuesto, para ejecutar un programa java en un computador hace falta instalar
previamente una máquina virtual.

La utilización de una máquina virtual tiene como propósito proporcionar al usuario un

entorno de desarrollo completamente configurado, eficiente y que le evite los problemas asociados a la
configuración y actualización de dicho entorno de desarrollo.

En este caso, la plataforma no es un hardware específico o un sistema operativo, sino más

bien una máquina virtual encargada de la ejecución de las aplicaciones, y un conjunto de bibliotecas
estándar que ofrecen una funcionalidad común.

Java es un ejemplo de plataforma independiente del SO debido a que es tanto el lenguaje

como la plataforma de desarrollo, la cual incluye la Java Virtual Machine (JVM) cuya función es
interpretar el bytecode resultante de la compilación del código fuente del programa en Java.

La plataforma Java define una plataforma de computación, capaz de ejecutar aplicaciones

desarrolladas usando el lenguaje Java u otros que compilen a bytecode y un conjunto de herramienta de
desarrollo.
Java ME
Tradicionalmente, los dispositivos móviles no han tenido, ni tienen tanta potencia como los
computadores Pc o Laptops. Por ello, se creó una versión de Java con librerías limitadas denominada
Java ME, diferenciándola de Java SE, que es la versión completa.

Java ME y Java SE también se diferencian en algunos aspectos en su máquina virtual y en

el lenguaje ya que, aunque el funcionamiento es idéntico (sintaxis e interpretación de bytecodes), la
máquina virtual ME tiene un subconjunto de las funcionalidades de SE. Eso sí, estos cambios están
documentados en sus correspondiente JSR3.

Orientado a objetos
La programación orientada a objetos (OO), se refiere a un método de programación y al
diseño del lenguaje. Aunque hay muchas interpretaciones para OO, una primera idea es diseñar el
software de forma que los distintos tipos de datos que usen estén unidos a sus operaciones. Así, los
datos y el código (funciones o métodos) se combinan en entidades llamadas objetos. Un objeto puede
verse como un paquete que contiene el “comportamiento” (el código) y el “estado” (datos). El principio
es separar aquello que cambia de las cosas que permanecen inalterables. Frecuentemente, cambiar una
estructura de datos implica un cambio en el código que opera sobre los mismos, o viceversa. Esta
separación en objetos coherentes e independientes ofrece una base estable para el diseño de un sistema
software. El objetivo es hacer que grandes proyectos sean fáciles de gestionar y manejar, mejorando
como consecuencia su calidad y reduciendo el número de proyectos fallidos.

Otra de las grandes promesas de la programación orientada a objetos es la creación de

entidades genéricas (objetos) para la reutilización del software entre proyectos, una de las premisas
fundamentales de la Ingeniería del Software. Un objeto “cliente”, debería en teoría, tener el mismo
conjunto de comportamiento en diferentes proyectos, sobre todo cuando estos coinciden en cierta
medida, algo que sucede en las grandes organizaciones. En este sentido, los objetos podrían verse como
piezas reutilizables que se emplean en múltiples proyectos distintos, posibilitando así a la industria del
software a construir proyectos de envergadura empleando componentes ya existentes y de comprobada
calidad; conduciendo esto finalmente a una reducción drástica del tiempo de desarrollo.

Sintaxis
La sintaxis de Java se deriva en gran medida de C++. Pero a diferencia de éste, que
combina la sintaxis para programación genérica, estructurada y orientada a objetos, Java fue construido
desde el principio para ser orientado a objetos. Todo en Java es un objeto (con excepciones), y todo
reside en alguna clase (una clase es un prototipo a partir del cual se crean varios objetos).

La reutilización del software ha experimentado resultados dispares, encontrando dos

dificultades principales: el diseño de objetos realmente genéricos es pobremente comprendido, y falta

3 Java Specification Request (JSR), las cuales son documentos formales que describen las especificaciones y tecnologías
propuestas para que sean añadidas a la plataforma Java.
una metodología para la amplia comunicación de oportunidades de reutilización. Algunas comunidades
de “código abierto” (open source) quieren ayudar en este problema dando medios a los desarrolladores
para diseminar la información sobre el uso y versatilidad de objetos reutilizables y bibliotecas de
objetos.

¿Qué es Android?
Android es una plataforma de software y un sistema operativo para dispositivos móviles
basada en un núcleo4 de Linux, desarrollada por Google y más tarde por Open Handset Alliance. En
esta plataforma, los desarrolladores escriben código en Java a ejecutar en móviles mediante las librerías
Java desarrolladas por Google. También, pueden escribir aplicaciones en otros lenguajes, como C, C++,
Objetive C, para luego ser compiladas en código nativo ARM5 y ejecutarlas, aunque este proceso de
desarrollo no está soportado oficialmente por Google. La mayor parte de la plataforma de Android está
disponible bajo licencia de software libre de Apache y otras licencias de código abierto.

La principal finalidad desde el punto de vista del desarrollador es: Obtener el máximo
partido de la plataforma, que la aplicación sea portable, fácil de ejecutar y reutilizable, y que tenga
facilidad para integrar todo tipo de programas con las aplicaciones Web de Google. Google buscaba
competir en el segmento de los teléfonos inteligentes para posicionar sus servicios de búsqueda.

Breve Historia
En Julio de 2005, Google adquirió Android, Inc, una pequeña compañía emergente de
California. En esos momentos, la compañía se dedicaba a la creación de software para teléfonos
móviles. Una vez en Google, el equipo desarrolló un SO basado en Linux para dispositivos móviles.
Más adelante, Google adaptó su buscador y sus aplicaciones para su uso en móviles.

En septiembre del 2007, Google tenía varias patentes de aplicaciones sobre el área de la
telefonía móvil. El 5 de noviembre del mismo año, se anunció la fundación de Open Handset Alliance
al mismo tiempo que la creación de la plataforma Android. En Noviembre del 2007 es lanzado por
primera vez Android Software Development Kit, y casi un año después (Agosto 2008) aparece Android
0.9 SDK en versión beta. Pasado un mes Google lanza la versión Android 1.0 (Release 1). Open
Handset Alliance está formada por un consorcio de 34 compañías de hardware, software y
comunicaciones, entre las cuales se incluyen Google, HTC, Intel, Samsung y Motorola entre otras,
dedicadas a investigar estándares abiertos para dispositivos móviles, liberaron en 2008 su sistema
operativo Android. Su núcleo estaba basado en Linux y utilizaba muchos otros proyectos código
abierto como SQLite o Webkit.

La plataforma completa se distribuye como software libre, aunque el propio Google o

algunas empresas de móviles suelen añadir aplicaciones no libres como Google Maps.

4 Kernel. Núcleo en Alemán.

5 ARM contiene un ambiente de desarrollo (IDE), un compilador C/C++, un depurador y un profiler.
 Respecto al desarrollo de aplicaciones, deseaban que el entorno fuera cómodo para los
programadores, y que portar aplicaciones ya existentes fuera lo más rápido y fácil posible. Es por ello
que eligieron Java, por ser un lenguaje muy popular y del cual existían ya muchas aplicaciones escritas,
además de varios entornos gráficos de desarrollo integrados.

El primer teléfono en el mercado con Android es el T-Mobile G1 (conocido como Dream),

lanzado el día 22 de octubre de 2008 que viene con la versión Android 1.0 preinstalada. Este móvil es
el resultado conjunto de T-Mobile, HTC y Google. Por último, desde el 21 de octubre de 2008, Android
está disponible como código abierto. Gracias a esto, cualquier desarrollador añade extensiones, nuevas
aplicaciones o reemplaza las existentes por otras dentro del dispositivo móvil. Ver figura 3.

Figura 3: T-Mobile
G1 (Dream)

Características de Android
• Amplia variedad de diseños (VGA, librerías de gráficos 2D y 3D…).

• Almacenamiento de datos en BBDD SQLite. [13]

• Conectividad (GSM/EDGE, CDMA, EV-DO, UMTS, Bluetooth y Wi-Fi).

• Mensajería (SMS y MMS).

• Navegador Web.

• Las aplicaciones escritas en Java pueden ser compiladas y ejecutadas en la máquina virtual de
Dalvik, la cual es una especializada máquina virtual diseñada para uso en dispositivos móviles.
• Soporte de formatos (MPEG-4, H.264, MP3, AAC, OGG, AMR, JPEG, PNG, GIF).

• Soporte para hardware adicional (cámaras de video, pantallas táctiles, GPS, acelerómetros…).

• Entorno de desarrollo (emulador, herramientas de depuración, perfiles de memoria y

funcionamiento, plugin para Eclipse IDE).
Arquitectura Android
A continuación, se explica en detalle la arquitectura Android y cada una de sus partes. Ver
figura 4.

Figura 4: Pila de compilación de una aplicación Android.

La figura 4 representa la pila de la arquitectura Android desde la cima que es el nivel de las
aplicaciones, hasta la base del Hardware:
• Aplicaciones: cualquier tipo de aplicación Android. Es la capa que utiliza el usuario.

• Framework de Android: Acceso al API de Android para reutilizar o modificar componentes.

Es la capa en la que, como desarrolladores Android, trabajaremos con SDK. Todo en esta capa
será una representación exacta de la capa HAL.
 • Bibliotecas nativas en C/C++: el desarrollador puede usarlas a través del Framework. Es la
capa en la que trabajamos Android a bajo nivel (se trabaja con NDK6 y se programa en C/C++).
• Runtime de Android: bibliotecas del lenguaje Java que se ejecutan sobre:

◦ Una única instancia en la máquina virtual Dalvik (antigua).

◦ Sobre el entorno de ejecución Android Runtime (o conocido por sus siglas ART).

• Comunicación ligada entre procesos (Binder IPC, Inter-Procces Communication):

Mecanismo que facilita al Framework ir más allá de un proceso y llamar a los servicios del
sistema operativo Android. Con ello, las API interactuan con los servicios del sistema operativo
Android. Estas comunicaciones están ocultas para el desarrollador en la capa de Framework
(ver Services).
• Servicios del Sistema Android: Casi todas las funcionalidades en el API del Framework se
comunicarán con algún servicio (Service) del sistema para acceder al hardware implicado. Cada
servicio se divide en componentes enfocados en funcionalidades. Los servicios se agrupan en:
◦ System: Incluye gestores de ventanas, de notificaciones, etc.

◦ Media: Incluye aquellos involucrados en la reproducción y la grabación multimedia

(imágenes, audio, video, etc).
• Capa de abstracción del Hardware (HAL, Hardware Abstraction Layer): Interfaz para que
el sistema operativo Android llame a la capa de drivers (controladores) del dispositivo.
• Núcleo de Linux: Capa de abstracción del hardware y servicios de seguridad, gestión de
memoria, de procesos, pila de red, modelo de los controladores, etc.
• Ensamblador: lenguaje de bajo nivel para circuitos integrados programables. Es una
representación mnemotécnica del código máquina en binario y varias constantes para programar
de una manera sencilla que utilizar directamente el binario.
• Firmware: Instrucciones de máquina grabadas en un chip para propósitos específicos.

• Hardware: Son las partes físicas y los componentes de un dispositivo.

Dalvik
Dalvik es la máquina virtual que ejecuta las aplicaciones Android. Pero no es una máquina
virtual Java. Es un software que simula ser una computadora, y que puede ejecutar programas y
órdenes cómo si fuese una computadora. Dalvik está dentro de nuestro dispositivo móvil, por lo que es
un equipo virtual dentro de otro.

Expliquemos cómo es el proceso de desarrollo de una aplicación Android. Ver figura 5.

6 NDK (Native Development Kit) facilita a los desarrolladores reutilizar código escrito en C/C++ introduciéndolo en las
aplicaciones a través de JNI (Java Native Interface).
 Figura 5: Dalvik caché.

Las herramientas de Google compilan código Java en bytecode. Hasta aquí se comporta
como cualquier otro kit de desarrollo Java. Sin embargo, el bytecode, a su vez, es transformado en el
formato binario propio de la máquina Dalvik: .dex. La máquina virtual Dalvik tiene grandes diferencias
con HotSpot. Está optimizada para utilizar baja memoria (esto es posible a que es una máquina basada
en registros y no en pila) y está diseñada para ejecutar cada aplicación aislada una máquina virtual
diferente.

ART, la nueva máquina virtual que usará Android.

ART a diferencia de Dalvik, tiene un sistema de compilación diferente a lo que se

conoce de su antecesor, pues compila los procesos y guarda el caché desde el momento de la
instalación de la aplicación. Esto quiere decir, que en vez de que a diferencia de lo que sucede en
Dalvik que la aplicación se va compilando a medida que vas navegando dentro de la app, en ART
sucede que la compilación de la app se ha realizado y se ha cacheado en el sistema desde el momento
de su instalación, por ende, la aplicación deberá iniciar más rápido y ser más fluido, por otra parte,
también hay que recalcar que los procesos gastarán menos batería y por ende el rendimiento del sistema
a nivel general deberá ser mayor.

ART sólo está presente en Android 4.4 KitKat, así que de momento sólo en los Nexus 5 (
u Otros dispositivos que hayan instalado una ROM basada en AOSP con Android 4.4, pero aún muy
inestables) y en los próximos días el resto de los Nexus 7, Nexus 4 y 10. Más tarde y como viene
siendo habitual, Samsung y HTC serán los primeros fabricantes también en actualizar.

Gracias al proyecto Apache Harmony, Android proporciona un subconjunto relativamente

completo de la API de Java SE. De esta forma, crear o portar aplicaciones java, ya sean en código
fuente o en formato binario resulta -en algunos casos- trivial.
 Sin embargo, la API de Google no es 100% compatible con la de Java SE. Bibliotecas
como las del entorno gráfico (Swing, Awt) no están disponibles en Android. Además, conceptos como
la gestión de la seguridad han sido completamente reinventados.

La máquina virtual Dalvik levantó suspicacias de Sun Microsystems por no utilizar una
plataforma Java estándar como era ME, SE o JavaFX. Los bytecodes de un programa Android no son
compatibles con el Java de las especificaciones, lo cual contribuye -según Sun- a la fragmentación del
mercado.

Como sabemos, las apps de Android se distribuyen en el formato .apk. Un apk contiene
clases de Java compiladas en un formato de bytecode conocido como DEX. El formato DEX es
independiente de arquitectura de procesador, por lo que para ser ejecutado necesita traducirse a “código
máquina” nativo para el procesador de nuestro dispositivo.

La diferencia fundamental entre Dalvik y ART es cuándo hacen esta traducción o

compilación. Dalvik utiliza lo que se llama compilación “justo a tiempo” (just-in-time, o JIT), mientras
que ART utiliza compilación previa (ahead-of-time, o AOT).

Con el compilador JIT de Dalvik, cada que iniciamos una app, la máquina virtual
dinámicamente traduce una parte del bytecode DEX a código máquina. Conforme continúa la ejecución
de la app, se compila más bytecode y se almacena en memoria cache. Es por ello que se dice que la app
está siendo compilada “justo a tiempo” conforme la usamos. En el caso de ART, las apps se compilan
desde que se instalan en el dispositivo, y ya se deja instalado el código máquina listo para ejecutarse y
sin necesidad de mayor compilación.

La gran mayoría de las apps para Dalvik deben funcionar en ART sin problema. Sin
embargo, hay algunas casos donde sí es mejor ajustar tu código para asegurar que tu app funcione bien
en ART.

Una práctica relativamente común en Android apps hasta ahora es que en el código se
incluyan llamadas explícitas al recolector de basura por medio de System.gc(). Típicamente esto se
hace para evitar ocurrencias de GC_FOR_ALLOC (cuando el sistema se queda sin memoria y llama de
manera forzada al recolector de basura en un momento que puede no ser el ideal). En ART, debido a las
mejoras en el sistema de recolección de basura, ya no será necesario estar haciendo llamadas explícitas
a System.gc().

Desde el código de tu app detectas si se está ejecutando sobre Dalvik o ART, checando el
valor deSystem.getProperty(“java.vm.version”). Si el valor es 2.0.0 o mayor, entonces la app se está
ejecutando en ART.
Figura 6: Vida de una APK.

ART es más estricto que Dalvik en la verificación de código. El código producido con el
SDK de Android no debería tener problema, pero sí puede ser que herramientas terceras generen código
que ART no acepte. Por ejemplo, esto podría ser el caso con herramientas para ofuscación de código.
Los proveedores terceros están ajustando sus herramientas para asegurar que sean compatibles con
ART así que la recomendación en ese sentido es actualizar tus herramientas a la versión más reciente.

Un aspecto positivo es que será más fácil rastrear errores de tipo NullPointerException, ya
que ART dará información sobre cuál fue el método que el código intentó acceder.

Bytecode
En programación en general, el bytecode es el resultado de realizar el trabajo de procesar el
código fuente (el código programado) y optimizarlo. Como resultado, se obtiene el archivo llamado
bytecode. El cual es portable entre arquitecturas. La máquina virtual es la encargada compilar, en
tiempo de ejecución, a código máquina del sistema donde se despliega. Lo que resulta más rápido que
realizar todo el trabajo desde el código fuente, pues se ha realizado de antemano el trabajo.

En Android los programas están escritos normalmente en Java y compilados a bytecode

por la máquina virtual de Java. Luego es traducido a archivos bytecode para Dalvik o para ART:
• DEX (Dalvik Executable Format, Formato Ejecutable para máquinas virtuales Dalvik): Archivo
de bytecode que siempre será llamado “classes.dex” comprimido dentro del archivo APK. Este
archivo es general y no está preparado para un Hardware en específico, por lo que tiene que ser
 traducido al código máquina en cada dispositivo (para no tener que traducirlo cada vez que se
ejecute la aplicación se crea o un archivo ODEX o un ELF). Es necesario tanto para la máquina
virtual Dalvik, como para ART.
• ODEX (Optimized DEX, archivo DEX Optimizado): Este archivo contiene el conjunto de
instrucciones utilizado por la máquina virtual Dalvik. Cada vez que la aplicación se ejecuta en
el dispositivo, la máquina virtual Dalvik traduce las partes utilizadas del archivo DEX
dinámicamente y lo guarda en el archivo ODEX; a medida que se va traduciendo más, se va
guardando en el archivo ODEX. Se genera mediante la herramienta “dexopt” a partir de un
archivo DEX. Es necesario para la máquina virtual Dalvik.
• ELF (Executable and Linkable Format, Formato Ejecutable y Enlazable): El archivo ELF es un
ejecutable para Linux; es un formato de archivo para ejecutables, código objeto, bibliotecas
compartidas y volcados de memoria. Es decir, el archivo bytecode DEX se traduce al archivo
archivo ELF siendo éste la traducción a código máquina del Hardware donde se va a ejecutar;
de ahí que se compile en el mismo dispositivo en el momento de la instalación (a diferencia de
ODEX, ELF es la traducción completa de todo el archivo DEX en una sola vez durante la
instalación; ODEX es la suma de las partes que ha ido traduciendo la máquina virtual Dalvik
cada vez que se ejecutó la aplicación). Se genera mediante la herramienta “dex2oat” a partir de
un archivo DEX. Es necesario para ART (sustituye al archivo ODEX de la antigua máquina
virtual Dalvik).

Empaquetar en APK un programa Android

El Sistema de Construcción (Build System) combina el JDK de Java y las herramientas del
SDK de Android. Las pruebas (testing) se realizan para asegurar que la aplicación funciona como se
espera en condiciones reales. Con Gradle en Android Studio se compila, firma y optimiza la aplicación
a la vez. Al terminar, se obtiene una aplicación APK firmada que se puede distribuir a los usuarios
directamente o través de la tienda de aplicaciones “Google Play”. El archivo APK contiene: código
fuente compilado, recursos, el manifiesto (AndroidManifest.xml), entre otros.
Figura 7: Creando un paquete APK.
 A continuación, los pasos para crear un paquete APK (ver figura 7). Va desde la zona alta
de la imagen, donde tendremos el código que estamos programando con Android Studio y los recursos
que añadamos a nuestra aplicación; hasta la zona baja, donde obtendremos el archivo APK firmado.

El resultado es una plataforma que no es estrictamente “Tecnología Java”, simplemente

utiliza el lenguaje Java como base para crear aplicaciones.

A continuación, explicamos los pasos de la figura 7, por herramienta utilizada, las cuales
encontramos como ejecutables en la carpeta de SDK de Android y se usa el compilador de Java. Este
proceso es automático:
• aapt (Herramienta de empaquetado de activos Android, The Android Asset Packaging Tool):
Compila el archivo “AndroidManiest.xml” y los archivos XML de las Activities. Además,
genera el archivo “R.java” para referenciar los recursos desde el código Java.
• Aidl (Lenguaje para definir interfaces Android, Android Interface Definition Language):
Convierte los interfaces “.aidl” (interfaces para comunicar servicios mediante la comunicación
entre procesos, IPC) en interfaces Java.
• Compilador Java: toma el código Java, incluidos los archivos “R.java”, los interfaces de“.aidl”
y los compila en archivos “.class”.
• dex: Convierte los archivos “.class” en archivos bytecode DEX. Además, cualquier biblioteca
importada, así como otros archivos “.class” incluidos son convertidos a archivos DEX,
incluyendo las clases de nuestro código en un único archivo DEX. Para optimizar el espacio, los
Strings duplicados y otras constantes repetidas se introducen una única vez en el archivo DEX.
• dexopt: Sólo se aplica si se ejecuta en el emulador desde Android Studio. Convierte el archivo
DEX al archivo compilado ODEX mediante una compilación AOT (Ahead Of Time, Antes de
Tiempo) para que funcione única y exclusivamente en el emulador. En este caso, ODEX no se
empaqueta dentro del APK, sino que adjunta al APK.
• apkbuilder: imágenes, vídeos, y otros que no se compilan, junto con los archivos DEX, son
empaquetados en el archivo APK.
• Jarsigner: Firmamos el archivos APK con una clave de desarrollo (debug) o de lanzamiento
(release). El archivo APK resultante ya se puede instalar en cualquier dispositivo Android.
• Zipalign: Si el archivo APK se ha firmado con la clave de lanzamiento (release), el archivo se
debe alinear (la alineación de la estructura de datos consiste en desplazar los bits un múltiplo
del tamaño de la palabra que pueda controlar el procesador, y rellenar lo que falte; en Android
normalmente son 4 bytes). El archivo APK alineado resultante aumenta el rendimiento del
sistema de memoria debido a la forma en que el procesador gestiona la memoria en un
dispositivo.
Archivo APK
El archivo APK contiene el resultado del anterior proceso. Los archivos son:
• DEX: contiene los archivos Java, como nuestros archivos Java o el R.java

• Recursos compilados: archivos XML, como el AndroidManifest.xml, o los Layouts.

• Recursos No compilados: vídeos, imágenes, audios, etc.

Figura 8: El archivo APK contiene el resultado del anterior proceso.

También recordar que el APK está firmado y alineado.

Falta el archivo ELF para ART, que no se ha obtenido en el anterior proceso. La conversión
de un archivo DEX a un archivo ELF se realiza mediante la herramienta “dex2oat”. Ésta herramienta
se encuentra dentro del sistema operativo Android. En cuanto instalemos el archivo APK en el sistema
operativo Android, la herramienta “dex2oat” toma el archivo DEX y crea el archivo ELF.

Dalvik aplica la herramienta “dexopt” sobre las partes del archivo DEX que se estén
usando, para generar el archivo ODEX en el momento de la ejecución por la máquina virtual Dalvik.

Instalación del APK en el dispositivo

El archivo DEX en su estado original se dice que está en el estado Pre-dexopt.

En el momento de la instalación de la aplicación en el dispositivo, el archivo DEX es

modificado:
• Sé optimiza.

• Sé intercambia el orden de los bits según el formato Endianness, de cómo se almacenan los
datos y la arquitectura con la que funciona el procesador (es decir, de cómo se almacenen los
datos en big-endian que es el orden natural, little-endian que es del menos relevante al más
 relevante, y middle-endian que es el soporte para los dos formatos anteriores).
• Sé crean estructuras de datos simples.

• Sé enlazan las funciones de las bibliotecas inline (se insertan una copia del código fuente de la
función en la sección del código donde sea llamada).
• Los objetos de clases vacías serán cortocircuitadas (short-circuited, referido en programación a
que no se evaluará si no es necesario).
• Si trabajamos con ART, cuando se instala la aplicación se genera el archivo ELF desde el DEX.

• Si trabajamos con Dalvik, puede crearse el archivo ODEX al instalarse, aunque no será
completo.

Una curiosidad que seguro que has notado cuando se actualiza tu dispositivo Android. Al
terminar la actualización se tienen que actualizar las aplicaciones instaladas. Esta actualización es la
compilación de los bytecodes DEX dentro de tu dispositivo.

Compilación JIT (Just-In-Time, Justo a tiempo)

La compilación JIT es compilar el bytecode del programa en tiempo de ejecución.

Supongamos que tienes un móvil con una aplicación. De esta aplicación sólo está el
bytecode DEX dentro del archivo APK. Cuando presionas el icono para ejecutar la aplicación por
primera vez, se realiza la compilación de la aplicación en tu dispositivo por la máquina virtual Dalvik,
lo que convierte el bytecode a código máquina (archivo ODEX). Luego, el código es entendido por el
Hardware. En este momento podemos decir que la aplicación funciona.

Evidentemente este proceso de compilación JIT consume tiempo ; por lo que no se compila
cada vez que se ejecuta el mismo programa. Sino que se compila el bytecode DEX y se cachea el
código máquina resultante en el archivo archivo ODEX. En siguientes ejecuciones de la misma
aplicación se reutiliza el código ya cacheado del archivo ODEX.

Las razones para realizar una compilación JIT son:

• Compilar el bytecode a código máquina optimizado para la CPU y el sistema operativo donde
se va a ejecutar.
• El sistema colecta estadísticas de la ejecución de la aplicación en una máquina. De este modo,
decide recompilarla manera para optimizar el rendimiento.
• El sistema realiza optimizaciones globales sin perder las ventajas del enlazamiento dinámico (el
sistema operativo carga las bibliotecas compartidas a memoria RAM, y vincula las que necesite
a la aplicación; si desarrollamos una aplicación con la cámara de fotos, Android carga la
biblioteca de Camera a RAM y la vincula a nuestra aplicación para que la utilice).
Herramienta "dexopt"
Se verifican y optimizan las clases del archivo DEX cargando las clases en la máquina
virtual y ejecutándolas. En caso de que algo falle, no se verifica ni optimiza.

La herramienta “dexopt” efectua una inicialización abreviada de la máquina virtual,

cargando cero o más archivos DEX desde la ruta de la clase de arranque (bootstrap class path), y luego
verifica y optimiza, lo posible, del archivo DEX objetivo. Al terminar, el proceso libera los recursos.

La herramienta “dexopt” genera archivos ODEX desde archivos DEX en los siguientes
casos (La letra precedente a la descripción corresponde en la figura 9 con la letra de cada aplicación):

A) Aplicación de producción (para Google Play): El instalador de aplicaciones del

sistema lo genera cuando la aplicación se instala por primera vez. Esta aplicación tiene privilegios
para escribir en el directorio “dalvik-cache”. Si no se ha convertido el código DEX a ODEX, se genera
cuando se ejecute la aplicación.

B) Aplicación de desarrollo para el emulador: El Sistema de Contrucción (Build

System) realiza una compilación AOT(Ahead Of Time, Antes de Tiempo) en el momento en que el
SDK de Android empaqueta el APK. Se extrae el archivo DEX y se elimina (el APK resultante no
tendrá archivo DEX). El ODEX se almacena al lado del archivo comprimido original (no en el
directorio “dalvik-cache”), formando parte de la imagen del sistema. Este caso requiere utilizar el
emulador, forzar una compilación JIT del archivo DEX, para extraer el archivo ODEX resultante al
directorio “dalvik-cache”.

C) Aplicación de desarrollo para dispositivo físico: La máquina virtual Dalvik realiza

una compilación JIT. La salida va a un directorio especial llamado “dalvik-cache”. Este método solo
está permitido para desarrollo, donde los permisos del directorio “dalvik-cache” no están restringidos.
En producción no está permitido.
Figura 9: Generación de archivos ODEX desde archivos DEX.

El directorio “dalvik-cache” se localiza en la ruta “$ANDROID_DATA/data/dalvik-cache”.

Los archivos ODEX tienen un nombre derivado de la ruta donde se encuentra el archivo
DEX. Sólo tiene permiso para leer –pero no modificar o eliminar- los archivos DEX tanto de nuestra
aplicación como de otras. Las aplicaciones sólo tienen permiso para acceder a su archivo ODEX.

La creación ODEX desde DEX, en los casos donde “Dalvik compila con JIT el archivo
ODEX” y “el instalador de aplicaciones genera el archivo ODEX”, sigue los siguientes pasos:

1º Si no existe, crea el directorio “dalvik-cache”.

 2º El archivo DEX se descomprime del archivo APK. Se reserva una pequeña cantidad de
espacio al inicio del archivo DEX para la cabecera del archivo ODEX.

3º El archivo se asigna a memoria para acceder a ella fácilmente y se ajusta para el sistema
operativo. Incluye el intercambio de bytes, la reordenación de bytes, comprobaciones estructurales
básicas (como asegurar que los offsets y los índices de los archivos estén dentro de rangos válidos), sin
cambiar nada significativo del archivo DEX.

El proceso de verificación del bytecode implica el escaneo de todas las instrucciones de

cada método en cada clase de un archivo DEX. El objetivo consiste en identificar las secuencias de
instrucciones ilegales (algo ilegal es realizar una llamada desde un paquete a un método de una clase de
otro paquete diferente) para no tener que realizar las comprobaciones en tiempo de ejecución. Muchos
de los cálculos son necesarios para la recolección exacta de basura.

Por razones de rendimiento, la optimización asume que la verificación se ha ejecutado

correctamente. Por defecto, Dalvik verifica las clases y optimiza las clases verificadas.

Una vez pasada la verificación exitosamente, se inserta un flag en el ODEX. De esta

manera no se verifica cuando se recargue.

La optimización de Dalvik consta de lo siguiente:

• Para llamadas a métodos virtuales, remplaza el índice de método por una índice de vtable.

• Para instancias de campos get/put, remplaza el índice del campo por un byte offset. También,
fusiona las variante boolean / byte / char / short en una sola forma de 32 bits.
• Remplaza las llamadas de alto volumen, como String.length(), con remplazos en línea (inline).
Salta la llamada a métodos sobrecargados, directamente se intercambia desde el intérprete a la
implementación nativa.
• Elimina los métodos vacíos.

• Añade datos previamente calculados.

Con respecto a la optimización pueden darse los siguientes problemas:

• Los índices vtable y los byte offset están sujetos a cambios si se actualiza la máquina virtual.

• Si la superclase (en herencia es la clase padre) pertenece a un archivo DEX diferente, y el otro
DEX con la clase padre se actualiza, habrá que asegurar que nuestros índices y offsets se
actualicen también.

Entorno de ejecución ART

ART (Android Runtime, Entorno de ejecución Android), realiza una compilación AOT en
el momento de la instalación para obtener el ejecutable ELF (sustituye al archivo ODEX de Dalvik).
Figura 10: Ejecución ART.

ART mejora respecto a la máquina virtual Dalvik:

 • Mejora el rendimiento del recolector de basura.

• Mejora la depuración de aplicaciones.

• Mejora los análisis de ayuda al desarrollo.

• Consume menos energía.

• Mejora el rendimiento general del sistema.

• No hay caché de código en tiempo de ejecución.

• Al utilizar sólo memoria RAM se puede paginar (Dalvik usa memoria Caché no paginable).

• Pre-inicializa el conjunto de clases en tiempo de compilación lo que mejora el rendimiento de la

memoria RAM.
• Compilar con la herramienta “dex2oat” desde un archivo DEX a un ELF consume casi tres
veces más de tiempo que, compilar con la herramienta “dexopt” de DEX a ODEX. Pese a esto,
el resultado es una compilación completa en los archivo ELF, al contrario que en los ODEX que
sólo se compilaba una parte.

Como añadido, ART mantiene la retro-compatibilidad con Dalvik al utilizar sus mismos
bytecode “.dex”. Pero ART no utiliza “.odex”, los sustituye por los ejecutables “ELF”.

Compilación AOT (Ahead-Of-Time, Antes de tiempo)

La compilación AOT es compilar el bytecode en código máquina antes de que se ejecute
el programa.

En Android se compila el bytecode DEX en el momento en el que se instala la aplicación

en el dispositivo, convirtiéndose en el archivo ejecutable ELF.

Las razones para realizar una compilación AOT son:

• La ejecución es rápida al tener compilados los programas y bibliotecas. Ahorra espacio en disco
duro, en memoria RAM, y reduce el tiempo en iniciarse. Utilizar AOT reduce el número de
compilaciones, utiliza menos el procesador, por lo que ahorra batería; por esto es muy útil en
dispositivos móviles.
• En contraposición. Compilar “justo a tiempo” (JIT) es lento –por compilar mientras se ejecuta-
cuando hay código complejo y provoca latencia, cosa que no ocurre al compilar con AOT.
Aunque con AOT no se permite realizar ciertas optimizaciones que sí se pueden hacer con JIT.

Odex y Deodex (u Odexing y Deodexing)

Posiblemente hayas escuchado la palabra ROM (memoria de sólo lectura que guarda el
sistema operativo). Una ROM cocinada o modificada quiere decir que el sistema operativo se ha
modificado con aplicaciones, animaciones, temas, procesos internos, configuraciones, etc elegidos por
su creador; y cuando la instalemos en nuestro dispositivo, se verá como lo han modificado desde el
principio.

Seguro que habrás visto que las palabras “Odex” y “Deodex” se parecen al archivo ODEX.
Como vimos anteriormente, ODEX es el bytecode que optimiza el inicio de las aplicaciones para cada
dispositivo (es el DEX optimizado para la máquina virtual Dalvik).

La problemática de los cocineros de ROM, es que si modifican un archivo APK ya

instalado en el dispositivo, y no refrescan el archivo ODEX, provoca errores. Por lo que tienen que
“deodexar” el archivo APK antes de trabajar con éste, para facilitar su tarea.

He utilizado “Deodex” como verbo, pues es la acción. Tenemos tipos de acciones con la
conversión de los bytecode:
• Odex (Odexar): Es lo que ya vimos (lo “normal”), lo que se hace al crear desde el archivo DEX
el archivo ODEX mediante la herramienta “dexopt”.
• Deodex (Deodexar): Implica elegir un archivo APK, buscar su archivo ODEX en la memoria
caché, e introducirlo dentro de dicho APK. Esto agiliza la programación, al modificar los
archivos APK sin preocuparse de que el ODEX no esté actualizado por estar en la memoria
caché; asegurando así la integridad de la aplicación. Puede “deodexarse” toda una ROM entera,
lo que implica la “deodexación” de todos sus archivos APK instalados.

Por tanto, para trabajar con ROM cocinadas es mejor que hayan sido “Deodexadas”.

Otras dificultades son:

• El archivo ODEX tiene dependencias en cada archivo BOOTCLASSPATH que se carga cuando
se genera. El archivo ODEX sólo es válido cuando se utiliza ese archivo BOOTCLASSPATH.
Dalvik fuerza esto al almacenar un checksum (suma de control) de cada archivo en el archivo
ODEX. Lo que hace que sea dependiente de su checksum, asegurando que el checksum de cada
archivo coincida con el archivo ODEX cargado. El archivo BOOTCLASSPATH es un listado de
APK o JAR (los cuales son “core.jar”, “ext.jar”, “framework.jar”, “android.policy.jar” y
“services.jar”, y están en el directorio “/system/framework”) donde las clases son cargadas. Sin
embargo, algunas APK tienen dependencias extras a otros APK o JAR (además de las
anteriores). Las dependencias de los archivos ODEX complican la modificación de aplicaciones
ya instaladas. Esto se debe a que no se puede tomar una APK con su archivo ODEX de una
imagen del sistema, e intentar ejecutarla en otra imagen del sistema (a menos que utilicen
exactamente los mismos archivos del Framework, cosa casi imposible).
• Si hace cualquier cambio en el archivo BOOTCLASSPATH, invalida todas las dependencias de
los archivos ODEX (lo que implica la invalidación de todos los APK y JAR del dispositivo).
• Los archivos ODEX son difíciles de convertir a archivos DEX.
 • La primera vez que una aplicación “deodexada” sea ejecutada por la máquina virtual Dalvik,
requerirá un tiempo superior de inicio. El resto de ejecuciones la aplicación no tarda más, pues
ya habrá movido el archivo ODEX a la carpeta de caché.

Diferencias entre Java y Android

¿Qué es Java exactamente: un lenguaje, una máquina virtual, …? ¿Es Java libre? ¿Dónde
entra Android en todo esto? ¿Android es Java? ¿Funciona una aplicación Java tal cual en Android?
¿Android es libre?

Android y Java son dos plataformas diferentes que comparten lenguaje, así como las
bibliotecas básicas de programación.

En cualquier caso, hoy más que nunca, este lenguaje de programación sigue presente en
prácticamente todos los entornos, desde el escritorio, a la web y a los dispositivos móviles, en
cualquiera de sus variantes.

Introducción a Android
Hoy, los teléfonos inteligentes o smartphone son dispositivos multiuso. Buscamos
información, jugar, navegamos por Internet, pasamos el rato en las redes sociales o trabajar se han
convertido en tareas habituales para quienes han hecho del teléfono inteligente uno de sus compañeros
preferidos. Llegar a este nuevo tipo de consumidores desde la pantalla del smartphone con nuevas
formas de comunicación es todo un desafío -y un caudal de oportunidades- para las marcas. Este es un
tiempo único para el mundo de los celulares, en particular de los teléfonos inteligentes (Smartphones).
Este tipo de dispositivos nunca han sido tan populares. El sistema operativo Android ha expandido su
mercado no solamente a este tipo de teléfonos, sino también a tabletas y televisores.

La evolución y la reducción de costos de los teléfonos inteligentes ha permitido que

millones de personas tengan acceso a este tipo de tecnología, permitiendo llevar mucha de la
información consigo. Anteriormente esto solo era posible con Laptops, pero al día de hoy los celulares
son las computadoras portátiles de nuestra era.

Millones de teléfonos Android se activan diariamente, y con el uso de Google Play

(anteriormente conocido como Android Market) para la distribución de aplicaciones, los
desarrolladores de aplicaciones Android pueden poner de inmediato y al alcance de los usuarios las
aplicaciones y juegos creados. Google Play es un mercado abierto, sin un proceso de revisión, con el
objetivo de distribuir de manera libre o de paga a los teléfonos Android que sean compatibles con las
aplicaciones distribuidas.

Pero, ¿Qué es Android? En términos concretos, Android es un sistema operativo basado en

Linux, creado por Google y utiliza como base el lenguaje de programación Java para el desarrollo de
aplicaciones. Google y otras compañías de dispositivos, han desarrollado una estrategia para que este
ya famoso sistema operativo se pueda instalar en smartphones, tablets, televisores, y se proyecta que
sea el sistema operativo de varios tipos de dispositivos más.

Con más de medio millón de aplicaciones para Android publicadas en Google Play, es un
hecho que este es un gran momento para participar de este mercado y de la creación de aplicaciones
Android para un mercado en crecimiento.

En este curso estudiamos cómo desarrollar aplicaciones para el sistema operativo Android
utilizando el lenguaje de programación Java, por lo que un conocimiento básico de este lenguaje es
necesario para poder crear de manera exitosa estas aplicaciones.

Arquitectura de Android
la figura 11 muestra la estructura de este sistema operativo y cada una de las partes que lo
conforman.

Figura 11: Arquitectura de Android

Anteriormente los programadores de bajo nivel con lenguajes como C o C++ requerían
entender las características del Hardware sobre el que programaban, ya sea de un dispositivo en
específico o un conjunto de dispositivos del mismo fabricante. Además el programador, en muchas
ocasiones, estaba obligado a aprender ciertas APIs del fabricante para poder desarrollar sus
aplicaciones, generando un código muy complejo de mantener y desarrollar, y en muchas ocasiones las
aplicaciones ya no se les daba continuidad.

La diversidad de fabricantes de dispositivos móviles conlleva como reto contar con una
plataforma estándar, código de fuente abierta (open source), robusta, segura, entre otras características
para el desarrollo de una aplicaciones móviles. Dichas aplicaciones deben poder ser ejecutadas en
cualquier dispositivo móvil o tableta sin tener que volver a programar para un fabricante en específico.

Con la popularidad de Java y su Máquina Virtual (JVM) sabemos que es posible abstraer
los detalles del hardware para el dispositivo que estamos desarrollando, y así el programador es libre de
crear el programa una vez y ejecutarlo sobre cualquier dispositivo que tenga una JVM.

Con esto en mente, y con la experiencia previa de los dispositivos móviles, se creó el
sistema operativo Android.

Como podemos observar en la figura, la arquitectura Android se divide en varias capas, y

con el uso una de máquina Virtual llamada Dalvik, es posible abstraer el detalle del hardware al
programador y así desarrollar sólo una vez la aplicación y ejecutarla en cualquier dispositivo que tenga
una máquina virtual compatible.

Dalvik es la máquina virtual que utiliza la plataforma para dispositivos móviles Android.
Dalvik ha sido diseñada por Dan Bornstein con contribuciones de otros ingenieros de Google.

La Máquina Virtual Dalvik (DVM) permite ejecutar aplicaciones programadas en Java. La

DVM no afirma ser una máquina virtual de java (JVM) debido a que le ocasionaría problemas de
licenciamiento, sin embargo cumple ese propósito. La mayoría de los programas escritos en Java 5
pueden correr sobre la DVM.

DVM sacrifica la portabilidad que caracteriza a Java para poder crear aplicaciones con un
mejor rendimiento y menor consumo de energía, estas dos características son extremadamente
importantes en dispositivos móviles, debido a que la capacidad de las baterías en estos dispositivos es
limitada.

DVM está optimizada para requerir poca memoria y está diseñada para permitir ejecutar
varias instancias de la máquina virtual simultáneamente, delegando en el sistema operativo subyacente
el soporte de aislamiento de procesos, gestión de memoria e hilos.

A menudo Dalvik es nombrada como una máquina virtual Java, pero esto no es
estrictamente correcto, ya que el bytecode con el que opera no es Java bytecode. Sin embargo, la
herramienta dx incluida en el SDK de Android transforma los archivos Class de Java compilados por
un compilador Java al formato de archivos Dex.

El nombre de Dalvik fue elegido por Bornstein en honor a Dalvik, un pueblo de Eyjajorour,
Islandia, donde vivieron antepasados suyos. En la última versión del sistema operativo Android
(Lollipop), Dalvik fue sustituida por ART.

Android explota los recursos del dispositivo móvil sin las restricciones que normalmente
encontramos con otros sistemas operativos móviles como iOS de Apple o Windows Phone de
Microsoft. Android ofrece nuevas posibilidades debido a que su ambiente de desarrollo está basado en
software libre, desde el Kernel basado en Linux, hasta las API’s para el desarrollo de las aplicaciones.
El hardware es accesible a cualquier aplicación Android a través de una serie de API’s que son
ejecutadas en la máquina virtual.

En Android tanto las aplicaciones de terceros como las aplicaciones nativas son
desarrolladas utilizando la misma API y son ejecutadas en el mismo ambiente de ejecución. De esta
manera el usuario final es libre de reemplazar cualquier aplicación Nativa con aplicaciones de terceros,
ofreciendo una flexibilidad y libertad única a los usuarios de dispositivos móviles que cuentan con la
plataforma Android.

Desde su nacimiento el sistema operativo Android ha sufrido bastantes cambios. En la

figura podemos observar la historia de las versiones hasta el día de hoy, así como algunas de las
características de cada versión. Como podemos observar, en tan sólo algunos años Android se ha
posicionado como una de las plataformas más populares para el desarrollo de aplicaciones móviles.

Android Inc. fue adquirida por Google en 2005, y se comenzó el desarrollo del primer
sistema operativo libre para ser utilizado por defecto en los teléfonos móviles, y se ha extendido al día
de hoy a tablets, televisores y muchos tipos de dispositivos más. Una de las principales ventajas de
Android, es que se diseño con el objetivo de que las aplicaciones pudieran interactuar entre ellas,
permitiendo reutilizar realmente los servicios, datos e interfaces (UI).

En las primeras versiones de Android (2008) no se soportaba el teclado en pantalla, y

obligaba a los dispositivos a tener un teclado físicamente. Por ello, se agregó un teclado en pantalla en
la versión 1.5 (2009), así como otras características tales como: grabación de audio y video, widgets y
creación de folders.

A finales del 2009 de liberaron 2 versiones más de Android, permitiendo un gran

crecimiento y venta de dispositivos para la navidad del 2009. Se introdujo la búsqueda avanzada así
como capacidades de texto a voz.

La versión 2.3 significó una mejora en todos los servicios ya disponibles, tales como el uso
de la cámara, conectividad WiFi, soporte OpenGL ES 2.0, mejoras en el respaldo de datos y
aplicaciones, video chat, entre muchas mejoras que hacen al día de hoy esta versión sea la más utilizada
en los teléfonos.

La versión 3.0 se enfocó en los dispositivos Tablets, con soporte para pantallas más
grandes. Se introdujo el concepto de fragmentos, así como capacidades similares a las aplicaciones de
escritorio, tales como Action Bar, Drag-and-drop, mejoras en los widgets home-screen, así como más
controles IU y layouts para el soporte de estos nuevos dispositivos.
 La versión 4.0 surgió para unificar las versión 2.x y 3.x para permitir un único desarrollo
para teléfonos y tablets. Esta unificación permite aprovechar las nuevas características que estaban
disponibles sólo para las tabletas, e incrementar la experiencia de usuario en los teléfonos con versión
4.0

La versión 4.1 es una mejora sobre todo en cuestiones visuales y un incremento en el

performance de las aplicaciones en general.

Debido a que la versión Android 2.3.x está instalada en una gran cantidad teléfonos, es
necesario considerar cual será la versión mínima que soportaremos para el desarrollo de nuestras
aplicaciones. Por ello, en este curso nos enfocaremos en aprender muchas de las características que
aplican a la mayoría de las versiones, y estudiaremos las más relevantes de la versión 4 de Android.

Características
Uno de los mayores éxitos de Android radica en su API de desarrollo. Android crea
aplicaciones que son parte del dispositivo como lo es cualquier aplicación nativa ya instalada (out-of-
the-box). A continuación mencionaremos algunas de las características más importantes del API de
Android:
• Acceso a Hardware, incluyendo Cámara, GPS y Sensores: Android incluye API’s que
simplifican el desarrollo sin importar el hardware sobre el que se está trabajando. Esto asegura
que no necesitamos crear implementaciones específicas para distintos dispositivos, así que
podemos crear aplicaciones que deben trabajar según lo esperado en cualquier dispositivo que
tenga una versión compatible de Android.
• Transferencia de Datos con WiFi, BlueTooth y NFC: Android ofrece soporte muy completo para
transferir datos entre dispositivos, incluyendo Bluetooth, Wi-Fi y Android Beam. Estas
tecnologías permiten compartir datos entre dispositivos, dependiendo del hardware disponible
en el dispositivo utilizado.
• Mapas y Geolocalización: El manejo de mapas embebido con el que cuenta Android crea
aplicaciones que de manera programática pueden manipular los mapas de Google Maps.
Además, la integración de un GPS y los servicios de localización de Google para determinar la
ubicación actual del dispositivo, permite combinar posicionamiento con mapas.
• Servicios en Segundo Plano (Background Services): Android soporta aplicaciones y servicios
diseñados para ser ejecutados en segundo plano, mientras nuestra aplicación no está activa,
debido a que solamente una aplicación puede estar visible a la vez.
• Base de Datos SQLite: El almacenamiento y la recuperación de información de manera rápida y
eficiente es básica para dispositivos con capacidad limitada. Android utiliza SQLite para
cumplir con este objetivo. Nuestras aplicaciones pueden aprovechar esta base de datos
relacional para almacenar y recuperar información de manera segura y eficiente.
 • Compartición de Datos y Comunicación entre Aplicaciones: Android incluye técnicas para
compartir información entre las distintas aplicaciones, tales como: Intents y Content Providers.
• Soporte para gráficos 2D y 3D: Android provee librerías gráficas para dibujos 2D y 3D con
OpenGL. Además, Android provee soporte para imágenes, video, audio, incluyendo video en
formato mpeg4 y h.264.
• Optimización de Memoria y Administración de Procesos: Android utiliza su propia máquina
virtual para la administración de la memoria. Android asegura que una aplicación responda en
un tiempo determinado, de lo contrario la detiene y la puede eliminar en caso de ser necesario,
con el objetivo de liberar recursos. De esta manera Android controla el ciclo de vida de las
aplicaciones en un ambiente enfocado en hacer más eficiente el uso de memoria de los
dispositivos.

Conclusiones
Sabemos que existen muchas plataformas para desarrollos móviles, como Apple iOS,
Windows Phone, BlackBerry, Palm, Java Micro Edition, Linux Mobile (LiMo),Firefox OS, entre otros.
Sólo Android presenta características que lo hacen diferente. Es el primero que combina en una misma
solución las siguientes cualidades:
• Plataforma realmente abierta.

• Adaptable a cualquier tipo de hardware.

• Portabilidad asegurada.

• Arquitectura basada en componentes inspirados en Internet.

• Filosofía de dispositivo siempre conectado a Internet.

• Gran cantidad de servicios incorporados.

• Aceptable nivel de seguridad.

• Optimizado para baja potencia y poca memoria.

• Alta calidad de gráficos y sonido.

Android ofrece una forma sencilla y novedosa de implementar potentes aplicaciones para
diferentes tipos de dispositivos.

Referencias Bibliográficas
Web oficial para desarrolladores Android

http://developer.android.com/index.html
Comunidad de desarrolladores I (proyectos open source)

http://www.codeproject.com/

Comunidad de desarrolladores II

http://stackoverflow.com/

Curso de programación Android

http://www.sgoliver.net/

Video tutoriales Android de la Universidad Politécnica de Valencia

http://politube.upv.es

Video tutoriales Android en Youtube

http://www.youtube.com/user/0utKast/videos?view=0

Android. Guía para desarrolladores. W. Frank Ableson, Robi Sen y Chris King.