---
title: "Un Pixel 3a europeo con Linux: lo que Google abandonó en 2022 hoy corre un núcleo de 2026"
subtitle: "Una hora perdida en cuatro pistas falsas, una línea en /sys que da la respuesta, y un teléfono con la pantalla rota convertido en máquina de desarrollo"
description: "Un Pixel 3a europeo (G020F), última actualización de Google en mayo de 2022, restablecido de fábrica y con la pantalla rota. En una tarde: postmarketOS con un núcleo Linux mainline 7.1.3, Phosh, acceso SSH por el cable USB. El relato completo — por qué el núcleo mainline y no Ubuntu Touch, el desbloqueo del gestor de arranque, y la hora perdida culpando al cable cuando el responsable era la suspensión automática USB del núcleo, reaplicada por TLP. Y por qué no es solo un pasatiempo: Chat Control, la verificación de edad, y el documento de identidad que Google exigirá pronto a los desarrolladores para que podamos instalar sus aplicaciones."
date: 2026-09-07
image: images/pixel3a/og-pixel3a.jpg
tags: [pixel 3a, postmarketos, linux mainline, sdm670, obsolescencia, fastboot, suspensión usb, tlp, libcamera, phosh, software libre, derecho a reparar, chat control, verificación de edad, soberanía digital, grapheneos, privacidad]
slug: pixel-3a-postmarketos-linux-mainline
lang: es
---
# Un Pixel 3a europeo con Linux: lo que Google abandonó en 2022 hoy corre un núcleo de 2026
## Una hora perdida en cuatro pistas falsas, una línea en /sys que da la respuesta, y un teléfono con la pantalla rota convertido en máquina de desarrollo
**En dos minutos**
- **Punto de partida**: un Pixel 3a de 2019, modelo europeo G020F, última actualización de seguridad el 5 de mayo de 2022, pantalla rota, restablecido de fábrica. Oficialmente: un residuo.
- **Punto de llegada**, unas horas después: **postmarketOS** con un **núcleo Linux 7.1.3 mainline** — no un núcleo Android remendado, el de verdad —, el entorno Phosh, las dos cámaras detectadas y acceso `ssh` por el simple cable USB.
- **La decisión que importa**: Ubuntu Touch hace que todo funcione mejor, pero se apoya en controladores Android congelados. postmarketOS hace funcionar menos cosas, sobre código que se puede corregir y enviar aguas arriba. Para quien quiera contribuir, es la única opción.
- **La hora perdida**: `fastboot` se quedaba colgado sin un solo mensaje. Culpé sucesivamente a los permisos, al cable, al puerto USB y a la versión del binario. Las cuatro eran falsas. El responsable: **el núcleo duerme la interfaz USB tras dos segundos**, el gestor de arranque del Pixel no sabe despertar — y **TLP** deshacía mi corrección en silencio.
- **Lo que eso revela**: esta trampa no está documentada en ninguna parte. Quien la encuentra concluye que su cable está muerto y abandona. Una corrección de dos líneas lo resuelve, para todos los Pixel.
- **Lo que viene**: `cam -l` reproduce un fallo conocido de libcamera desde el primer arranque — y revela un segundo, más fácil, que nadie había reportado.
- **¿Y tu teléfono?** postmarketOS cubre 39 aparatos en `community` (catorce de ellos teléfonos) y 149 en `testing`; Ubuntu Touch anuncia 111. Las tablas completas, [más abajo](#y-tu-telefono).
*Este artículo pretende leerse sin saber nada de Android ni de Linux: cada término técnico se explica la primera vez que aparece. Los recuadros «Para profundizar» se despliegan para quien quiera los comandos exactos.*
*La parte trasera del aparato. «Model G020F» — la variante europea. Al lado, el marcado CE y el contenedor tachado, ese pictograma que significa «no tirar con la basura doméstica». Han hecho falta siete años para que ese símbolo dejara de ser un trámite y se convirtiera en el tema.*
## Qué significa realmente «fin de soporte»
El Pixel 3a salió en mayo de 2019. Era el sensato de su generación: una cámara notable por 400 €, un conector de auriculares que los buques insignia ya habían suprimido, un procesador Snapdragon 670 sin pretensiones. Google lo actualizó hasta el **5 de mayo de 2022**. La última versión instalada en este lleva el número `SP2A.220505.008` — Android 12, parche de seguridad de mayo de 2022.
Desde entonces, nada. No porque el hardware haya fallado: funciona perfectamente. Porque una empresa decidió que un plazo se había cumplido.
«El dispositivo ya no tiene soporte» es una frase que se lee sin pensarla. Traduzcámosla. El procesador, la pantalla, las cámaras, el módem, la batería — todo eso sigue funcionando. Lo que se detiene es un servicio: alguien, en algún sitio, deja de compilar software para esa combinación concreta de chips. El teléfono no se vuelve defectuoso, se vuelve **huérfano**. Y como el software que ejecuta no lo puede modificar su propietario, huérfano significa condenado.
Salvo que este era un Pixel. Y los Pixel tienen una propiedad rara: Google, a diferencia de casi todos sus competidores, permite al propietario **desbloquear el gestor de arranque** — el pequeño programa que decide qué sistema operativo tiene derecho a iniciarse. Ese permiso, sobre el que volveré, es lo que separa un aparato recuperable de un ladrillo.
Para profundizar: qué bloquea exactamente un gestor de arranque
Cuando un teléfono se enciende, un programa diminuto grabado en el chip arranca primero, verifica una firma criptográfica sobre el sistema que viene a continuación y se niega a seguir si no coincide. Es el *arranque verificado* (**verified boot**), y es algo bueno: impide que un software malicioso reemplace tu sistema a tus espaldas.
El problema no es el mecanismo, es **quién tiene la llave**. En un aparato bloqueado, solo el fabricante puede firmar un sistema. El día en que deja de producirlos, la cerradura sigue ahí, pero ya nadie tiene la llave. La seguridad se convierte en una condena.
Google deja que el propietario desactive ese control, con un aviso bien visible y un borrado completo de los datos por el camino — que es la forma correcta de hacerlo, ya que un ladrón no puede desbloquear sin destruirlo todo. Las variantes vendidas por ciertos operadores estadounidenses, en cambio, están selladas de forma definitiva. La diferencia no es técnica: es comercial. En la trasera del mío, «G020F» significa *Rest of World*, la versión europea. Vendida sin operador, por tanto desbloqueable.
## Tres maneras de poner Linux en un teléfono, y solo una que cuenta aquí
Un teléfono Android ya ejecuta un núcleo Linux. Pero un núcleo Android es una versión antigua del núcleo oficial, a la que el fabricante del chip ha añadido miles de modificaciones que nunca publica aguas arriba. Ese código solo vive lo que dura el producto. Ahí está toda la diferencia entre las tres opciones que había:
| | postmarketOS | Ubuntu Touch | Droidian |
|---|---|---|---|
| Base | **núcleo Linux mainline** | controladores Android congelados (Halium) | controladores Android congelados |
| En el Pixel 3a | categoría *community* | versión estable, muy pulida | funcional |
| Llamadas, cámara, huella | parcial | **todo funciona** | parcial |
| Esperanza de vida | la de Linux | la de los controladores de 2019 | ídem |
| Corregible aguas arriba | **sí** | no | no |
Ubuntu Touch es objetivamente la mejor opción para *usar* este teléfono: llamadas, SMS, 4G, Bluetooth, NFC, las dos cámaras, el lector de huella — todo funciona. Pero lo consigue reutilizando los controladores binarios de Android 9. Es decir, embalsamando 2019. Nada de lo que allí se corrija beneficia a nadie más, y el día en que esa base se pudra, no habrá nada que hacer.
postmarketOS toma el camino inverso: hacer funcionar el **núcleo Linux oficial**, el que usa todo el mundo, sobre este chip. Es más difícil, faltan cosas, y ahí está precisamente el interés — lo que se escribe allí sube al núcleo que el mundo entero usará dentro de diez años. Un grupo de desarrolladores se dedica específicamente a este procesador, bajo el nombre **sdm670-mainline**.
La elección era pues sencilla, a condición de asumir lo que implica: este teléfono no será mi teléfono. Es un banco de pruebas.
## El desbloqueo, y la trampa del teléfono restablecido
El aparato llegó restablecido de fábrica, lo que parecía simplificar las cosas. No fue así.
Para desbloquear el gestor de arranque hay que activar una opción llamada **Desbloqueo de OEM** en los ajustes de Android. Ahora bien, esa opción permanece atenuada mientras el teléfono no haya alcanzado la red al menos una vez: Google comprueba que el aparato no esté denunciado como robado. Hay que encender el teléfono, atravesar el asistente de configuración, conectar el Wi-Fi — y solo entonces activar la opción. En un aparato que uno se dispone a borrar por completo, es un rodeo absurdo pero obligatorio.
Segunda trampa, más traicionera: la combinación de teclas para entrar en modo *fastboot* — el modo de mantenimiento del gestor de arranque — es **Bajar volumen + Encendido**, pero **únicamente desde un teléfono completamente apagado**. En un aparato encendido, esa misma combinación hace una captura de pantalla. Uno pulsa, no ocurre nada de lo esperado, vuelve a intentarlo y empieza a dudar de su hardware. Hay que apagar, esperar dos segundos, mantener Bajar volumen *primero*, y luego pulsar Encendido.
El resto cabe en un comando, y un aviso rojo en pantalla que hay que confirmar con los botones físicos:
```
fastboot flashing unlock
```
*La pantalla de fastboot después de la operación. «Device state: unlocked» en rojo: el teléfono acepta ya arrancar un sistema que Google no ha firmado. Nótese «sargo MP1.0 (ROW)» — sargo es el nombre en clave del Pixel 3a, ROW confirma la variante internacional.*
El teléfono lo borra todo y se reinicia. A partir de ahí, ya no pertenece del todo a Google.
## Preparar el sistema: media hora de preguntas
Del lado del ordenador, postmarketOS se construye con una herramienta llamada `pmbootstrap`, disponible en los repositorios de la mayoría de las distribuciones. No descarga una imagen ya hecha: ensambla el sistema para tu aparato concreto, en un entorno aislado, haciéndote una veintena de preguntas.
La mayoría admiten la respuesta por defecto. Tres merecen reflexión, y resolví las tres con el mismo principio: **ceñirse a lo que prueban los mantenedores.**
Es un principio que merece explicitarse, porque es contraintuitivo. Cuando uno instala un sistema para sí mismo, elige lo que prefiere. Cuando lo instala para contribuir, cada desviación respecto de la elección mayoritaria es una variable más que hará inservibles tus informes de fallo. Si reporto un problema de audio sobre una pila que nadie más usa, el mantenedor no puede ni reproducirlo ni compararlo. Mi informe se convierte en ruido.
Así que tomé `pulseaudio` en vez del más moderno `pipewire`, `wpa_supplicant` en vez de `iwd`, el entorno **Phosh** en vez del muy tentador `sxmo`, y — a regañadientes — systemd. Sobre esto último, postmarketOS es uno de los pocos sitios donde OpenRC sigue siendo un ciudadano de primera clase; mi reflejo no tenía nada de marginal. Pero cuatro de los quince fallos abiertos para este aparato están reportados bajo Phosh con systemd, y `journalctl` sigue siendo lo más cómodo para extraer una traza limpia.
Dos respuestas merecen una advertencia.
**No activar el cifrado del disco.** La opción está ahí, es tentadora, y en este teléfono deja el aparato sin poder arrancar: un fallo abierto describe un sistema que no detecta la escritura de la contraseña durante el arranque. Uno acaba con una máquina que pide una frase de paso imposible de teclear.
**Mantener la configuración regional en inglés.** Contraintuitivo para un blog francófono, pero los mensajes de error y los registros saldrán en inglés, y por tanto podrán pegarse directamente en un informe y compararse con los de los demás. No impide en absoluto tener un teclado AZERTY.
Para profundizar: las respuestas exactas y los paquetes que llevar
```
Channel edge # donde se reportan los fallos y aterrizan las correcciones
Vendor google
Device sargo
UI phosh
Audio backend pulseaudio # por defecto
WiFi backend wpa_supplicant # por defecto
usb-moded developer # red USB SIEMPRE activa — el cabo de seguridad
Service manager default # systemd para Phosh
Locale en_US
```
La elección `usb-moded: developer` merece subrayarse: mantiene una interfaz de red activa sobre el cable USB de forma permanente. Cuando la pantalla deje de responder — y ocurrirá —, `ssh` por el cable será la única manera de entrar a recoger los registros. La otra opción, `charging`, exigiría activar la red a mano desde un teléfono posiblemente inutilizable.
Como paquetes adicionales, llevé con qué trabajar desde el primer arranque:
```
libcamera-tools,v4l-utils,evtest,tmux,vim,strace,usbutils
```
`libcamera-tools` proporciona el comando `cam`, que es precisamente la herramienta citada en el fallo de cámara que quería reproducir. `v4l-utils` proporciona `v4l2-ctl`, el instrumento de medida de la corrección buscada. `evtest` sirve para los fallos táctiles. `tmux` permite que una sesión SSH sobreviva a la desconexión del cable.
Una observación de método: **no adivines los nombres de los paquetes.** Alpine, la distribución sobre la que se apoya postmarketOS, no siempre los nombra como tu distribución habitual. Un nombre erróneo hace fracasar la instalación tras varios minutos. El índice es público y se comprueba en diez segundos:
```bash
curl -s -o idx.tar.gz \
"https://dl-cdn.alpinelinux.org/alpine/edge/community/aarch64/APKINDEX.tar.gz"
tar xzf idx.tar.gz -O APKINDEX | grep '^P:' | sed 's/^P://' > paquetes.txt
grep -qx "libcamera-tools" paquetes.txt && echo presente
```
Así descubrí que `device-tree-compiler` se llama `dtc` en Alpine.
*Lo cual no dice nada en español. En argot francés, `dtc` es una abreviatura que no le dirías a tu madre, y sí, releí el comando dos veces antes de ejecutarlo.*
Media hora después, el sistema estaba construido. Quedaba escribirlo en el teléfono. Ahí es donde la tarde se torció.
## Una hora culpando al responsable equivocado
El teléfono estaba en modo fastboot, conectado, reconocido. El comando de escritura arrancaba — y se quedaba colgado. Indefinidamente. **Sin el más mínimo mensaje de error**, ni en la salida estándar ni en la de error. Un proceso dormido, para siempre.
Lo desconcertante era que el aparato parecía perfectamente presente:
```
$ fastboot devices
058AY1WZGT fastboot
```
Respondía. Estaba ahí. Y sin embargo toda escritura se bloqueaba.
Formulé cuatro hipótesis. Las cuatro eran falsas, y descartarlas me llevó una hora. Merece la pena enumerarlas, porque son exactamente las que formularía cualquiera.
**Un problema de permisos.** La hipótesis clásica: el nodo USB pertenece a `root`, el usuario no tiene derecho a escribir en él. Verificado: el fichero llevaba una lista de control de acceso que concedía explícitamente el acceso a mi cuenta. Descartado por la medida, no por la suposición.
**Un cable o un puerto defectuosos.** Es el reflejo siguiente, y el más extendido en los foros. Salvo que los registros del núcleo estaban impecables: enumeración a alta velocidad, ningún error, ninguna reinicialización, ninguna desconexión intempestiva. Un cable dañado deja rastro; no había ninguno.
**Un problema de controladora USB.** Pista seria: los Pixel solo tienen USB 2.0, y las controladoras modernas tienen fama de caprichosas con ciertos gestores de arranque. El consejo habitual es «conéctalo a un puerto USB 2.0». Dos medidas lo descartaron: el teléfono ya negociaba a 480 megabits, es decir ya en USB 2.0, y la placa base de la máquina (una Raptor Lake de Intel) ya no tiene controladora de generación anterior — todo pasa por el mismo bloque. «Cambiar a un puerto USB 2.0» no tenía sentido.
**Una regresión del software.** `pmbootstrap` ejecuta su propia copia de `fastboot`, en versión 37, mientras que mi sistema tenía la versión 35. Así que salté la herramienta y flasheé directamente con la del sistema. **Se colgó exactamente igual.** Hipótesis muerta.
Cuatro pistas, cuatro callejones sin salida. Y un detalle que debería haberme alertado mucho antes: en cada nueva entrada en modo fastboot, **el primer comando pasaba** — en trece milisegundos — y todos los siguientes se colgaban.
Tenía ese hecho delante desde el principio. Tardé una hora en escucharlo, porque seguía interrogando al aparato en lugar de interrogar al sistema.
## La respuesta cabía en un fichero
El modo fastboot es un diálogo: el ordenador pregunta, el gestor de arranque responde. Acabé mirando no lo que respondía el teléfono, sino **lo que el núcleo Linux pensaba de él**. Esa información vive en `/sys`, un sistema de ficheros virtual donde el núcleo expone su estado interno en forma de ficheros legibles.
```
$ cat /sys/bus/usb/devices/1-9/power/control
auto
$ cat /sys/bus/usb/devices/1-9/power/autosuspend_delay_ms
2000
$ cat /sys/bus/usb/devices/1-9/power/runtime_status
suspended
```
**Dormido.**
Para ahorrar energía, el núcleo suspende los periféricos USB tras un plazo de inactividad — aquí, dos segundos. Es un comportamiento normal y deseable para la mayoría de aparatos, que saben despertar cuando se les vuelve a hablar. **El gestor de arranque del Pixel no sabe.** Una vez dormido, ya no responde nunca.
Todo encaja de golpe:
| Lo que observaba | Lo que ocurría |
|---|---|
| El primer comando pasa, los siguientes se cuelgan | El teléfono se duerme en el intervalo |
| `fastboot devices` lo lista igualmente | La enumeración está en caché, no requiere intercambio |
| El desbloqueo había funcionado | Era el primer comando tras entrar en fastboot |
| Salir y volver a entrar en fastboot «arreglaba» | Una nueva enumeración despierta el aparato, para un comando |
| Las dos versiones de `fastboot` fallaban igual | El binario no tenía nada que ver |
| Los registros del núcleo seguían limpios | La suspensión no es un error, es el funcionamiento normal |
La corrección es una regla de tres líneas, que pide al núcleo no dormir nunca los aparatos Google:
```
# /etc/udev/rules.d/52-fastboot-no-autosuspend.rules
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", \
TEST=="power/control", ATTR{power/control}="on"
```
Salvo que no cambió nada. Y la razón de ese fracaso es la parte más interesante de la historia.
## El segundo responsable, agazapado tras el primero
Mi regla era correcta — la herramienta de diagnóstico de udev confirmaba que se evaluaba y se aplicaba bien. Pero tras cada conexión, el ajuste volvía a `auto`.
Alguien pasaba detrás de mí. Ese alguien se llamaba **TLP**, un gestor de energía muy extendido en los portátiles Linux, que aplica sus propios ajustes de suspensión USB *después* de udev, y sobrescribe por tanto los tuyos en silencio. Mucha gente lo instala una vez para ganar autonomía y luego se olvida por completo.
TLP tiene precisamente una opción prevista para este caso:
```
# /etc/tlp.conf
USB_EXCLUDE_PHONE=1
USB_DENYLIST="18d1:4ee0 18d1:4ee1 18d1:4ee2 18d1:4ee3 18d1:4ee7"
```
Esta vez el ajuste aguantó. Un detalle que conviene saber: **aplicar la corrección no desbloquea un aparato ya dormido.** El estado USB del gestor de arranque solo se repara al reenumerar. Hay que corregir, *y luego* salir y volver a entrar en modo fastboot.
Y para maximizar las probabilidades, agrupé las tres escrituras en una sola invocación, en lugar de tres procesos sucesivos:
```bash
fastboot flash vbmeta vbmeta.img \
flash boot boot.img \
flash userdata google-sargo.img
```
```
Sending 'vbmeta_b' (4 KB) OKAY [ 0.120s]
Writing 'vbmeta_b' OKAY [ 0.071s]
Sending 'boot_b' (28008 KB) OKAY [ 0.747s]
Writing 'boot_b' OKAY [ 0.194s]
Sending sparse 'userdata' 1/9 (258751 KB) OKAY [ 6.306s]
...
Finished. Total time: 94.883s
```
Noventa y cinco segundos. Tras una hora de bloqueo.
Para profundizar: diagnosticar un fastboot que se cuelga
Tres reflejos, en este orden:
**1. Comprobar que el aparato está realmente ahí antes de interpretar nada.** Un `< waiting for any device >` significa a menudo que el teléfono simplemente ha salido del modo fastboot, no que haya un problema de acceso. Estuve a punto de concluir que había un problema de permisos invertido a partir de una prueba en la que el aparato estaba en realidad ausente.
```bash
lsusb | grep 18d1
```
**2. Mirar el estado del núcleo, no solo la salida del comando.**
```bash
cat /sys/bus/usb/devices//power/runtime_status
```
**3. Inspeccionar el proceso colgado.** Dice si ha abierto el periférico — en cuyo caso espera una respuesta que no llegará — y en qué entorno se ejecuta:
```bash
sudo readlink /proc//root # ¿se ejecuta en un chroot?
sudo ls -l /proc//fd | grep usb # ¿ha abierto el periférico?
```
Dos trampas del intérprete de comandos con las que tropecé, y que me costaron tiempo:
- `rc=$?` después de una tubería captura el código del **último eslabón**, nunca el de `timeout`. Mi sonda de diagnóstico mostraba por tanto «OK» en comandos que se colgaban. Redirigir a ficheros y comprobar directamente, o usar `set -o pipefail`.
- `pkill -f 'un patrón'` mata al intérprete que lo llama cuando el patrón figura en su propia línea de comandos. Mejor un bucle sobre `pgrep -x`.
## Lo que arrancó
Veinte segundos después del reinicio, la máquina vio aparecer una interfaz de red. El teléfono repartía él mismo las direcciones.
```
$ ssh sam@172.16.42.1
$ uname -r
7.1.3-sdm670
$ df -h /
/dev/loop0p2 47.9G 2.2G 43.2G 5% /
```
**Núcleo 7.1.3.** En un teléfono cuyo fabricante dejó de ocuparse en mayo de 2022, con un núcleo Android congelado en el 4.9. El sistema de ficheros se había agrandado solo en el primer arranque para ocupar los 48 gigabytes disponibles.
*Primer arranque. La pantalla lleva rota mucho tiempo; el aparato, en cambio, acaba de rejuvenecer cuatro años.*
*El panel de ajustes rápidos. Wi-Fi, Bluetooth, batería al 94 %. Y en las notificaciones, el selector «USB Developer mode» — exactamente el perfil elegido en la instalación, el que mantiene la red USB activa de forma permanente. El reloj marca «jueves 1 de enero, 4:12»: el reloj físico aún no está en hora, nadie le ha dicho todavía qué día es.*
## La cámara, o cómo una herramienta bien escrita te tiende el trabajo
Quedaba comprobar aquello a lo que venía. En postmarketOS, la gestión de las cámaras pasa por **libcamera**, una biblioteca libre que sustituye a la pila propietaria de Android. Un fallo conocido señala que el controlador del sensor frontal de este teléfono está incompleto, y que el comando `cam -l` — que lista las cámaras — se queja de ello.
Se quejó, en efecto. Pero mucho mejor de lo que esperaba:
```
ERROR V4L2 'imx355 4-001a': Unable to get rectangle 2 on pad 0/0
ERROR V4L2 'imx355 4-001a': Unable to get rectangle 1 on pad 0/0
ERROR V4L2 'imx355 4-001a': Unable to get rectangle 0 on pad 0/0
WARN 'imx355 4-001a': Failed to retrieve the sensor crop rectangle
WARN 'imx355 4-001a': The sensor kernel driver needs to be fixed
WARN See Documentation/sensor_driver_requirements.rst
```
Hay algo reconfortante en un software que te dice literalmente «el controlador del núcleo del sensor necesita ser corregido» y te da la referencia del documento que explica cómo. Es exactamente lo contrario de [un error 4202 en una aspiradora](erreur-4202-neato-obsolescence.html).
Concretamente: el controlador no sabe responder cuando se le piden las dimensiones reales de su matriz de píxeles. libcamera se inventa entonces valores por defecto y trabaja sobre una geometría aproximada.
Pero la salida revelaba además esto, que no esperaba:
```
WARN 'imx363': No static properties available — Please consider updating the database
WARN 'imx355': No static properties available
WARN IPASoft: Failed to create camera sensor helper for imx355 / imx363
```
Este segundo problema no está en el núcleo. Son dos tablas de datos, dentro de la propia libcamera, donde los sensores del Pixel 3a faltan — mientras que decenas de otros ya figuran allí y ofrecen un modelo que copiar. Datos puros, nada de algoritmia.
**Actualización, unas horas después.** Al ir a escribir esa corrección, descubrí que la mitad acababa de hacerse: el sensor frontal, el **imx355**, se añadió aguas arriba *después* de la versión 0.7.2 que ejecuta este teléfono. El aviso de más arriba es pues un artefacto de versión, no una carencia — bastará con actualizar. El sensor trasero, el **imx363**, sigue ausente de todo el repositorio, y su controlador ni siquiera está en el núcleo oficial: se escribió en Intel, nunca se envió aguas arriba, y postmarketOS lo carga como módulo.
Y al comparar la entrada nueva del imx355 con lo que el controlador expone realmente en el aparato, algo no cuadra: asocia «barras de color» al valor 1 y «color sólido» al valor 2, cuando el controlador hace exactamente lo contrario. Otros dos sensores con menú idéntico, el imx258 y el imx471, están descritos correctamente justo al lado. Son pues dos correcciones en lugar de una — y la más sencilla es la que nadie esperaba.
Dicho de otro modo: la primera corrección que escribir no es la que venía buscando. Ha hecho falta encender el hardware real para darse cuenta. Es una lección bastante general — uno puede leer informes de fallos durante días sin ver lo que una máquina encendida te dice en tres segundos.
## Por qué esto no es solo un pasatiempo
La misma mañana en que este teléfono arrancó, la cuenta `balade.nomade` publicaba [un reel](https://www.instagram.com/reel/Dc-vV23MGIi/) ([copia local del texto y del hilo de comentarios](../assets/pixel3a/refs/balade-nomade-reel-2026-09-07.md)) que resume lo que se está jugando ahora mismo en Bruselas. Termina con una pregunta que me parece bien planteada:
> ¿Estás dispuesto a escanear tu documento de identidad para usar Instagram?
El tono es militante, así que verifiqué los tres puntos. Dos se sostienen sólidamente, el tercero merece un matiz — y el hilo de comentarios añadió un cuarto, más pertinente para este artículo que los otros tres.
**Chat Control.** Exacto. El reglamento europeo llamado CSAR sigue bloqueado en trílogo, y las negociaciones se reanudan a finales de septiembre de 2026 bajo presidencia irlandesa del Consejo. El 9 de julio de 2026, el Parlamento Europeo votó 314 contra 276 por retirar el dispositivo — sin alcanzar el umbral de 360 votos necesario para bloquear la posición del Consejo. La excepción que autoriza el escaneo «voluntario» de los mensajes se prorrogó por tanto hasta 2028. El análisis en el lado del cliente se retiró de la última versión del texto, pero el propio servicio jurídico del Consejo, en un dictamen del 10 de junio de 2026, estima que ese escaneo voluntario sigue siendo un registro generalizado de las comunicaciones, incompatible con el artículo 7 de la Carta de los Derechos Fundamentales.
**El fin del anonimato.** Exacto, con una novedad que el reel no menciona: la ley francesa del 21 de julio de 2026 que prohibía las redes sociales a los menores de quince años fue **anulada el 14 de agosto por el Consejo Constitucional** (decisión n.º 2026-911 DC), por vulneración desproporcionada de la libertad de expresión y de la vida privada. No entrará pues en vigor tal cual. Pero el movimiento de fondo continúa en otros frentes: la Comisión Europea anunció el 15 de abril de 2026 que su solución de verificación de edad estaba lista para el despliegue, y la cartera de identidad digital europea debe llegar a los Estados miembros antes de fin de año.
**Los metadatos.** Aquí matizo. El EDPB sí adoptó el 7 de julio de 2026 unas nuevas directrices sobre anonimización, en consulta hasta el 30 de octubre, que sustituyen al dictamen de referencia de 2014. Pero es un trabajo de clarificación técnica, no un puñetazo en la mesa. Y la jurisprudencia reciente apunta más bien en sentido contrario: el Tribunal de Justicia de la Unión Europea, en septiembre de 2025, adoptó un enfoque *relativo* — un mismo dato seudonimizado puede ser anónimo para quien no tiene medio alguno de reidentificar, y personal para otro.
### El cuarto punto, el que habla de verdad de este artículo
En los comentarios, alguien señala que Google está cambiando su política de instalación de aplicaciones y teme que eso «ponga en peligro GrapheneOS». La respuesta del autor corrige con razón ese temor, y los hechos le dan la razón.
Desde agosto de 2025, Google exige que **toda aplicación instalada en un dispositivo Android certificado provenga de un desarrollador verificado** — incluso cuando se instala un archivo APK a mano, fuera de cualquier tienda. Las primeras restricciones visibles llegan el **30 de septiembre de 2026** a Brasil, Indonesia, Singapur y Tailandia, antes de una extensión mundial en 2027. Instalar la aplicación de un desarrollador no verificado pasará por un recorrido indirecto con un **plazo de espera obligatorio de veinticuatro horas**. Y para verificarse, un desarrollador debe abrir una cuenta, pagar veinticinco dólares y aportar un **documento de identidad oficial**.
Relee la pregunta del reel y sustituye al usuario por el desarrollador. Es el mismo gesto: un documento de identidad como condición de acceso. De un lado para leer, del otro para escribir.
El comentarista se equivocaba sin embargo en un punto, y es el que cuenta. La restricción afecta a los dispositivos **certificados** — los que incorporan los servicios de Google bajo licencia. GrapheneOS no los incorpora: queda fuera del perímetro. La restricción no pone pues en peligro a los sistemas desgooglizados, **hace que su existencia sea más necesaria**.
### Instalar tu propio software, esa batalla
Es lo que más me exaspera, y es anterior a toda esta actualidad. Tanto en Android como en iOS, instalar un software que uno mismo ha compilado, o recuperado de un repositorio Git, es una carrera de obstáculos.
En Android hay que autorizar un origen desconocido, pasar tres avisos, y pronto rebuscar en las opciones de desarrollador y esperar veinticuatro horas. En iOS es peor: una aplicación que compilas y firmas con una cuenta Apple gratuita **deja de funcionar a los siete días** y hay que reinstalarla desde un ordenador. Para que sobreviva, hay que pagar noventa y nueve euros al año. El reglamento europeo de mercados digitales entreabrió la puerta en 2024 — tiendas alternativas, distribución desde el propio sitio web — pero solo dentro de la Unión, y en las condiciones de Apple.
La justificación es siempre la misma: la seguridad. Merece tomarse en serio y, por tanto, examinarse.
Si la apertura causara inseguridad, se notaría. Linux permite instalar cualquier cosa desde cualquier sitio — un repositorio, un archivo comprimido, código compilado a mano — y no es un desastre de seguridad: es el sistema que hace funcionar la mayor parte de los servidores del planeta, bajo ataque permanente. Windows, en cambio, tuvo durante mucho tiempo el modelo más permisivo **y** la peor reputación. Si la teoría fuese buena, Android e iOS serían los sistemas más seguros jamás concebidos. Se observa más o menos lo contrario de lo que predice.
Lo que protege no es pues el cierre, sino **una cadena de confianza verificable**: repositorios firmados, mantenedores identificados, código fuente que cualquiera puede releer, compilaciones reproducibles. La seguridad viene de la transparencia, no del permiso. Y esa cadena ya existe en Android: F-Droid distribuye desde hace años aplicaciones libres compiladas a partir de fuentes públicas, sin peaje ni documento de identidad.
Mientras tanto, la tienda oficial deja pasar. En 2026, una familia de software malicioso llamada NoVoice se encontró en más de cincuenta aplicaciones de Play Store, sumando al menos 2,3 millones de descargas — con acceso root y capaz de sobrevivir a un restablecimiento de fábrica. El año anterior, la campaña SlopAds: 224 aplicaciones, 38 millones de descargas. Y Google baneó **80 000 cuentas de desarrollador en 2025**, bajo un régimen que ya exige verificación de identidad para publicar en Play Store.
Es esa cifra la que zanja la discusión. La verificación de desarrolladores ya existe allí donde se supone que protege, y aun así hay que banear ochenta mil cuentas al año. Extenderla a la instalación manual no detendrá las campañas industriales — entran por la puerta grande, y está documentado. Detendrá al desarrollador solitario que publica su código en un repositorio Git.
El riesgo, en sí, es real: quien instala un archivo recibido por SMS cae efectivamente en la trampa. Pero eso aboga por un aviso claro, no por un derecho de entrada. Se protege a alguien diciéndole lo que está haciendo; no se le protege cobrando a quien escribe.
Y hay un criterio que zanja la cuestión. Para operar una tienda alternativa en la Unión Europea, Apple exige, a partir del **1 de octubre de 2026**, cotizar en bolsa, o estar financiado por capital riesgo, o haber pasado una auditoría financiera, o sumar un millón de instalaciones anuales. Ninguno de esos criterios mide la seguridad de nada. Son criterios de **tamaño**.
Estoy dispuesto a conceder la buena fe en el principio. Me cuesta más cuando la misma empresa cierra la puerta y lleva la caja.
### Lo que eso cambia para un teléfono viejo
El hilo común de todo esto es técnico, y es el que conecta esta actualidad con un Pixel de 2019.
El análisis en el lado del cliente consiste en inspeccionar los mensajes **en el aparato, antes del cifrado**. Un dispositivo así no se implementa en una aplicación: se implementa en el sistema. Ese es el desplazamiento decisivo. Mientras la garantía descansaba en el protocolo, podía auditarse desde fuera. En cuanto descansa en el aparato, la única pregunta que importa pasa a ser: *¿quién decide lo que hace este aparato?*
En un teléfono cuyo sistema no puede reemplazarse, la respuesta es: el fabricante. Y a través de él, quienquiera que legisle sobre el fabricante. No es un escándalo, es una cadena de decisión perfectamente ordinaria — pero en ningún momento pasa por el propietario.
Las dos vías de escape existentes — GrapheneOS, postmarketOS — descansan exactamente en lo mismo: **un gestor de arranque que se tiene derecho a desbloquear**. La misma casilla en las opciones de desarrollador que abrió esta tarde. Toda la salida práctica, para Android, ha dependido hasta ahora de la buena voluntad de un solo fabricante sobre un solo ajuste. GrapheneOS solo está disponible en Pixel; habrá que esperar a los Motorola de gama alta de 2027 para que eso deje de ser cierto.
Y hay que decir lo que este artículo no demuestra. **postmarketOS en un Pixel 3a no es una solución de privacidad.** El módem sigue siendo una caja negra, un procesador autónomo que ejecuta software propietario al que el sistema no tiene acceso. Este aparato en concreto no es utilizable a diario, lo dije desde el principio. Para un uso real, la respuesta seria es la que el reel pone como etiqueta: GrapheneOS.
Lo que este artículo sí demuestra es más modesto, y basta: **la capacidad existe, está al alcance de una tarde, y se ejerce.** Una capacidad que nunca se ejerce acaba desapareciendo sin que nadie se dé cuenta — no por prohibición, simplemente porque un día ningún aparato la ofrece ya y nadie la habrá reclamado.
## ¿Y tu teléfono?
Fue la primera pregunta que me hicieron, y es la buena. Esto es lo que la responde — las cifras vienen del repositorio `pmaports` a fecha del 5 de septiembre de 2026 y del sitio oficial de Ubuntu Touch, no de una lista copiada de algún sitio.
Primero, una advertencia sobre el vocabulario. postmarketOS clasifica sus aparatos en tres niveles, y significan algo:
- **`community`** — funciona en general, con carencias identificadas. **39 aparatos**, de los cuales solo catorce son teléfonos.
- **`testing`** — desde «arranca, en cierto sentido» hasta «funciona casi todo». **149 aparatos.** Ahí está la mayoría del parque, y ahí está el trabajo.
- **`downstream`** — núcleo Android de origen, funcionalidades muy limitadas. **20 aparatos**, desaconsejados.
Ningún aparato está hoy clasificado por encima de `community`. Eso sitúa honestamente el estado del ecosistema.
### Los catorce teléfonos en `community`
| Año | Aparato |
|---|---|
| 2009 | Nokia N900 |
| 2012 | Samsung Galaxy S III |
| 2014 | Samsung Galaxy Core Prime VE LTE |
| 2018 | OnePlus 6 · OnePlus 6T · Samsung Galaxy S9 · Xiaomi Poco F1 |
| 2019 | **Google Pixel 3a** · Pixel 3a XL · Purism Librem 5 |
| 2020 | SHIFT6mq |
| 2021 | **Fairphone 4** · PinePhone Pro |
Dos sorpresas en esa lista. El **Xiaomi Poco F1** y los **OnePlus 6 / 6T** son excelentes candidatos: potentes para su edad, muy extendidos de segunda mano, y portados desde hace tiempo. Y el **PinePhone original**, diseñado para Linux, está en `testing` — es su sucesor Pro el que está en `community`.
El resto de la categoría no son teléfonos: una docena de **Chromebooks** ARM, el Lenovo ThinkPad X13s, la PineNote, la Odroid XU4, la RockPro64. Si lo que buscas es un pequeño ordenador ARM con Linux en lugar de un teléfono, es una vía muy infravalorada.
En `testing`, los 149 aparatos se reparten sobre todo entre **Samsung** (30), **Xiaomi** (18), **Sony**, **OnePlus**, **LG** y **Google** (5 cada uno), y **Fairphone** (4). Hay pues bastantes probabilidades de que tu teléfono esté ahí — con trabajo pendiente, que es precisamente el interés.
### Si quieres un teléfono que funcione, no un banco de pruebas
Es otra necesidad, y tiene otras respuestas. **Ubuntu Touch** anuncia **111 aparatos** compatibles, con un porcentaje de funcionalidad por aparato. Los mejor servidos:
| Aparato | Funcional |
|---|---|
| Lenovo Tab M10 HD 2.ª gen. (WiFi) | 100 % |
| BQ Aquaris M10 HD / FHD | 98,7 % |
| **Fairphone 5** (2023) | 97,4 % |
| Xiaomi Redmi Note 9 Pro · Poco X3 NFC | 97,4 % |
| OnePlus Nord N10 5G · Nord N100 | 97,4 % |
| **Fairphone 4** · Pixel 3a / 3a XL | 97,3 % |
| **Nothing Phone (1)** (2022) | 95,6 % |
| Fairphone 3 / 3+ | 95,6 % |
El **Fairphone 4** es el punto de equilibrio de todo esto: está a la vez en `community` en postmarketOS **y** al 97,3 % en Ubuntu Touch, y es además el teléfono más reparable del mercado. Si alguien me preguntara qué comprar para hacer esto en serio, sería ese — o el Fairphone 5 si el objetivo es sobre todo usarlo.
Y si quieres quedarte en Android saliendo de la órbita de Google, **GrapheneOS** sigue siendo la respuesta más sólida — pero solo en Pixel 6 y posteriores, con siete años de actualizaciones garantizadas en los Pixel 8, 9 y 10. La alianza con Motorola anunciada en agosto de 2026 debería levantar esa exclusividad en 2027; la lista oficial, hoy, sigue siendo exclusivamente Pixel.
### Cómo comprobarlo con el tuyo
Busca el nombre en clave de tu aparato — no su nombre comercial — en el wiki de postmarketOS y en `devices.ubuntu-touch.io`. El nombre en clave se lee con un solo comando, con el aparato conectado por USB:
```bash
adb shell getprop ro.product.device
```
En el mío responde `sargo`. Y dos condiciones previas valen para todo el mundo, diga lo que diga la lista: **el gestor de arranque debe poder desbloquearse**, lo que excluye la mayoría de los aparatos vendidos por operadores estadounidenses; y la operación **lo borra todo**.
## Lo que me llevo
La parte técnica es casi anecdótica. Me quedan tres cosas.
**La trampa no está en ninguna parte.** La suspensión automática USB no se menciona en ninguna guía de instalación. Quien la encuentra ve un comando que se cuelga sin mensaje, prueba otro cable, otro puerto, y concluye que su hardware tiene la culpa. Abandona. La corrección son dos líneas y vale para todos los Pixel. Es lo que voy a escribir primero — antes que cualquier código, antes que la cámara. Una tarde perdida por mí puede ahorrar muchas a otros, y es probablemente la contribución más rentable de toda la historia.
**Busqué en el sitio equivocado durante una hora.** No por falta de método, sino porque seguía interrogando al aparato — reintentar el comando, cambiar un parámetro, volver a probar — en lugar de interrogar al sistema que gobernaba el aparato. La respuesta estaba en un fichero de texto de nueve caracteres. Cada vez que una herramienta calla en lugar de fallar, hay que dejar de relanzarla e ir a leer el estado de la capa de abajo.
**Y luego está el fondo.** Este teléfono lleva grabado en la trasera un contenedor tachado, ese pictograma que significa que no se tira con la basura. El símbolo está ahí desde 2019, obligatorio, decorativo. Esta noche se ha vuelto exacto: el aparato no ha ido al vertedero, funciona, y funciona con un núcleo más reciente que el de muchas máquinas en servicio.
No es una proeza técnica — gente mucho más competente hizo el trabajo difícil, el de portar un núcleo moderno a este chip. Yo solo he seguido sus huellas y he tropezado con una trampa que no habían documentado. Pero es una demostración: el fin de soporte no es una propiedad del hardware. Es una decisión. Y cuando el fabricante deja la puerta abierta — como hace Google en los Pixel, hay que reconocérselo —, esa decisión puede retomarla otro.
Un Pixel 3a de segunda mano se encuentra por unas decenas de euros. Hay millones en los cajones.
Lo siguiente es la cámara.