El sistema operativo de los dispositivos Android consta de dos partes principales:
- El código genérico de Android (AOSP) y
- El código específico del hardware, proporcionado por el proveedor OEM/SoC (en su mayoría basado en las implementaciones de referencia de AOSP).
Proyecto Treble tiene como objetivo separar el código AOSP del código del proveedor para que cada uno pueda ser compilado y actualizado independientemente. HIDL (la capa de comunicación entre ambas capas de código: HALs y el marco AOSP) fue diseñada específicamente para lograr el objetivo. Así que ahora tenemos necesariamente separados system y vendor / odm particiones. Resolvió (o intentó resolver) el problema del retraso o la ausencia de actualizaciones OTA de los OEM tras el lanzamiento del dispositivo.
Partición A/B pone AOSP + código de proveedor en dos pares/ranuras idénticas de particiones (incluyendo boot , system y vendor ). Así, si la actualización OTA falla en una ranura, la otra sigue funcionando. También hace posible la actualización de la ranura inactiva mientras el sistema operativo (ranura activa) está funcionando, por lo que no afecta al flujo de trabajo del usuario. Este enfoque anima a los OEM a enviar actualizaciones más frecuentes, sin ningún temor. Como el documentación oficial estados:
Este enfoque reduce la probabilidad de un dispositivo inactivo después de una actualización, lo que significa menos reemplazos de dispositivos y reflashings de dispositivos en los centros de reparación y garantía.
A nivel de diseño, ambos son independientes entre sí (salvo que ambos implican particiones). Agudos es relevante para el sistema operativo (principalmente el espacio de usuario), es decir, cómo interactúan entre sí los procesos en ejecución de AOSP y del proveedor (incluye IPC basado en carpetas ). Mientras que Partición A/B sustituye al fenómeno de la actualización OTA que antes se basaba en recovery y cache particiones. Por lo tanto, implica cambios necesarios incluso en el cargador de arranque, es decir, la lógica: cómo se inicia desde diferentes boot / system particiones, especialmente después de una actualización OTA fallida. Una vez cargado el sistema operativo, el A/B no es de mucha importancia (excepto cuando se produce la actualización OTA).
Así pues, ambas innovaciones abordan problemas diferentes pero en cierto modo relacionados para lograr el mismo objetivo: más actualizaciones OTA . Además, colectivamente, sentaron las bases para particiones dinámicas que permiten a los OEM cambiar el tamaño system / vendor / odm / product particiones durante las actualizaciones de la OTA a medida que el AOSP y el código del proveedor crecen o se reducen.
