R8: minificar, ofuscar y encoger recursos

Hay una categoría de error que todo equipo de Android acaba conociendo y que tiene una firma inconfundible: la aplicación funciona perfectamente durante meses de desarrollo, pasa todas las pruebas, se sube a la tienda, y entonces empiezan a llegar informes de fallos con trazas ilegibles en las que aparecen clases llamadas con una sola letra invocando métodos llamados con otra sola letra. El código es el mismo. Lo que cambió es que entre tu fuente y el artefacto publicado se interpuso un programa que reescribió el binario entero con permiso tuyo, aunque probablemente sin que nadie del equipo revisara jamás bajo qué reglas. Ese programa es R8, y entenderlo no es un lujo de especialista: es la diferencia entre un artefacto pequeño y rápido y una tarde entera intentando descifrar por qué una biblioteca de serialización devuelve objetos con todos los campos a nulo.

Cuatro trabajos bajo un solo interruptor

Activar la minificación enciende de golpe una cadena de transformaciones que conviene tener separadas mentalmente, porque cada una produce una familia distinta de fallos. El primer trabajo es el encogido de código: R8 construye el grafo de alcanzabilidad del programa y elimina toda clase, método y campo al que no se llega desde ninguna raíz. El segundo es la optimización, y es el menos comentado y el más profundo: incorpora métodos en sus llamantes, fusiona clases, convierte llamadas virtuales en directas cuando puede probar el tipo, propaga constantes, desempaqueta enumeraciones, elimina ramas muertas resultantes de todo lo anterior y extrae secuencias repetidas a métodos comunes. El tercero es la ofuscación: renombrar clases, métodos y campos con identificadores cortos. El cuarto, gobernado por una opción independiente, es el encogido de recursos.

La distinción importa porque la ofuscación se lleva casi toda la culpa y casi nunca es la única responsable. Un fallo de serialización se debe a la ofuscación, porque los nombres de campo dejaron de coincidir con las claves del documento. Pero un método que desaparece pese a estar escrito se debe al encogido, y un comportamiento que cambia sin que nadie toque el código puede deberse a la optimización, que es capaz de eliminar una comprobación de nulidad que el análisis considera imposible y que en la práctica ocurría porque alguien devolvía nulo desde código nativo o desde reflexión.

El modelo mental correcto para todo lo demás es el de alcanzabilidad desde un conjunto de raíces. Las raíces por defecto son los componentes declarados en el manifiesto, los puntos de entrada de la plataforma y lo que las bibliotecas declaran mediante sus propias reglas empaquetadas. Todo lo que se alcanza desde ahí siguiendo llamadas y referencias sobrevive. Todo lo demás desaparece. Una regla de keep no es otra cosa que la declaración manual de una raíz adicional, necesaria precisamente cuando el enlace no es visible en el código porque pasa por reflexión, por código nativo o por un fichero de configuración.

La gramática de keep: tres verbos que no son sinónimos

La confusión más extendida consiste en creer que existe una única forma de conservar algo. Existen al menos tres, y elegir mal produce artefactos innecesariamente grandes o fallos sutiles. La directiva -keep conserva la clase y los miembros indicados frente al encogido y frente a la ofuscación: sobreviven y mantienen su nombre. La directiva -keepnames es más débil y a menudo la correcta: no impide que se elimine si resulta inalcanzable, pero garantiza que, si sobrevive, conserve su nombre. La directiva -keepclassmembers es condicional: no conserva la clase por sí misma, pero si la clase sobrevive por otro motivo, entonces sus miembros indicados también sobreviven con su nombre.

# Nombres de campo estables para una biblioteca que serializa por reflexion
-keepclassmembers class com.ejemplo.app.red.dto.** {
    <fields>;
}

# Metodos invocados desde codigo nativo: enlace invisible para el analisis
-keepclasseswithmembernames class * {
    native <methods>;
}

# Atributos necesarios para genericos y anotaciones en tiempo de ejecucion
-keepattributes Signature, InnerClasses, EnclosingMethod
-keepattributes RuntimeVisibleAnnotations, AnnotationDefault

# Antipatron: anula el beneficio completo para todo el paquete
# -keep class com.ejemplo.app.** { *; }

La última línea del ejemplo, comentada a propósito, es el error más frecuente y el más caro. Cuando aparece un fallo en publicación, la reacción instintiva consiste en conservar el paquete entero con todos sus miembros, comprobar que el fallo desaparece y seguir adelante. El resultado es que se desactivan las cuatro transformaciones sobre la mayor parte del código propio: el artefacto crece, se cargan clases que nadie usa, se pierde la optimización y la ofuscación deja de proteger nada. Y como el síntoma desaparece, nadie vuelve a mirarlo.

