Código fuente de referencia

1. Qué es y por qué existe

El documento anterior termina con una lista de catorce cosas que ninguna especificación cubre: el layout de resources.arsc, el de AXML, las reglas de match de ResTable_config, la tolerancia del lector de ZIP de Android, la gramática completa de mapping.txt, los formatos de perfil de ART. Este documento dice qué fichero abrir para cada una.

Es el más práctico del bloque y también el más frágil, por dos motivos que conviene tener presentes desde la primera línea:

• Las rutas se mueven. Entre versiones de Android, los ficheros cambian de sitio, se parten y desaparecen. art/dexlayout/ ya no existe en la rama main; ARSCDecoder.java de apktool tampoco. Ambas se comprobaron el 12 de agosto de 2026 y ambas se citaban habitualmente hace poco.
• Leer main es leer el futuro. La rama de desarrollo de AOSP contiene código que no está en ningún dispositivo. Documentar desde main es la forma más rápida de escribir algo que es cierto en el repositorio y falso en el mundo. La sección 2.3 es la regla que evita eso, y es la parte más importante del documento.

Todas las rutas de aquí se comprobaron el 12 de agosto de 2026 y devolvieron HTTP 200, salvo las que se señalan expresamente como inexistentes (que se señalan precisamente porque alguien las va a buscar).

2. Cómo leer AOSP sin clonarlo

AOSP son más de un centenar de gigabytes repartidos en cientos de repositorios git. No hace falta clonar nada para leer un fichero, y para el trabajo de este corpus clonar es contraproducente: un clon envejece en silencio.

Hay tres vías, y sirven para cosas distintas.

2.1 cs.android.com — navegar y buscar

https://cs.android.com/android/platform/superproject/main

Es Code Search: el buscador de código de Google sobre AOSP. Lo que aporta y las otras vías no: referencias cruzadas. Al pinchar sobre un símbolo muestra dónde se define y todos los sitios donde se usa, que es exactamente lo que hace falta cuando uno se pregunta «¿quién escribe este campo?».

Formato de enlace directo a un fichero:

https://cs.android.com/android/platform/superproject/main/+/main:<ruta>

Y con número de línea, añadiendo ;l=<n>:

https://cs.android.com/android/platform/superproject/main/+/main:frameworks/base/libs/androidfw/include/androidfw/ResourceTypes.h;l=200

Búsqueda por símbolo en todo AOSP:

https://cs.android.com/search?q=ResTable_package&ss=android

Cuándo: para explorar y para entender. Los cuatro enlaces de arriba devuelven 200, comprobado.

Su límite: sirve HTML pensado para un navegador. No es la vía para descargar el fichero.

2.2 android.googlesource.com — el fichero crudo y fijado

https://android.googlesource.com/ es la instancia de Gitiles sobre los repositorios reales. El patrón general:

https://android.googlesource.com/<repo>/+/<ref>/<ruta>

Y el detalle que lo hace útil de verdad: añadiendo ?format=TEXT devuelve el fichero en base64, sin HTML alrededor. Eso permite descargar y procesar sin clonar:

curl -s 'https://android.googlesource.com/platform/frameworks/base/+/refs/heads/main/libs/androidfw/include/androidfw/ResourceTypes.h?format=TEXT' \
  | base64 -d > ResourceTypes.h
wc -c ResourceTypes.h

   86255 ResourceTypes.h

(Ejecutado el 12 de agosto de 2026 en la máquina de referencia.)

Cuándo: siempre que haya que leer el contenido de verdad, extraer constantes o comparar dos versiones.

2.3 La regla: fijar una etiqueta, no leer main

Las dos formas de <ref>:

Comprobado el 12 de agosto de 2026: la etiqueta más alta publicada es android-17.0.0_r1, y existen también android-16.0.0_r1 a _r4 y android-15.0.0_r1 a _r36. Se verificó además que la misma etiqueta resuelve en los distintos repositorios —platform/art, platform/tools/apksig y platform/system/libziparchive devuelven 200 para android-15.0.0_r1, android-16.0.0_r4 y android-17.0.0_r1—, lo que permite fijar una release y leer todos los componentes coherentes entre sí.

TAG=android-16.0.0_r4
BASE=https://android.googlesource.com/platform/frameworks/base/+/refs/tags/$TAG
curl -s "$BASE/libs/androidfw/include/androidfw/ResourceTypes.h?format=TEXT" | base64 -d | head -40

Por qué importa tanto. El corpus ya usa esta técnica para fechar cambios: la tabla 7.4 de XML binario determina en qué versión de Android se introdujo la validación del tipo del chunk raíz comparando seis etiquetas, y la tabla 8.2 de Tabla de recursos reconstruye el historial de campos de ResTable_config del mismo modo. Sin etiquetas eso no se puede hacer, y con solo main uno acaba afirmando que un campo «existe» cuando no existe en ningún teléfono.

