¿Qué ha pasado con la actualización a Lollipop?
Esta semana se ha publicado la noticia de la cancelación del programa beta para los Aquaris E5 FHD y E6. Como es lógico la noticia ha sentado mal a muchos usuarios que han visto como una actualización que estaba a punto de llegar ha desaparecido de un día para otro. Las cosas no son blancas o negras y en el artículo encontraréis un análisis de lo que ha pasado para llegar a esta situación. El firmware de la versión beta se publicará a corto plazo y cualquier usuario podrá probarlo o tomarlo como base para una ROM cocinada. Otro de los afectados ha sido el Aquaris E10. De este modelo no ha llegado a salir una versión estable en el programa de beta por lo que se desconoce si se llegará a publicar algún firmware de Lollipop.
Nota: Antes de continuar leyendo quiero comentar que soy MVP en el foro de bq. No trabajo en bq pero si tengo una relación más directa. Si piensas que soy una parte interesada y que no soy imparcial puedes cerrar la página y continuar con otras cosas.
Introducción
Android es uno de los sistemas operativos que podemos encontrar en teléfonos o tabletas junto a iOS o Windows Phone. Es un sistema operativo de código abierto, lo que quiere decir es que el código fuente está disponible para que cualquier usuario lo pueda modificar. Para que funcione hace falta también un conjunto de drivers que comuniquen el sistema operativo con los diferentes elementos del terminal como son la pantalla, la memoria o el módulo de comunicaciones. El encargado de crear los drivers es el fabricante del SoC ya que dispone de la documentación y los recursos para implementarlos.
El flujo de desarrollo de una versión de Android sería, de forma resumida, el siguiente:
- Google publica una nueva versión de Android con el código fuente.
- El fabricante del SOC publica el código fuente asociado a esa versión de Android.
- Los fabricantes de los terminales utilizan el código que proporciona el fabricante del SoC para generar la ROM.
Si Google publica el código fuente y el fabricante del SoC también lo hace, ¿dónde está el problema en migrar un terminal de una versión de Android a una superior? ¿Por qué bq ha cancelado la actualización a Lollipop de sus terminales de la gama E cuando lo había prometido? La respuesta para ambas preguntas está en un elemento que ha quedado oculto y está en la parte privativa de Android.
El kernel de Android tiene una licencia GPL. A efectos de desarrollo quiere decir que cualquier modificación que haga un fabricante tiene que publicarla de forma obligatoria con el código fuente. Hay una excepción a esta regla en forma de blob binario. Un blob binario es un driver ya compilado que se puede usar en un kernel concreto. Es una forma de introducir código privativo en el kernel de GNU/Linux sin invalidar la licencia GPL. Ese archivo es una caja negra y el único que puede crearlo es el fabricante del SoC.
Consecuencias de usar un blob binario
La razón de que el fabricante del SoC proporcione un blob en lugar del código fuente es simple y está relacionada con la propiedad intelectual. El driver trabaja a bajo nivel para comunicarse con los elementos que conforman el SoC. Un tercero que tuviera acceso a ese código fuente podría conocer el funcionamiento interno del SoC y copiar algunas de sus características. Lógicamente no es un proceso trivial pero si es un punto de inicio para que trabajen.
Supongamos que desarrollamos una ROM con el código que ha publicado el fabricante del SoC. Durante el desarrollo se detecta que el teléfono no entra en el modo de ahorro de energía o que la cámara funciona mal. Después de depurar el software se encuentra que el fallo está en la parte del driver. En este punto el fabricante del terminal reporta el bug y espera a que el fabricante del SoC lo arregle. ¿Qué pasa si el fabricante del SoC no corrige el bug? En ese caso estaríamos en un callejón sin salida.
Algo similar ha ocurrido hasta hace poco en las distribuciones de GNU/Linux. En las tarjetas gráficas de AMD (ATI) y NVIDIA se pueden encontrar dos tipos de drivers. Uno era el driver del fabricante y tenía el mejor rendimiento posible. El otro driver era el libre y estaba desarrollado con la información que liberaba el fabricante. El funcionamiento era bueno pero no llegaba a sacar todo el rendimiento posible. Sólo cuando el fabricante ha publicado la documentación necesaria el rendimiento del driver libre ha mejorado de forma importante. Aplicando el mismo ejemplo se podría hacer un driver libre de los elementos del SoC que evitara los problemas que están apareciendo. El inconveniente es que para lograrlo hace falta documentación y tener recursos. Para desarrollar un driver es necesario conocer el funcionamiento interno del SoC de forma completa.
¿Qué podemos hacer en este punto?
Cuando se llega a este punto no hay una solución sencilla. El desarrollo de la ROM no puede continuar ya que tendrá fallos conocidos que no se puedan arreglar. El SoC que lleva un terminal no es único para ese fabricante sino que lo usan diferentes fabricantes. ¿El problema afectaría a todos los fabricantes que usen el mismo SoC? ¿Es posible que un fabricante tenga el driver y otro no?
En principio el problema afecta a todos los fabricantes que utilicen el mismo SoC. Hay un detalle importante que me gustaría comentar y es que la relación no es la misma con un fabricante que te compra pocas unidades de un SoC que con otro fabricante que compra muchas unidades. En este último caso hay una posición de fuerza frente al fabricante del SoC y se pueden conseguir los drivers necesarios para que todo funcione. Esa es una razón para que pueda existir algún terminal que lleve el mismo SoC y tenga Lollipop de serie. La cosa cambia si no tienes una posición de fuerza e intentas actualizar un terminal que ha salido con Kit Kat a Lollipop. El fabricante del SoC proporciona los recursos para la versión que sale de fábrica (Kit Kat) y si le interesa los recursos para pasar a una versión más reciente como es Lollipop.
Este problema con los drivers no afecta únicamente a los fabricantes sino que afecta a los cocineros. Es relativamente sencillo encontrar ROMs con versiones modernas de Android que funciona todo excepto algún módulo hardware concreto. Si existe algún terminal con el mismo hardware y que tenga los drivers es posible coger esos drivers y pasarlos a una ROM cocinada (dejando aparte temas de propiedad intelectual). Lo que no se podría es implementar el módulo que falla sin la ayuda del fabricante del SoC.
En muchas ocasiones los cocineros consiguen portar una versión de Android más reciente que la que ha publicado un fabricante. ¿Cómo es posible que un grupo de cocineros con pocos recursos pueda conseguirlo y un fabricante no? Al final llegamos a un problema de propiedad intelectual. En las ROMs cocinadas se “permite” coger los drivers de los terminales que los tienen. Si una empresa hace lo mismo digamos que no se le ocurrirá pensar en hacerlo de nuevo por las sanciones que recibiría.
El caso de bq
Después de esta introducción nos centramos en el caso de bq. De forma resumida la situación es la siguiente:
- Google publica el código fuente de Lollipop a finales de 2014.
- Mediatek libera el código fuente del SoC que usan los Aquaris E5 FHD, E6 y E10 en verano de 2015.
- El programa de beta empieza a finales de noviembre de 2015.
- Se van publicando varias betas de los Aquaris E5 FHD y E6. Los betatesters las prueban y reportan los errores que encuentran.
- Esta semana se publica el comunicado diciendo que se cancela la beta.
Lógicamente el comunicado es un jarro de agua fría tanto para los usuarios que esperaban Lollipop como para los equipos que estaban trabajando en la actualización. El cabreo es importante y aparecen noticias relacionadas en diferentes páginas Web a lo largo de la semana. La presencia de un SoC de Mediatek en los terminales afectados se ha vuelto un problema. Probablemente no habría pasado lo mismo si el SoC fuera de Qualcomm ya que este fabricante ofrece más facilidades a la hora de actualizar. Estas facilidades implican un incremento de coste que se habría aplicado a los terminales que compraban los usuarios.
En este punto el usuario afectado tiene varias opciones:
- Seguir con Android Kit Kat.
- Vender el teléfono y pasar a otra marca.
- Comprar un terminal de la gama M con el descuento de 50 € que da bq.
El firmware que estaba en el programa de beta de Lollipop se va a publicar. Los usuarios y los cocineros lo podrán usar en sus terminales teniendo en cuenta que habrá algunas cosas que no funcionarán de forma correcta. Cuando se publique el firmware lo comentaré en InnerZaurus indicando los fallos que tiene así como la forma de instalarlo.
Conclusiones
No se puede discutir que lo que ha pasado con la actualización es un error que tendrá consecuencias para bq. Una de las primeras medidas que han tomado es anunciar que todos los teléfonos nuevos pasarán a usar Qualcomm. De las tabletas no se han pronunciado de momento. Los SoC que usan son principalmente de Mediatek y hay algunas tabletas que usan un SoC de Intel. Veremos en un futuro si Qualcomm pasa también a las tabletas. A los afectados les quedan las opciones que he comentado antes y reclamar ante los organismos competentes si entienden que es un problema exclusivo de bq. Está claro que bq anunció la actualización a Lollipop de esos terminales y tiene parte de la culpa pero también hay que tener en cuenta que sin la ayuda de Mediatek poco se puede hacer.
Imágenes
- Imagen del artículo por David Mulder.
- Fotografía de Tux en la nieve por fsse8info.
- Logo de MediaTek.
- Logo de bq.
Dejar un comentario
¿Quieres unirte a la conversación?Siéntete libre de contribuir!