Android Auto y Automotive: plantillas y conduccion

Hasta ahora, cada superficie nueva ha añadido restricciones de espacio, de energía o de entrada, pero todas compartían una libertad fundamental: podías dibujar lo que quisieras. En el coche esa libertad desaparece y lo hace de forma deliberada. La biblioteca de aplicaciones para vehículo no te da un lienzo con componentes; te da un catálogo cerrado de plantillas que rellenas con datos, y el sistema decide el aspecto final, la tipografía, los tamaños de toque y hasta cuántos elementos puede tener una lista. No hay forma de saltarse esa restricción, no hay componente de escape, no existe el equivalente de un lienzo personalizado. La razón es que el coste de un error aquí no se mide en una mala reseña sino en segundos de mirada apartada de la carretera a cien kilómetros por hora, y el único modo de garantizar un límite superior de distracción para miles de aplicaciones de miles de equipos distintos es no permitir que ninguna de ellas construya su propia interfaz. A esa premisa se le suma una confusión persistente que conviene disolver antes de escribir una línea: Android Auto y Android Automotive no son dos nombres del mismo producto.

Dos productos distintos con nombres casi iguales

Android Auto es proyección. El sistema operativo del coche puede ser cualquiera; lo que ocurre es que el conductor conecta su teléfono, y una aplicación del teléfono envía a la pantalla del salpicadero una descripción de la interfaz que el receptor renderiza. El cómputo, los datos, la cuenta del usuario y la conexión a internet están en el teléfono. Si el teléfono se desconecta, la experiencia desaparece. La distribución es la del teléfono: se instala desde la tienda del móvil y no hay nada que instalar en el vehículo.

Android Automotive es el sistema operativo del coche. Android arranca en el hardware del vehículo, gestiona la instrumentación, el climatizador y la radio, y las aplicaciones se instalan directamente en el coche desde su propia tienda. No hay teléfono en la ecuación. El coche tiene su propia conectividad, su propia sesión de usuario y su propio ciclo de actualización, que es el del fabricante y se mide en años, no en semanas.

La confusión entre ambos productos se agrava porque el usuario final no los distingue y porque el vocabulario comercial de los fabricantes tampoco ayuda. Para el conductor, en los dos casos hay una pantalla en el salpicadero con aplicaciones que se parecen. Para ti, la diferencia decide dónde se ejecuta tu proceso, quién paga los datos, qué versión de Android estás pisando y con qué frecuencia podrás corregir un fallo. Es, en rigor, la misma distinción que existe entre proyectar la pantalla del teléfono en un monitor y ejecutar la aplicación en el ordenador que hay detrás de ese monitor.

La consecuencia práctica más útil es que, para la mayoría de las categorías, el mismo código sirve para ambos: la biblioteca de aplicaciones para vehículo es común, y una aplicación de navegación o de puntos de interés bien escrita se distribuye a las dos superficies con diferencias de configuración y no de arquitectura. Las diferencias importantes aparecen cuando se quiere ir más allá de las plantillas: solo en el sistema embarcado existen las propiedades del vehículo —velocidad, marcha, nivel de batería, estado del climatizador—, solo allí tiene sentido una aplicación con interfaz propia para usar con el coche aparcado, y solo allí hay que preocuparse por convivir con las aplicaciones del fabricante.

Las plantillas: un catálogo, no un lienzo

El modelo de programación es sencillo de describir y muy distinto de todo lo anterior. Publicas un servicio que el sistema del coche arranca, ese servicio crea una sesión, y la sesión gestiona una pila de pantallas. Cada pantalla, al pedírsele, devuelve una plantilla ya construida: una lista, una rejilla, un panel de información, un mensaje, una vista de navegación con mapa, un formulario de inicio de sesión. Tú eliges cuál y rellenas sus huecos con textos, iconos y acciones. No eliges cómo se ve.

class PantallaDeAparcamientos(carContext: CarContext) : Screen(carContext) {
    override fun onGetTemplate(): Template {
        val constructor = ItemList.Builder()
        aparcamientosCercanos().take(6).forEach { sitio ->
            constructor.addItem(
                Row.Builder()
                    .setTitle(sitio.nombre)
                    .addText(sitio.distanciaLegible)
                    .setOnClickListener { abrirDetalle(sitio.id) }
                    .build()
            )
        }
        return ListTemplate.Builder()
            .setSingleList(constructor.build())
            .setTitle("Aparcamientos cerca")
            .setHeaderAction(Action.BACK)
            .build()
    }
}

