android

Las alternativas a Android

Dejando de lado el ecosistema privativo de Apple, Microsoft o RIM, algunos pensaran que Android está solo dentro del mundo de sistemas operativos móviles Open Source. Nada mas lejos de la realidad, diferentes alternativas están siendo desarrolladas y alcanzando niveles de madurez aceptables para a corto medio plazo competir con Android.

Algunos, seguramente penséis, que interés existe en segmentar mas el mercado cuando ya existe una alternativa Open Source que actualmente es conocida y extensamente implantada. Pues la razones son diversas:

  1. Android para muchos no es totalmente Open Source (+pdf)
  2. Las operadoras quieren “pillar cacho” en el mercado de las mobile stores (WAC)
  3. Estrategias multidispositivo diferentes (móvil+escritorio+tv)
  4. Competir con Android y robarle una porción de mercado (o todo, google no fue el primer buscador y existían buscadores previos dominando el mercado. También existen otros ejemplos como Symbian o Internet Explorer)

En ese sentido quiero hacer un repaso al ecosistema actual de sistemas operativos móviles “libres”.

FirefoxOS (boot2gecko)

Una de las alternativas que puede que se materialice mas a corto plazo, gracias o de la mano de Telefonica. FirefoxOs (antes conocido como boot2gecko) es la apuesta de Mozilla por un sistema operativo basado en la plataforma Open Web/HTML5 no solo de cara a las aplicaciones sino que todo su entorno de usuario (Gaia) esta desarrollado también en tecnologías Open Web.

Uno de sus principales socios es Telefónica, que lo ha adoptado como su principal caballo de Troya de cara a competir en la guerra por la distribución de aplicaciones y contenidos en dispositivos móviles. En esta apuesta, Telefónica ha llegado a un acuerdo con la empresa española GeeksPhone para el suministro de dispositivo móviles de bajo coste con este sistema operativo integrado, lo cual también pretende romper el mercado de la telefonía en cuanto a la subvención de terminales se refiere, después de la perdida de clientes sufrida, vamos, lo que se viene a decir, dos pájaros de un tiro.

Tizen

De las cenizas de MeeGo (que a su vez fue una combinación de los sistemas operativos móviles Moblin, creado por Intel, y Maemo, creado por Nokia) resurge Tizen, como la alternativa apoyada por la Linux Foundation o empresas como Intel o la propia Samsung.

La apuesta es similar a la de FirefoxOs, es decir, una plataforma basada en tecnología Open Web/HTML5, pero en este caso inciden mas que el sistema de Mozilla en que sea un sistema operativo orientado a ejecutarse en múltiples dispositivos, ya sean televisores, tablets u ordenadores a bordo de vehículos. Es quizá esto ultimo y el apoyo de la Linux Foundation su gran baza, ya que la apuesta actual de Samsung parece que claramente es Android.

Ubuntu

Parece que Canonical apuesta firmemente por que Ubuntu funcione en múltiples dispositivos. La apuesta por el entorno de escritorio Unity estaba totalmente orientada a que la interfaz de acceso a los diferentes dispositivos, como Pcs, televisores o tablets, fuera lo mas común y homogénea posible, y en el caso de los teléfonos móviles también ha sido así según la presentación realizada hace pocos días.

Ademas de la popularización de Ubuntu en el PCs, una de las principales bazas de este sistema operativo es la posibilidad de que gracias a un “docking” o adaptador, nuestro móvil se convierta en una estación de trabajo, conectándolo a una pantalla o teclado. Esta posibilidad ya existía con la solución Ubuntu for Android también desarrollada por canonical, pero es con su propio sistema operativo para móviles con lo que cobra mayor sentido e integración.

Ubuntu apuesta por HTML5 como principal plataforma para el desarrollo de aplicaciones, aunque de cara a aplicaciones de alto rendimiento o requerimientos gráficos altos como juegos ofrece una plataforma de desarrollo basada en QML.

Open WebOS

