Me divorcié de Google, parte 3: El enemigo final

En la entrega anterior armé una isla de Google adentro del celular para que el mapa apareciera en la pantalla del auto, y lo logré: Tres de cada cuatro veces. Terminé con una pregunta que todavía me debo: ¿Me doy por vencido?

Antes de contestarla, hay que presentar al enemigo final.

Enemigo final

Android Auto proyecta el celular en la pantalla del auto: mapas, música, llamadas, mensajes. Con cable es simple. Sin cable es una coreografía: el celular y el auto se saludan por Bluetooth, el auto levanta su propia red Wi-Fi, el celular se conecta a ella y, recién ahí, empieza la proyección. Cuatro pasos, cuatro lugares donde algo puede salir mal. Y además consume: con la proyección por Wi-Fi, Waze y música, la batería bajaba 22% por hora.

Salió mal de varias maneras. Algunas, por desconocimiento mío.

La VPN

La primera vez que lo usé con el filtro de red encendido, Android Auto me recibió con una pantalla roja. Lo saqué del filtro. Más adelante intenté meterlo adentro con una excepción para la red local, y Android Auto me contestó con todas las letras: “Error de comunicación 21: estar conectado a una VPN puede impedir que Android Auto se inicie”.

Android Auto revisa si su propio tráfico pasa por una VPN y, si pasa, no arranca. No es un error: es una decisión. Otra opinión de Google que se talla en piedra.

Aquí viene otro rant, y creo que este está justificado:

Yo entiendo el negocio, el vendor lock-in (o como diríamos por estos lares, “hacer cautivo al cliente”), y muchas otras maravillas tecnológicas que sólo atrasan… tecnológicamente. Pero es inaceptable no poder manipular como yo quiero, un dispositivo que yo me compré, que yo decido cómo se comporta, y que yo decido cómo usar (te estoy mirando, Huawei). Android es un hueso duro de roer, pero dentro de todo tiene algunas grietas interesantes que nos permiten cierta ilusión de control.

Hablar con Android Auto es como negociar con una pared. Intentarlo es simplemente delirar.

Estoy bien.

Sin datos en la calle

Una noche, manejando, Maps mostraba un error genérico, Waze el ícono de “sin conexión” y el navegador andaba en cámara lenta. En casa, todo perfecto.

Dos culpables: Una opción del firewall que bloquea los datos móviles para todas las aplicaciones había quedado encendida, y mi propia optimización le cortaba los datos móviles en segundo plano a Android Auto, a Play Services y a la aplicación de Google. Lo que hacían con la pantalla apagada, lo hacían sin datos. Y en el auto, la pantalla del celular está apagada todo el tiempo.

La optimización, otra vez, cobrándose lo suyo.

Lento y furioso

Y después está el problema de verdad. A veces, al arrancar el auto, la pantalla dice “Android Auto no está disponible”.

Una de esas veces, los registros mostraron algo absurdo: el celular se había conectado a la red del auto y transmitió la proyección durante todo el viaje, casi 600 MB, mientras la pantalla del auto seguía diciendo “no disponible”. Sólo el cable lo arregló.

Otra vez, el celular estaba compartiendo internet (el famoso hotspot), y este celular no puede compartir internet y conectarse a otra red Wi-Fi al mismo tiempo: No tenía cómo unirse a la red del auto. Apagué el hotspot, el celular se conectó y empezó a transmitir. La pantalla del auto, igual: “no disponible”.

En esta combinación “pantalla de auto” y celular, una vez que la pantalla del auto falla un arranque, no vuelve a intentar. Ni aunque el celular esté conectado y transmitiendo. Sólo una conexión de Bluetooth nueva (o un cable) la despierta.

Otro pequeño rant (prometo que es el último): ¿A quién se le ocurrió que una pantalla que falla una vez no tiene por qué volver a intentarlo? En fin.

Seguimos.

En los registros que sobrevivieron hubo ocho arranques inalámbricos, y fallaron dos. Hubo más que no llegué a monitorear. Aun quedándome con los números que tengo, es uno de cada cuatro. Para un uso así, es inmenso.