2.4 La API de GitHub, para los espejos y la comunidad

Parte de AOSP se espeja en github.com/aosp-mirror, y todas las herramientas de la comunidad viven en GitHub. La API sirve contenido y metadatos sin clonar:

# ¿existe esta ruta? (200 / 404) y metadatos del fichero
curl -s -o /dev/null -w '%{http_code}\n' \
  https://api.github.com/repos/skylot/jadx/contents/jadx-core/src/main/java/jadx/core/Jadx.java

# el contenido en crudo
curl -s https://raw.githubusercontent.com/google/bundletool/master/src/main/proto/commands.proto | head -30

# la rama por defecto, que no siempre es la que uno supone
curl -s https://api.github.com/repos/pxb1988/dex2jar | python3 -c 'import sys,json;print(json.load(sys.stdin)["default_branch"])'

Aviso sobre la rama por defecto. No dar por hecho master ni main: se comprobaron las diez y no coinciden (tabla en §4.11). pxb1988/dex2jar usa 2.x, y cualquier URL con master sobre ese repositorio falla.

3. AOSP: dónde está cada cosa

3.1 Los recursos — la autoridad sin especificación

Este es el bloque que justifica el documento entero.

Por qué es la autoridad. No hay documento que describa resources.arsc. Lo que ResourceTypes.cpp acepta al leer es el formato; lo que TableFlattener.cpp escribe es lo que hay en los ficheros reales. Y no son lo mismo: el lector acepta bastante más de lo que el escritor produce, y esa diferencia es donde viven las malformaciones deliberadas que documenta XML binario §7.3.

Por dónde entrar: ResourceTypes.h primero, entero. Son unos 86 KB y es la mejor hora que se puede invertir en este dominio. Después TableFlattener.cpp si se va a escribir, o LoadedArsc.cpp si se va a leer.

3.2 El código — DEX y bytecode

Los valores de dex_instruction.h citados arriba se leyeron del fichero el 12 de agosto de 2026 con ?format=TEXT.

Ruta que ya no existe: ⚠️ art/dexlayout/ fue eliminado de la rama main. Se comprobó el 12 de agosto de 2026 listando el árbol de platform/art: los directorios relacionados con DEX que quedan son dexdump, dexlist, libdexfile, dex2oat, dexoptanalyzer y dexopt_chroot_setup. Quien busque dexlayout.cc por una referencia antigua tiene que ir a una etiqueta anterior.

3.3 La firma — tools/apksig

apksig es la biblioteca que hay detrás de apksigner, y es el mejor código de todo AOSP para este propósito: está en Java, es autocontenido y sus comentarios son buenos.

Raíz: https://android.googlesource.com/platform/tools/apksig/+/refs/heads/main/ Prefijo común de las rutas: src/main/java/com/android/apksig/

Por dónde entrar: ApkVerifier.java, y desde ahí seguir las llamadas. La estructura del paquete internal/apk/vN/ es tan regular que una vez visto un esquema se leen los otros solos.

Lo que no está aquí: las constantes de v3.2 no aparecen en la rama pública de apksig. Se obtuvieron del apksigner.jar de las build-tools 37.0.0 con javap -constants (20-firma/01 §2). Y los identificadores de bloque de terceros —dependency metadata, frosting, Meituan— no están en AOSP en absoluto: para eso, §4.10.

3.4 El contenedor — ZIP y alineación

Por qué importa zip_archive.cc más que APPNOTE.TXT para este dominio: la especificación describe el ZIP correcto; los APK del mundo real no siempre lo son. La divergencia entre Local File Header y Central Directory, el data descriptor ausente con el flag del bit 3 puesto, el comentario del EOCD con basura — todo eso solo se resuelve viendo qué hace este fichero. Es la raíz de las vulnerabilidades históricas Master Key y Janus (Contenedor ZIP §12).

3.5 Los artefactos auxiliares

4. Herramientas de la comunidad: por dónde se entra

Un enlace al repositorio no sirve de nada. Lo que sirve es el fichero por el que se empieza. Todas las rutas de esta sección se verificaron contra la API de GitHub el 12 de agosto de 2026 y devuelven HTTP 200.

4.1 jadx — rama master

El decompilador de referencia. Su arquitectura es de plugins de entrada más un pipeline de visitors.

https://github.com/skylot/jadx/blob/master/jadx-core/src/main/java/jadx/core/Jadx.java

Empieza por Jadx.java. La lista de passes explica en cincuenta líneas por qué decompilar es difícil, mejor que cualquier artículo.

4.2 apktool — rama main