Nótese lo que ese modelo hace con el ciclo de vida. Tu pantalla no dibuja: describe. El sistema pide la descripción cuando la necesita y tú se la devuelves construida de una pieza, sin estado intermedio, sin animaciones propias y sin control sobre el momento del repintado. Cuando algo cambia en tus datos, no modificas la interfaz sino que invalidas la pantalla y el sistema vuelve a pedirte la plantilla entera. Es, curiosamente, un modelo declarativo puro y muy próximo en espíritu al de Compose, con la diferencia de que aquí la representación intermedia no la interpreta tu proceso sino el del vehículo.

Dos límites del catálogo condicionan el diseño más que ningún otro detalle. El primero es la longitud de las listas: el sistema impone un máximo de elementos visibles, del orden de media docena en movimiento, y ese máximo lo fija el receptor y puede variar entre vehículos. Cualquier interfaz que asuma desplazamiento largo está mal planteada. El segundo es la profundidad de tarea: hay un límite estricto al número de pantallas que el conductor puede atravesar dentro de una misma tarea, del orden de cinco pasos, y superarlo no produce una advertencia sino un rechazo del sistema.

Al catálogo se le suman plantillas para situaciones que en un teléfono resolveríamos con una pantalla propia y que aquí tienen forma canónica: el mensaje con acciones para errores y confirmaciones, el panel de información para un detalle breve, la rejilla para una selección visual corta, la vista de navegación con su mapa y su banda de indicaciones, y un formulario de inicio de sesión con los pocos métodos que el sistema considera admisibles al volante. Que la autenticación tenga plantilla propia es revelador del nivel de control: ni siquiera el paso más sensible de tu producto puede diseñarse libremente.

Ese segundo límite es el que más reescrituras provoca, porque obliga a invertir la arquitectura de información. En un teléfono, una jerarquía profunda es aceptable porque el usuario tiene tiempo. En el coche hay que llevar arriba lo probable y descartar lo posible: los tres destinos frecuentes en lugar del árbol completo de categorías, la reanudación de lo último escuchado en lugar del catálogo entero. Toda navegación que no cabe en cinco pasos es, en realidad, una petición de que el conductor tome una decisión que no debería estar tomando mientras conduce.

flowchart TD
A[Servicio de aplicacion de coche] --> B[Sesion]
B --> C[Gestor de pila de pantallas]
C --> D[Pantalla devuelve una plantilla]
D --> E[El sistema del vehiculo la dibuja]
E --> F[Aplica tipografia y tamanos del fabricante]
E --> G[Aplica restricciones de conduccion vigentes]
G --> H[Vehiculo parado con contenido completo]
G --> I[Vehiculo en marcha con lista recortada]
style D fill:#89b4fa,color:#11111b
style I fill:#f9e2af,color:#11111b

Las restricciones de conducción como contrato

Las restricciones no son una guía de estilo: son un estado que el sistema publica y que cambia mientras la aplicación se ejecuta. Cuando el vehículo se pone en movimiento, el sistema declara activas una serie de limitaciones —longitud máxima de una cadena de texto, número máximo de elementos de lista, prohibición de vídeo, prohibición de contenido que exija lectura sostenida— y espera que la aplicación se reconfigure sola. No es una petición: si tu contenido las incumple, el receptor lo recorta o lo bloquea.

El fundamento de esas limitaciones no es una preferencia de la plataforma sino investigación de ergonomía del transporte con décadas de recorrido, cuyo resultado más citado es un presupuesto de mirada: cada vistazo a una pantalla debe durar por debajo de aproximadamente dos segundos, y el tiempo acumulado de una tarea completa debe mantenerse por debajo de unos doce. A cien kilómetros por hora, dos segundos son más de cincuenta metros recorridos sin mirar la carretera. Todas las cifras concretas del sistema —el número de elementos, la longitud de los textos, la profundidad de la pila— son traducciones de ese presupuesto a magnitudes que un programa puede verificar.

De ahí salen tres reglas de diseño que conviene interiorizar. La primera es que el texto se escribe para ser oído, no leído: los títulos van al grano, la información secundaria se convierte en voz y la lectura larga desaparece en marcha. La segunda es que ninguna tarea puede exigir precisión: los objetivos de toque son enormes por decisión del sistema, y cualquier flujo que necesite apuntar con cuidado está mal concebido para el medio. La tercera es que la entrada de texto no existe en movimiento, lo que empuja toda búsqueda hacia la voz y hacia las sugerencias preparadas de antemano.

Hay una cuarta regla que se deduce de las anteriores y que conviene decir explícitamente: la aplicación no puede exigir atención por su cuenta. Nada de solicitar el primer plano, nada de diálogos que interrumpen, nada de animaciones que capturan la vista periférica. En el coche, quien decide cuándo el conductor mira la pantalla es el conductor, y toda función que dependa de que mire en un instante concreto está mal diseñada. La única excepción legítima es la guía de navegación en curso, y precisamente por eso tiene una plantilla propia y una categoría propia.

