Especificaciones oficiales

1. Qué es y por qué existe

Este documento es el índice de lo normativo: lo que define el formato, no lo que lo describe. Es el primero de los tres del bloque de referencias porque fija la pregunta que ordena a los otros dos: ¿quién tiene la autoridad sobre cada pieza de un APK?

La respuesta incomoda, y conviene darla antes que nada:

Varios de los formatos centrales del APK no tienen especificación publicada. resources.arsc no la tiene. El XML binario (AXML) tampoco. No hay ningún documento de Google que enumere los campos de ResTable_package ni el layout de un ResStringPool. La autoridad, en esos casos, es el código de AOSP: lo que hace ResourceTypes.cpp al leer el fichero es, por definición, lo que el formato significa.

Esto no es un descuido de la documentación: son formatos internos de la plataforma que nunca se pensaron como un contrato con terceros. Google puede cambiarlos en una release y solo tiene que actualizar su lector y su escritor a la vez. Que exista un ecosistema entero de herramientas dependiendo de ellos es un accidente histórico, no un compromiso adquirido.

La consecuencia práctica para quien implementa es doble. Primera: para DEX, el bytecode, la firma y el ZIP hay spec, y hay que leerla — citar un blog para un dato que está en la especificación es un error. Segunda: para los recursos no la hay, y buscarla es perder el tiempo; hay que ir al código, que es de lo que trata Código fuente de referencia.

2. La autoridad real de cada formato

La tabla que resume todo el bloque. «Tipo de autoridad» distingue tres cosas muy diferentes:

• Spec publicada — un documento con voluntad de contrato, versionado y fechado. Se puede citar un número de sección y esperar que signifique lo mismo dentro de dos años.
• Código fuente — no hay documento. La implementación es la definición. Se cita una ruta de fichero y, si uno es honesto, una etiqueta de release.
• Documentación de producto — una página de developer.android.com que describe el comportamiento de una herramienta. Útil y oficial, pero no es una especificación: no enumera campos, cambia sin aviso y no se versiona.

Las dos filas en negrita son el motivo de existir del documento 02.

2.1 Cómo se lee una ficha de aquí

Cada entrada de las secciones 4 a 12 da título y URL exacta, qué contiene, cuándo consultarla y, cuando aplica, qué revisión se cita. Esa última importa: las specs cambian y las páginas de producto cambian sin dejar rastro. La tabla de §13 las recoge todas.

Todas las URL de este documento se comprobaron el 12 de agosto de 2026 devolviendo HTTP 200; las que redirigen se señalan en su ficha. Informe completo en doc 03 §8.4.

3. Advertencia sobre developer.android.com

Buena parte de lo que sigue vive ahí. Tres cosas que saber antes de citarlo:

1. No se versiona. Una página no dice a qué versión de Android o de AGP corresponde. Hay que mirar la marca «Last updated» del pie, y aun así describe el estado actual.
2. Reorganiza rutas. Las notas de release de AGP se movieron de /build/releases/past-releases/agp-N-N-0-… a /build/releases/agp-N-N-0-…; /build/shrink-code lleva ahora a /topic/performance/app-optimization/enable-app-optimization, y /training/articles/perf-jni a /ndk/guides/jni-tips. Las viejas rutas redirigen — hoy.
3. Discrimina por User-Agent. Con un User-Agent de navegador, curl recibe un 302 hacia accounts.google.com; sin él, 200. Quien automatice la comprobación de enlaces debe saberlo o se llenará de falsos positivos (doc 03 §8.4).

source.android.com es más estable y más cercano a una especificación real. Cuando algo está en los dos sitios, manda source.android.com.

4. Google: el código y el runtime

4.1 Dalvik executable format

https://source.android.com/docs/core/runtime/dex-format Revisión citada: «Last updated 2025-10-03 UTC».

La especificación completa del fichero DEX, y una de las mejores que publica Google. Da header_item campo a campo, los códigos TYPE_* del map_list, las tablas de índices (string_ids, type_ids, proto_ids, field_ids, method_ids), class_data_item, code_item, debug_info_item, encoded_value, el formato de anotaciones, los access_flags y las codificaciones LEB128 y MUTF-8.