⚠️ Rutas que ya no existen: ARSCDecoder.java y ResourcesDecoder.java fueron refactorizados y no están en el árbol actual. Se siguen citando en documentación de terceros. El sustituto es BinaryResourceParser.java.

4.3 smali / baksmali (google/smali) — rama main

⚠️ Aviso: el repositorio contiene un árbol duplicado bajo third_party/smali/. Usar siempre las rutas sin ese prefijo.

4.4 ARSCLib — rama main

La reimplementación en Java de los formatos de recursos, sin aapt2. Es la referencia de diseño obligada para cualquier lector de resources.arsc escrito desde cero.

Por qué leerlo: es el ejemplo trabajado de modelar los chunks fielmente para poder reescribirlos, que es exactamente el problema del round-trip byte-exacto.

4.5 APKEditor — rama master

Matiz importante: la fusión real no está aquí, está en ApkBundle de ARSCLib (§4.4). APKEditor es la CLI; la lógica es de la biblioteca.

4.6 dex2jar — rama 2.x

⚠️ La rama por defecto es 2.x. Las URL con master no funcionan. Último push del repositorio: julio de 2024.

4.7 APKiD — rama master

Las reglas se organizan en apkid/rules/{apk,dex,elf,dll,res}/ con categorías repetidas (common, obfuscators, packers, protectors, anti-vm, abnormal).

Sobre el alcance: estas reglas son material de detección e identificación, que es exactamente lo que el corpus documenta. Leerlas no enseña a desempaquetar nada; enseña qué cadenas y qué estructuras delatan a cada familia.

4.8 bundletool — rama master

⚠️ ShardedApksGenerator no existe en el árbol actual. El directorio splitters/ contiene los splitters por dimensión (AbiNativeLibrariesSplitter, CountrySetAssetsSplitter…).

Y sus .proto (§6.2 del documento 01) son la autoridad sobre el APK Set.

4.9 R8 — r8.googlesource.com, rama main

No está en GitHub. Se lee con el mismo patrón de Gitiles que AOSP: https://r8.googlesource.com/r8/+/refs/heads/main/<ruta>

⚠️ naming/ProguardMapWriter.java no existe (404 comprobado). No hay ninguna clase *MapWriter: el lado de escritura es ProguardMapSupplier.java. Es un error de búsqueda natural y por eso se deja anotado.

4.10 avast/apkverifier — rama master

Verificador de firma independiente, en Go. Vale la pena precisamente porque no es de Google: documenta los identificadores de bloque que AOSP no reconoce.

De aquí salen los tres identificadores de APK Signing Block §11 que no están en apksig.

4.11 Ramas por defecto y estado — comprobado el 12 de agosto de 2026

El análisis de mantenimiento y bus factor de estos proyectos está en Mapa del ecosistema; aquí solo interesa la rama, porque de ella dependen todas las URL de arriba.

5. Tabla de trazabilidad

El mapa del corpus: qué código sostiene cada documento. Si una afirmación de la columna izquierda se pone en duda, se comprueba en la de la derecha.

Tres documentos —10-formatos/07 en su mayor parte, y las partes de spec de 02 y 03— se sostienen en especificación publicada y no necesitan código. Son la excepción, y por eso están en el documento 01.

6. Trampas verificadas

Resumen de lo que se comprobó y falló, para que nadie repita la búsqueda:

Fuentes

Todas las rutas de este documento se comprobaron el 12 de agosto de 2026: las de AOSP y R8 con curl sobre android.googlesource.com y r8.googlesource.com, y las de GitHub con la API (GET /repos/<org>/<repo>/contents/<ruta>?ref=<rama>). Las señaladas como inexistentes devolvieron 404 o no aparecen en el listado del árbol.

