Me divorcié de Google, parte 1: Cuando cambian las reglas del juego

En 2019 publiqué el prólogo de esta serie, con la promesa de una guía paso a paso para recuperar el control de nuestros dispositivos y nuestra privacidad. Para entonces ya llevaba casi nueve años haciéndolo. A partir de 2010 jugué con varios dispositivos: desde un Motorola Milestone 2, pasando por un Asus Zenfone 2 con un procesador como los que podría usar una computadora de escritorio, un Huawei P20 Pro que terminó en empate porque Huawei decidió que abrir el *bootloader* (el programa que decide qué sistema operativo puede arrancar) era mala idea, hasta el mismísimo Motorola One Hyper (que da lugar a este artículo) al que ya operé con distintos grados de éxito dado que se producían serios problemas en la batería y el sistema de gestión de energía. La guía que no llegó se llenó de polvo en mi cabeza mientras la aplicaba en un par de decenas de dispositivos con el correr de los años. Lo intenté documentar el año pasado; me quedó a medias. Este es el segundo intento de documentarlo, y esta vez como corresponde.

En octubre me propuse algo concreto: desgooglear una vez más el Motorola One Hyper, un celular de 2020 con Android 11, sin rootearlo, sin flashearlo y sin crearle jamás una cuenta de Google.

Por supuesto que lo volví a lograr. Con concesiones que elegí hacer, y con un celular que se defendió bastante más de lo que esperaba al entrar en un terreno que nunca antes había pisado: Android Auto.

La pregunta obligada: ¿por qué no le instalaste otro sistema?

Por la batería.

Las ROMs (en la jerga, es sinónimo de “sistema operativo” para celulares y otros pequeños dispositivos) que existen hoy para este modelo tienen problemas serios de consumo: el celular no logra entrar en reposo y la carga no dura. No estaba dispuesto a convivir con eso. Tampoco con el riesgo de que la instalación (flashear, como se le suele decir en el ambiente) termine convirtiendo el celular en un lindo pisapapeles: me pasó varias veces con el Zenfone, a tal punto que tras el brickeo (de brick, término en inglés que significa “ladrillo” y viene de la acción de volver inservible un dispositivo electrónico al convertirlo en algo inerte como un ladrillo) ya lo desbrickeaba de memoria y volvía a empezar. Hoy no tengo el tiempo ni los recursos para dedicarle.

El usuario root de un sistema operativo *NIX (Unix, Linux y derivados) es el único usuario del sistema al que nadie le puede decir que no*; en Android, “rootear”, implica lograr acceso a ese usuario, que viene normalmente restringido. Con ello se puede manipular el sistema a nuestro antojo, y lograr las cosas que las operadoras y Google no quieren. Rootear requiere abrir el bootloader y para ello en algunos casos el fabricante debe entregar un código de apertura (eso que Huawei no quería hacer), e implica el sistema operativo instalado a nuevo con un kernel modificado (es decir, la aplicación que ayuda a iniciar el sistema y toma el control de todo el hardware del dispositivo). Con los kernels modificados, y sobre todo con sistemas operativos alternativos, a veces llegan las incompatibilidades. En mi caso, la batería.

Así que fui por mi cuenta. Esta trilogía es lo que salió de eso.

*: Aplican términos y condiciones

Las reglas del juego

Partí de un celular recién reseteado de fábrica, y de cinco reglas:

• Sin root.
• Sin flashear.
• Sin cuenta de Google. Nunca. Ni siquiera “un ratito, para probar”.
• Cero fallas que afecten el uso diario. Si algo se rompe y lo noto en el día a día, es un fracaso.
• Todo reversible. Cualquier cambio tiene que poder deshacerse.

Y un requisito nuevo: Android Auto tenía que seguir funcionando. Uso el celular para tener mapas y navegación en la pantalla del auto. Esa línea va a tener protagonismo más adelante.

Todo el trabajo se hizo desde la computadora, por ADB: un centro de comandos que se conecta al celular por cable. Los reemplazos de las aplicaciones de Google salieron de F-Droid, el repositorio de software libre que ya presenté en el prólogo, y de Aurora Store, que descarga aplicaciones de Play Store (la tienda de software de Google) sin usar una cuenta propia.

Aquí entra una regla del juego nueva para compensar la balanza: Ya que la mitad de las ROMs de código abierto habían desaparecido y ahora me enfrentaba a un nuevo escenario con Android Auto, es que decido incorporar asistencia con Inteligencia Artificial utilizando contratos para definir reglas estrictas de trabajo.

