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 · Código fuente de referencia».

2.1 Cómo se lee una ficha de aquí

Cada entrada de las «secciones 4 · Google: el código y el runtime» 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 · Qué revisión se está citando» 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 alcance: llega hasta la 040 —la de Android 10, que amplió los caracteres admitidos en SimpleName, con anotaciones «since DEX version 040» en la gramática— y sí documenta el DEX de contenedor en una sección propia, «Container format»: «Version 41 introduces a new container format for DEX data», más la semántica v41 de file_size, header_size = 0x78, data_size y data_off como «Unused (v41 or later)» y los campos nuevos container_size y header_offset. La marca como experimental en Android 16. La constante kDexContainerVersion = 41 está además en art/libdexfile/dex/dex_file.h.

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 índice meth@ de 16 bits de los formatos 35c y 3rc, los de las invocaciones— está en «§4.3 · Dalvik executable instruction formats», 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 cubre v3.2, la firma híbrida de Android 17, que tiene página propia: https://source.android.com/docs/security/features/apksigning/v3-2. Su código está en la etiqueta android-17.0.0_r1 de apksig, no en la rama main, congelada desde marzo de 2025 («20-firma/01 §7»).

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 · fs-verity»), 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/tags/android-17.0.0_r1/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 toda esta documentación.

El otro requisito con fecha es el de las páginas de 16 KB («§8 · Google: la plataforma y el empaquetado»), 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 del dominio principal, https://www.pkware.com/documents/casestudies/APPNOTE.TXT, sí devuelve texto, pero la versión 6.3.9 de julio de 2020, desde una copia en pkwaredownloads.blob.core.windows.net. El mismo CDN de arriba publica la versión con su número en la ruta, https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.10.TXT, byte a byte idéntica (SHA-256 0b993022…a50cd6, mismo ETag): es lo más parecido a una dirección permanente, porque no cambiará de contenido cuando salga otra versión, aunque ninguna página de PKWARE la enlace. Comprobado el 25 de septiembre de 2026. Aun así, conviene guardar una copia local con su SHA-256.

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 la base de v1, pero Android no la sigue al pie de la letra. apksig lo dice en V1SchemeVerifier: «Android's APK verification logic differs from that spec». La spec mete en el manifiesto los ficheros de los subdirectorios de META-INF/ y los de META-INF/ que no son de firma, y Android no exige digest de nada bajo META-INF/; además, el .SF de Android lleva X-Android-APK-Signed, que Java no conoce. Un verificador escrito solo con esta spec no se comporta como el de Android.

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 el apartado 9 de la RFC 1950 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 24 de septiembre de 2026: redirige a https://www.unicode.org/versions/Unicode18.0.0/, es decir, la versión en vigor es Unicode 18.0.0 (el 12 de agosto aún era la 17.0.0).

RFC 3629 define el UTF-8 estándar, y el string pool de resources.arsc y AXML con el UTF8_FLAG puesto casi lo es: aapt2 pasa cada cadena por Utf8ToModifiedUtf8, que sustituye cada carácter fuera del BMP —cuatro bytes en UTF-8— por dos subrogados de tres bytes, al estilo de CESU-8. Para el BMP coincide con RFC 3629; con un emoji, no.

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 · Dalvik executable format») 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 · Dalvik executable format») 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. LEB128 está en la sección 7.6, «Variable Length Data» (páginas 221-222, con los ejemplos de las tablas 7.7 y 7.8), y los algoritmos de codificación y decodificación, en el apéndice C, «Variable Length Data: Encoding/Decoding (Informative)» (página 283).

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. Ojo con la versión: la de refspecs es un borrador de 2001, y en él EM_AARCH64 (183, 0xB7) no está. Sí está en el gABI mantenido (https://www.sco.com/developers/gabi/latest/ch4.eheader.html) y 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 · APK signature scheme v4») 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 describe la versión 041 del DEX en «Container format», pero la da por experimental en Android 16.
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 · Google: la firma».
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/tags/android-17.0.0_r1/tools/aapt2/Resources.proto Consultado el 25 de septiembre 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 · Advertencia sobre developer.android.com».
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 · Google: la plataforma y el empaquetado», 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 · Google Play: los requisitos que caducan cada año», 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 · Estándares externos: la criptografía».
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/ redirigía a Unicode17.0.0; el 24 de septiembre de 2026 ya redirige a Unicode18.0.0 (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. Define EM_AARCH64, que el borrador de la fuente 20 no tiene y el gABI mantenido sí (fuente 25).
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. 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 · Advertencia sobre developer.android.com» y el informe de «doc 03 §8.4».
25. System V ABI (gABI) mantenido, capítulo 4 — https://www.sco.com/developers/gabi/latest/ch4.eheader.html Consultado el 24 de septiembre de 2026. Lista EM_AARCH64 183 (ficha 12.4).