Inicio Systemless updates, Treble y APEX: Qué son, y que significan

Systemless updates, Treble y APEX: Qué son, y que significan

Android es un sistema veterano, con 10 años (casi 11) e infinidad de versiones, Google ha conseguido casi el 90% de la cuota mundial de moviles, sin contar la cuota en Televisores, Autos, Relojes, Tv Boxes, etc. Y al principio la filosofía era bien clara, una versión de Android para todo.

Hoy, la cosa va bastante diferente, eliminando el paralelismo que existía entre versiones, y viendo como los fabricantes día tras día agregaban funciones y aplicaciones a sus Frameworks (Sus capas de personalización). E incluso estas han evolucionado entre versiones, algunas de forma discreta (HTC Sense por ejemplo) u otras de forma más radical (Samsung con OneUI).

Huawei, Oppo, Xiaomi, Meizu, Vivo, etc, simplemente llegan, toman la base de Android, la deforman a niveles astronomicos y arman un sistema operativo «derivado» de Android (los conocidos Fork). Esto tiene un grave problema detrás: Las actualizaciones.

La base de las actualizaciones de Android hasta antes de Oreo era bastante compleja:

  • Google envíaba una versión «vainilla» de la nueva versión de Android
  • Los fabricantes debían adaptar sus capas de personalización (Frameworks) a la nueva versión de Android
  • Los fabricantes de chips debían actualizar sus drivers para ser compatibles con la nueva versión de Android (esto es solo para actualizaciones mayores, los saltos inter-versión normalmente no requieren actualización a nivel de drivers y/o kernel)
  • Corroborar la compatibilidad de los drivers, el framework y el sistema operativo ya después de todas las modificaciones.
  • Periodo de beta-testing, donde usuarios, ya sea internos o público general, tenían acceso a estas versiones sin pulir, para detectar fallos y evitar problemas.
  • Se lanza la actualización al publico general, normalmente de forma escalonada entre países, zonas, variantes y empresas de telecomunicaciones.

Todo este proceso podía tomar varios meses (incluso más de un año desde que se lanza la nueva versión), por lo qué Google ha intentado hacer más sencilla la vida de los usuarios con 3 grandes pilares, 2 proyectos aún mayores:

Google Play Services

El primer pilar es Google Play Services, que se encarga de mantener algunas de las funciones básicas del telefono funcionando, incluso teniendo una versión anterior. (Ejemplo de ello es que Play Services pide Android 4.0 para funcionar)

Systemless updates (O Actualizaciones A/B)

Esto, integrado por primera vez en Nougat, aunque no es obligatorio según el CDD (Compatibility Definition Document) permite que el equipo tenga 2 particiones del sistema (/system_a y /system_b) y que cada una de estas sea independiente una de otra. Entonces, cuando llega una nueva actualización vía OTA (Over the Air) en lugar de modificar la partición en uso (/system_a por ejemplo), modifica la que no está actualmente en uso (/system_b), cosa de que cuándo la actualización ya esté instalada, solo tengas que reiniciar el equipo.
Sin embargo, cuando reinicias el equipo la partición cambia, a través de una función del cargador de arranque (o bootloader) de la siguiente manera:

fastboot --set_active b
[bootloader]Active slot set on b
fastboot continue

El cargador de arranque al entender el cambio de partición activa, en vez de invocar a /system_a, invoca a la partición ya actualizada, permitiendo luego, en segundo plano, aplicar la actualización en la otra partición ahora inactiva.

Proyect Treble (O unificación de la base de Android)

Gracias a Treble, introducido en Oreo y obligatorio para todos los equipos que monten esta versión de fabrica, es el último escalón actual de Google, que separa la base de Android (Imagen de arranque, núcleo, datos y sistema) de la capa de personalización (ahora en /vendor), permitiendo al menos en teoría hacer más rápidas las actualizaciones (Lo cuál es en cierta medida cierto) y poder permitir que existan una gran cantidad de imagenes personalizadas (Custom ROMS)

El futuro con APEX: Actualizaciones como Debian, Fedora o SUSE

Project APEX, que está dando vueltas en el código de Android, prometiendo un formato de actualizaciones «en caliente» y «sin interacción», qué como hablé en su momento será parte del Sistema de Actualizaciones nativo de Android, o bien por una sección especial de Google Play.

Promete de este modo actualizar frameworks de forma transparente, solo pidiendo un reinicio en caso de que sea estrictamente necesario (Actualización de kernel, por ejemplo). Con este sistema, se intentará mantener una estructura aún más modular del sistema operativo, permitiendo entre otras cosas, el siguiente punto:

Android -> Fuchsia

Android ya es un sistema operativo qué, en terminos de programación, es obsoleto. Escrito en java, presenta todos los problemas de este lenguaje de programación, qué es entre otras cosas, el sacrificio de rendimiento en comparación a sistemas operativos escritos en C++ (Ejemplo de ello es iOS y el difunto Windows Phone).

Fuchsia viene a tomar el relevo a Android, luego de años de trabajo, y han aparecido más pistas de él en el código de Android, dando a entender, si tomamos todos los datos qué tenemos como un movimiento bastante inteligente.

A modo especulativo tenemos el siguiente punto:

  • Google empieza a converger Android con Fuschia utilizando APEX, actualizando primero vinculos dinámicos dentro de la raíz del sistema, y agregando lentamente el código de este en Android.
  • Posteriormente, se actualiza el main-framework, convirtiendo Android en una mezcla entre este y Fuchsia, permitiendo así que las API sigan siendo compatibles con el código de Android, y además se añadan funciones propia de Fuchsia.
  • Se actualiza el Kernel (Qué actualmente es Linux) por el propietario en el que Google se encuentra trabajando para este nuevo sistema operativo.
  • Finalmente, a modo de «Actualización Mayor de Android», se presenta Fuchsia como nuevo sistema operativo, convergiendo y siendo completamente operativo desde el primer momento, sin perder compatibilidad ni funciones para los usuarios.

Lo de Fuchsia y APEX son especulaciones mías, pero es el camino más logico considerando los últimos movimientos de Google. Es probable que en la conferencia de Desarrolladores se confirme o de desmienta todo esto, pero sin duda alguna, sería un excelente modo de presentar lo nuevo sin dejar espacio a que existan vacios de compatibilidad. Algo qué ya pasó en 2 oportunidades con Windows Phone/Mobile, que terminó enterrandolo.

Y tú, ¿Qué opinas de todo esto?

Ultimas Noticias

¡Sorpresa! WOM estaría pronto a lanzar Fibra óptica

WOM estaría pronta a ofrecer Internet y televisión por fibra óptica

Xiaomi registra marcas: Se asoman MIX Alpha y Xiaomi Watch

Sabemos que a Xiaomi le encanta llenar de dispositivos cada categoría que pueda, y como aún nos queda 2019 por recorrer, hoy...

iOS no mostrará la información de tu batería si esta no fue instalada por Apple.

Malas noticias tenemos a los usuarios de Apple, ya que según reportan en el sitio estadounidense iFixit, las últimas versiones de iOS...

Eclipse 2019: ¿Fotografía con smartphone? Se puede, y te decimos como aprovecharlo al máximo.

Si estas en Chile o Argentina, seguro ya has escuchado de todo acerca del eclipse solar que se producirá el día de...