Share on Google+Share on FacebookTweet about this on Twitter

Nota: Los ejemplos expuestos no tienen por qué funcionar en todos los terminales en el mercado, antes de probar NADA hay que ser consciente de que se está realizando y las repercusiones que puede tener lo que estamos haciendo. Ante la duda no hacer nada que pueda suponer un riesgo para el terminal. Dicho de otro modo, no me hago responsable ni me voy a preocupar siquiera de nadie que me diga que hizo algo porque yo lo dije y se ha cargado su terminal.

 

Android

La verdad es que cuando no dispones de mucho tiempo, escribir es algo que pasa a un segundo plano (y no precisamente porque no me gustaría hacerlo más a menudo). No obstante como prometí, tenía que empezar a dedicar algunas palabras sobre Android al estilo Theliel. Espero que sirva un poco de punto de referencia o partida para todos aquellos a los que le gustaría conocer un poquito de este OS para móviles (y proximamente tablets). Vamos a intentar tratar los siguientes puntos:

  • ¿Que es Android? Estructura, Código y SDK
  • Integración/Implementación, un vistazo general y ¿Fragmentación?
  • Comunidad: Rooms, Radios, Kernels…

 

¿Que es Android?

Bueno, esta pregunta debería de ser muy simple de contestar. Android es simplemente un OS  (Sistema Operativo). ¿Y que es un OS? Bueno, para quien ande un poco perdido podemos simplificar que un OS es el software que gobierna y controla el Hardware del sistema, y a la vez proporciona recursos para la buena gestión, ejecución de cualquier otra tarea.

Hace unos años, Apple tubo una idea brillante reinventando el concepto de Móvil (esto habrá que reconocérselo siempre). Por aquel entonces prácticamente cada fabricante de móviles tenía su propio OS para sus dispositivos, aunque Windows Mobile, Symbian o RIM OS podían ser los más extendidos en cuanto a SmartPhones se refería. Apple creó su propio OS basado en MAC OS para su terminal, que mucho después rebautizó como iPhone OS, supongo que para evitar cualquier relación directa con MAC OS, aunque como digo está basado en él. Con la llegada de iPhone y su aparente éxito, los fabricantes no se quedaron a esperar, y los terminales tipo iPhone comenzaron a inundar los mercados. Pero claro… tampoco había un entorno decente para gestionar los terminales que iban a salir, a fin de cuenta un hardware no sirve para nada sin un software que lo controle de la mejor forma posible. Tan solo Windows Mobile o Symbian parecían alternativas viables. Google vio este mercado emergente y se puso manos a la obra. En muy poco tiempo tendría preparada la primera versión de lo que sería su Sistema Operativo para terminales móviles, y lo llamo Android.

Android, a diferencia de Symbian, iPhone OS, Windows Mobile y otros, no es un OS privado!! Esto implica varias cosas:

  1. Cualquier fabricante de dispositivos portátiles (o no portátiles) puede usar Android sin tener que pagar ni un solo céntimo por royalties!! Es decir por licencias de uso. Pensar que por cada terminal con Windows Mobile que se vende, Microsoft cobra parte del dinero del terminal en conceptos de licencias. En caso de RIM OS o Iphone OS esto no es necesario dado que ambos sistemas operativos son de uso exclusivo de sus creadores, con lo que directamente los fabricantes no pueden implementarlo.
  2. Android es un proyecto de código abierto!! Esto contribuye a que el crecimiento, adaptación, seguridad, rendimiento… del proyecto evolucione a una velocidad infinitamente superior a la de un OS de código cerrado. Si Apple tiene a lo mejor 100o ingenieros trabajando (cobran) por programar iPhone OS, Google tiene 1.000.000 de personas que hacen que Android mejore día a día, por supuesto muchos trabajadores de Google (que cobran) y otros muchísimos más que colaboran de forma totalmente altruista para el proyecto.

Estas y otras razones hicieron de Android un interesante punto de mira de cara a los fabricantes de móviles, dado que ellos mismos podían descargar una parte muy importante de su trabajo a Android!! En vez de diseñar y mantener de forma exhaustiva sus propios OS, tan solo tenían que crear sus propias aplicaciones (si querían) para Android y dedicar infinitamente menos recursos (y en definitiva dinero) en mantener, adaptar e integrar Android en sus dispositivos. Y es lo que hicieron.

Creo que ni siquiera Google en un principio pudo imaginar el éxito de su OS. Quizás la mejor prueba de ello es que incluso su proyecto Chrome (OS para tablets y Netbooks) quedó en un segundo plano. Apple, lider indiscutible (hace unos años) no se preocupó demasiado y fue demasiado arrogante para aceptar que su OS se iba quedando cada día más atrás. Comenzaría entonces el ataque de Apple a Google, que aun dura. De nuevo, cada vez que Apple se ve amenazado no sabe hacer otra cosa q tirar piedras con la esperanza de que cada dos clientes que se van de ellos pueda darle a uno y que ese vuelva. Primero fue que si Android era un plagio, después con denuncias a prácticamente a todos los fabricantes de móviles Android por infringir patentes. A Apple se le empezaba a acabar la gallina de los huevos de oro, sus políticas altamente restrictivas (y algunas de chiste) que tenía en su AppStore hacía que los desarrolladores para iPhone se lo pensasen dos veces a la hora de escoger iPhone como plataforma predilecta, y empezaban a mirar a Android como una plataforma mucho más factible. Recordar que el AppStore de Apple no permite navegadores, emuladores, aplicaciones siquiera eróticas, ninguna aplicación que haga de intérprete, ninguna aplicación que se salga del SDK de ellos, ninguna aplicación siquiera en la que aparezca la palabra Android (no, no es broma). Lo único que le quedaba ya a Apple era aferrarse al echo de que el AppStore era el Store con más aplicaciones que existía, muy por encima de Android Market. Esto tiene su gracia, dado que el AppStore de Apple no fue una idea propia, sino de la comunidad quien comenzó a crear aplicaciones para iPhone, y Apple a raiz de esto creó su Store.

Pues bien, así llegamos al día de hoy. Apple se ha visto obligado a relajar muchas de sus normas absurdas en el Store, pero el problema es que no puede desdecirse en muchas otras. Cuando insultas al defender tu política, no puedes decir un año después que estabas equivocado. Steve Jobs a dejado frases tan bonitas como: “Quien quiera pornografía que se vaya a Android” y por supuesto toda la historia de Flash. Después de pasar todo lo que pasó, resultaría complicado que Apple reconociese ahora que Flash continúa siendo imprescindible, o que no tiene nada de malo que se permitan aplicaciones para adultos. Eso sí, después no tiene problema de aceptar aplicaciones homófogas. Es el doble rasero de Apple, y que muestra exactamente como funcionan.