Tras la decisión de HP de cesar el soporte y desarrollo de WebOs, inicio Open WebOs como un proyecto Open Source, y a mediados de Septiembre de 2012 vio la luz una primera versión alpha del sistema operativo. Además hace pocos días salio la noticia de que había sido posible ejecutar Open WebOs 1.0 en un tablet Nexus 7 de google.

Como su propio nombre indica, es un sistema basado en Web. Hay que tener en cuenta que WebOs fue uno de los principales precursores de la utilización de la plataformas Open Web como entorno multiplataforma y sobre todo orientado a dispositivos moviles, pero por desgracia, no es suficiente para asegurar que este sistema podrá competir con FirefoxOs, Tizen o Ubuntu.

Bada

Aunque el proyecto no es Open Source gran parte de sus componentes si lo son y en muchas ocasiones se ha rumoreado con su liberación, y es por eso que se ha añadido a esta lista.

En principio la apuesta personal de Samsung, pero como hemos visto, la marca coreana también esta detrás de Tizen y actualmente apuesta por Android para los terminales de gama alta. Es por eso que en la actualidad, Samsung, ha orientado este sistema operativo a dotar de “inteligencia” a sus terminales de gama mas baja, gracias a que este sistema consume menos recursos que Android. Su potencial únicamente radica en que es una solución desarrollada por uno de los principales fabricantes de terminales móviles, pero aun así, la posibilidades de que este sistema tenga algún tipo de éxito son remotas por diversas razones; APIs cerradas, limitación de instalación de aplicaciones, limitación de utilización de aplicaciones VoIP o el hecho de que es un sistema que no permite ejecutar aplicaciones en paralelo.

Aplicación para Programas de Fiestas

Desde hace tiempo tenía pensado hacer una aplicación que se conectara a algún servicio de datos para consultar los programas de fiestas de los diferentes pueblos. Por otro lado también existía la opción de crear una aplicación genérica sencilla fácilmente actualizable y adaptable a diferentes programas con la intención de generar una aplicación para cada programa de fiestas. Ambas tenias pros y contras:

Aplicación Genérica Aplicación Especifica
A favor
Tener toda la información No necesidad de conexión
Al ser online se actualiza Mas fácil de mantener
Una única aplicación Posibilidad de cierta customizacion (publicidad local o imágenes)
En contra
Necesidad de mantener infraestructura de servidor Market lleno de programas de fiestas
Mucho trabajo actualizar y mantener
Necesidad de conectividad

Al final tras algún intento de desarrollar un servicio que se alimentara de páginas de fiestas de terceros, opten por la segunda aproximación, la de hacer una aplicación especifica con el programa de fiestas de un pueblo concreto. En este caso, quise hacerla para Fiestas de San Ignacio de Algorta, peor por problemas de tiempo, al final, la hice para Fiestas del Puerto Viejo de Algorta.

null

La aplicación ya esta publicada y es gratuita, y el siguiente paso será publicar el código fuente y un breve tutorial de cómo crear tu propio programa de fiestas a partir de este. También publicaré los fuentes de los iconos y demás recursos para mantener una línea de estilo común.

Obtener drivers USB Samsung sin instalar Kies

Los que desarrollamos para Android en sistemas operativos como GNU/Linux o MacOs X no solemos tener problemas para acceder a los teléfonos a través de USB, bien para instalar aplicaciones o acceder a los logs a través de ADB. El problema lo tenemos cuando queremos hacer esto mismo en sistemas Windows y nos encontramos que al conectar el móvil al PC nos aparece un mensaje de dispositivo desconocido o que no encuentra los drivers.

En mi caso, hace poco he me hecho con un Samsung Galaxy SI II con el que estoy haciendo unas pruebas. Y lo primero que hice fue buscar los drivers para poder conectarme vía ADB. Mi sorpresa fue encontrar un montón de referencias a un paquete instalador de drivers para dispositivos Samsung que no me funcionaba. Otras referencias me indicaban que instalara Kies, un software de Samsung para acceder al dispositivos, sincronizar y demás herramientas que suelen ofrecer las empresas fabricantes de teléfonos móviles. Por supuesto, no estaba dispuesto a instalar todo una suite para instalar unos drivers USB, por lo que pensé que quizás seria posible obtener los driver del propio paquete de instalación de Kies.

