PROGRAMACION AVANZADA

HORA INICIO:3:30–17:30 enviar a: [email protected]

ASUNTO: PROGRAMACION AVANZADA-01L- trabajo de programación avanzada-
vilca Aguilar limber luis-1623225026
Nombre de archivo igual. Datos del estudiantes:vilca Aguilar limber luis, código:1623225026,
 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.

¿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 API 1.
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.
 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 Sun 2

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.
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
2 Java Specification Request (JSR), las cuales son documentos formales que describen
las especificaciones y tecnologías propuetas para qu 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.
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:
TMobile 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.

 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
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
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
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
 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
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).
 • 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.
 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.

EJEMPLO DE LA ARQUITECTURA DE UN ANDROID

Se muestra la estructura de este sistema operativo y cada una de las partes que lo
conforman.

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
 • 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
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.