Cuándo: siempre que se toque el contenedor DEX. Es la fuente primaria de Formato DEX casi en su totalidad.

Su límite: describe el formato hasta la versión 039. No documenta el DEX de contenedor (versión 041), que sí está en el código (kDexContainerVersion en dex_file.h). Para eso hay que ir a AOSP.

4.2 Dalvik bytecode

https://source.android.com/docs/core/runtime/dalvik-bytecode Revisión citada: «Last updated 2025-01-07 UTC».

La tabla completa de opcodes: para cada uno, su valor, su formato de instrucción, su mnemónico y su semántica. Incluye los sufijos (/2addr, /lit8, /jumbo, /range) y los tres formatos de payload (packed-switch, sparse-switch, fill-array-data).

Cuándo: al escribir un desensamblador o al leer smali sin saberlo de memoria. Fuente principal de Bytecode Dalvik.

4.3 Dalvik executable instruction formats

https://source.android.com/docs/core/runtime/instruction-formats Revisión citada: «Last updated 2024-08-26 UTC».

El complemento imprescindible de la anterior: cómo se disponen los bits dentro de cada instrucción. Define la nomenclatura (35c, 3rc, 21c, 22c, 31c…), las letras de tipo y el layout exacto de cada formato.

Cuándo: en el momento de decodificar bytes de verdad. La tabla de opcodes dice qué hace invoke-virtual; esta dice dónde están sus operandos.

4.4 Multidex

https://developer.android.com/build/multidex — documentación de producto. El límite de 65.536 referencias a método por fichero DEX, el soporte nativo desde API 21 y androidx.multidex para minSdkVersion ≤ 20. El porqué del límite —el campo de 16 bits de los formatos 35c y 22c— está en §4.3, no aquí.

5. Google: la firma

Este es el bloque mejor especificado de todo el APK, y con diferencia. Las cuatro páginas de source.android.com son específicas, completas y estables.

5.1 Application signing (panorámica)

https://source.android.com/docs/security/features/apksigning

En qué versión de Android se introdujo cada esquema, cómo conviven y por qué se recomienda firmar con todos los que admita el rango de SDK. Es la puerta de entrada al bloque.

5.2 APK signature scheme v2

https://source.android.com/docs/security/features/apksigning/v2

La pieza normativa central de la firma moderna. Define las cuatro secciones en que queda dividido el APK, la posición y el layout del APK Signing Block, la cadena mágica APK Sig Block 42, el algoritmo de digest por bloques de 1 MiB con sus prefijos 0xa5 y 0x5a, y la tabla de identificadores de algoritmo de firma.

Cuándo: antes de escribir una sola línea de un verificador. Fuente principal de APK Signing Block.

5.3 APK signature scheme v3 y v3.1

https://source.android.com/docs/security/features/apksigning/v3 https://source.android.com/docs/security/features/apksigning/v3-1

v3 añade la rotación de claves: el proof-of-rotation (0x3ba06f8c) y los campos minSDK/maxSDK. v3.1 separa el bloque para que los dispositivos antiguos no se atraganten con una rotación que no entienden.

Cuándo: al implementar lineage o al explicar por qué un APK trae dos bloques que parecen redundantes.

Su límite: no existe página oficial de v3.2. Sus constantes solo aparecen en el código, y ni siquiera en la rama pública de apksig — se leyeron del apksigner.jar de las build-tools 37.0.0 con javap -constants (20-firma/01 §2).

5.4 APK signature scheme v4

https://source.android.com/docs/security/features/apksigning/v4

El fichero .idsig, el árbol de Merkle, el tamaño de bloque, la sal y la exigencia de que v4 vaya siempre acompañada de una firma v2 o v3. Corta y precisa.

Cuándo: al tratar con instalación incremental. Se lee junto con la documentación de fs-verity del kernel (§12.5), que es donde está la construcción real del árbol.

6. Google: la distribución

6.1 Formato del Android App Bundle