Y el costo escondido: para cuando me doy cuenta de que la pantalla decidió no volver, ya hice media cuadra con el auto; no puedo ponerme a manipular el celular. Muchas veces ni siquiera uso la navegación; sólo quiero el mapa para ver las alertas de tránsito y ubicarme. Precisamente eso es lo que se pierde.

Y aún así, con cable, funciona perfecto. Siempre.

Pequeña aclaración: en una de esas vueltas también se fue el GPS. Y antes de que alguien diga nada: tuve celulares funcionando sólo con GPS durante muchísimos años, y concuerdo en que hay momentos de pérdida de señal, pero en seguida vuelve. Lo que muestran los registros es que cada vez que Android Auto se reiniciaba, el mapa arrancaba una búsqueda de satélites nueva. Si el chip perdió la señal o no, no lo sé: esa parte del registro se la llevó un reinicio.

Blindé lo que pude: Android Auto ya no está restringido, y Aurora tiene prohibido actualizarlo por su cuenta. Lo que no pude blindar es la pantalla del auto: Es una caja cerrada del fabricante, y no se puede reemplazar ni reprogramar sin meterse en territorio de brickeo. Contra ese “no” no hay debate a menos que, por supuesto, estemos decididos a meternos en electrónica y desarrollo a bajo nivel.

Un juego de sombras

Es un error fundamental teorizar antes de tener datos. Insensiblemente, se comienza a adaptar los hechos a las teorías, en lugar de adaptar las teorías a los hechos.

– Sherlock Holmes

El problema de investigar una falla en el auto es que, para cuando llego a la computadora, la evidencia ya no está. Android guarda sus registros en una memoria circular: lo nuevo pisa a lo viejo, y lo que pasó al salir de casa se borró antes de volver. Agrandarla ayuda, pero un reinicio la devuelve a su tamaño original, y sin root no hay forma de que el cambio quede fijo.

Así que hubo que investigar con lo que sobrevive: el historial de las redes Wi-Fi (cuándo el celular se unió a la red del auto y cuánto transmitió), las últimas conexiones de Bluetooth, el registro de por qué se cerró cada aplicación, el historial de uso del último día y la caja donde Android guarda las fallas. Ninguno estaba pensado para esto. Juntos, alcanzan.

La primera teoría fue elegante: el día anterior, Android Auto se había actualizado, y que el primer arranque inalámbrico después de una actualización falle es un patrón conocido. Encajaba. Hasta que di la hora exacta de la falla, y el historial mostró dos arranques sin problemas después de esa actualización. La teoría murió ahí. Holmes tenía razón.

En la segunda falla, la respuesta estaba a la vista. No fue el mayordomo: Fue el hotspot.

Y hubo falsos culpables: un conteo de “aplicaciones cerradas por falta de memoria” resultó ser la limpieza de rutina que Android hace con lo que nadie usa hace rato.

Las herramientas para esta clase de autopsia van a vivir, como el resto, en el repositorio público.

Opiniones testarudas

En la primera entrega dejé un “a veces” colgado: el celular manda, a veces. Es hora de explicarlo.

Cada “no” del fabricante es, en principio, una opinión. Motorola parecía opinar que sus aplicaciones tenían que volver en cada reinicio (no: era yo, reiniciando mal). Android opina que sin la pantalla de inicio original no hay botón de recientes. Android Auto opina que sin el motor de voz de Google no arranca, y que con una VPN tampoco.

Huawei lo dijo por escrito. Hace años, después de seis correos pidiendo el código para abrir el bootloader de mi P20 Pro, la respuesta final fue que no lo daban “por razones de seguridad”, y que agradecían todas mis sugerencias y opiniones al respecto. Mi pedido, para Huawei, era una opinión. La suya, en la práctica, fue una ley.

La diferencia entre una opinión y una ley no está escrita en ningún lado: Depende de los recursos que uno tiene y de sus prioridades. En este proyecto, las leyes fueron tres, y las tres tienen letra chica:

• No desarrollar una solución propia. Un reemplazo libre de Android Auto no se escribe en una tarde.
• No arriesgar la pantalla del auto. Convertir el tablero en un lindo pisapapeles no estaba en los planes.
• Un procesador con años encima, y una batería que ya perdió un cuarto de su capacidad no valen el esfuerzo más allá de demostrar un punto político y tecnológico.