Desgooglear, para este proyecto, significa tres cosas: ninguna cuenta de Google en el celular, las aplicaciones de Google afuera, y lo que no se pudiera sacar, neutralizado. Si no se puede neutralizar, mitigado. Si no se puede mitigar, contenido. Si no se puede contener, vigilado.

Complicaciones: el celular se defiende

Tenía un plan prolijo: sacar aplicaciones por tandas, reiniciar, verificar, seguir.

El celular tenía otra opinión.

Contexto: para Android, cada aplicación es un paquete, identificado por un nombre único como com.google.android.youtube. Voy a usar “aplicación” y “paquete” casi como sinónimos.

Los que no vuelven

La primera tanda fueron doce paquetes: las aplicaciones de redes sociales que venían preinstaladas, y varias de Google.

Sacar una aplicación del sistema sin root no la borra. Lo que hace es decirle a Android que la aplicación ya no está (aunque Android no se dé cuenta de que sigue ahí): la copia de fábrica queda guardada en la parte del sistema que no se toca, y se puede traer de vuelta con un comando; salvo que no haya copia de fábrica.

Esas aplicaciones de Google no venían en el sistema: las instaló el asistente de configuración inicial, en el mismo lugar donde se instala cualquier aplicación. Al sacarlas, Android borró su archivo de instalación (el APK) y no quedó nada para restaurar.

No era grave: se pueden volver a descargar. Pero me dejó la primera regla: antes de sacar algo, fijate dónde vive. Desde ese momento, cada paquete sin copia de fábrica quedó anotado en una lista aparte.

Y el primer rechazo: un paquete de Amazon respondió que no se puede desactivar (package is non-disable). Motorola no deja sacarlo ni desactivarlo. Venía desactivado de fábrica, así que quedó como estaba.

Uno a cero para Motorola. Seguimos.

Los que vuelven

Unos reinicios más tarde, todas las aplicaciones de Motorola (y también Lenovo, no nos olvidemos) que había sacado estaban de vuelta. Instaladas, funcionando, como si nada. Y no era la primera vez: ya habían vuelto en un reinicio anterior, y no lo había visto porque esa revisión sólo buscaba fallas.

El registro decía Success. El celular decía otra cosa. Desde entonces, si el registro y el celular no coinciden, el celular tiene razón.

Las hipótesis no tardaron en llegar. ¿Un mecanismo de Motorola que reinstala sus aplicaciones en cada arranque? ¿La falta de chip, que hace que el sistema vuelva a aplicar la configuración de la operadora? Probé tres formas distintas de neutralizar aplicaciones de Motorola (desinstalar, desactivar, suspender): las tres se deshacían al reiniciar.

La pista apareció de la forma más simple: saqué dos de esos paquetes a mano y reinicié desde el menú de apagado, como cualquier persona.

No volvieron.

La diferencia estaba en cómo reiniciaba. Yo venía usando adb reboot, que reinicia salteándose el apagado ordenado. Y en este modelo, Android recién guarda el estado de las aplicaciones de cada usuario durante ese apagado. Era como apagar la computadora desde la zapatilla: lo que no se guardó, se pierde.

La prueba de fuego fue repetir el procedimiento con un reinicio ordenado. Funcionó. Desde ahí, después de cualquier cambio, el primer reinicio es ordenado. Una vez que el estado está guardado, adb reboot ya no hace daño.

# Reinicio ordenado: Android guarda el estado antes de apagarse
adb shell svc power reboot

# Reinicio abrupto: en este modelo, se pierde lo que no se guardó
adb reboot

Queda un misterio: las aplicaciones de Google y de redes sociales que saqué en esas mismas tandas sí sobrevivieron a los reinicios abruptos. Por qué, no lo sé. Lo anoté y seguí.

Botones inservibles

Quería reemplazar la pantalla de inicio de Motorola (el menú de aplicaciones y el “escritorio” se llama launcher), como parte de esta misión de reducir la huella de telemetría que vuelve hacia Motorola o hacia Google. Para ello, instalé una alternativa libre, le asigné esa función y saqué la aplicación original: Inmediatamente dejó de funcionar el botón de aplicaciones recientes, el que muestra lo que está abierto.

En Android 11, la pantalla de recientes la provee un componente de la pantalla de inicio original, y una pantalla de inicio de terceros no puede reemplazarlo. Ya me había pasado en varias ocasiones; esperaba poder resolverlo con ayuda de inteligencia artificial. Otra vez Google decidiendo que tiene razón.