https://developer.android.com/guide/app-bundle/app-bundle-format

La estructura interna del .aab: BUNDLE-METADATA/, root/, la separación de manifest/ y dex/, y qué va en cada módulo.

Cuándo: al abrir un .aab por primera vez. Ojo: es documentación de producto, no especificación. El contrato real de los ficheros .pb está en los .proto, no aquí.

6.2 Los .proto de bundletool

https://raw.githubusercontent.com/google/bundletool/master/src/main/proto/commands.proto https://raw.githubusercontent.com/google/bundletool/master/src/main/proto/config.proto https://raw.githubusercontent.com/google/bundletool/master/src/main/proto/targeting.proto

Esta es la autoridad real sobre el APK Set. commands.proto define BuildApksResult, que es exactamente lo que contiene un toc.pb, con la jerarquía Variant → ApkSet → ApkDescription. config.proto define BundleConfig.

Cuándo: siempre que haya que interpretar un toc.pb o un BundleConfig.pb. Un fichero .proto es una especificación de las buenas: es ejecutable y no puede desincronizarse de la implementación.

6.3 Resources.proto de aapt2

https://android.googlesource.com/platform/frameworks/base/+/refs/heads/main/tools/aapt2/Resources.proto

La versión en protobuf de la tabla de recursos, que es lo que lleva un .aab en lugar de resources.arsc. Define la jerarquía ResourceTable → Package → Type → Entry → ConfigValue.

Cuándo: al comparar el mundo .aab con el mundo .apk. Es, además, la descripción más cercana a una especificación que Google publica del modelo de datos de recursos, aunque sea del formato protobuf y no del binario.

7. Google: la cadena de compilación

7.1 Documentación de producto de las herramientas

Ninguna de estas páginas es una especificación —no enumeran campos ni se versionan—, pero son la única fuente oficial de la sintaxis de cada herramienta.

7.2 R8

https://developer.android.com/topic/performance/app-optimization/enable-app-optimization (la ruta antigua https://developer.android.com/build/shrink-code redirige aquí) https://r8.googlesource.com/r8/+/refs/heads/main/compatibility-faq.md https://r8.googlesource.com/r8/+/refs/heads/main/doc/retrace.md

La primera es la documentación de producto: shrinking, optimización y ofuscación, y el estado del full mode. Las otras dos viven en el repositorio de R8 y son mucho más útiles: compatibility-faq.md enumera las diferencias del full mode frente a ProGuard, y doc/retrace.md es lo más parecido a una especificación del formato mapping.txt que existe: versionado del formato, rango catch-all 0:65535 y semántica de sourceFile, synthesized, rewriteFrame, outline y residualsignature.

Cuándo: retrace.md es obligatorio para cualquiera que analice un mapping.txt. Aun así no cubre la gramática entera; el resto sale de ProguardMapReader.java (doc 02 §4.9).

8. Google: la plataforma y el empaquetado

Las tres primeras son las que más se mueven: las fechas y umbrales que contienen caducan. Ver el procedimiento de revisión en doc 03 §8.

9. Google Play: los requisitos que caducan cada año

https://developer.android.com/google/play/requirements/target-sdk Consultado el 12 de agosto de 2026.

No es una especificación de formato, pero condiciona qué APK existen en circulación, y por eso pertenece a este índice. Estado el día de la consulta:

Esta tabla tiene fecha de caducidad conocida: se queda obsoleta en agosto de 2027. Es el elemento de mantenimiento más previsible de todo el corpus.

El otro requisito con fecha es el de las páginas de 16 KB (§8), que 20-firma/04 §3 sitúa el 1 de febrero de 2027 para targetSdkVersion 35 o superior.

10. Estándares externos: el contenedor

10.1 PKWARE APPNOTE.TXT — .ZIP File Format Specification

https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT Versión 6.3.10, revisada el 1 de noviembre de 2022. Estado: FINAL, sustituye a la 6.3.9. (Los tres datos están en la cabecera del propio fichero y se leyeron de ahí.)

