Presentación. Programación Android con Java. Qué es una plataforma de software?

Transcripción

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

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

3 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). 2 Unas herramientas (JDK) para generar las aplicaciones a partir del código fuente. SUN significa Stanford University.

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

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

6 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 5 Kernel. Núcleo en Alemán. ARM contiene un ambiente de desarrollo (IDE), un compilador C/C++, un depurador y un profiler.

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

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

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

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

11 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 o mayor, entonces la app se está ejecutando en ART.

12 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

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

14 Figura 7: Creando un paquete APK.

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

16 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

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

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

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

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

21 Figura 10: Ejecución ART. ART mejora respecto a la máquina virtual Dalvik:

22 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 ejecutacuando 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

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

24 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

25 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

26 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