La solución fue traer de vuelta el launcher de Motorola, dejarlo en segundo plano y asignar la alternativa como principal. De esa manera, el botoncito de aplicaciones recientes puede volver a llamar a la funcionalidad que viene embebida en el launcher de Motorola y no necesariamente come los mismos recursos.

“No service”

Con el chip ya puesto, tocó limpiar los paquetes de la operadora. Había 4G con señal completa, y arriba, en la pantalla, el celular decía “No service”.

El celular funcionaba pero mentía sobre algo básicamente cosmético: Un paquete de Google (com.google.android.carrier) que, en este modelo, es el que le dice al sistema cómo mostrar el nombre de la operadora había sido desinstalado en el afán de hacer todo más liviano. Volvió al celular sólo por eso, y el nombre de la operadora volvió a aparecer. Minutos después lo desactivé, y el nombre siguió ahí, al menos hasta el próximo cambio de chip.

Método: trazabilidad antes que velocidad

Cada complicación dejó una lección, y cada lección fue a parar a un documento que existía desde el primer día y creció con cada hallazgo: AGENTS.md. Es el contrato bajo el cual trabajó el asistente de IA. Acá alcanza con lo esencial:

• La foto del antes. Antes del primer cambio, registramos el estado completo del celular: qué hay instalado, qué viene desactivado de fábrica, qué aplicación atiende cada función.
• Trazabilidad. Cada cambio queda anotado con el comando exacto, lo que respondió el celular, cómo se deshace y el estado en que quedó, leído del celular y no de la respuesta del comando.
• Tandas chicas. Después de cada una: reinicio ordenado, comparación entre el registro y el celular, y revisión de fallas en el registro de errores de Android, que sobrevive a los reinicios.
• El celular manda (a veces), como ya contó “Los que vuelven”.

Todo eso se resume en una propiedad: cualquiera que tenga sólo el registro y el celular tiene que poder saber qué cambió y volverlo atrás.

En menos de un día quedaron afuera 130 paquetes; al cierre eran 124, porque algunos tuvieron que volver. El registro terminó con 228 acciones y 640 cambios de permisos y restricciones. Todos los que dejan algo cambiado en el celular tienen su forma de deshacerse.

Quitar sin romper

El par de comandos que sostiene todo el proyecto:

adb shell pm uninstall -k --user 0 com.ejemplo.app      # "ya no está" (para el usuario principal)
adb shell pm install-existing --user 0 com.ejemplo.app  # "volvé"

-k conserva los datos de la aplicación; --user 0 aplica el cambio sólo al usuario principal. El original sigue intacto en la parte del sistema que no se toca: un reseteo de fábrica trae todo de vuelta.

El detalle técnico, con los comandos, va a vivir en un repositorio público.

Existe una escalera, siempre en el mismo orden:

1. Desinstalar para el usuario. Es la opción por defecto.
2. Desactivar, sólo si el celular se niega a desinstalar.
3. Restringir lo que la aplicación puede hacer, sólo si se niega a las dos cosas. De eso trata la parte 2.

El caso más interesante de los que se negaron a ser desinstalados fue el actualizador del sistema de Motorola: protegido, imposible de desinstalar o desactivar. Lo neutralicé restringiéndolo al máximo. Efecto colateral: en cada arranque intenta iniciarse, Android no lo deja, y queda registrada una falla, una sola vez por arranque, sin consecuencias visibles. Lo acepté. Sin actualizador no llegan actualizaciones del sistema, y esa decisión quedó anotada como tal.

Otras dos lecciones de esta etapa:

• Primero el reemplazo, después la baja. Antes de sacar la aplicación de teléfono, la de mensajes o la pantalla de inicio, instalé el reemplazo y le asigné la función (Android lo llama rol: qué aplicación atiende las llamadas, cuál los mensajes, cuál la pantalla de inicio). Recién después saqué la original. Lo de recientes enseñó que además hay que revisar quién depende de la aplicación.
• Play Store, sin cuenta, igual trabaja. Se actualizaba sola y, de paso, actualizaba aplicaciones del sistema. Salió esa misma noche.

Lo que queda

Hay cosas que no se pueden sacar: piezas protegidas, componentes de los que depende otra cosa, partes del propio sistema. Pero pueden volverse tan inertes como el sistema lo permita.

Ahí empieza la negociación.

Porque el requisito del principio seguía en pie: Android Auto. Y Android Auto necesita Google Play Services, el sistema nervioso del sistema.

¿Cuánto de Google hay que dejar volver para que el mapa aparezca en la pantalla del auto?

Continuará.