Por lo tanto, lo primero que hice fue buscar Kies en Google y acceder a la pagina oficial de Kies donde descargué el software para Windows

http://org.downloadcenter.samsung.com/downloadfile/ContentsFile.aspx?CDSite=UNI_ES&CDCttType=SW&ModelType=N&ModelName=FM_UPDATE&idyn=N&VPath=SW/201105/20110512115717796/Kies_2.0.2.11071_128_2.exe

Por otro lado me descargué también el UniversalExtractor, el cual es un software capaz de desempaquetar instaladores, y ya que al fin y al cabo un instalador no es mas que un contenedor de binarios con instrucciones de donde copiarlos, no tiene mayor misterio acceder a su interior (la otra opción es instalar Kies coger el driver y desinstalarlo después).

http://legroom.net/scripts/download.php?file=uniextract161

Une vez instalado el UniversalExtractor, accedemos a nuestro directorio de descargas y extraemos el instalador de Kies seleccionando la opción “Instalshield /b Interconector“

Lo que hará que se nos cree una carpeta Kies_XXXXXX\ uni_xuemcfc\

Dentro de esta carpeta tendremos otro instalador MSI “Samsung Kies.msi“. Que volveremos a extraer de manera parecida pero esta vez con la opción “MSI Instalador Administrativo“.

Al desempaquetar el MSI obtendremos el contenido del instalador de Kies y si indagáis encontrareis que el instalador de los Drivers USB esta en Samsung Kies\program files\Samsung\Kies\USB Driver con el nombre de SAMSUNG_USB_Driver_for_Mobile_Phones.exe

Ejecutáis el instalador y pronto veréis como Windows va reconociendo vuestros dispositivos móviles.

El nombre del instalador de drivers es el mismo que el que en foros anteriores había encontrado e instalado pero que no me funcionaban. Esto se debía a que eran versiones anteriores del instalador de drivers que no contenían los drivers compatibles con el Samsung Galaxy S II. Por tanto en vez de alojar el instalador en un repositorio y enlazarlo en foros, he creído mas interesante mostrar como obtener la ultima versión del instalador de drivers a partir del instalador de Kies.

Espero que os haya sido de utilidad.

XML, JSON… Protocol Buffers

El intercambio de información en los sistema distribuidos o en cualquier tipo de servicio, es un tema clave, para lo cual, a lo largo de los años han surgido un montón de soluciones y tecnologías. Hasta ahora la formula mas utilizada era el formato XML, en muchos caso envueltos de una capa extra de gestión, como son el caso de SOAP o WCF impulsados por Microsoft. En general XML sigue siendo claro dominador a la hora de proveer información estructurada. Los feeds de nuestra Web, Sitemaps o muchos proyectos de OpenData proporcionan información en este formato.

A pesar de ello, XML para muchos es un formato engorroso, su interpretación o extracción de la información, a pesar de que existen muchas librerías que lo facilitan, suele traer de cabeza a muchos desarrolladores y cada vez, tiene mas presencia la tecnología JSON a la hora de acceder a servidores de datos, APIs, etc.. la facilidad para generar y recuperar la información que ofrece JSON esta haciendo que sea estándar de facto en prácticamente todos los servicios que permiten interactuar con servicios terceros. Empresas como Facebook o WOT, apuestan por JSON para el acceso a la información, sobre todo cuando esta se genera de forma dinámica. Aun así en la mayoría de los casos sigue estando opcional el acceso s los datos en XML.

En este articulo trato de presentar Protocol Buffers, una solución que pretende ser mas optima, en lo que respecta a trafico de datos, y mas opaca, si lo que interesa es que la información no viaje de forma totalmente visible. Personalmente, creo que lo mas interesante de este sistema es que reduce considerablemente el volumen de trafico generado en cada petición de información, lo cual es muy interesante si lo que queremos es desarrollar un servicio explotado por aplicaciones móviles, donde podemos conseguir aplicaciones mas fluidas, si conseguimos que el tiempo de conexión sea el menor posible.

