Cuando compras un nuevo teléfono o tableta Android, lo que más esperas es ver qué nos depara Google en el dispositivo. Sin embargo, ¿y si lo que no quieres es utilizar los servicios de Google o sus aplicaciones por preocupaciones sobre tu privacidad? Android es de código abierto, así que nada te pare de hacer justo eso, abandonar la “relativa” seguridad de Google y utilizar una ROM AOSP.
¿Alguna vez te has preguntado cómo sería utilizar Android sin Google? Nos referimos al ecosistema de Google que acompaña a prácticamente todas las ROMs disponibles, es decir, a las aplicaciones y herramientas que todos utilizamos como Gmail, la tienda de aplicaciones Play Store, Maps… Lo cierto es que normalmente las tenemos en cuenta como parte de Android, pero lo cierto es que técnicamente no lo son. La plataforma, por sí misma, es de código abierto y es mantenida por el Android Open Source Project (AOSP) donde claro está, Google es el mayor contribuidor. No obstante, las aplicaciones y servicios de esta compañía son propietarios y muchos usuarios no están cómodos con estos instalados en su terminal, lo que podría ser una razón para que alguien quiera utilizar un Android libre de Google.
Una versión AOSP Android es diferente de una versión “stock” ya que esta última, que es la que tienen por ejemplo los Nexus y los dispositivos Google Play Edition, ya cuentan con los servicios de Google, mientras que la versión AOSP plana tan solo trae consigo características como el marcador, el navegador, el calendario, el teclado o la aplicación de mensajería. Muchas de ellas son algo más antiguas de las que obtendríamos con una versión de Google, pero no hay problema ya que AOSP contiene un sistema operativo repleto de características.
Convirtiéndose en un Android libre de Google
Lograr esto es más fácil en algunos dispositivos que en otros. Antes de nada se necesita tener el bootloader desbloqueado así como instalado un recovery custom, por lo que un Nexus 5 puede prepararse en apenas un par de minutos. El propósito final de este proceso es conseguir reemplazar todo el software de Google en el dispositivo por algo libre de las influencias de la compañía, por lo que lo mejor es conseguir una versión de Android que nosotros queramos, como KitKat 4.4, desde el proyecto AOSP sin ningún tipo de modificación (en este enlace, por ejemplo, encontramos las imágenes para los Nexus).
Más allá de desbloquear, es recomendable hacer copia de seguridad completa (datos, fotos, mensajes y particiones críticas si sabes cómo) y verificar la compatibilidad del dispositivo con la ROM o el método que vas a usar. Ten en cuenta que VoLTE/VoWiFi, NFC o la cámara pueden requerir blobs propietarios y configuraciones del operador, por lo que conviene revisar hilos técnicos en XDA y la wiki del proyecto elegido.
Arrancar con una ROM AOSP es un poco chocante si estamos acostumbrados a Android desde hace tiempo ya que faltan distintos detalles, aunque en general, es muy semejante. No obstante, el navegador para acceder a internet, por ejemplo, tiene un aspecto parecido al de Android 4.0, y mejor olvidarse de aplicaciones como el reproductor de música. La primera parada recomendable es la instalación de F-Droid, un repositorio de aplicaciones gratuitas de código abierto. Se instala como una aplicación y encontraremos software interesante como K9 Mail, un potente pero poco intuitivo cliente de correo electrónico, el reproductor de música Apollo y uno de los widgets más interesantes, Dashclock. Incluso podemos instalar Duck Duck Go como cliente de búsqueda alternativo a Google.
Lamentablemente, la cada vez mayor dependencia de los Servicios de Google Play provoca que muchas aplicaciones no funcionen con nuestra ROM AOSP incluyendo cosas como escáners de malware, localización de dispositivos… Otra opción es la de descargar APKs por internet, pero necesitaremos ser especialmente cuidadosos ya que es como instalar EXEs “extraños” en nuestro ordenador con Windows. Recordad que el escáner anti-malware de Google viene incluido en los servicios de Google Play, que no tendremos en nuestro sistema operativo, por lo que debemos extremar la preocupación –no obstante, como ya sabemos, en muchas ocasiones se nos dice que un APK tiene malware cuando en realidad lo único que hemos hecho es descargarlo de una página web oficial y no de la Play Store-.
Otra opción para encontrar buenas aplicaciones es la Tienda de aplicaciones de Amazon ya que cuenta con una increíble variedad, interesante y sobre todo, fiable. De esta forma seremos capaces de utilizar servicios como Dropbox, algo fundamental actualmente.
Herramientas automatizadas para crear ROMs: ScriBt
Si tu objetivo es crear tu propia ROM personalizada a partir de fuentes AOSP o proyectos derivados, existen utilidades que agilizan el flujo. Una de las más completas es ScriBt, concebida como una “navaja suiza” para cocineros y aspirantes. Esta herramienta puede crear y sincronizar repositorios, realizar la preparación previa a la compilación y lanzar la construcción de la ROM con menos pasos manuales. Además, incluye instaladores de dependencias (Java, ADB y paquetes del sistema) y utilidades útiles para adaptar ROMs a dispositivos concretos, facilitando puertos a partir de árboles de dispositivo compatibles.
ScriBt está pensada para dos perfiles: quienes ya compilan ROMs y quieren automatizar tareas repetitivas, y quienes empiezan y necesitan una guía operativa. Aunque reduce la fricción, requiere conocimientos mínimos de repos, ramas, árboles de dispositivo y resolución de errores. El proyecto suele alojarse y documentarse en foros de desarrollo como XDA, y en ocasiones se publica en fase beta; conviene leer bien la documentación antes de usarla.
Requisitos previos y entorno de compilación
Ya uses herramientas automatizadas o manuales, los requisitos suelen ser similares: PC de 64 bits con Linux, buena conexión a Internet y mucha capacidad de disco (el árbol completo de una ROM puede ocupar decenas de GB; usar SSD acelera mucho). Asegúrate de tener Java adecuado, Git, Python, ADB/fastboot y el comando repo configurados en el PATH. La RAM importa: 16 GB o más hacen la diferencia; con menos puede compilar, pero será más lento.
Además, necesitarás el código fuente del kernel del fabricante, el device tree y los blobs propietarios (bibliotecas binarias) del dispositivo. Muchos fabricantes publican el kernel, pero el árbol de dispositivo suele extraerse de la ROM stock. Proyectos como TheMuppets recogen vendors propietarios para multitud de modelos; puedes añadir el repositorio del vendor o clonar el correspondiente a tu marca para que la compilación encuentre los blobs.
Compilar una ROM basada en LineageOS: pasos clave
LineageOS mantiene una wiki con instrucciones claras por dispositivo. A modo de síntesis: inicializa el repositorio con repo init apuntando a la rama adecuada, sincroniza con repo sync (puede tardar horas la primera vez), carga el entorno con source build/envsetup.sh y selecciona el dispositivo con breakfast <codename>. Si faltan blobs, incorpora el vendor (por ejemplo, clonando el repositorio de TheMuppets) y repite el paso de breakfast.
Activa la caché de compilación con ccache para acelerar reconstrucciones y lanza brunch <codename> para construir. Al finalizar, el archivo ZIP flasheable aparece en out/target/product/<codename>. Cada nueva sesión conviene comenzar con repo sync, volver a source del entorno y recompilar. Ten presente que la primera compilación es la más lenta; a partir de ahí, con ccache y cambios incrementales, mejora mucho.
¿Qué pasa si quiero “cocinar” sin compilar desde cero?
Existen acercamientos más artesanales centrados en modificar una ROM base sin compilar todo el sistema. En Windows, herramientas como dsixda Android Kitchen (funciona sobre Cygwin) permiten desempaquetar una ROM, alterar su contenido y volver a empaquetarla. Esto facilita operaciones como añadir/eliminar apps del sistema (system/app), ajustar build.prop, actualizar la carpeta META-INF para que el ZIP sea flasheable, cambiar bootanimation o personalizar tonos, fuentes y temas. Son métodos útiles para aprender, pero recuerda que no sustituyen a una compilación limpia cuando buscas cambios profundos o saltos de versión.
En este enfoque manual conviene usar editores como Notepad++ para evitar dañar los finales de línea, conocer el updater-script y respetar permisos. Para dispositivos que requieren archivos específicos (por ejemplo, variaciones en boot.img o peculiaridades de fabricantes), consulta siempre guías por modelo. Aunque veteranas, estas cocinas aún sirven de introducción a la estructura de una ROM.
Instalar apps sin Google Play: repos, tiendas y seguridad
F-Droid es el repositorio de referencia para software libre; allí encontrarás clientes como K-9 Mail, navegadores, reproductores y widgets. Además, tiendas alternativas como Amazon Appstore cubren aplicaciones populares que no están en F-Droid. Si decides descargar APKs desde la web, verifica firmas, usa fuentes oficiales y considera un antimalware de terceros si lo crees necesario, ya que Play Protect no estará en tu sistema. También puedes usar clientes que actúan como interfaz de Play sin GMS en el dispositivo, siempre valorando su política de privacidad y procedencia.
MicroG, ROMs sin Google y soporte de operadoras
Para quienes desean más compatibilidad de apps sin instalar GMS, microG implementa de forma libre partes de los Servicios de Google Play. Algunas ROMs lo integran de serie o facilitan su instalación (por ejemplo, LineageOS con microG o proyectos enfocados en privacidad como /e/OS). Cada una equilibra privacidad, compatibilidad y actualizaciones de forma distinta: AOSP puro es lo más “limpio”, microG mejora la compatibilidad manteniendo control, y otras roms añaden servicios alternativos de ubicación y nubes propias.
Respecto a las operadoras, usar una ROM personalizada no suele impedir que tu SIM funcione. Las redes móviles se negocian por el módem/firmware de radio y la tarjeta; lo que sí puede requerir ajustes son VoLTE/VoWiFi, IMS o el tethering según el APN y las políticas del operador. Es buena práctica guardar la configuración APN original, y revisar si tu ROM soporta las bandas y perfiles de tu región.
Cómo trabaja la comunidad y qué limita una ROM
Detrás de cada ROM hay equipos de desarrolladores y testers que se organizan en remoto. Suelen repartirse tareas como mantenimiento por dispositivo, desarrollo del kernel, integración de parches y verificación de errores. Tras las compilaciones, los testers prueban funciones clave (cámara, llamadas, WiFi, BT) antes de publicar.
Para soportar un nuevo dispositivo, es imprescindible que se pueda desbloquear el bootloader y que el fabricante libere el código fuente del kernel. El device tree se adapta a cada hardware, y lo más delicado suele ser la cámara, ya que depende de blobs, HALs y cambios de API entre versiones de Android. Además, mecanismos de integridad como SafetyNet/Play Integrity pueden limitar apps bancarias o de pagos en ROMs personalizadas; existen parches y módulos, pero su éxito varía con el tiempo y las políticas de cada servicio.
Glosario básico para orientarte
- ADB: puente de depuración para comunicar PC y dispositivo, instalar apps o acceder a shell.
- AOSP: base de código abierto de Android, sin apps/servicios propietarios de Google.
- Bootloader: cargador de arranque; desbloquearlo permite flashear ROMs/recoveries.
- Recovery: entorno de rescate/instalación (TWRP u otros) para flashear ZIPs y wipes.
- Kernel: núcleo del sistema; cada dispositivo necesita su versión y configuración.
- Device tree: configuración y código específico del hardware de un modelo.
- Blobs: bibliotecas propietarias sin código fuente necesarias para hardware (cámara, radio…).
- ROM stock/custom: la ROM de fábrica frente a una personalizada con cambios o mejoras.
- GApps/microG: paquetes con servicios de Google o su implementación libre.
¿Deberíamos hacerlo?
Desde mi punto de vista, no es necesario. Google ha conseguido crear una suite de aplicaciones excelente, con un funcionamiento realmente pulido y actualizado constantemente. Claro está, si somos unos “locos” de la privacidad, la instalación de Android AOSP es una buena opción, pero no creo que valga la pena. Eso sí, es un experimento muy curioso y que nos permitirá ver otra vertiente del sistema operativo y comprobar que podemos vivir sin Google.
Vía Geek.
Si te atrae la idea, empieza por un dispositivo bien documentado, lee las wikis oficiales, prepara el entorno y elige si compilarás o “cocinarás” sobre una base. Con herramientas como ScriBt, repos de vendors como TheMuppets, repositorios de apps libres como F-Droid y opciones intermedias como microG, es posible equilibrar privacidad, funcionalidad y control sin renunciar a una buena experiencia.