Conviene además conocer el modo estricto, que en las versiones recientes viene activado por defecto y que cambia supuestos importantes. En ese modo R8 asume que no hay reflexión salvo declaración explícita, no conserva automáticamente los constructores por defecto de las clases conservadas, es más agresivo al asumir tipos y trata las anotaciones con menos indulgencia. Es el modo correcto, pero migrar a él desde una configuración antigua suele destapar reglas que llevaban años siendo insuficientes y que el modo compatible disimulaba.

Recursos: el encogido que depende del código

El encogido de recursos no funciona de forma independiente: se apoya en el resultado del encogido de código para saber qué identificadores de recurso siguen siendo referenciados. Por eso solo tiene efecto cuando la minificación está activada, y por eso conservar de más en el código conserva también recursos de más. Los dos encogidos están acoplados, y una configuración de keep excesiva engorda el artefacto por dos vías simultáneas.

La trampa clásica está en la referencia por nombre. Cuando el código construye el nombre de un recurso a partir de una cadena y lo resuelve en tiempo de ejecución, el análisis estático no ve ninguna referencia y el recurso desaparece. El síntoma es una imagen que no aparece o una cadena que sale vacía solo en publicación, y el diagnóstico es especialmente lento porque nadie sospecha del encogido de recursos. La solución consiste en declarar explícitamente qué se conserva mediante un fichero de recursos destinado a ese fin, o mejor aún, en eliminar la resolución por nombre y sustituirla por una correspondencia explícita en código.

# Comprobar el tamaño y el contenido del artefacto final
./gradlew :app:assembleRelease
./gradlew :app:analyzeReleaseBundle

# Localizar el mapa de nombres para poder revertir las trazas
ls app/build/outputs/mapping/release/

# Revertir una traza ofuscada usando el mapa de esa version exacta
retrace app/build/outputs/mapping/release/mapping.txt traza_ofuscada.txt

Existe además un modo estricto para los recursos que conviene activar deliberadamente. Por defecto la herramienta es conservadora ante referencias ambiguas y prefiere conservar de más; en modo estricto elimina todo lo que no vea referenciado con claridad, lo que reduce mucho más el artefacto pero exige que las excepciones estén declaradas. La decisión razonable es activarlo y declarar las excepciones, no dejarlo permisivo por comodidad.

flowchart TD
A[Raices: manifiesto, entradas de plataforma y reglas de bibliotecas] --> B[Grafo de alcanzabilidad]
B --> C[Encogido de codigo: se elimina lo inalcanzable]
C --> D[Optimizacion: incorporar, fusionar, desvirtualizar]
D --> E[Ofuscacion: renombrar clases y miembros]
E --> F[Mapa de nombres generado]
C --> G[Conjunto de identificadores de recurso vivos]
G --> H[Encogido de recursos]
I[Reglas de keep propias] --> A
F --> J[Archivar y subir para revertir trazas]
style C fill:#89b4fa,color:#11111b
style E fill:#f9e2af,color:#11111b
style J fill:#a6e3a1,color:#11111b

Depurar el fallo que solo existe en publicación

El método que funciona tiene un orden y conviene respetarlo, porque el instinto lleva siempre a la solución equivocada. El primer paso es hacer el fallo reproducible en local, y para eso se crea una variante de construcción que active la minificación y el encogido de recursos pero mantenga el binario depurable y las trazas legibles. Con esa variante, un fallo que tardaba días en confirmarse desde el campo se reproduce en minutos con un depurador conectado.

El segundo paso es determinar cuál de los cuatro trabajos es el responsable, y se hace por bisección desactivando uno cada vez. Si el fallo desaparece al desactivar solo la ofuscación, el problema es de nombres y apunta a reflexión o serialización. Si persiste sin ofuscación pero desaparece sin encogido, falta una raíz. Si solo desaparece desactivando la optimización, se trata de un supuesto que el análisis dio por válido y que en tiempo de ejecución no lo era, y ahí casi siempre hay un contrato de nulidad mentiroso en la frontera con código nativo, con reflexión o con una biblioteca sin anotaciones.

El tercer paso es escribir la regla mínima que corrige el caso concreto, no la máxima que lo tapa. Y el cuarto, que rara vez se hace y siempre se agradece, es añadir una prueba instrumentada que se ejecute sobre la variante minificada en integración continua, de modo que la próxima regresión de este tipo se detecte antes de publicar y no después.

# Diagnostico por biseccion sobre la variante minificada
-dontobfuscate      # aisla los fallos de nombres
-dontoptimize       # aisla los fallos de supuestos del analisis
-printusage salida/eliminado.txt
-printseeds salida/raices.txt
-printconfiguration salida/configuracion_efectiva.txt