La especificación del ZIP, y por tanto de la capa más externa de todo APK, AAB, .apks, .xapk y .apkm. Define Local File Header, Central Directory, EOCD, las estructuras Zip64, el data descriptor y el bit 3 del campo de flags, y los métodos de compresión.

Cuándo: es la fuente de casi todo Contenedor ZIP.

Trampa de acceso: la URL «bonita» https://support.pkware.com/pkzip/appnote ya no sirve el documento: redirige a una página de producto en pkware.my.site.com. La única dirección comprobada que devuelve el texto es la de cachefly de arriba. ⚠️ sin verificar: no se ha localizado una URL de PKWARE con aspecto de permanente; conviene guardar una copia local del fichero, porque este enlace es de los frágiles.

Su límite, y es grande: la especificación describe el ZIP correcto. No describe qué hace Android con un ZIP incorrecto, que es donde vive la mitad de los problemas reales (divergencia entre Local File Header y Central Directory, data descriptor ausente con el flag puesto). Eso solo está en libziparchive.

10.2 JAR File Specification

https://docs.oracle.com/en/java/javase/21/docs/specs/jar/jar.html (Java SE 21) La edición antigua https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html (Java SE 8) también responde y es la que citan muchas herramientas.

Define META-INF/MANIFEST.MF con su gramática, el límite de 72 bytes por línea y su regla de continuación, los atributos x-Digest-Manifest y x-Digest, los nombres reservados de META-INF/, las extensiones .RSA/.DSA/.EC y el procedimiento de validación.

Cuándo: para todo lo relativo a la firma v1. Es normativa para v1: el JAR signing de Android es el de Java, no una variante.

JEP 238: Multi-Release JAR Files — https://openjdk.org/jeps/238. El atributo Multi-Release: true y la estructura META-INF/versions/<N>/, que aparece en APK reales que empaquetan bibliotecas Java multi-release.

10.3 DEFLATE y ZLIB

https://www.rfc-editor.org/rfc/rfc1951.html — DEFLATE Compressed Data Format Specification version 1.3, mayo de 1996. https://www.rfc-editor.org/rfc/rfc1950.html — ZLIB Compressed Data Format Specification version 3.3, mayo de 1996.

RFC 1951 define el método de compresión 8 del ZIP, que es el que usa casi toda entrada comprimida de un APK. RFC 1950 define Adler-32, que es la suma de comprobación de la cabecera del DEX (bytes 8 a 11).

Cuándo: rara vez hay que implementarlos —hay bibliotecas—, pero RFC 1950 §9 es la definición de Adler-32 que hay que citar si se recalcula la cabecera de un DEX.

11. Estándares externos: la criptografía

Todo lo que un APK firma se apoya en esta pila. Ninguno de estos documentos es específico de Android; todos son normativos.

Cuándo: RFC 5652 y RFC 8017 son las dos que de verdad hacen falta para implementar un verificador; las demás se consultan puntualmente. La tabla de qué algoritmo concreto usa cada identificador no está en ningún RFC: está en SignatureAlgorithm.java de apksig.

12. Estándares externos: codificaciones y binario

12.1 UTF-8, y por qué el DEX no lo usa

https://www.rfc-editor.org/rfc/rfc3629.html — UTF-8, a transformation format of ISO 10646. STD 63, noviembre de 2003. https://www.unicode.org/versions/latest/ — el estándar Unicode vigente. Comprobado el 12 de agosto de 2026: redirige a https://www.unicode.org/versions/Unicode17.0.0/, es decir, la versión en vigor es Unicode 17.0.0.

RFC 3629 define el UTF-8 estándar, que es lo que usa el string pool de resources.arsc y AXML cuando lleva el UTF8_FLAG puesto.

El DEX no usa esto. Usa MUTF-8 (Modified UTF-8), que se aparta del estándar en dos puntos: codifica U+0000 en dos bytes (0xC0 0x80) en vez de uno, y codifica los caracteres fuera del plano básico como pares subrogados de tres bytes cada uno en vez de una secuencia de cuatro. Tratar MUTF-8 como UTF-8 no falla en las cadenas ASCII —que son la inmensa mayoría— y falla en silencio en las demás; es un error clásico.

