Código fuente de referencia

1. Qué es y por qué existe

El documento anterior termina con una lista de trece 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 pasado. aosp-main es de solo lectura desde el 27 de marzo de 2025: Google desarrolla en interno y publica el código en ramas de release dos veces al año, y el manifiesto android-latest-release apunta siempre a la más reciente —android17-release el 24 de septiembre de 2026—. El último commit de main es del 26 de marzo de 2025 en platform/frameworks/base y platform/art, y del 8 de marzo en platform/tools/apksig. Lo que no aparece en main puede ser, simplemente, posterior: es lo que pasó con la firma v3.2, que está en la etiqueta android-17.0.0_r1 y no en main. La «sección 2.3 · La regla: fijar una etiqueta, no leer main» 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 esta documentación 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.) La orden lleva refs/heads/main a propósito, como ejemplo de lo que la «sección 2.3 · La regla: fijar una etiqueta, no leer main» desaconseja: esa rama está congelada desde el 27 de marzo de 2025 y el fichero que baja no es el vigente. Con la etiqueta android-17.0.0_r1, el mismo ResourceTypes.h tiene 90.638 bytes, no 86.255, y kIdmapCurrentVersion pasa de 0x0000000Au a 0x0000000Bu (comprobado el 25 de septiembre de 2026).

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. Esta documentación ya usa la 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 algo «no existe» cuando está en la última release.

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 · Ramas por defecto y estado — comprobado el 12 de agosto de 2026»). 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 90 KB en android-17.0.0_r1 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, a propósito en main para ilustrar el error de la «sección 2.3 · La regla: fijar una etiqueta, no leer main»: https://android.googlesource.com/platform/tools/apksig/+/refs/heads/main/. Esa rama no recibe commits desde marzo de 2025 y le falta v3.2 (abajo); para leer lo vigente, refs/tags/android-17.0.0_r1. 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á en main: las constantes de v3.2, que llegaron después de congelarse la rama. Están en la etiqueta android-17.0.0_r1: V3SchemeConstants.java trae APK_SIGNATURE_SCHEME_V32_BLOCK_ID = 0x70e1c89f, MIN_SDK_WITH_V32_SUPPORT = AndroidSdkVersion.C, que vale 37, y los atributos 0xbf940529 y 0x9f06b79c («20-firma/01 §7»). Y los identificadores de bloque de terceros —dependency metadata, frosting, Meituan— no están en AOSP en absoluto: para eso, «§4.10 · avast/apkverifier — rama master».

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: third_party/smali/ no es un duplicado. Es la ubicación canónica de las fuentes BSD heredadas de JesusFreke. De los 964 ficheros del repositorio (recontados el 25 de septiembre de 2026), 40 cuelgan de ahí y 36 no existen en ninguna otra ruta —third_party/baksmali/…/Baksmali.java, los diez de Adaptors/, LiteralTools.java, util/Hex.java—: pedir la versión sin prefijo devuelve 404. Android.bp tiene un homónimo distinto en la raíz, y las tres gramáticas .g sí aparecen fuera, pero son symlinks de menos de 120 bytes que apuntan hacia dentro —el repositorio tiene un cuarto, el LICENSE de la raíz— (smali/src/main/antlr/smaliParser.g → ../../../../third_party/smali/src/main/antlr/smaliParser.g). Trampa al verificar: la API de contenidos de GitHub resuelve esos symlinks y devuelve el fichero real con "type":"file", así que una comprobación por esa vía no detecta nada; el stub solo se ve con raw.githubusercontent.com, con la vista blob o listando el árbol.

4.4 ARSCLib — rama main

La reimplementación en Java de los formatos de recursos, sin aapt2. Es la referencia de diseño obligada de cualquier reimplementación.

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 · ARSCLib — rama main»). 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 aquí se 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 · Los .proto de bundletool») 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 §4» 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 muestrario: 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/tags/android-17.0.0_r1/libs/androidfw/ Consultado el 25 de septiembre de 2026. De aquí sale la tabla de la «sección 3.1 · Los recursos — la autoridad sin especificación». 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/tags/android-17.0.0_r1/tools/aapt2/ Consultado el 25 de septiembre 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/tags/android-17.0.0_r1/libdexfile/dex/dex_instruction.h Consultado el 25 de septiembre 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 · El código — DEX y bytecode». 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/tags/android-17.0.0_r1/ Consultado el 25 de septiembre 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 · El código — DEX y bytecode» 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/tags/android-17.0.0_r1/runtime/verifier/method_verifier.cc Consultados el 25 de septiembre de 2026. Secciones «3.2» y «3.5».
6. AOSP — platform/tools/apksig — https://android.googlesource.com/platform/tools/apksig/+/refs/tags/android-17.0.0_r1/ Consultado el 25 de septiembre de 2026. Las dieciséis rutas de la tabla de la «sección 3.3 · La firma — tools/apksig» 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/tags/android-17.0.0_r1/zip_archive.cc y https://android.googlesource.com/platform/build/+/refs/tags/android-17.0.0_r1/tools/zipalign/ZipAlign.cpp Consultados el 25 de septiembre de 2026. «Sección 3.4 · El contenedor — ZIP y alineación». 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 · La regla: fijar una etiqueta, no leer main»).
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 · La regla: fijar una etiqueta, no leer main» 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 · cs.android.com — navegar y buscar»: 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 · android.googlesource.com — el fichero crudo y fijado» 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 · Herramientas de la comunidad: por dónde se entra» y las rutas de cada uno. De aquí salen íntegras las tablas de las «secciones 4.1 · jadx — rama master» 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 · R8 — r8.googlesource.com, rama main», incluido que ProguardMapWriter.java devuelve 404 y que el lado de escritura es ProguardMapSupplier.java.
14. Documentos ya escritos de esta documentación — «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 · Tabla de trazabilidad» 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 · Los recursos — la autoridad sin especificación» a 3.5 resumen lo que cada documento declara haber tomado de cada fichero.
15. API de GitHub — árbol de google/smali — https://api.github.com/repos/google/smali/git/trees/main?recursive=1 · Consultado el 25 de septiembre de 2026. De aquí sale que smali/src/main/antlr/smaliParser.g tiene modo 120000 (symlink) y apunta a third_party/smali/src/main/antlr/smaliParser.g (secciones «4.3» y «6»).