1. AOSP — frameworks/base/libs/androidfw/ — https://android.googlesource.com/platform/frameworks/base/+/refs/heads/main/libs/androidfw/ Consultado el 12 de agosto de 2026. De aquí sale la tabla de la sección 3.1. El contenido concreto de ResourceTypes.h, ResourceTypes.cpp y LoadedArsc.cpp está desarrollado en 10-formatos/04 y 10-formatos/05, que los citan campo a campo.
2. AOSP — frameworks/base/tools/aapt2/ — https://android.googlesource.com/platform/frameworks/base/+/refs/heads/main/tools/aapt2/ Consultado el 12 de agosto de 2026. Rutas verificadas: Resource.h, Resources.proto, cmd/Link.cpp, format/binary/TableFlattener.cpp, format/binary/XmlFlattener.cpp.
3. AOSP — art/libdexfile/dex/ — https://android.googlesource.com/platform/art/+/refs/heads/main/libdexfile/dex/dex_instruction.h Consultado el 12 de agosto de 2026, descargado con ?format=TEXT y decodificado. De aquí se leyeron directamente kNumPackedOpcodes = 0x100, kPackedSwitchSignature = 0x0100, kSparseSwitchSignature = 0x0200, kArrayDataSignature = 0x0300 y kMaxVarArgRegs = 5 citados en la sección 3.2. Verificadas además dex_file.h, standard_dex_file.{h,cc}, dex_file_structs.h, dex_file_verifier.cc y dex_file_loader.cc.
4. AOSP — listado del árbol de platform/art — https://android.googlesource.com/platform/art/+/refs/heads/main/ Consultado el 12 de agosto de 2026. De aquí sale que dexlayout/ ya no existe y la lista de directorios relacionados con DEX que sí quedan (sección 3.2 y tabla 6).
5. AOSP — art/runtime/verifier/method_verifier.cc, art/dexdump/dexdump.cc, art/runtime/oat/oat_file_assistant.cc, art/libprofile/profile/profile_compilation_info.cc — https://android.googlesource.com/platform/art/+/refs/heads/main/runtime/verifier/method_verifier.cc Consultados el 12 de agosto de 2026. Secciones 3.2 y 3.5.
6. AOSP — platform/tools/apksig — https://android.googlesource.com/platform/tools/apksig/+/refs/heads/main/ Consultado el 12 de agosto de 2026. Las dieciséis rutas de la tabla de la sección 3.3 se verificaron una a una. Su contenido está desarrollado en 20-firma/01, 02 y 03.
7. AOSP — system/libziparchive y build/tools/zipalign — https://android.googlesource.com/platform/system/libziparchive/+/refs/heads/main/zip_archive.cc y https://android.googlesource.com/platform/build/+/refs/heads/main/tools/zipalign/ZipAlign.cpp Consultados el 12 de agosto de 2026. Sección 3.4. Se comprobó que ZipAlign.cpp está disponible tanto en android.googlesource.com como en el espejo github.com/aosp-mirror/platform_build, que es el que citan 10-formatos/01 y 20-firma/04.
8. AOSP — listado de etiquetas de platform/frameworks/base — https://android.googlesource.com/platform/frameworks/base/+refs Consultado el 12 de agosto de 2026. De aquí sale que la etiqueta más alta es android-17.0.0_r1 y la existencia de android-16.0.0_r1–_r4 y android-15.0.0_r1–_r36 (sección 2.3).
9. Comprobación de resolución de etiquetas entre repositorios — ejecutada con curl el 12 de agosto de 2026 sobre platform/art, platform/tools/apksig y platform/system/libziparchive con las etiquetas android-15.0.0_r1, android-16.0.0_r4 y android-17.0.0_r1: las nueve combinaciones devolvieron HTTP 200. De aquí sale la afirmación de la sección 2.3 de que una misma etiqueta permite leer todos los componentes coherentes entre sí.
10. cs.android.com — https://cs.android.com/android/platform/superproject/main Consultado el 12 de agosto de 2026. Se verificaron los cuatro formatos de enlace de la sección 2.1: la raíz, el enlace a fichero con +/main:<ruta>, el enlace con ;l=<n> y la búsqueda search?q=…&ss=android. Los cuatro devolvieron HTTP 200.
11. Mecanismo ?format=TEXT de Gitiles — comprobado el 12 de agosto de 2026 descargando ResourceTypes.h de la rama main y de la etiqueta android-16.0.0_r4, decodificando con base64 -d. El tamaño de 86.255 bytes de la sección 2.2 es la salida real de wc -c.
12. API de GitHub — https://api.github.com/repos/<org>/<repo> y /contents/<ruta>?ref=<rama> Consultada el 12 de agosto de 2026 para los nueve repositorios de la sección 4 y las rutas de cada uno. De aquí salen íntegras las tablas de las secciones 4.1 a 4.8 y 4.10, la tabla de ramas por defecto de 4.11 y las cinco entradas de rutas inexistentes de la tabla 6.
13. R8 — r8.googlesource.com/r8 — https://r8.googlesource.com/r8/+/refs/heads/main/src/main/java/com/android/tools/r8/naming/ProguardMapReader.java Consultado el 12 de agosto de 2026 con ?format=TEXT. De aquí sale la tabla de la sección 4.9, incluido que ProguardMapWriter.java devuelve 404 y que el lado de escritura es ProguardMapSupplier.java.
14. Documentos ya escritos del corpus — 10-formatos/, 20-firma/, 30-herramientas/ y 40-ofuscacion/ Consultados el 12 de agosto de 2026. La tabla de trazabilidad de la sección 5 se construyó extrayendo con python3 la sección ## Fuentes de los treinta documentos que la tienen y reagrupando por fichero de código, no por documento. Las columnas «qué define» de las secciones 3.1 a 3.5 resumen lo que cada documento declara haber tomado de cada fichero.