La definición normativa de MUTF-8 no está en un RFC, sino en la especificación de la JVM: https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html, sección 4.4.7 («The CONSTANT_Utf8_info Structure»). La spec del DEX (§4.1) la describe también, y remite al mismo sitio.

Cuándo: al escribir el lector de cadenas de un DEX. Es la diferencia entre un parser que funciona y uno que corrompe nombres de clase con caracteres no latinos.

12.2 LEB128

https://dwarfstd.org/doc/DWARF5.pdf — DWARF Debugging Information Format, Version 5, 13 de febrero de 2017, DWARF Debugging Information Format Committee. (Título y fecha leídos de la portada del propio PDF.)

LEB128 (Little Endian Base 128) es la codificación de enteros de longitud variable que el DEX usa en casi todas sus estructuras, en las variantes uleb128, sleb128 y uleb128p1. Su origen normativo es DWARF, no Android: Google la tomó prestada.

Cuándo: en la práctica, la descripción de la spec del DEX (§4.1) basta y es más directa. Se cita DWARF por rigor de procedencia y porque su redacción del caso con signo es más clara. ⚠️ sin verificar: no se ha podido confirmar el número exacto de sección de LEB128 dentro del PDF; sí se ha confirmado que el documento la define (188 apariciones del término en el texto extraído).

12.3 Protocol Buffers

https://protobuf.dev/programming-guides/encoding/ — la referencia del wire format. https://protobuf.dev/programming-guides/proto3/ — el lenguaje .proto.

El AAB está hecho de protobuf: BundleConfig.pb, resources.pb, toc.pb. La página de encoding documenta los varints (base 128, con bit de continuación — el mismo principio que LEB128, distinto formato) y los seis wire types: VARINT (0), I64 (1), LEN (2), SGROUP (3), EGROUP (4), I32 (5).

Cuándo: al leer un .pb sin tener el .proto a mano. Con los wire types se puede recorrer un mensaje desconocido y sacar la estructura, que es exactamente lo que hace falta para inspeccionar un toc.pb cuya versión no se conoce.

12.4 ELF

https://refspecs.linuxfoundation.org/elf/gabi4+/contents.html — System V ABI, generic (gABI): ch4.eheader.html para Elf64_Ehdr y e_ident, ch5.pheader.html para Elf64_Phdr y p_align. https://github.com/ARM-software/abi-aa/blob/main/aaelf64/aaelf64.rst — ELF for the Arm 64-bit Architecture (AAELF64).

El gABI es la parte genérica; la parte específica de cada arquitectura vive aparte. En concreto, EM_AARCH64 (183, 0xB7) no está en el gABI: está en AAELF64. Es la constante que más falta hace, porque arm64-v8a es la ABI dominante.

Cuándo: al identificar un .so de lib/<abi>/ o al comprobar la alineación de sus segmentos LOAD para la regla de 16 KB.

12.5 fs-verity

https://docs.kernel.org/filesystems/fsverity.html — documentación del kernel de Linux. Define la construcción del árbol de Merkle, el relleno con ceros del último bloque, el tratamiento de la sal y —el detalle que se escapa— que el digest se calcula sobre la estructura fsverity_descriptor, no sobre la raíz del árbol a secas.

Cuándo: imprescindible para la firma v4. La página de v4 de source.android.com (§5.4) describe el .idsig pero delega en esta la matemática del árbol.

12.6 JNI

https://docs.oracle.com/en/java/javase/21/docs/specs/jni/index.html (Java SE 21) y https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/design.html (Java SE 8, Design Overview). La composición del nombre mangled, la tabla de escapes _0–_3 y la regla del nombre corto frente al largo. Normativa: Android implementa JNI, no lo redefine.