Con esas premisas, algunos “no” se comportaron como leyes. Sin ellas, quizás no. Esto no era de vida o muerte para mí, así que algunos quedaron donde estaban. Aun así, creo que llegamos bastante lejos.

No es “no se puede”. Es “a qué renuncio para obtener lo que necesito”.

La escalera

Si tuviera que resumir el proyecto en una imagen, sería una escalera de necesidades.

• Primer escalón: llamadas, mensajes, GPS, mapas sin conexión, un poco de redes sociales. Sin dolor. Visto así, el celular es un “teléfono tonto” con pasos extra que casualmente tiene ubicación, mapas y algo de redes: Nada se rompió, la batería duraba, todo era coherente.

• Segundo escalón: mensajería que depende de notificaciones, billeteras virtuales, controles de identidad. Ahí aparecen las aristas de Play Services y de la tienda de Google, y acá llega la factura que dejé pendiente: aplicaciones que piden el control de integridad y no tienen a quién preguntarle, y una aplicación bancaria que, al pedirme validar mi identidad con una selfie, decidió del lado de sus servidores que era un “intento de suplantación”*.

• Último escalón: el auto. La pantalla del auto, Android Auto, y la ubicación y la voz de Google se asumen entre sí. Ahí es donde se rompe todo.

*: Intenté dos veces más, al aire libre y con buena luz. Luego de hablar con soporte, resulta ser que sus sistemas decían que “yo estaba haciendo zoom”, siendo que yo no tenía controles de zoom de mi lado. Es decir, que su validador malinterpretaba alguna API (interfaz de comunicaciones) de mi chip de cámara y decidía que yo quería cometer fraude.

Con el zoom de la cámara selfie, pude calcular a ojo que el validador de identidad le pedía a mi cámara selfie un zoom de algo más de 3x, sin que yo pudiese opinar al respecto. El misterio se resolvió; el problema sigue ahí.

Cuanto más específica la necesidad, más Google hace falta.

Los números lo confirman. Hubo trece regresos en todo el proyecto. Seis fueron piezas de Google que volvieron por el auto. Cinco fueron maquinaria del sistema: la pantalla de inicio de Motorola, el nombre de la operadora, Peek y los dos servicios de impresión. Los dos restantes: el teléfono de Google, para las llamadas con el celular bloqueado, y el reloj de Google, porque la alternativa libre fallaba en el uso diario.

En mis notas, Android Auto ocupa más o menos una de cada cinco palabras (y si cuento los rants, ¡mis notas son un ensayo contra Android Auto!). Sumándole Play Services y los controles de identidad, un cuarto de todo lo anotado. Sin auto, la mitad de este proyecto no existiría.

Uno tiene cierto grado de libertad. Apunta al 110% del dispositivo y llega al 80 y pico. En esa diferencia vive la frustración, y esa diferencia está justo en las grietas donde las piezas de Google se asumen entre sí: integración y dependencia del fabricante. Lo que probablemente la cerraría es lo mismo que me empujaría a traer de vuelta la tienda de Google y un poco más de sus servicios. Llegué a considerarlo.

¿Me di por vencido?

No. Di por terminado el experimento, que no es lo mismo.

La misión era desgooglear un celular sin root, sin flashear y sin cuenta de Google. Se cumplió: En 2026 todavía es posible y, con una batería al 76% de su capacidad real, logré más de 24 horas de autonomía. Los resultados pueden variar (YMMV, dirían en inglés), pero es posible.

Lo que volvió, no lo hizo por darme por vencido: volvió porque elegí qué ceder para obtener lo que necesitaba. Casi tres semanas, 228 acciones, 640 cambios de permisos y restricciones, 124 paquetes afuera y trece regresos, mientras continuaba con mi vida cotidiana, todo anotado.

“Uno a cero para Motorola”, escribí en la primera entrega. El partido terminó bastante más parejo.

El regreso del Jedi

El Motorola One Hyper no se va a un cajón. Le queda una última jugada: convertirse en la terminal (la parte que interactúa con el mundo) de un asistente de inteligencia artificial que estoy planeando.

Pero esa será otra historia.

Continuará.