Merece la pena subrayar que las restricciones son un estado observable y no una comprobación de arranque, exactamente igual que la clase de tamaño de ventana o que las capacidades espaciales. El vehículo arranca parado, se pone en marcha, se detiene en un semáforo y vuelve a arrancar, y cada una de esas transiciones ocurre en mitad de la sesión del usuario. Una aplicación que consulta el estado al crear la pantalla y no vuelve a mirarlo mostrará contenido completo a ochenta por hora o contenido recortado en un aparcamiento, y ambas cosas son defectos.

Elegir la categoría y probar sin coche

Conviene distinguir las categorías admitidas, porque determinan qué plantillas se te permiten y cuándo. Navegación, aparcamiento y recarga tienen acceso a la plantilla con mapa y a la guía paso a paso. Puntos de interés y control del hogar conectado se quedan en listas y rejillas. El audio no usa plantillas sino el mecanismo de exploración multimedia que ya conoces del teléfono, y la mensajería no dibuja nada: se apoya en notificaciones con lectura por voz y respuesta dictada. Y el vídeo y los juegos existen únicamente en el sistema embarcado y únicamente con el vehículo detenido, lo que en la práctica los convierte en una categoría aparte con su propio ciclo de vida.

Esa pregunta merece formularse sin complacencia, porque la respuesta correcta para la mayoría de los productos es que no tienen nada que hacer en un coche. Una tienda, una red social, un gestor de tareas o una aplicación de banca no tienen ninguna tarea que un conductor deba realizar en marcha, y llevarlas al salpicadero no añade valor: añade una superficie más que mantener y una tentación más para alguien que debería estar mirando la carretera. Reconocerlo a tiempo es una decisión de producto excelente, aunque no genere ninguna entrega.

La elección de categoría no es un trámite de registro: define el contrato entero. Determina qué plantillas puedes instanciar, qué permisos se te conceden, qué requisitos de calidad se te exigirán en la revisión y en qué lugar de la pantalla de inicio del vehículo aparecerás. Elegir mal, o intentar hacer pasar un catálogo general por una aplicación de puntos de interés, produce rechazos que llegan tarde y obligan a rehacer la arquitectura de información completa. La pregunta previa correcta es cuál de las tareas de tu producto es genuinamente de conducción, y con frecuencia la respuesta honesta es ninguna.

Hay una asimetría de plataforma que conviene tener presente al planificar: en el sistema embarcado, además de las plantillas, existe la posibilidad de publicar aplicaciones con interfaz propia destinadas a usarse con el vehículo detenido —vídeo, juegos, navegadores— y existe el acceso a las propiedades del vehículo para aplicaciones autorizadas. Ambas cosas amplían mucho lo que se puede hacer y ambas reducen a cero la portabilidad hacia la proyección. Mezclarlas en el mismo módulo produce una aplicación que no puede entregarse a ninguna de las dos plataformas sin cirugía.

La buena noticia es que probar no exige un vehículo. Para la proyección existe una unidad de cabecera de escritorio que conecta con el teléfono por depuración y reproduce en el ordenador la pantalla del salpicadero, con sus mismos límites y sus mismas restricciones, incluida la posibilidad de simular el estado en marcha. Para el sistema embarcado existen imágenes de emulador con las propiedades del vehículo simuladas, donde se puede variar la velocidad, la marcha o el nivel de batería y observar cómo reacciona la aplicación. Ninguna de las dos sustituye a una prueba real, pero ambas detectan la inmensa mayoría de los defectos y ambas caben en el flujo de trabajo diario.

Conviene además construir la matriz de pruebas alrededor de las transiciones y no de los estados. Los estados estáticos —parado con contenido completo, en marcha con contenido recortado— casi siempre funcionan a la primera. Los defectos viven en el instante en que el vehículo arranca con un diálogo abierto, en la pérdida de conectividad a mitad de una carga, en la desconexión del cable durante una navegación activa y en la llegada de una llamada mientras el usuario recorre una lista. Son los mismos escenarios de continuidad que llevamos estudiando todo el nivel, con la diferencia de que aquí el usuario no puede permitirse resolverlos mirando.

Queda una última pieza de proceso que conviene interiorizar: la revisión de la tienda para las categorías de vehículo es sustancialmente más estricta y más lenta que la ordinaria, y sus criterios incluyen aspectos que en otras superficies ni se miran, como la longitud de las cadenas, la ausencia de imágenes con texto embebido o el comportamiento ante la pérdida de conectividad. Planificar una entrega de coche con los plazos de una entrega de móvil es una de las causas más frecuentes de lanzamiento fallido.