En mi caso, Protocol Buffers me parece una solución interesante, ya que suelo usar Google App Engine, como web service generador de datos, y para terminales móviles suelo trabajar con Android, para el cual existen librerias. Además hay que tener en cuenta que muchas de las aplicaciones de serie en Android como el Market usan Protocol Buffers internamente (a pesar de que oficialmente la SDK de Android no ofrece acceso a dichas librerías).

En próximos post explicare como manejar Protocol Buffers en python.

Archivos DEX (Dalvik Executable): La Tabla de Tipos

Seguimos desenmarañando la estructura de los archivos Dex y ahora nos toca la tabla de tipos, es decir, los diferentes tipos de datos que utiliza nuestra aplicación a analizar. En este caso al igual que hicimos con la tabla de strings, obtenemos el offset y numero de elementos en la tabla de tipos de la cabecera. En el caso que estamos analizando la tabla de tipos comienza en 0x000001AC y tiene 28 (0x0000001C) elementos. Recorriendo de 4 en 4 bytes obtenemos las posiciones en la tabla de strings que identifican los tipos a usar: 2,7,8,9,10..

  1. elemento 2 de la lista de STRINGS: I
  2. elemento 7 de la lista de STRINGS: Landroid/app/Activity;
  3. elemento 8 de la lista de STRINGS: Landroid/os/Bundle;
  4. elemento 9 de la lista de STRINGS: Landroid/text/Editable;
  5. elemento 10 de la lista de STRINGS: Landroid/view/View$OnClickListener;
  6. elemento 11 de la lista de STRINGS: Landroid/view/View;
  7. elemento 12 de la lista de STRINGS: Landroid/widget/Button;
  8. elemento 13 de la lista de STRINGS: Landroid/widget/EditText;
  9. elemento 14 de la lista de STRINGS: Landroid/widget/TextView;
  10. elemento 15 de la lista de STRINGS: Lcom/marakana/NDKDemo$1;
  11. elemento 16 de la lista de STRINGS: Lcom/marakana/NDKDemo;
  12. elemento 17 de la lista de STRINGS: Lcom/marakana/NativeLib;
  13. elemento 18 de la lista de STRINGS: Lcom/marakana/R$attr;
  14. elemento 19 de la lista de STRINGS: Lcom/marakana/R$drawable;
  15. elemento 20 de la lista de STRINGS: Lcom/marakana/R$id;
  16. elemento 21 de la lista de STRINGS: Lcom/marakana/R$layout;
  17. elemento 22 de la lista de STRINGS: Lcom/marakana/R$string;
  18. elemento 23 de la lista de STRINGS: Lcom/marakana/R;
  19. elemento 24 de la lista de STRINGS: Ldalvik/annotation/EnclosingClass;
  20. elemento 25 de la lista de STRINGS: Ldalvik/annotation/EnclosingMethod;
  21. elemento 26 de la lista de STRINGS: Ldalvik/annotation/InnerClass;
  22. elemento 27 de la lista de STRINGS: Ldalvik/annotation/MemberClasses;
  23. elemento 28 de la lista de STRINGS: Ljava/lang/CharSequence;
  24. elemento 29 de la lista de STRINGS: Ljava/lang/Integer;
  25. elemento 30 de la lista de STRINGS: Ljava/lang/Object;
  26. elemento 31 de la lista de STRINGS: Ljava/lang/String;
  27. elemento 32 de la lista de STRINGS: Ljava/lang/System;
  28. elemento 37 de la lista de STRINGS: V

Estos strings usan una sintaxis concreta y pueden traducirse a una forma mas común de definir los tipos mediante la siguiente tabla.