Cuándo: al correlacionar un método native con el símbolo exportado de un .so. La guía de Android (https://developer.android.com/ndk/guides/jni-tips, antes /training/articles/perf-jni) añade RegisterNatives, que es justo lo que rompe esa correlación.

13. Qué revisión se está citando

Resumen de todo lo anterior en un solo sitio. Sin esta tabla la lista no vale para mantener nada: dentro de un año habrá que comparar contra estos valores para saber qué se movió.

14. Lo que ninguna especificación cubre

La lista concreta. Todo lo de aquí solo está en el código, y por eso existe el documento 02:

Un patrón que conviene ver: casi todo lo que no tiene spec es lo que Google no consideró nunca una interfaz pública. Y casi todo eso es precisamente lo que una herramienta de terceros necesita para reescribir un APK.

Fuentes

Todas las URL de esta lista se comprobaron con curl el 12 de agosto de 2026 y devolvieron HTTP 200, salvo donde se indica lo contrario en la ficha correspondiente.

1. Dalvik executable format — https://source.android.com/docs/core/runtime/dex-format Consultado el 12 de agosto de 2026 («Last updated 2025-10-03 UTC»). De aquí sale la ficha 4.1 y la observación de que la spec no cubre la versión 041 del DEX.
2. Dalvik bytecode format — https://source.android.com/docs/core/runtime/dalvik-bytecode Consultado el 12 de agosto de 2026 («Last updated 2025-01-07 UTC»). Ficha 4.2.
3. Dalvik executable instruction formats — https://source.android.com/docs/core/runtime/instruction-formats Consultado el 12 de agosto de 2026 («Last updated 2024-08-26 UTC»). Ficha 4.3.
4. Application signing / APK signature schemes v2, v3, v3.1 y v4 — https://source.android.com/docs/security/features/apksigning , https://source.android.com/docs/security/features/apksigning/v2 , https://source.android.com/docs/security/features/apksigning/v3 , https://source.android.com/docs/security/features/apksigning/v3-1 , https://source.android.com/docs/security/features/apksigning/v4 Consultadas el 12 de agosto de 2026. De aquí sale íntegra la sección 5.
5. Formato del Android App Bundle — https://developer.android.com/guide/app-bundle/app-bundle-format Consultado el 12 de agosto de 2026. Ficha 6.1.
6. google/bundletool: commands.proto, config.proto, targeting.proto — https://raw.githubusercontent.com/google/bundletool/master/src/main/proto/commands.proto Consultado el 12 de agosto de 2026. Ficha 6.2; la jerarquía Variant → ApkSet → ApkDescription se toma de 10-formatos/06.
7. frameworks/base/tools/aapt2/Resources.proto — https://android.googlesource.com/platform/frameworks/base/+/refs/heads/main/tools/aapt2/Resources.proto Consultado el 12 de agosto de 2026. Ficha 6.3.
8. bundletool, aapt2, d8, apksigner, zipalign, retrace, apkanalyzer — documentación de producto — https://developer.android.com/tools/bundletool , https://developer.android.com/tools/aapt2 , https://developer.android.com/tools/d8 , https://developer.android.com/tools/apksigner , https://developer.android.com/tools/zipalign , https://developer.android.com/tools/retrace , https://developer.android.com/tools/apkanalyzer Consultadas el 12 de agosto de 2026. De aquí sale íntegra la tabla de la ficha 7.1, y la redirección de /studio/command-line/apkanalyzer registrada en la sección 3.
9. Enable app optimization with R8 — https://developer.android.com/topic/performance/app-optimization/enable-app-optimization Consultado el 12 de agosto de 2026. Ficha 7.2; se comprobó que https://developer.android.com/build/shrink-code redirige aquí.
10. R8: compatibility-faq.md y doc/retrace.md — https://r8.googlesource.com/r8/+/refs/heads/main/compatibility-faq.md y https://r8.googlesource.com/r8/+/refs/heads/main/doc/retrace.md Consultados el 12 de agosto de 2026. De aquí sale la afirmación de que retrace.md es lo más parecido a una especificación de mapping.txt que existe (ficha 7.2).
11. Páginas de plataforma y empaquetado de Android — las nueve URL de la tabla de la sección 8, consultadas el 12 de agosto de 2026. Su contenido concreto está desarrollado en 10-formatos/07, 10-formatos/08 y 20-firma/04.
12. Target API level requirements for Google Play apps — https://developer.android.com/google/play/requirements/target-sdk Consultado el 12 de agosto de 2026. De aquí sale íntegra la tabla de la sección 9, incluidas la fecha del 31 de agosto de 2026 y la prórroga hasta el 1 de noviembre de 2026.
13. APPNOTE.TXT — .ZIP File Format Specification, versión 6.3.10 — https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT Consultado el 12 de agosto de 2026. La versión, el estado FINAL y la fecha del 1 de noviembre de 2022 se leyeron de la cabecera del propio fichero. Se comprobó además que https://support.pkware.com/pkzip/appnote redirige a una página de producto y no sirve el documento.
14. JAR File Specification y JEP 238 — https://docs.oracle.com/en/java/javase/21/docs/specs/jar/jar.html , https://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html y https://openjdk.org/jeps/238 Consultadas el 12 de agosto de 2026. Fichas 10.2 y 10.3.
15. RFC 1950, 1951, 2315, 3629, 5280, 5652, 7292 y 8017 — https://www.rfc-editor.org/rfc/rfc1950.html y las siete homólogas. Consultadas el 12 de agosto de 2026. Los títulos, autores, fechas y estados de las tablas de las secciones 10.3, 11 y 12.1 se leyeron de la cabecera de cada RFC, no de fuentes secundarias.
16. FIPS 180-4 — Secure Hash Standard — https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf Consultado el 12 de agosto de 2026. Fila correspondiente de la tabla de la sección 11.
17. JVM Specification (Java SE 21) y The Unicode Standard — https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-4.html y https://www.unicode.org/versions/latest/ Consultadas el 12 de agosto de 2026. De aquí sale que la definición normativa de MUTF-8 es la sección 4.4.7 de la spec de la JVM, y que versions/latest/ redirige a Unicode17.0.0, lo que fija la versión vigente (ficha 12.1).
18. DWARF Debugging Information Format, Version 5 — https://dwarfstd.org/doc/DWARF5.pdf Consultado el 12 de agosto de 2026. El título y la fecha del 13 de febrero de 2017 se leyeron de la portada del PDF descargado; la presencia de la definición de LEB128 se confirmó extrayendo el texto del PDF con python3 y zlib (188 apariciones del término).
19. Protocol Buffers — Encoding y Language Guide (proto 3) — https://protobuf.dev/programming-guides/encoding/ y https://protobuf.dev/programming-guides/proto3/ Consultadas el 12 de agosto de 2026. De aquí salen los seis wire types y la descripción de los varints de la ficha 12.3.
20. System V ABI (gABI), capítulos 4 y 5 — https://refspecs.linuxfoundation.org/elf/gabi4+/contents.html Consultado el 12 de agosto de 2026. Ficha 12.4.
21. ELF for the Arm 64-bit Architecture (AAELF64) — https://github.com/ARM-software/abi-aa/blob/main/aaelf64/aaelf64.rst Consultado el 12 de agosto de 2026. De aquí sale que EM_AARCH64 no está en el gABI.
22. fs-verity — documentación del kernel de Linux — https://docs.kernel.org/filesystems/fsverity.html Consultado el 12 de agosto de 2026. Ficha 12.5.
23. Java Native Interface Specification — https://docs.oracle.com/en/java/javase/21/docs/specs/jni/index.html y https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/design.html Consultadas el 12 de agosto de 2026. Ficha 12.6; se comprobó que https://developer.android.com/training/articles/perf-jni redirige a /ndk/guides/jni-tips.
24. Secciones ## Fuentes de los demás documentos del corpus — extraídas el 12 de agosto de 2026 con un guion en python3 que recorrió todos los .md del corpus y las agrupó por documento. De ahí sale la base de este índice y las columnas «qué contiene» de casi todas las fichas.
25. Comprobación de enlaces — 286 URL verificadas con curl -sSL -o /dev/null -w '%{http_code}\t%{url_effective}' el 12 de agosto de 2026, sin User-Agent. De aquí salen la advertencia de la sección 3 y el informe de doc 03 §8.4.