El SDK de Android incluye un completo emulador que permite probar y depurar eficientemente las aplicaciones que se van desarrollando. Este emulador incluye diferentes skins para representar gráficamente un dispositivo móvil real, con pantalla, teclado y botones de función, así como aplicaciones de usuario preinstaladas que incluyen navegador web o visor de mapa, y una consola que permite interactuar con él a través de Telnet.
El emulador, como se ha comentado, es muy completo y escapa al propósito de este apartado su explicación detallada. Aún así, se mencionan a continuación algunas de las principales características de esta útil herramienta para el desarrollo en Android.
Puede ser lanzado tanto a través de una ventana de comandos, con el ejecutable de nombre “emulator.exe” de la carpeta “\tools” o, la que probablemente será la mejor, a través del plug-in para Eclipse. En este último caso, cada vez que se ejecute una
Proyecto Fin de Carrera
Desarrollo de aplicaciones para dispositivos móviles sobre la plataforma Android de Google aplicación, se hará automáticamente a través del emulador incluido en el SDK. Las opciones de lanzamiento desde Eclipse se pueden revisar en Debug/Run -> Target. Este emulador simula un procesador del tipo ARM y permite tener varias instancias corriendo al mismo tiempo, cada uno con una emulación distinta. Permite simular varios eventos como llamadas entrantes o mensajes SMS, incluso conectar varios emuladores entre sí (para ello es necesario redireccionar puertos, como se verá más adelante).
Figura 10. Ejemplo de skin para el emulador de Android
Una vez lanzado el emulador, puede interactuarse con éste a través de su interfaz gráfica pulsando en la pantalla del dispositivo, sobre sus botones de función o en el teclado virtual. También pueden lanzarse órdenes conectándose por Telnet al puerto donde esté escuchando, siendo el 5554 para la primera de las instancias que se lancen.
3.9.1 Uso de imágenes
En el emulador de Android pueden utilizarse imágenes de datos que se guardan en el propio equipo de desarrollo. Estas imágenes simulan memorias internas, tipo flash, y otras.
Proyecto Fin de Carrera
Desarrollo de aplicaciones para dispositivos móviles sobre la plataforma Android de Google En concreto, el emulador dispone de tres tipos de ficheros imagen:
Imagen de sistema: contiene datos y especificaciones para la ejecución, fundamentales para el emulador. Es únicamente de lectura ya que se lee al principio y no se vuelve a acceder a ella hasta la próxima ejecución. Se almacenan en la carpeta “\lib” y se llaman “kernel.img”, “system.img”, “ramdisk.img” y “userdata.img”.
Imagen de ejecución: el emulador dispone de dos ficheros imagen para lectura y escritura de datos. El primer de ellos, “userdata-qemu.img”, almacena los datos del usuario como preferencias, ficheros, contenidos de la base de datos SQLite, etc. Al arrancar, el emulador comprueba si existe este fichero: si no, lo crea como una copia exacta de la imagen de sistema “userdata.img”; si existe, lo abre sin más. Si al terminar los datos han sido modificados, serán guardados en esta imagen. Si se utilizan varios emuladores, deberán ser configurados para que cada uno cuente con su propia imagen “userdata-qemu.img”. La otra imagen de ejecución se denomina “sdcard.img”, y se utiliza para simular dispositivos de almacenamiento extraíbles. Para crear una imagen de este tipo, que es opcional, es necesario utilizar la herramienta “mksdcard” de la carpeta “\tools”.
Imagen temporal: al ejecutarse el emulador, siempre se crean dos ficheros imagen para datos temporales: uno que hace una copia del sistema completo, y otro que se utiliza como caché para el navegador web y otros servicios. Ambas imágenes se eliminan al terminar la emulación.
3.9.2 Aspectos de red
Android incorpora a su emulador un pequeño router/firewall virtual, de forma que el sistema emulado desconoce tanto la máquina de desarrollo como las demás instancias del mismo emulador. Sin embargo, este comportamiento es configurable.
Todas las instancias del emulador tienen asignada una dirección de red de la forma 10.0.2/24. Por defecto, las direcciones definidas para cada instancia son las mostradas en la siguiente tabla: IP Descripción 10.0.2.1 Gateway virtual 10.0.2.2 Máquina de desarrollo. 10.0.2.3 Servidor DNS principal. 10.0.2.4 / 10.0.2.5 / 10.0.2.6 Servidores DNS secundarios.
10.0.2.15 El sistema emulado, esto es, localhost.
Proyecto Fin de Carrera
Desarrollo de aplicaciones para dispositivos móviles sobre la plataforma Android de Google Para poder interactuar libremente con la aplicación emulada, es necesario redireccionar los puertos correspondientes a fin de saltar las restricciones impuestas por el router virtual del emulador. Para ello se utiliza el comando redir, después de haberse conectado por Telnet. Véase siguiente ejemplo, mostrado en el Código 4:
> telnet localhost 5554
Android console: type ‘help’ for a list of commands OK
redir add tcp:5000:6000 OK
Código 4. Ejemplo de redirección de puertos en el emulador
En este ejemplo en primer lugar se conecta al emulador por Telnet, usando el puerto 5554, que es el utilizado para la primera de las instancias del emulador. A continuación se invoca el comando redir, y se añade una nueva regla mediante add. Dicha regla especifica que todas las conexiones TCP llegadas al puerto 5000 de la máquina de desarrollo se deriven al puerto 6000 del emulador. También puede utilizarse con el protocolo UDP.
Esta sencilla regla puede utilizarse para poder comunicar dos instancias del emulador. Supóngase el siguiente escenario:
1. A es la máquina de desarrollo.
2. B es una instancia del emulador Android, ejecutándose en A. En B existe una aplicación que hace de servidor y escucha por el puerto 80.
3. C es otra instancia del emulador, también ejecutándose en A. En C existe una aplicación que hace de cliente y desea conectarse con el servidor en B. Para poder cumplir estos supuestos, se debe establecer esta configuración:
1. B debe escuchar en la dirección 10.2.0.15:80, es decir, en su localhost. 2. B debe tener una regla del tipo redir add tcp 8080:80
3. C debe conectarse a la dirección 10.0.2.2:8080.
De esta forma, C siempre se conectará a la máquina de desarrollo en su puerto 8080, y la regla puesta en B hará que esta conexión TCP se derive a ella misma por el puerto 80. Así, ambos emuladores pueden establecer comunicación.
Proyecto Fin de Carrera
Desarrollo de aplicaciones para dispositivos móviles sobre la plataforma Android de Google
3.9.3 Órdenes desde consola
Aunque el emulador ya esté funcionando, hay muchos aspectos de este que pueden ser configurados al momento utilizando la consola a través de un Telnet al puerto 5554 y posteriores, según la instancia del emulador deseada.
Algunos de los comandos aceptados por la consola son los siguientes: help: muestra una lista de los comandos disponibles.
event: permite enviar diferentes tipos de eventos al emulador.
geo: permite establecer una localización fija mediante coordenadas. Será la que devuelva el dispositivo de GPS al ser invocado desde una aplicación.
gsm: emula llamadas telefónicas.
kill: finaliza la instancia del emulador.
network: diferentes aspectos relacionados con el control de los distintos tipos de conexiones (GSM, GPRS, UMTS, EDGE), como los valores de latencia. power: controla la simulación del nivel de batería del dispositivo móvil. quit/exit: cierra la conexión con el emulador y la consola.
redir: permite redireccionar puertos entre el emulador y la máquina de desarrollo.
sms: permite enviar mensajes SMS al emulador. vm: control de la máquina virtual Dalvik.
window: configuración del skin del emulador.
3.9.4 Dalvik Debug Monitor
El emulador incluye una potente herramienta llamada Dalvik Debug Monitor, que será de gran ayuda para testear las aplicaciones. Esta aplicación permite hacer un seguimiento de los puertos utilizados, ver mensajes de log, información acerca de los procesos en ejecución, gestión de memoria, eventos entrantes como llamadas y SMS, así como otras muchísimas opciones orientados a la depuración.
Para utilizarla, debe ser lanzado en primer lugar un emulador. Entonces, en la carpeta “Tools” se debe ejecutar un fichero de nombre “ddms.exe”. La ventana que se abre en ese momento es similar a la mostrada a continuación:
Proyecto Fin de Carrera
Desarrollo de aplicaciones para dispositivos móviles sobre la plataforma Android de Google
Figura 11. Dalvik Debug Monitor
Una de las opciones ofrecidas más útiles, y que probablemente se quieran utilizar durante la depuración de las distintas aplicaciones, es la posibilidad de imprimir mensajes de traza. Para tal efecto está destinada la pestaña inferior de las mostradas en la Figura 11. En cada ejecución existe siempre una pestaña de nombre “Log” que se utiliza para indicar al desarrollador los diferentes procesos y eventos que tienen lugar durante la ejecución, utilizando un código de colores para diferenciar su naturaleza. Una de los paquetes de Android, android.util, contiene una clase llamada Log que permite imprimir mensajes de debug en la pestaña antes referenciada. El método Log.d(title,message) permite escribir estos mensajes, que después Dalvik Debug Monitor puede capturar. En dicho método, title representa el título o etiqueta que se desee dar, a fin de poder filtrar después todos los mensajes de dicha categoría; por otro lado, message indica el mensaje concreto que se quiere imprimir bajo esta etiqueta.