Syntax Meaning
V void
Z boolean
B byte
S short
C char
I int
J long
F float
D double
Lnombre/completo/Clase; la clase nombre.completo.Clase
[descriptor Array de elementos descriptor, es posible crear arrays de arrays, con limite de profundidad 255
Ejemplo: [I ~ array de ints (int[])

Por tanto, la tabla, nos quedaria de esta manera:

  1. int
  2. android.app.Activity
  3. android.os.Bundle
  4. android.text.Editable
  5. android.view.View.OnClickListener
  6. android.view.View
  7. android.widget.Button
  8. android.widget.EditText
  9. android.widget.TextView
  10. com.marakana.NDKDemo.1
  11. com.marakana.NDKDemo
  12. com.marakana.NativeLib
  13. com.marakana.R.attr
  14. com.marakana.R.drawable
  15. com.marakana.R.id
  16. com.marakana.R.layout
  17. com.marakana.R.string
  18. com.marakana.R
  19. dalvik.annotation.EnclosingClass
  20. dalvik.annotation.EnclosingMethod
  21. dalvik.annotation.InnerClass
  22. dalvik.annotation.MemberClasses
  23. java.lang.CharSequence
  24. java.lang.Integer
  25. java.lang.Object
  26. java.lang.String
  27. java.lang.System
  28. void

Otro recurso mas, que sera utilizado junto a la tabla de strings para desensamblar el resto de estructuras de nuestra aplicación.

Entrevista en NickDutNik

Como anuncié a bombo y platillo semanas antes y publiqué (no lo suficiente) en las redes sociales, el día 2 de Febrero (2011) aparecía en el programa NickDutNik de ETB producido por Factoria Crossmedia. En la entrevista presentaba mi aplicación de Bizkaibus para Android y además explicaba las razones y motivaciones que me llevaron a desarrollar esta aplicación. Pinchando en la imagen podéis ver el video de la entrevista.

Archivos DEX (Dalvik Executable): La Tabla de Strings

La tabla strings, es una estructura que contiene las posiciones de los recursos string que utiliza nuestra aplicación. En esta lista de strings tendremos desde nombres de clases, métodos, variables o constantes que nos indicaran el tipo de los datos. Es una lista ordenada ya que desde otras estructuras se hará referencia a los strings en función de su posición en la lista. Es decir, en el proceso de compilación, se extraen los strings de todas las estructuras y código, se eliminan duplicados y se meten en una lista ordenada, por lo que a partir de entonces, ahí donde había un string ahora hay un entero que hace referencia a la posición del string en la lista. Con esto se consigue reducir el tamaño de la aplicación evitando la redundancia de recursos.

Para entenderlo mejor, a partir de este momento vamos a desensamblar, paso a paso, un archivo .dex de ejemplo que hemos obtenido a partir de este ejemplo http://marakana.com/forums/android/examples/49.html que es pequeño y usa la NDK (de cara a ser un ejemplo relativamente completo).

Analizando la cabecera como explicamos en el artículo anterior obtenemos el offset o desplazamiento desde el inicio del fichero donde empieza la tabla de posiciones de los strings, y el numero de strings. Por tanto obtenemos que la tabla de strings empieza en la posición 0×00000070 y que tiene 79 (0x0000004F) elementos. Por tanto deberemos recorrer el archivo desde la posición 0×00000070 en bloques de 32bist, 79 veces para obtener la posición de los 79 strings.

En el ejemplo de la imagen superior recorremos los tres primeros strings. La estructura de cada string es, un byte que indica la longitud del string y a continuación el string, por tanto, el primer string esta en la posición 0x0000084E, su longitud es de 0×08 caracteres y su valor es “<clinit>”. El segundo string esta en la posición 0×00000858, es de longitud 0×06 y valor “<init>”, el tercero esta en la posición 0×00000860 es de longitud 0×01 y valor “I”. Seguiríamos así con los 79 strings, con lo que en el ejemplo de la imagen obtendríamos la siguiente lista.

  1. <clinit>
  2. <init>
  3. I
  4. III
  5. IL
  6. L
  7. LI
  8. Landroid/app/Activity;
  9. Landroid/os/Bundle;
  10. Landroid/text/Editable;
  11. Landroid/view/View$OnClickListener;
  12. Landroid/view/View;
  13. Landroid/widget/Button;
  14. Landroid/widget/EditText;
  15. Landroid/widget/TextView;
  16. Lcom/marakana/NDKDemo$1;
  17. Lcom/marakana/NDKDemo;
  18. Lcom/marakana/NativeLib;
  19. Lcom/marakana/R$attr;
  20. Lcom/marakana/R$drawable;
  21. Lcom/marakana/R$id;
  22. Lcom/marakana/R$layout;
  23. Lcom/marakana/R$string;
  24. Lcom/marakana/R;
  25. Ldalvik/annotation/EnclosingClass;
  26. Ldalvik/annotation/EnclosingMethod;
  27. Ldalvik/annotation/InnerClass;
  28. Ldalvik/annotation/MemberClasses;
  29. Ljava/lang/CharSequence;
  30. Ljava/lang/Integer;
  31. Ljava/lang/Object;
  32. Ljava/lang/String;
  33. Ljava/lang/System;
  34. NDKDemo.java
  35. NativeLib.java
  36. R.java
  37. TextView01
  38. V
  39. VI
  40. VL
  41. accessFlags
  42. add
  43. app_name
  44. attr
  45. buttonCalc
  46. drawable
  47. findViewById
  48. getText
  49. hello
  50. helloText
  51. icon
  52. id
  53. layout
  54. loadLibrary
  55. main
  56. name
  57. nativeLib
  58. ndk_demo
  59. onClick
  60. onCreate
  61. outText
  62. parseInt
  63. res
  64. result
  65. savedInstanceState
  66. setContentView
  67. setOnClickListener
  68. setText
  69. string
  70. textOut
  71. this
  72. this$0
  73. toString
  74. v
  75. v1
  76. v2
  77. value
  78. value1
  79. value2

A partir de ahora las siguientes estructuras que vayamos desensamblando harán referencia a esta lista de strings.

Archivos DEX (Dalvik Executable): La Cabecera

La cabecera es como cabe de esperar, una de las partes mas importantes de la estructura el archivo .dex. Contiene el magic que nos permite identificar el formato de archivo, además de diferentes chechsums y hashes para comprobar la integridad del propio archivo. Pero lo que es mas importante, en la cabecera se encuentra el “mapa” para entender y descomponer el formato .dex en sus diferentes partes, ya que contiene una lista con los offsets y longitud de las diferentes parte de el archivo que comentábamos en el artículo anterior.

  • Tabla con las posiciones de los Strings
  • Tabla con las posiciones de los Tipos
  • Tabla con las posiciones de las estructuras/Prototipos de los métodos
  • Tabla con las posiciones de las Propiedades de las clases o Campos de los métodos
  • Tabla con las posiciones de los Métodos
  • Tabla con las posiciones de las Clases
  • Datos



Name Format Description
magic ubyte[8] Este valor es el que identifica el tipo de fichero.
checksum uint Checksum (adler32) calculado en base a todo el fichero, menos magic y checksum.
signature ubyte[20] Firma HashSHA-1 de todo el fichero menos magic, checksum y la propia firma.
file_size uint Tamaño de todo el fichero incluida la cabecera (en bytes).
header_size uint Tamañode la cabecera (en bytes). Actualmente siempre toma el valor de 0×70 (112)
endian_tag uint Nos indica que tipo de formato endian usa el fichero. Importante de cara a interpretar los valores de los datos del archivo, pero defecto es litle-endian. [aclaración]
link_size uint Indicael tamaño de la sección de enlace (link section) o 0, si elfichero es enlazado de forma dinámica.
link_off uint Desplazamientoal comienzo de la sección de enlace desde el inicio del ficheroo 0 si link_size == 0.
map_off uint Desplazamientoal map_list en caso que éste exista o 0 en caso contrario. Elmap_list es una lista con todo el contenido del fichero. Estaestructura de datos puede contener datos redundantes, pero laintención de la misma es el poder recorrer el contenido delfichero de una forma más cómoda. Esta lista está ordenada.
string_ids_size uint Númerode elementos en la lista de strings.
string_ids_off uint Desplazamientoa la lista de strings o 0 en caso que dicha lista este vacía,circunstancia que raramente se va a dar.
type_ids_size uint Númerode elementos en la lista de tipos (type).
type_ids_off uint Desplazamientoa la lista de tipos o 0 en caso que dicha lista este vacía. Casoque raramente también se dará.
proto_ids_size uint Númerode elementos en la lista de prototipos.
proto_ids_off uint Desplazamientoa la lista de prototipos. 0 en caso que dicha lista este vacía.De nuevo, situación que raramente se dará.
field_ids_size uint Númerode elementos en la lista de campos.
field_ids_off uint Desplazamientoa la lista de campos o 0 en caso que dicha lista esté vacía.
method_ids_size uint Númerode elementos en la lista de métodos.
method_ids_off uint Desplazamientoa la lista de métodos. 0 si la lista está vacía.
class_defs_size uint Númerode elementos en la lista de clases.
class_defs_off uint Desplazamientoa la lista de clases. 0 en caso dicha lista este vacía,situación poco probable.
data_size uint Tamañoen bytes de la sección de datos. Debe ser un número parmúltiplo del tamaño de un uint (sizeof(uint)).
data_off uint Desplazamientoa la sección de datos.


ENDIAN_CONSTANT y REVERSE_ENDIAN_CONSTANT

En caso de que el valor se el campo endian_tag sea igual a REVERSE_ENDIAN_CONSTANT (0×78563412), consideraremos que el archivo esta en formato litle-endian, lo cual es el estandar y lo mas común. A pesar de ello, es posible usar otras configuraciones, tipo big-endian, en tal caso el campo endian_tag tomara el valor ENDIAN_CONSTANT (0×12345678).

Fuente: http://www.netmite.com/android/mydroid/dalvik/docs/dex-format.html

Archivos DEX (Dalvik Executable): Introducción

En los entornos Java estándar, el código fuente de Java es compilado en bytecode de Java, y almacenado en archivos .class. Los archivos .class son leídos por la máquina virtual Java en tiempo de ejecución. Cada clase en tu código Java se traducirá en un archivo .class. Esto significa que si tienes, por ejemplo, un archivo .java (código fuente) que contiene una clase pública, una clase interna estática, y tres clases anónimas, el proceso de compilación (javac) nos generará 5 archivos .class.

En la plataforma Android, el código fuente de Java también se compila en archivos .class. Pero después de generar los archivos .class, mediante la herramienta “dx“ son convertidos a un único archivo dex (Dalvik Executable). Mientras que un archivo .class contiene una sola clase, un archivo .dex contiene múltiples clases. Es el archivo .dex el que se ejecuta en la máquina virtual Dalvik.

El archivo .dex ha sido optimizado para el mínimo consumo de memoria y el diseño esta condicionado por la reutilización de datos. El siguiente diagrama compara el formato de los archivos .class utilizado por la JVM con el formato de .dex utilizado por la máquina virtual Dalvik.

.jar vs .dex

A grandes rasgos las estructura de un Archivo .dex consta de las siguientes partes:

  • Cabecera
  • Tabla con las posiciones de los Strings
  • Tabla con las posiciones de los Tipos
  • Tabla con las posiciones de las estructuras/Prototipos de los métodos
  • Tabla con las posiciones de las Propiedades de las clases o Campos de los métodos
  • Tabla con las posiciones de los Métodos
  • Tabla con las posiciones de las Clases
  • Datos

Salvo la tabla de Strings (que es a la que hacen referencia todas las tablas ya que es en esta parte donde se almacenan todos los nombre de clases, métodos, funciones, variable y tipos de datos), el resto sigue un orden jerárquico inverso, es decir, si quisiéramos desensamblar el archivos dex, tras obtener el listado de Strings, obtendríamos el listado de Clases, sus métodos, sus propiedades y campos de los métodos, la estructura de dichos métodos – que relaciona métodos y campos – y por ultimo los tipos, que nos indicaría los tipos de los campos de los métodos y los tipos que devuelven los métodos. Es decir, es una estructura relacional, que tiene como objetivo el reaprovechamiento máximo de la información, evitando redundancias y así conseguir un formato optimo para terminales móviles.

Como he indicado, son tablas donde se indica la posición donde esta la información que compone dicha tabla, normalmente mediante un Offset y opcionalmente una longitud. Estos datos junto con el código maquina están en la sección de datos.

En próximos artículos iremos desgranando con mas detalle, cada parte de la estructura del formato Dalvik Executable.

Fuente 1:http://davidehringer.com/software/android/The_Dalvik_Virtual_Machine.pdf
Fuente 2:http://www.scribd.com/doc/17194679/DalvikVMInternals#

Disponible la aplicación de Bizkaibus para Android desde el Market

Por fin ya esta disponible en Android Market la nueva aplicación para consultar información sobre líneas y horarios de Bizkaibus en nuestros terminales Android. Han sido varios meses en los que he ido sacando ratitos para ir montando las diferentes partes de la infraestructura, como el webservice OpenBizkaibus API, necesarias para poder completar una aplicación estable con un acabado relativamente profesional. Si sois usuarios de los servicios de Bizkaibus y tenéis un teléfono móvil Android con conexión a Internet, esta aplicación os será de gran utilidad. Para poder descargarla solo tenéis que pinchar aquí o escanear el código QR que tenéis a la derecha.




Review

La aplicación para android de Bizkaibus es una interfaz para poder consultar la información sobre horarios, líneas y tiempos de llegada por parada, de los autobuses del servicio Bizkaibus. Por tanto es una aplicación que consulta información en tiempo real a través de la conexión a Internet del terminal móvil. Por tanto al iniciar la aplicación, esta intentara conectarse a Internet para obtener información actualizada sobre cobertura, líneas, etc… Y en caso de que no pueda realizarse dicha conexión nos mostrara un dialogo avisándonos y no nos permitirá seguir adelante ya que es indispensable estar conectado para el uso de la aplicación.

Una vez inicializada la aplicación se nos mostrara la interfaz principal, donde podremos realizar los diferentes tipos de consultas: buscar líneas indicando origen y destino, buscar líneas que pasen por una determinada población o seleccionar directamente la línea de una lista. Actualmente la opción de búsquedas por línea a partir de origen y destino no esta disponible ya que es necesario ampliar la funcionalidad de BizkaibusOpen API, es decir, el webservice, en el que se apoya esta aplicación. Por tanto si pulsamos dicha opción de búsqueda se nos mostrara un dialogo indicándonos que aun no esta disponible.

Las opciones que si están ya implementadas en este versión de la aplicación son la búsqueda por Municipio, que nos mostrara las líneas que pasa por el municipio seleccionado, y la selección directa de una línea que queramos consultar.

Por tanto, una vez seleccionada línea, se nos mostrara la información relativa a horarios y demás incidencias. El usuario puede considerar que esta información es suficiente o de lo contrario puede desear saber cuando va a pasar un autobús por una parada determinada.

Actualmente la flota de autobuses de Bizkaibus esta equipada con GPSs que actualizan la posición del autobús en tiempo real. Por tanto es posible conocer el tiempo de llegada aproximado en función de dicha posición. Por tanto la aplicación es capaz de mostrar las paradas en las que para un autobús que cubre una línea determinada, tanto es su sentido de ida como en el de vuelta y mostrarnos sus tiempos de llegada.

Una vez seleccionado el sentido de la ruta, se mostraran todas las paradas por las que pasara la línea seleccionada. Existe la posibilidad de filtrar por Municipio de cara a facilitar la búsqueda de la parada en la lista.

Una vez elegida la parada se nos mostrara los tiempos de llegada para todas las líneas que pasan por dicha parada, al igual que aparecen en el panel informativo que hay en algunas marquesinas de Bizkaibus. En caso de desconocer donde se sitúa dicha parada o querer comprobar si la parada seleccionada se corresponde con la parada que queremos consultar, es posible mostrar la situación de dicha parada en el mapa.

Debido a que el proceso de búsqueda puede ser relativamente largo, existe la posibilidad de añadir paradas a nuestra lista de paradas favoritas. Con lo que, al acceder al la pantalla principal de la aplicación, mostrando el menú, podemos acceder a nuestra lista de paradas favoritas, para acceder a su información directamente.

1 2  Scroll to top