¿Que ha sucedido? Que Apple, incluso lanzamiento tras lanzamiento de nuevos iPhone (todos prácticamente iguales) lejos de aumentar su tasa de mercado ha empezado incluso a retroceder!! Y sin embargo Android continúa ascendiendo de forma exponencial. Según los últimos datos suministrados por Google hace unos días, Google activa ya más de 300.000 terminales con Android diarios!! Según Apple, consiguió colocar en los últimos 3 meses 14.1 Millones de iPhone, pero según estas cifras Android está colocando más de 27 millones. Es decir, a día de hoy por cada iPhone vendido se venden dos terminales Android. Esto produce a su vez el efecto rebote de los programadores, que ven que android es una plataforma mucho más viable. En EEUU Android supera ya con creces a iPhone OS, y casi con toda probabilidad, en 2011 Android sea el OS número 1 en el mundo para este tipo de terminales. De cara a los programadores es evidente: Si tienes que elegir hacer una aplicación que funciona en 500 millones de dispositivos o hacerla para 100 millones, escoges para 500 millones. No obstante Apple no morirá a corto medio plazo, y como en todos sus productos, los fanboys persistirán. De echo, se sabe que el 80% de todos los iPhone que se venden caen en manos de usuarios que son asiduos a productos de Apple. ¿Gracioso verdad? A día de hoy el Market de android aun no ha superado al AppStore de Apple, mantienen una diferencia aproximada de unas 100.000 aplicaciones: Market 400.000 AppStore 500.000 (el dato sobre el número de aplicaciones de cada uno es aproximado y sin mucha rigurosidad, no tengo ganas de buscar el número exacto de cada uno ahora mismo)

 

¿Estructura?

Android está basado como no podía ser de otro modo en el todopoderoso Linux. En un principio incluso Google mantenía su propio árbol en los repositorios oficiales de Linux, pero por algunas peleas prefirieron mudarse. Esto produjo en principio algunas riñas con la comunidad Linux, pero pronto anunciaría Google que para nada iba a dejar de ayudar, adaptar o publicar todo el código para dicha comunidad. No obstante, que Android esté basado en Linux sería complicado verlo como una distribución de Linux, sino como un proyecto derivado de este. Quizás, la mejor forma de ver esto es con la propia imagen que usa el site de Android para ilustrar la arquitectura de este:

Android consta así de 5 partes diferentes perfectamente diferenciadas y nada complicadas de comprender. Aunque esta información está publicada y explicada perfectamente en la URL de Android, voy a tratar de explicarlo de forma simple.

  • Nivel de Aplicaciones/Aplicaciones

    En este nivel o capa, estarían implementadas todas las aplicaciones que usará el terminal. Es decir desde gestores de correo electrónico, navegadores web, juegos… En este caso Google optó por usar JAVA como lenguaje de programación para las aplicaciones. En realidad no es JAVA nativo, ya que a priori, Android no es capaz de ejecutar aplicaciones JAVA nativas creadas por ejemplo con el SDK SE de este.

  • Nivel de Aplicaciones/Framework

    En este nivel, Google constituyó una API completa para las aplicaciones. Es decir, podríamos verlo como las piezas básicas con las que se pueden crear cualquier aplicación para Android. Por ejemplo, si un programador quisiese usar una notificación tipo SMS en su aplicación, tan solo tendría que conocer el Framework de Android para esto, no tendría que reinventarlo o implementarlo de alguna otra manera. Es como he dicho simplemente una API, una interfaz de programación de aplicaciones. Al contrario que el SDK que da Apple a sus programadores, Google otorga un acceso completo a este framework, lo que permite a los programadores o desarrolladores tener al mismo acceso que las propias aplicaciones que el OS Android incorpora. Básicamente un programador para Android puede crear la aplicación que quiera y publicarla en el Market sin problema alguno. Por supuesto diferentes fabricantes crean, mantienen o modifican este Framework para sus propias aplicaciones si así lo desean, aquí tratamos a priori Android tal cual sale de los repositorios de Google.

  • Librerías

    Bueno, el propio nombre lo dice todo. Son las librerías que proveen al framework de las funciones que requieren. Por ejemplo, las librerías SSL son las que permiten gestionar entre otro las conexiones cifradas TLS/SSL a cualquier aplicación. Al contrario de lo que sucede con el nivel de aplicación, las librerías están escritas todas en C/C++, básicamente en código nativo para Linux que puede ser ejecutado en teoría en cualquier equipo (compilado para la plataforma que sea evidentemente).

  • Runtime de Android

    ES necesario un nivel intermedio por así decirlo entre las aplicaciones y el sistema. Dado que las aplicaciones están escritas en JAVA, es necesario un intérprete de este para el sistema central. Aquí es donde el Runtime de Android entra en juego. El runtime se divide así en dos partes. La primera es un conjunto de librerías/clases que permiten proveer a la segunda parte (la máquina virtual Dalvik) las herramientas adecuadas. Cuando una aplicación se ejecuta, se abre una instancia nueva en la máquina virtual Dalvik, que por así decirlo permite la interacción necesaria con las librerías del sistema, y por supuesto la ejecución del código JAVA escrito en dicha aplicación. Es decir, todas las aplicaciones que corren en Android se ejecutan sobre dicha VM en su propio espacio de trabajo. Esto no es quizás el sistema más eficiente, siempre se podría haber optado por usar C/C++ directamente y que fuese ejecutado por el sistema. En cambio, esta VM provee una solución muy eficiente y segura en cuanto a la separación entre lo que puede ser el propio sistema y las aplicaciones. Un movil no es un PC, es un movil, y las soluciones existentes para un PC no tiene por qué ser las mejores para otros dispositivos. Ejecutando las aplicaciones fuera de lo que podríamos llamar el propio sistema, da al sistema mucha más estabilidad y por supuesto seguridad. Podría pensarse que esto hace de Android relativamente estricto, pero todo lo contrario. Para empezar porque el Framework creado por Google es suficientemente amplio para cubrir prácticamente cualquier necesidad de cualquier programador, y segundo, cuando este no fuese siquiera suficiente el programador podría crear su propio framework para añadir funciones avanzadas, o incluso usar cualquier herramienta Linux, a fin de cuenta el corazón es el mismo, y por ende es capaz de ejecutar perfectamente cualquier herramienta de las de siempre.

  • Kernel

    En último lugar, pero la más importante de las piezas es evidentemente el Nucleo (Kernel) de Linux. Actualmente se está usando un Kernel 2.6.X, en cada nueva versión este es actualizado, modificado, mejorado… de que se encarga el ¿Kernel? Pues básicamente de toda la gestión del OS. Desde los drivers, la gestión de energía, sistemas de archivos… es sobre él donde se construye el resto del sistema, por tanto es una de las piezas más importantes de todo Android, si es que no es la más importante.

 

Código Fuente

Android no es solo un sistema gratuito, sino que es un sistema de código abierto. Eso significa que cualquier persona que lo desee puede tener acceso al código fuente de este, modificarlo como desee, recompilarlo y usarlo. Android actualmente cuenta con infinidad de colaboradores que ayudan al equipo principal en su desarrollo, desde ideas innovadoras, códigos más eficientes y seguros… quizás esta imagen muestre mucho mejor el proceso de Google en cuanto al código fuente de Android:

