Hace unas semanas di el salto y dejé mi viejo teléfono Symbian en el cajón para comprarme un Samsung Galaxy S (el famoso i9000). A nivel de hardware es una absoluta bestia: ese procesador Hummingbird a 1 GHz y la pantalla Super AMOLED de 4 pulgadas te dejan con la boca abierta. Pero claro, a nivel de software, pronto descubrí por qué los foros de XDA Developers están echando humo.
El teléfono venía con Android 2.1 (Eclair), lo cual no está mal, pero la capa de personalización de Samsung, TouchWiz, sufre de un "lag" desesperante. Puedes estar navegando fluido y, de repente, la interfaz se congela durante tres segundos al abrir los contactos. Como buen informático, esto no me dejaba dormir, así que decidí meterme en un lio.
El problema subyacente: El infame sistema de archivos RFS
Investigando un poco en foros, descubrí que el cuello de botella no era la RAM ni la CPU, sino la memoria interna. Samsung decidió usar un sistema de archivos propietario llamado RFS (Robust File System), que supuestamente está optimizado para memoria flash, pero que en la práctica tiene unas latencias de escritura horribles en operaciones pequeñas y concurrentes.
La comunidad, liderada por un desarrollador francés apodado Supercurio, ha ideado algo llamado "Voodoo Lagfix". La idea técnica es brillante: reemplazar el núcleo (kernel) de Android por uno modificado que formatea automáticamente la partición de datos de RFS al clásico y robusto ext4 de Linux en el momento del arranque.
Manos a la obra: Compilando el Kernel
Podría haberme bajado el kernel ya compilado en un archivo .tar y flashearlo con Odin, pero quería entender qué pasa por debajo y hacerlo yo mismo. Al fin y al cabo, Android es Linux.
Me bajé el código fuente del kernel que Samsung está obligado a liberar por la licencia GPL, preparé mi entorno en y me dispuse a cruzar los dedos.
# Exportar las variables de entorno para usar el compilador ARM
export ARCH=arm
export CROSS_COMPILE=/opt/toolchains/arm-eabi-4.4.0/bin/arm-eabi-
# Entrar al directorio del código fuente y limpiar basuras previas
cd /home/user/dev/android/kernel_samsung/
make clean && make mrproper
# Configurar el kernel usando el archivo de configuración base del i9000
make c1_defconfig
# Aquí es donde ocurre la magia. Abrimos el menú de configuración visual
make menuconfig
En el menú de configuración, habilité el soporte completo para sistemas de archivos ext4, desactivé algunos módulos inútiles de depuración de Samsung para aligerar la carga y salvé la configuración.
# Compilar la imagen del kernel (zImage) usando 4 hilos
make -j4
Tras unos minutos de ventiladores soplando al máximo, ahí estaba: mi fichero zImage. Lo empaqueté, puse el teléfono en "Modo Download" (apretando el botón de bajar volumen + home + encendido) y lo inyecté a través de USB.
El reinicio que duró una eternidad
El primer arranque tras flashear tardó casi diez minutos. En la pantalla salía una voz robótica y unas líneas de texto indicando que estaba copiando todos mis datos temporales, formateando la partición /data a ext4 y restaurándolos de nuevo. Pensé que me lo iba a cargar...
Pero no, cuando por fin cargó el escritorio... ¡la diferencia fue abismal! El lag ha desaparecido por completo. El terminal vuela, las aplicaciones se abren instantáneamente y las puntuaciones en el benchmark de Quadrant se han duplicado.
Reflexión sobre el ecosistema Android
Esta experiencia me deja una sensación agridulce. Por un lado, Android es el paraíso absoluto para un perfil técnico. El hecho de que pueda descargarme el núcleo del sistema operativo de mi teléfono, modificar el código C, recompilarlo y arreglar un problema de diseño del fabricante es algo que a los usuarios de iPhone les debe sonar a ciencia ficción.
Por otro lado, me preocupa mucho la fragmentación a futuro. Un usuario normal, tu padre o tu abuela, no deberían tener que compilar un kernel en Linux y usar ext4 para que su teléfono de gama alta funcione sin tirones. Si los fabricantes (HTC, Samsung, Motorola) siguen modificando Android a su antojo y metiendo capas chapuceras, temo que la plataforma se vuelva inestable y caótica. Ojalá Google tome las riendas y empiece a exigir unos estándares de calidad más rígidos en el código base, porque la libertad técnica está muy bien, pero la usabilidad manda en el mercado de consumo.