Android como tal ha consistido y consiste en diferentes árboles y ramas de desarrollo. Como podemos ver en la imagen, existen principalmente 3 ramas principales de Android, dos de ellas de acceso público, y otra más de acceso privado solo de Google. Esto de privado puede sonar mal, pero tiene su lógica. La primera rama en aparecer es evidentemente una rama de desarrollo que todos pueden ir mejorando, actualizando y haciendo crecer. Esta rama es constituida principalmente al trabajo de Google por supuesto, la comunidad en general y fabricantes interesados. Al terminar el desarrollo, se hace pública una rama oficial terminada, que es la que cualquier fabricante o usuario puede descargar, modificar si desea y usar. Una vez se ha lanzado la versión final, se vuelve al trabajo en las ramas de desarrollo, cunado el trabajo se termina se vuelve a crear una nueva rama terminada, que será la nueva versión de Android. ¿Entonces que sentido tienen las ramas privadas de Google? Google es evidentemente el alma mater de Android y su principal desarrollador, pero ello no significa que todos sus cambios, novedades, modificaciones… se vean reflejadas de forma inmediata en las ramas de desarrollo generales. ¿Por qué? Por una cuestión de llevar un control de calidad, novedades, sorpresas… Cuando la versión está preparada, Google toma su rama privada (que por supuesto incorpora aquello del a rama de desarrollo que estime adecuado y bueno para Android y de ahí se genera la rama oficial. Es por ello que aunque Gingerbread (Android 2.3) ha sido anunciado, habrá que esperar unos dias o semanas a que Google hace pública dicha rama (el código fuente completo de la versión 2.3). Una vez haga esto, cualquier programador podrá crear su propia versión, y con programador me refiero desde las propias empresas de telefonía como desarrolladores de Roms independientes.

En el mismo portal de Android se detalla paso a paso todo lo necesario para descargar el código fuente, las herramientas usadas, como compilar el código… información muy util si deseamos crear un kernel específico, añadir modificaciones concretas o lo que deseemos. No voy a detallar como, para eso estoy seguro q cualquier desarrollador sabe como obtener la información 🙂

 

SDK

La mayoría de los programadores no obtante, no les importa ni les interesa como funciona Android, tan solo tienen en mente ganar dinero creando aplicaciones para la plataforma de Google o simplemente muchos otros que quieren crear aplicaciones personalizadas para ellos mismos, o aplicaciones empresariales que no estarán jamas en venta. Google, al contrario de Apple, permite sin problema alguno que cualquier persona que así lo desee pueda crear las aplicaciones que quiera, sin pagar nada, y poder instalarlas en sus dispositivos a voluntad.

¿Pero que es un SDK? Un conjunto bastante amplio de herramientas, código, ejemplos, librerías, drivers… que permiten a cualquier programador crear programas basados en él de la forma más simple y eficiente posible. Es el punto de partida de cualquier programador. En este caso, Google ha realizado un gran trabajo, y su SDK está cargado de interesantes utilidades/herramientas, no solo es un conjunto de ejemplos o librerías para que sean usadas. Dado que las aplicaciones están escritas en JAVA, será JAVA lo que se use para escribirlas, lo que implica que los requerimentos mínimos para comenzar serán ni más ni menos que el SDK de JAVA SE (al menos), el SDK de Android y evidentemente recomendado un IDE para el entorno de programación, que en este caso se aconseja Eclipse, también multiplataforma y gratuito.

¿A destacar? Hay tres herramientas concretas que son dignas de mención, y que posiblemente precisarían de artículos concretos para cada una de ellas:

  • Android Debug Bridge (ADB)

    Esta pequeña utilidad es posiblemente una de las herramientas más potentes que podemos encontrar. ADB es una interfaz directa de comunicación con el sistema Android, capaz de modificar o consultar cualquier estado actual de nuestro terminal, o incluso acceder al sistema de archivos de este para copiar, mover, crear… cualquier archivo de este. De cara a un usuario normal esta herramienta ya es de por sí bastante útil en momentos dados, y para un desarrollador directamente no tiene precio.

    Todos los terminales Android (o la gran mayoría al menos) permiten habilitar la “depuración USB”, una mala traducción o quizas un nombre poco adecuado para especificar una opción del terminal para habilitar el uso de ADB. ADB es una herramienta tipo Cliente-Servidor, es decir, es posible usarla porque nuestro equipo tiene instalado el SDK de android (y con el el servidor ADB), mientras que nuestro terminal, al activar la opción antes mencionada activaría el cliente ADB en nuestro terminal. Una vez se activa dicha opción, podemos comunicarnos con nuestro terminal por medio de dicha interfaz. En este momento, podremos ejecutar cualquier acción por medio de línea de comando ADB. Si tan solo tenemos un terminal conectado, no será necesario especificar ningun terminal concreto, las acciones se ejecutarán sobre el único terminal conectado

    Explicar cada una de las funciones de ADB es un poco absurdo, dado que la web de Android ya lo explica perfectamente todo, pero si podemos a lo mejor destacar la posibilidad de instalar cualquier aplicación que deseemos que tengamos en nuestro equipo, reiniciar nuestro dispositivo en cualquiera de sus modos de operación, copiar/eliminar archivos o incluso obtener una shell. Veamos algunos ejemplos, todos ellos a ejecutar por supuesto desde linea de comando, en mi caso Windows 7:

    Reiniciar el terminal:

    “adb reboot” -> Reinicia y entra en modo normal
    “adb reboot recovery” -> Reinicia y entra en modo Recovery
    “”adb reboot bootloader/reboot-bootloader” -> Reinicia y entra en modo hboot

    Instalar cualquier aplicación:

    “adb install [ruta/aplicacion.apk]” -> Opcionalmente se puede especificar los argumentos -s para instalarla en la SD o -r para reinstalarla

    Copiar archivos:

    “adb push [ruta/carpeta o archivo en el PC] [ruta/carpeta en el dispositivo]” -> Permite copiar un archivo de nuestro PC al terminal en la ubicación especificada
    “adb pull [ruta/carpeta o archivo en el dispositivo] [ruta/carpeta en el PC]” -> Permite copiar un archivo de nuestro terminal al PC

    Shell:

    “adbe Shell” -> Obtiene una Shell remota a nuestro dispositivo

    Tan solo hay que tener en cuenta un par de detalles. Si el terminal está encendido y funcionando en modo normal, el cliente ADB instalado en el terminal estará ejecutándose en modo usuario, esto quiere decir que tan solo podremos llegar a cabo por medio de ADB desde nuestro PC aquellas operaciones que no requieran de permisos administrativos en nuestro dispositivo. Es decir, podremos por ejemplo instalar aplicaciones sin problema, copiar o eliminar archivos que se encuentren en la SD, pero bajo ninguna circunstancia podremos por ejemplo copiar un archivo en la carpeta /System de nuestro dispositivo, ya que para eso tendríamos que tener permisos administrativos en el dispositivo (aka rootear el dispositivo).

    Por seguridad sobre todo, todos los terminales Android que se venden (prácticamente todos, no todos) no tienen permisos de root para nada, lo que implica que si se desea realizar una operación por medio de ADB que requiera un acceso total, generalmente es necesario hacerlo por medio del modo recovery, y aun así, esto no es posible en la mayoría de los casos, puesto que las imágenes Recovery que se encuentran en la mayoría de los dispositivos tienen ciertas funciones deshabilitadas, aunque esto se tratará más adelante.

  • Android Virtual Devices (AVD)

    Android Virtual Devices no es más que una herramienta para poder crear y ejecutar entornos Android virtuales. Es decir, nos posibilita crear un terminal Android virtual con las características que deseemos para poder probar insitu las aplicaciones desarrrolladas. Es decir, un emulador de Android. Cualquiera puede crear un dispositivo virtual y probar si así lo desea como funciona y como es un terminal Android. Por supuesto siempre sometido a ciertas limitaciones, pero suficiente para probar prácticamente todas las características de Android. Veamos un ejemplo de este emulador funcionando con el SDK YA PUBLICADO de Gingerbread (Android 2.3):


Esto no quiere decir que el código fuente de Android 2.3 haya sido aun publicado, por ahora tan solo el SDK. Se espera que en los próximos días se libere para disfrute de todos. La cuestión es que por medio de esta herramienta, podemos a todos los efectos crear un emulador o máquina virtual que nos permita trastear lo que necesitemos, y por supuesto, ADB funcionará perfectamente con él también, de echo, es ideal si deseamos probar algunas funciones.

  • Dalvik Debug Monitor (DDMS)

    Como se dijo anteriormente, la máquina virtual (VM) Dalvik es por así decirlo el intérprete de las aplicaciones de nuestro terminal, y se comunica con el Kernel para ciertas tareas. Pues bien, la herramienta DDMS nos permitirá tener acceso de forma simple a una cantidad ingente de información que será realmente útil a la hora de depurar nuestras aplicaciones, o para aquellos que somos curiosos, aprender un poco más como funciona nuestro terminal.

    Por ejemplo, nos da acceso simple a los logs (registros) de nuestro terminal, los avisos, información, errores… se integra perfectamente con el propio emulador (AVD), lo que nos permite además ver como sería un arranque estandar de un terminal Android (emulado), lo que a su vez nos sirve cuando comparemos los registros obtenidos con nuestro dispositivo real. El propio DDMS nos permite incluso si tenemos una instancia del emulador abierto, similar llamadas o SMS, establecer una localización ficticia en el GPS… todo lo necesario para poder probar prácticamente cualquier aplicacion sin necesidad de un dispositivo físico. También posee un explorador de archivos, dump del estado de las aplicaciones y dele terminal…. De nuevo, cuando las cosas se hacen bien, se hacen bien:

El SDK incluye admeás de estas tres herramientas comentadas muchas otras utilidades interesantes, como es la herramienta FastBoot, códigos de ejemplo, librerías… recomiendo incluso su descarga e instalación aun cuando no se tenga pensado crear ninguna aplicación, nunca se sabe cuando nos puede hacer falta… o simplemente cuando cotillearlo.

 

Integración/Implementación, un vistazo general y ¿Fragmentación?

  • BaseBand
  • Sistemas de protección
  • Android y ¿fragmentación?

 

BaseBand

La idea de Android es genial, pero para que sea real en dispositivos físicos, es necesario algo más, ya no vale un simple papel. Además, cualquier terminal móvil tiene dos partes bien diferencias: El software principal del terminal y el software que controla/gestiona lo que podríamos llamar el Modem, la baseband, la radio… podemos encontrarlo definido con mil palabras diferentes, pero en definitivas es el software que gestiona realmente las comunicaciones del dispositivo: GPS, GSM, HSDPA… en algunos incluso el mismo adaptador WIFI, Radio FM y BT son controlados por ella. Esto es muy simple, la gran mayoría de todos estos dispositivos (por no decir todos) no poseen un procesador, sino dos. Uno es el procesador principal del sistema que gestiona todo el sistema operativo mientras que el otro procesador es el procesador que posee las características de comunicaciones. Si el adaptado WIFI, GPS… está dentro del procesador de la parte del Modem, entonces la baseband controlará también dichas funciones.

El caso es que esto produce que sea necesario de algún mdo la integración de ambas partes. Android como tal es el Sistema Operativo base, y es a través de una capa de software de este, llamada RIL, como Android accede por así decirlo al procesador de señales (por llamarlo de algún modo). Este RIL (Radio Interface Layer) será el que hablará directamente con el software del modem (modem, radio, baseband…), pero a diferencia de Android, este software (o firmware) no pertenece en sí mismo al ámbito de Android, este solo provee un RIL, el fabricante del perminal es el que deberá suministrar el software del modem por otro lado.

Al igual que se actualiza una aplicación o el mismo Sistema Operativo, la baseband requiere igualmente de actualizaciones, y aunque estas suelen ser menos habituales, suelen ser de gran importancia en cuestiones tales como la cobertura, la rapidez de localización del GPS, la señal WIFI, la batería consumida en llamadas o conexiones de datos 3G… y dado que esta no depende de Google, será necesario siempre estar enterado de las actualizaciones oficiales del fabricante para poder ver si ha lanzado alguna firmware nueva dele modeme en alguna actualización.

No obstante, desde el punto de vista de Android, es este quien suele gestionar el propio software del modem, en cierto modo es el sistema pre-arranque de android quien se encarga de actualizar dicho software/firmware en el teléfono

Sistemas de protección

Y con sistemas de protección nos referimos a mecanismos para garantizar que nuestro terminal siempre puede ser rescatado/restaurado en caso de una actualización defectuosa, medidas para el correcto testeo y desarrollo del terminal y las aplicaciones y protecciones incluso de cara a los propios descuidos de los usuarios (o aplicaciones malignas). En un mundo perfecto en el que no existen los errores, estos sistemas no harían falta, todo siempre funcionaría perfectamente y nadie nuca cometería errores. Claro que en el mundo real esto está lejos de la realidad. No obstante estos sistemas si son algo más dependientes de cada fabricante, aunque más o menos son iguales.

Para comprender estos sistemas, hay que ver como funciona más o menos el arranque de la mayoría de los terminales Android, aunque esto no tiene por qué ser de este modo obligado, vamos a reprensetar un caso típico:

 

  • BootLoader

    Ante un encendido NORMAL de un terminal Android, lo primero en ejecutarse como en prácticamente cualquier dispositivo informático es un cargador de arranque, comúnmente llamado BootLoader. Este Bootloader no suele ser otra cosa que un pequeño programa contenido en una zona generalmente protegida de una memoria no volatil, generalmente la propia memoria secundaria del dispositivo (la memoria Flash, no RAM). Este pequeño programa suele tener unas funciones muy básicas, pero suficientes para que en caso de desastre total poder restaurar completamente el sistema. Podríamos verlo la Bios del PC, cuando este viene de fábrica tenemos que acceder a la bios para configurar el equipo y establecer el disco duro que arrancará el sistema, pero en cambio no es algo a lo que tengamos que acceder nunca de forma directa por regla general (solo en casos extremos). Pues bien, el bootloader de estos terminales funciona de forma muy similar. Esto no quiere decir que este Bootloader sea intocable, y prácticamente todos los terminales permiten la actualización de un modo u otro de este bootloader. ¿El motivo? Errores de programación en el propio bootloader, fallos de seguridad en él, nuevas revisiones del dispositivo… no es algo que sea realmente extraño. Es por tanto que la actualización de este bootloader sería siempre el mayor riesgo que podríamos cometer. Por ello, los booloader suelen ser siempre simples, sin demasiadas funciones, lo básico y necesario.

    ¿Algún sistema de protección en caso de que el BootLoader se corrompiese? Bueno, llegado a este punto posiblemente sería posible introducir un nuevo Bootloader, pero no por medios ortodoxos, la mayoría de las veces sería necesario un cable de servicio del propio servicio técnico o abrir el terminal e introducirlo por medio por algún JTAG o cable serie, casi con toda seguridad el terminal estaría preparado para soportar la carga de un bootloader por algún método externo y de forma forzada.

    Al igual que la BIOS de un PC, El Bootloader ante un arranque normal, llamaría posiblemente al gestor de arranque principal del sistema, cargaría en RAM el ramdisk de arranque de Android y el sistema comenzaría el arranque.

    Aquí entra ahora las preferencias de cada cual. Por regla general se han optado por Bootloaders algo más complejos pero con más posibilidades que simples Bootloaders que tan solo son un mero gestor de arranque. Y el caso es que gracias a estos Bootloader podemos arrancar si así lo deseamos nuestros dispositivos en modo Bootloader. Es como si entrásemos en la Bios del PC. ¿Que sentido tiene esto? Bueno, es muy posible que el BootLoader nos permita de forma interactiva cargar una nueva imagen completa del sistema en caso de desastre total!! y con completa me refiero a una imagen que contenga no solo el propio sistema operativo, sino la baseband, las imágenes de recuperación (se verá más adelante), imagen del propio bootloader nuevo (en caso de que se tenga que actualizar), una tabla de particiones nueva… todo. Por supuesto, para evitar todo tipo de imágenes dañadas o indebidas, estos Bootloader suelen permitir tan solo determinadas imágenes firmadas digitalmente por el fabricante y en condiciones concretas. Es por ello que tan solo sería el último método a utilizar a la hora de querer actualizar o recuperar nuestro dispositivo.



  • FastBoot

    El FastBoot no pertenece a la cadena de arranque estandar de un terminal Android y generalmente tan solo es posible acceder a él por medio de una combinación específica de teclas en el terminal (al igual que para entrar en el Bootloader), de echo no es algo que posean todos los terminales Android. El Fastboot sería algo así como una extensión del Bootloader. Es cierto que algunos BootLoader permiten restauración del sistema en caso de desastre total, pero dado al simpleza que se intenta siempre dar a los Bootloader, estos procesos suelen ser completamente automatizados. Por ejemplo, en caso de Un HTC Desire el Bootloader permite la restauración automática de una imagen si esta se encuentra en una tarjeta SD externa, con un nombre determinado y dicha SD posee un sector de arranque también determinado (A estas tarjetas SD se les llama GoldCard). Es decir, en este caso el Bootloader permite restaurar el sistema completo, sí, pero solo en unas condiciones muy concretas y evidentemente un proceso sin controlar.

    El FastBoot va un poco más allá. Permitiría un control más específico en la recuperación, permitiendo el “flasheo” (una palabra acuñada coloquialmente para indicar la carga de una imagen o datos en la memoria Flash (o en parte de esta) del terminal) del terminal completo o incluso de partes específicas de este, como por ejemplo tan solo la baseband, o tan solo reconstruir la tabla de particiones, o incluso actualizar el bootloader. A diferencia del Bootloader, Android si provee la herramienta Fastboot para permitir la comunicación con el dispositivo cuando se encuentra en dicho modo, por medio del cable USB. Esta herramienta se encuentra igualmente en el SDK de Android.

    FastBoot podría verse también como un ADB de muy bajo nivel encargado prácticamente tan solo para “flashear” una imagen en una partición concreta del terminal, sea el bootloader, una imagen de recuperación, una de sistema… incluso la imagen de arranque del terminal (no la dele OS arrancándose, sino la primera). Reside también en memoria no volatil y suele ser algo más grande que el bootloader, aunque como digo a veces no es más que una extensión de este. Veamos algunos ejemplos que podríamos realizar por línea de comando cuando nuestro terminal estuviese conectado en modo FastBoot:

    “fastboot.exe flash hboot nuevo_bootloader.img” -> Escribiría una imagen nueva llamada nuevo_bootloader.img en la partición hboot (es decir, escribiría un nuevo bootloader en el teléfono)
    “fastboot.exe flash splash1 imagen_google.img” -> Escribiría en la partición splash1 dicha imagen de datos, en este caso se escribiría en el terminal la imagen (foto) de inicio  de este.
    “fastboot.exe -w” -> Haría un Wipe del terminal, es decir, eliminaría los datos del usuario y el caché. Básicamente sería como un restablecer valores de fabrica.


  • Recovery

    Android especifica la existencia de una partición con un pequeño sistema linux mínimo que permita de forma interactiva restaurar de forma simple el dispositivo en caso de “problemas menores”. Dicho de otro modo, sería algo así como un bootloader completamente interactivo, con más opciones y con menos peligro de toquetear que el bootloader. Esta partición tampoco se ejecutaría ni intervendría en el inicio normal de nuestro terminal, aunque sería llamada por el bootloader en determinadas circunstancias si fuese necesario (generalmente presionando una combinación concreta de botones al arrancar el terminal). No obstante, para evitar la piratería o la modificación tan simple del sistema, los fabricantes suelen incluir en sus terminales imágenes Recovery muy simples, con funciones muy limitadas. Por lo general, en modo Recovery (sin ningún Recovery alternativo) permite la escritura de prácticamente cualquier archivo en la memoria Flash siempre y cuando dicha imagen cumpla las firmas digitales pertinentes. También suelen permitir el borrado de datos de usuario, caché y otros, permiten recalibrar la batería y otros ajustes.

    ¿Que sucede? Que a la comunidad le gusta poder disponer de Revocerys más completos que permitan muchas más opciones como poder escribir contenido no firmado en el dispositivo, realizar copias de seguridad, eliminar datos más concretos… por otro lado, mientras que el sistema está en recovery, mediante ADB (si la imagen Recovery lo permite) permitiría el acceso como administrador al sistema, lo que permitiría eliminar o copiar el archivo que fuese. No obstante, a día de hoy estos Recoverys se usan fundamentalmente para dos cosas: Primero para poder escribir Roms no oficiales, y segundo para realizar copias de segurdad y restauraciones de forma simple. El término Rom es un poco ambiguo, dentro de la terminología Android, se usa el término Roms para designar a fin de cuenta la firmware principal del terminal, es decir sin baseband. En realidad se le podría llamar firmware, software o de cualquier otro modo, y parece que por lo general se le llama a estas versiones no oficiales Roms. Yo soy más partidario de usar el término Firmware, pero para no liarnos, las llamaremos Roms y listo.

  • Otros

    Los tres métodos comentados son parte del sistema de Android de una u otra forma. No obstante no implica que cada fabricante añada o quite otros posibles sistemas de protección, o simplemente de comodidad. Por ejemplo, Samsung implementa un modo adicional llamado modo “Download” que se usa para actualizar el sistema de un modo muy similar a como lo haría un FastBoot. Otros en cambio eliminan el FastBoot y dejan el bootloader prácticamente pelado. Otros poseen imágenes de recuperación bastantes interesantes y otros muy simples.

Del mismo modo que el fabricante incluye el Recovery modificado y compilado que ellos creen que será el mejor, la comunidad hace lo mismo, y tiene famosos Recovery que expanden en mucho las funciones básicas que otorgan los fabricantes. Una vez que se logra gracias al fastboot o el bootloader el cargar una imagen de recuperación personalizada, el sistema queda completamente abierto a nosotros. Es por tanto que toda la complejidad dentro de lo qeu podríamos llamar el JailBreak de Android suele simplemente consistir en modificar la imagen de Recuperacion. Este proceso suele ser completamente trivial, suele ser suficiente acceder al FastBoot y cargar una imagen Recovery diferente, del mismo modo que originalmente el fabricante cargó la suya. No obstante de nuevo hay fabricantes que implementan otras capas de seguridad que deniegan al Fastboot el acceso al sistema, o simplemente protegen ciertas zonas de la memoria contra escritura.

Un caso típico de esta situación lo encontramos por ejemplo en HTC. HTC implementa en la mayoría de sus terminales una protección en el bootloader que si está habilitada impide la escritura en zonas cruciales de la memoria, lo que impide por ejemplo poder cargar una imagen Recovery de forma tradicional, y hace falta acudir a Exploits para hacerlo. Esta medida de seguridad no solo se aplica a la imagen de Recovery, sino que por ejemplo impide cualquier escritura a las carpetas del sistemas, lo cual puede ser un poco molesto para programadores u otras personas como yo que nos gusta toquetearlo todo. Por suerte, el juego del ratón y el gato es el más viejo que se conoce, y mientras que unos ponen X medidas, otros las quitan. en el caso de HTC que implementa este sistema, se ha logrado Flashear el hboot de forma que se deshabilita el bit que realiza dicho bloqueo. Una vez deshabilitado, se obtiene acceso completo al sistema desde el FastBoot como en los demás terminales. Evidentemente son métodos más extremos, dado que modificar el Bootloader es bastante más peligroso que modificar una imagen de recuperación. Si alguien está interesado en el proceso, que lo comente y lo vemos, pero no voy a extenderme aquí sobre ello.

Me gustaría poner algunas imágenes mostrando los diferentes modos de operación, pero no tengo a mano una cámara para realizar fotografía a los terminales, con lo que quien esté interesado solo tiene que buscar en google o como siempre, lo vemos en los comentarios.

 

Queda por hablar de un último sistema de protección. Este se usa más que nada por conciencia, y no por impedir de forma arbitraria el acceso al terminal, y es que TODO lo que se realiza dentro del terminal una vez este está arrancado, se realiza con permisos restrictuvos, nunca de Superusuario (root). Esto significa que hay ciertas aplicaciones que no estarán disponibles mientras no dispongamos de permisos de administrador, aplicaciones que requieren de unos privilegios superiores. Imaginaros por ejemplo que deseamos tener acceso de escritura a la carpeta de sistema (presuponiendo que no hay ningún sistema de protección como el que implementa HTC, o de tenerlo está deshabilitado). Para poder eliminar archivos de sistema sería necesario poseer permisos de administraodor, y como esto muhas otras aplicaciones que podemos encontrar en el propio Market que lo requiere. No es algo que sea imprescindible, ojo, en cambio es deseable para muchos otros. A diferencia del JB de Apple, rootear un terminal Android no se puede calidicar como JB. El sistema Android es de por sí muy abierto y prácticamente podemos disponer de todo sin necesidad de permisos de root.

¿Como lograr permisos de administrador? Cuando realizamos JB al iphone podemos instalar lo que queramos y se presupone que cualquier aplicación puede ejecutarse como root si así lo deseamos. Android está pensado desde su base ante este tipo de situaciones, y es mucho más seguro. De echo, aun cuando nuestro dispositivo está rooteado, todo continuará exactamente igual, salvo que cuando una aplicación requiera de permisos elevados para su ejecución nos preguntará en pantalla sobre si deseamos o no permitir el acceso elevado. Por supuesto, esto hace de Android un sistema mucho más seguro, y sobre todo nos enseña mucho mejor que es lo que se está cociendo debajo de nuestro terminal.

La siguiente pregunta por tanto es como realizar este proceso a un terminal. Si no hay ningun sistema de protección extraño, en teoría es tan simple como instalar por medio de Recovery o FastBoot una serie de herramientas como Busybox generalmente (Busybox es un único ejecutable que posee en si mismo la gran mayoría de las herramientas básicas de Linux) y una aplicación visual dentro de Android para controlar dichos permisos. Hay por ahí herramientas incluso genéricas para realizar esto, lo más normal como digo es encontrar imágenes que se escriben en el terminal por medio de fastboot o recovery, y una vez escrita, al reiniciar el terminal ya estará rooteado. Por regla general no hay muchos problemas de lograr rootear un terminal Android, y sinceramente pienso que a los mismos fabricantes les compensa, primero no tienen que estar jugando al ratón y al gato, y por otro lado mantiene contentos a sus clientes, sabiendo que estos hacen un buen uso de sus dispositivos.

 

Android y ¿Fragmentación?

Dicho todo esto hay que entrar ya en lo que es el propio OS. Todo lo anterior es muy bonito, pero a es hora de hablar un poco más de lo que es y de lo que no es Android.

Android no es solo el sistema operativo base, sino que incluye toda una suite de aplicaciones base para esto, en las que se incluye desde una aplicación para llamar, SMS, cámara, contactos, calendario, gestor de correo, navegador web, radio… una suite bastante completa. Pero al ser un sistema completamente abierto, a los fabricantes también le gusta dar su toque personal, sus personalizaciones, sus modificaciones sus… básicamente para que cuando alguien viese tu terminal dijese: Vaya!! este es el más bonito que he visto, mira todas las cositas q trae y que mono queda todo”. Hay fabricantes que usan la gran mayoría de todas las aplicaciones por defecto de Android, otros prefieren aplicaciones propias que ellos han desarrollado. no podríamos hablar de cada uno de los fabricantes y las aplicaciones que cada uno lleva, sería absurdo.

Quizás, los ejemplos más clásicos de esto sería la famosa Interfaz Sense de HTC frente a la Interfaz estandar de Android. La interfaz Sense es más bonita para quienes les guste los colorines y los sistemas cargados, mientras que la interfaz estandar de Android es más simplista. Pero todo ello en realidad no modifica en modo alguno el sistema propio. Es evidente que cuantas más cosillas tenga la firmware del fabricante, esta ocupará más y posiblemente sea más lenta que la firmware base de Google. Volviento a la comparación de Sense Vs Launcher, Sense tiene posiblemente un look más bonito, pero es también más lento. Es aquí donde entra el poder tener Roms o firmwares no oficiales, y poder seleccionar aquella que nos guste más. Ya sea Samsung. Motorola, SonyEriccson, HTC… a todos les gusta dejar su pequeña marca personal. ¿Personalmente? Cada uno tiene en realidad sus pros y sus contras, en mi caso opté por una firmware básica en la que poder yo toquetear e incluir lo que quisiese a posteriori, es decir… una versión compilada directamente de los repositorios oficiales de Android, y no una de mi fabricante.

Esto que en realidad es una ventaja en Android ha sido duramente criticado por Apple (algo se tiene que inventar) para atacar a Android. Según Steve Jobs, esto da paso a la fragmentación de Android. ¿Que quiere decir con esto? Según Jobs, que Android esté presente en cada vez más modelos de teléfono es un problema porque cada fabricante tirará cada vez más para él, que android se está dividiendo cada vez más por culpa de los mismos fabricantes, cada uno usando sus propios programas, ajustes o personalizaciones y que esto no es sino un problema para los programadores. Jobs asegura que hay en el mercado muchos terminales Android con versiones pre 2.0 que no han sido actualizado y que esto da de nuevo problema de compatibilidades con las aplicaciones. Pues bien, esto es completamente falso.

Al igual que sucede con cualquier software, las actualizaciones son algo común aquí. Claro, Apple tan solo tiene 4 iphone diferentes con lo que en teoría tan solo tendría que mantener 4 versiones de software diferente. En cambio, si HTC tiene 10 dispositivos con Android diferentes tendría que mantener 10 versiones diferentes, y cada vez que Google lance una versión de Android nueva tendría que actualizar dichas versiones. Dado que cada fabricante implementa sus cosillas, el usuario final puede ver retrasos considerables desde que Google lanza la versión nueva hasta que el fabricante publica la actualizacion. Esto es cierto a medias, porque la práctica dice que prácticamente TODOS los fabricantes estan poniedo gran interés en Android, y están dando un soporte por lo general muy bueno.

Por otro lado es gracioso que Steve Jobs diga que esto es un problema, cuando su compañía tan solo tiene 4 Dispositivos, cada uno de ellos casi idéntico a su sucesor y predecesor, y teniendo en cuenta que su iPhone 2G e iPod Touch primitivo dejaron de tener hace tiempo soporte por parte de Apple, sin contar que las nuevas características que incluyó en el iOS 4.0 tan solo eran accesibles para los últimos modelos de iPod Touch e iPhone 3GS y 4. Es decir, que de todos los terminales de Apple, el iPod Touch 1, 2 y algunos 3 no poseen soporte para su software mas actual, mientras que tan solo sus iphone 3GS y 4 llegan. Eso creo que lo deja con menos de un 50% de los dispositivos que tiene!! Y evidentemente, con nuevas versiones se implementan nuevas funciones. Las aplicaciones dele AppStore dejan de ser compatible poco a poco con los terminales antiguos.

Dicho de otro modo, no creo que Android tenga problemas realmente notables actualmente de fragmentación, y si tengo que comparar con los problemas de compatibilidad y de soporte que da Apple por otro lado… en fin… sin comentarios.

Aunque cada fabricante toquetea un poco los ajustes de Android a su gusto, la verdad es que la mayoría de terminales Android que he podido observar son todos muy similares sin grandes diferencias, lo que los hace bastante cómodos a aquellas personas que les gusta “lo mismo de siempre”. La mayoría de las diferencias son solo estéticas o alguna aplicación de más o de menos que traiga por defecto, pero nada que no se pueda arreglar rápidamente con el Market de Google.

Otro punto fuerte y muy interesante dentro de Android es sin duda alguna su integración con los servicios de Google y su sincronización. Desde hace ya tiempo, además, Google eliminó del propio Software de Android sus aplicaciones y las publicó en el Market, con la idea de que TODOS pudiesen beneficiarse de sus grandes actualizaciones si nnecesidad de actualizar el software base. Sin duda alguna el paquete base que posee Android es cuanto menos interesante, mas que suficiente para la mayoría de usuarios cuando instala algunas de las aplicaciones de Google, como es el increible navegador GPS de este, que dentro de unos días aparecerá la nueva versión.

 

Comunidad: Rooms, Radios, Kernels…

Uno de los grandes potenciales de Android es sin duda alguno su caracter de código abierto. Esto no quiere decir que todo el mundo necesite saber que es esto o para que sirve, pero sí aquellos que quieren siempre un poquito más, poder tenerlo. Es simple, dado que tenemos acceso a los repositorios oficiales de Android, cualquiera puede descargarlos, modificarlos, compilar una versión y usarla en sus dispositivo. Hombre, no es tan facil de hacer al final, pero tampoco es mucho más complejo.

Esto ha propiciado la aparición de multitud de Roms (firmwares) no oficiales para diferentes dispositivos. Prácticamente para todos los dispositivos Android que hay, hay varias opciones posible. Por regla general, ya sean Roms completas o simplemente kernels, se pueden diferenciar las Roms en dos grupos principales: Aquellas derivadas de las Roms oficiales de los fabricantes o Roms compiladas directamente desde los repositorios de Google. Por regla general, las Roms derivadas de las de los fabricantes suelen incorporar la mayoría de las aplicaciones y pijadas de estos, suelen ser por tanto Roms más pesadas, algo mas lentas y generalmente menos actualizadas. Por otro lado las Roms basadas en los repositorios oficiales, llamadas comúnmente Roms AOSP (Android Open Source Proyect), suelen ser bastante más actuales, más ligeras en cuanto a velocidad se refiere y más ligeras en cuanto a peso, pero en contrapartida suelen ser más inestables para la mayoría de terminales y por supuesto con menos pijadas particulares de cada fabricante. ¿Por qué inestables? Bueno, cada terminal de cada fabricante tiene su propio hardware, el cual requiere sus propios drivers y Kernels adaptados para funcionar. La mayoria de las Roms derivadas AOSP se adaptan a los terminales gracias a que se extrae de las Roms oficiales aquellos drivers que no se tienen por defecto o que son más inestables, pero como es de imaginar, no todas las Roms AOSP son adecuadas para todos los terminales Android. Esta es la ventaja sin duda de Terminales Android como Nexus One (O HTC Desire) y el próximo Nexus S, dado que llevan el sello de Google por así decirlo, las Roms AOSP se adaptan perfectamente a ellos.

De todos modos a día de hoy podemos decir que se le ha ido cogiendo el truco a esto de las Roms, y gracias a los cientos y miles de personas que ayudan, cada vez más son los que se deciden a crear sus propias Roms y compartirlas con los demás, lo que nos brida un sin fin más de posibilidades.

¿Pero tanta diferencia hay entre Roms? Bueno, en realidad no tanta. Lo que es la Rom en sí, es interesante porque puede tener mas o menos contenido que podemos necesitar por defecto o algunos ajustes extras al entorno que nos ayudan a la gestión de nuestro terminal, como pueda ser por ejemplo ajustes manuales del sensor de luminosidad, eliminación o inclusión de ciertos elementos visuales… pero no cambian de una forma completa lo que podría ser el terminal. En ese aspecto sin duda es más importante quizás el Kernel. La gran mayoría de las firmwares, ya sean oficiales o no incluyen el propio Kernel de dicha versión, pero también es posible cambiar tan solo el Kernel. ¿Y para que sirve esto? Bueno, es biens sabido que para gusto colores, y las necesidades de unos no son precisamente las necesidades de otros. Los fabricantes o incluso el equipo de Google cuando crean versiones de Android nuevas no pueden contentar al 100% de la población. Si 100.00. prefieren la barra blanca aunque consuma másbatería habrá otros tantos que la prefieran negra por estética o por un menor consumo. ¿Como se arreglar esto? No se puede, tienese que matener siempre un equilibrio para que más o menos todos estén contentos. Pues bien, ¿y que sucede si somos nosotros los que podemos ajustar estas necesidades?

El problema es que mientras las aplicaciones se pueden instalar o desinstalar sin problemas en Android, hay ciertas funciones, características podríamos llamar que tienen que habilitarse a nivel de Kernel, son partes cruciales del sistema entero, y por tanto no es algo que se pueda actualizar o cambiar desde el Market así como así. La gran mayoría de todos los Kernels oficiales son genéricos en tanto y cuanto intentan tener un equilibrio en todo. Es malo si por ejemplo sobrecargas mucho un Kernel con infinidad de módulos que tan solo 3 personas van a usar, estarías perjudicando a una mayoría en post de una minoría!! pero a lo mejor para esa minoría son funciones que son necesarias. Es muy raro que encontremos un Kernel que sea mejor a otro, la gran mayoría de todos seran siempre mejores en algo y peores en algo, nadie da duros a pesetas, y todo tiene un precio. Vamos a ver algunos ejemplos clásicos de Kernels para Android:

  • Kernels con soporte para IPv6, TUN, OpenVPN -> Soporte que será bien recibido siempre y cuando sean funciones que necesitamos. Si tenemos que escoger entre uno con dichas capacidades y otro sin ellas (el resto igual), es evidente que si no necesitamos dicho soporte, es mejor el Kernel simple. A fin de cuenta ahora mismo IPv6, TUN u OpenVPN no son características necesarias para la gran mayoría
  • Kernels que permiten el OverClock -> Existen muchas personas que quieren exprimir al máximo su procesador, y es muy posible hacerlo. Hemos visto procesadores de terminales Android a 1Ghz corriendo ha 1.2Ghz incluso y de forma estable. ¿Esto es malo? Ni bueno ni malo, todo tiene un coste. Si fuerzas el procesador pasan dos cosas: La primera se calienta más y por tanto le quitas vida útil, la segunda es que conyeva un mayor consumo de la batería. Una vez más, cuestión de preferencias
  • Kernel que permiten el Downclock -> El principio es el mismo que el anterior, pero aquí se trata del procedimiento contrario. Si ajustamos la CPU a un reloj inferior, estaremos ahorrando batería a costa de un rendimiento menor.
  • Kernels HAVS y SVS: Implementando las dos ideas anteriores, se puede constituir un sistema en el cual la frecuencia de reloj del procesador se escale en función de la carga del sistema. Así por ejemplo, si el sistema requiere de mucha CPU, la frecuencia de reloj se aumenta de forma dinámica, y cuando no es necesaria se baja. Los Kernels HAVS hacen esto controlando tambien el voltaje, mientras que los Kernels SVS mantienen el voltaje siempre constante. Esto implica que los Kernels HAVS casi con toda seguridad consumirán menos dado que son capaces de disminuir también el voltaje pero esto puede acarrear consigo un sistema más inestable o momentos en el que el dispositivo no responde correctamente. Esto no es el mundo ideal, sino el real, la única forma de ver que es lo mejor para nosotros suele ser probar y descartar. Aun así, hay muchos que prefieren Kernels sin controles de reloj y que siempre vayan al máximo, aunque ello repercuta en mayor o menor medida en su batería
  • Escaladores de frecuencia: Tampoco existe un solo método para escalar la frecuencia de la CPU.  Podemos encontrar escaladores de frecuencia más conversavadores que tienen a subir la frecuencia de forma más lenta, mientras que tenemos otros que son más agresivos y rápidamente se disparan. De nuevo, la elección de uno u otros es cuestion de preferencia, si se desea un mayor consumo de batería o uno menor, si importa más o importa menos la posiblidad de pequeños lag… no hay una fórmula concreta, y depnde solo de cada persona.
  • Planificadores: Andorid es completamente multitarea, muy al contrario que iPhone OS. Para gestionar diferentes procesos de forma simultanea de forma eficiente hace falta lo que se llama un scheduler (o planificador). La tarea de este será la de monitorizar los procesos e ir asignando a cada uno los recursos suficientes en los momentos concretos. No es algo tan simple como pueda parecer, dado que existen por ejemplo procesos con mayor o menor urgencia, otros con mayor o menor necesidad de tiempo de procesado pero a lo mejor con menos urgencia… cuanto mas eficiente sea nuestro scheduler para Android más rapido será nuestro sistema en general. El ejemplo más simple de esto es por ejemplo lo que sucede si en nuestro PC ponemos a codificar una película en HD. Sabemos que cuantos mas recursos se inviertan en ello antes finalizará, pero si lo que nos importa no es precisamente el tiempo de codificado sino el poder hacer otra tarea mucho más rapida, en este caso la codificación tendría una prioridad baja, aun cuando llevase mucho tiempo en terminarse. Dado que podemos encontrar todos los escenarios posibles, es imposible decir que un scheduler es mejor que otro, de nuevo toca probar y descargar. Como nota, diré que actualmente el planificador por defecto de Linux se denomina CFS, pero existen otras muchas alternativas que dependiendo de el caso pueden ser mejores. También recordar de nuevo que lo que es bueno para un PC no tiene por qué ser igualmente bueno para un dispositivo portatil.
  • Sistemas de archivo complementarios: Cada fabricante puede imponer por defecto un sistema de archivo que el cree es el más eficiente o el mejor para su dispositivo. Pero de nuevo esto es muy subjetivo. Por ejemplo, Samsung usa un sistema de archivo propietario llamado RFS (Robust fat File System), que es básicamente un sistema de archivos FAT con journalling. Otros dispositivos usan Fat32, otros formatos de sistema de archivos nativos de linux Ext2, ext3 o ext4. Son cuestiones que nadie se pondrá de acuerdo. Unos sistemas de archivo son mejores que otro para almacenar bases de datos, otros para datos pequeños, otros para datos grandes. Otro son mas eficientes pero reducen la vida util de las memorias Flash, otros son mas lentos pero más robustos… ¿Cual es el mejor? Al igual que como sucede con los planificadores, es común en ciertos campos de la informática optar por ciertos modelos antes que por otros, y al pasar el tiempo al avanzar la tecnología o después de años de pruebas resulta que lo que era peor hace 3 años ahora era mejor. Esto es habitual verlo en los planificadores, sistemas de archivos, algoritmos de congestión… tecnologías en constante desarrollo y que no se puede decir cual es la mejor de todas, puesto que cada una es mejor y peor en ciertas tareas. Este tipo de cuestiones son bastante complejas y no hay consenso universal, tan solo se puede acudir a ideas e intentar demostrarlas con test de todos los tipos. Por ejemplo, nuestros dispositivos poseen memorias Flash, no son discos duros. Esto significa que es posible incluso que haya sistemas de archivos más eficientes para este tipo de memorias que los comentados anteriormente, y dentro de un mes o dos o tres vemos que con otro sistema de archivo ganamos un buen pico en rendimiento solo con ello.
  • CIFS/Samba: Kernels con soporte para el protocolo de Microsoft SMB, es decir, para poder acceder desde nuestros terminales Android a carpetas compartidas en nuestra red, e incluso impresoras!! Podemos realizar Streaming a nuestros dispositivos sin problema alguno.
  • Drivers: Del mismo modo se pueden constituir Kernels con drivers mejores. Un claro ejemplo de esto es el propio Nexus One o el HTC Desire, en los que el adatador inalámbrico que poseen de fábrica realmente es un adaptador tipo 802.11n, y por consumo decidieron no habilitar wifi n en dichos modelos. En cambio, cambiando el driver de este es fácil habilitar wifi n en ellos, mejorando considerablemente el rendimiento WIFI y la cobertura, por supuesto a expensas de nuevo de la batería.
  • Etc…

En definitiva, no son ni dos ni tres los posibles ajustes que podemos realizar a nuestros dispositivos, y tampoco podemos dar una guía de cual es el perfecto equilibrio, tan solo podemos en todo caso exponer cual es la mejor configuración para nosotros. Dsde mi punto de vista? Una ROM AOSP con un kernel HAVS con voltaje reducido, con planificador BFS con soporte para CIFS y aun tengo que cambiar el sistema de archivos a una combinación de ext2 y ext4. Una interfaz sencilla sin sobrecargas, una o dos páginas a lo sumo en el escritorio y con muy pocos o ningun Widget, y despues de probar  5 baseband concretas opté por la que mejor resultado me daba en cuanto consumo y cobertura. Como digo, lo mejor es probar por uno mismo, saber que es cada cosa e ir afinando cada vez más. ¿Se nota la diferencia? Enormemente!! Por ejemplo, puedes fácilmente pasar de cargar el terminal una vez al día a a vez cada 3 días!! Todo es cuestión de ajustar, eliminar lo no necesario, volver a ajustar, corregir, dar dos pasos atrás, 3 adelante y todo apunto.

 

Creo sinceramente que hay grandes equipos detrás de foros, chats, blogs… personas individuales y grupos que sinceramente se ganan el respeto de muchos sin pedir nada a cambio y que demuestran el buen hacer. Cuanto menos creo que se merecen el respeto y las gracias de muchos, que como yo (el primero) disfrutamos de sus trabajos o aprendemos de ellos. He tenido la suerte de poder tratar con algunos verdaderos Gurús, y si bien es cierto que hay algunos que no hay por donde cogerlos, hay otros que son personas la verdad que son dignas de conocer. Un saludo para todos ellos, aun cuando nunca lean estas pobres letras.

Y para mis lectores, un: Pronto nos volvemos a ver por aquí