Comparativa y selección

1. Qué es y por qué existe

Los cinco documentos anteriores describen unas treinta herramientas, una por una. Este las pone en la misma mesa y responde a la única pregunta que importa cuando hay que empezar a trabajar: cuál usar.

La respuesta no es una recomendación única, porque las herramientas de este ecosistema no son sustitutivas sino complementarias — y esa es exactamente la conclusión del documento. Lo que sí se puede dar es un mapa: qué hace cada una, en qué estado está, y dónde falla. La última columna de la tabla maestra es la que aporta valor; las otras están en cualquier README.

Todos los datos de estado son del 12 de agosto de 2026 y se han verificado uno a uno contra la API de GitHub, crates.io o la página oficial del fabricante. Es el dato que más rápido caduca de todo el corpus: compruébalo antes de instalar nada.

2. Tabla maestra

Estado según el último push al repositorio y la última versión publicada, ambos verificados el 12 de agosto de 2026.

2.1 Leer código

2.2 Desensamblar y editar

2.3 Empaquetar, firmar e instalar

2.4 Analizar

3. Árbol de decisión

                        ¿QUÉ QUIERES HACER?
                                │
    ┌───────────────┬───────────┼───────────┬──────────────┬─────────────┐
    ▼               ▼           ▼           ▼              ▼             ▼
 LEER EL       MODIFICAR Y   FUSIONAR    AUDITAR      AUTOMATIZAR   SABER QUÉ
 CÓDIGO        REINSTALAR     SPLITS    SEGURIDAD       EN CI       ES ESTO
    │               │           │           │              │             │
    ▼               ▼           ▼           ▼              ▼             ▼

«Quiero leer el código»

  ¿el código está en DEX o en lib/*.so?
     │
     ├── DEX ──▶ jadx (o jadx-gui si es exploratorio)
     │             │
     │             └── ¿"JADX ERROR" en lo que me importa?
     │                    ├── sí ──▶ dex2jar + Vineflower  (funciona en ~96 % de esos casos)
     │                    │           └── ¿tampoco? ──▶ baksmali: el smali nunca falla
     │                    └── no ──▶ listo
     │
     └── .so ──▶ Ghidra   (radare2/rizin si son muchos y hay que automatizar)

«Quiero modificar y reinstalar»

  ¿qué toco?
     │
     ├── solo código ──▶ apktool d -r  ──▶ editar smali ──▶ apktool b
     │
     ├── solo recursos ─▶ APKEditor decode -t xml ──▶ editar ──▶ APKEditor build
     │
     └── ambos ────────▶ APKEditor decode  ──▶ editar ──▶ APKEditor build
                              (apktool si necesitas frameworks de fabricante)
                                        │
                                        ▼
                          zipalign -p -f 4   ← SIEMPRE antes de firmar
                                        │
                                        ▼
                          apksigner sign --v2 --v3   ← v1 sola NO se instala
                                        │
                                        ▼
                          apksigner verify --verbose
                                        │
                                        ▼
                          adb install -r

«Quiero fusionar splits»

  .xapk / .apks / .apkm / carpeta de splits
     │
     ├── ¿es un AAB? ──▶ bundletool build-apks + extract-apks
     │
     └── es un contenedor de splits ──▶ APKEditor merge
                                              │
                                              ▼
                                   zipalign  ──▶  apksigner sign
                                   (APKEditor no firma: hay que encadenar)

«Quiero auditar seguridad»

  1. APKiD            ¿packer? ¿ofuscador? ¿reempaquetado?
        │
        ├── hay packer ──▶ PARA. Lo que decompiles es el stub, no la app.
        │                   Detectar e informar; desempaquetar está fuera de alcance.
        │
        ▼
  2. aapt2 dump badging + MobSF     manifiesto, permisos, firma, red, secretos
        │
        ▼
  3. jadx --no-res + semgrep        el código — sabiendo que puede faltar un 5 %
        │
        ▼
  4. Ghidra sobre lib/*.so          si la lógica se movió al nativo
        │
        ▼
  5. Frida                          solo si lo anterior no bastó, y con autorización

«Quiero automatizar en CI»

  Herramientas con modo desatendido real, verificado:
     aapt2 · apksigner · zipalign · bundletool · jadx · apktool · APKEditor
     APKiD · semgrep · radare2 / rizin
  Herramientas que NO sirven:
     Bytecode Viewer · Cutter · jadx-gui · MobSF (es servidor web, se usa por su API)
     y once de las trece herramientas censadas en la sección 4

«Quiero saber qué es este fichero»

  aapt2 dump packagename   ─── el nombre del fichero miente
  aapt2 dump badging       ─── versión, SDK, permisos
  unzip -l | grep toc.pb   ─── ¿APK Set genuino o zip plano de splits?
  APKiD                    ─── cómo se construyó

4. La tesis del ecosistema

Hasta aquí, la selección práctica. Lo que sigue es el hallazgo estructural, y se sostiene con datos de dos procedencias: el censo de las trece herramientas de manipulación de APK que enumera la sección 4.3 —las que se dedican a desempaquetar, editar y reempaquetar, contadas una a una—, y la verificación de estado hecha para este bloque.

4.1 Quién fusiona splits y quién decompila a Java

De las trece herramientas censadas, la matriz de funcionalidades da esto:

Cero. Y no es casualidad ni descuido: es una consecuencia de cómo están construidas. Las que fusionan splits lo hacen con APKEditor o con su biblioteca ARSCLib, y APKEditor no decompila a Java, solo a smali. Las que decompilan a Java lo hacen empotrando jadx, y jadx no fusiona splits. Cada una hereda el punto ciego del motor que empaqueta.

La consecuencia operativa es directa y afecta al caso de uso más común de 2026: para un APK moderno descargado como XAPK o APKS, hay que encadenar dos herramientas. No existe la opción de elegir una.

La tabla maestra de la sección 2 confirma que el hueco no se ha cerrado desde entonces. jadx —sección 2.1— no fusiona; APKEditor —sección 2.2— no decompila a Java. Son las dos herramientas mejor mantenidas de sus respectivas categorías y son estrictamente complementarias.

4.2 Cuántas tienen modo desatendido de verdad

El recuento es tajante: APKEditor es el único con CLI real; todo lo demás del lote es GUI o extensión de editor.

Matizado con la columna de procesamiento por lotes de la matriz: APK Multi Tool y Tickle My Android tienen batch genuino, pero son consolas de texto con menú numerado —Windows, scripts .bat, la de 2016 y la de 2015 respectivamente— y ninguna de las dos está viva. Modo desatendido utilizable hoy, en un pipeline, con códigos de salida: uno de trece.

Y ese uno tampoco cierra el ciclo, porque no firma.

4.3 Cuántas están vivas

Ocho de las trece llevan entre dos y nueve años sin una línea de código. Y no es un matiz académico: cinco de ellas firman con esquema v1 o usan un apktool anterior a 2017, así que el APK que producen no se instala en un Android moderno aunque la decompilación salga bien. La sección 3.4 de Firma y empaquetado reproduce ese fallo con salida real: Target SDK version 36 requires a minimum of signature scheme v2.

El reparto de esquemas de firma del lote:

4.4 La paradoja del mercado

El dato más incómodo del censo:

La herramienta más descargada del sector es la que está abandonada, y por un margen grande: casi el doble que la siguiente. Su apktool congelado ya falla al reempaquetar aplicaciones modernas, el mantenedor no responde desde hace más de un año y medio, y la rama por defecto de su repositorio es una versión que nunca salió.

Es la base de usuarios más grande y más huérfana del ecosistema. Y explica por qué la métrica de descargas no dice nada sobre si una herramienta funciona hoy.

4.5 El bus factor

Tres de las cinco vivas dependen de una sola persona: APKEditor —mismo autor que ARSCLib, del que depende por completo—, APK Editor Studio y APKToolGUI. Puesto al lado de los grupos B y C de la sección 4.3 —ocho de las trece paradas—, es el riesgo que más pesa sobre el lote.

A lo que hay que añadir, de la verificación de este bloque: el crate smali de azw413 tiene 23 estrellas y un autor, y es la única implementación de su clase en Rust.

4.6 Y una advertencia sobre la cadena de suministro

Cinco de las trece son binarios cerrados distribuidos como ZIP por adjuntos de foro, a menudo rehospedados por blogs de terceros, y algunas piden explícitamente desactivar el antivirus antes de instalar. Son herramientas que firman APK.

Los falsos positivos de antivirus son reales y habituales en este tipo de software —APKToolGUI da 0 de 20 motores en su build actual y su autor lo documenta—, pero la diferencia entre un falso positivo verificable y un binario anónimo rehospedado es exactamente la auditabilidad. En cualquier entorno donde importe la trazabilidad de qué firma tus APK, ese patrón es descalificante.

5. Qué falta en el ecosistema

Sumando el censo de la sección 4 y la verificación de estado de este bloque, los huecos son concretos:

1. Nadie cierra el ciclo en un solo binario. Fusionar splits, decompilar, editar, reconstruir, alinear, firmar y verificar exige hoy encadenar entre tres y cinco herramientas de tres proyectos distintos, con formatos intermedios propios y sin contrato entre ellas.

2. Nadie informa de la cobertura de decompilación. Solo el 21 % de las aplicaciones de Play decompilan sin un solo fallo de método, y los fallos son silenciosos. Nadie te dice qué parte de lo que estás leyendo no es lo que la aplicación hace.

3. Nadie audita el requisito de 16 KB. Desde el 1 de febrero de 2027 Google Play no admite actualizaciones sin él. MobSF ni lo reporta.

4. Nadie correlaciona el manifiesto con la política de Play. Todas leen el targetSdk; ninguna responde «esto será rechazado y por qué».

5. Nadie genera un SBOM desde el binario. Ninguna de las herramientas del lote produce un inventario de componentes a partir del APK, y un SBOM derivado del manifiesto miente, porque los SDK embeben componentes propios.

6. Nadie hace diff semántico entre dos APK. diffuse de Jake Wharton solo mira tamaño, dex y arsc, y lleva sin release desde febrero de 2024.

7. Nadie deofusca recursos salvo APKEditor. Su verbo refactor es único en el lote.

8. No existe escritor de resources.arsc en Rust. El crate arsc está abandonado desde 2022 y resand es un proyecto personal. Hay cinco visores; ninguno escribe. Y sin escritor de tabla de recursos no hay editor: hay un visor.

Fuentes

1. Censo de las trece herramientas de manipulación de APK — inventario propio cerrado el 12 de agosto de 2026, con los datos de cada herramienta tomados de su repositorio, su página de descargas y su documentación el 11 y el 12 de agosto de 2026. Las trece están enumeradas una a una en la sección 4.3. De aquí sale íntegra la sección 4: la matriz de funcionalidades con las columnas de merge, Java y batch; la clasificación en grupos A, B y C; el reparto de esquemas de firma; las cifras de descargas; el recuento de cuáles tienen CLI real; y la advertencia sobre la cadena de suministro.
2. A Large-Scale Empirical Study of Android App Decompilation — Noah Mauthe, Ulf Kargén, Nahid Shahmehri. SANER 2021. https://www.ida.liu.se/~ulfka17/papers/SANER2021.pdf Consultado el 12 de agosto de 2026; PDF descargado y extraído con pdftotext. De aquí salen el 21 % de aplicaciones de Play que decompilan enteras, el 2,9 % de fallos de dex2jar, la media ponderada de fallo de Procyon del 4,733 % y el 96 % de complementariedad entre decompiladores citados en las tablas de la sección 2.1 y en el árbol de decisión.
3. Verificación de estado de cada herramienta vía la API de GitHub — https://api.github.com/repos/<org>/<repo> y /releases/latest para: skylot/jadx, pxb1988/dex2jar, leibnitz27/cfr, Vineflower/vineflower, mstrobel/procyon, Konloch/bytecode-viewer, google/smali, JesusFreke/smali, azw413/smali, iBotPeaches/Apktool, REAndroid/APKEditor, REAndroid/ARSCLib, google/bundletool, patrickfav/uber-apk-signer, NationalSecurityAgency/ghidra, radareorg/radare2, rizinorg/rizin, rizinorg/cutter, MobSF/Mobile-Security-Framework-MobSF, rednaga/APKiD, semgrep/semgrep, frida/frida y sensepost/objection. Consultados todos el 12 de agosto de 2026. De aquí salen todas las columnas de licencia, lenguaje, versión, fecha de release y fecha del último push de la tabla maestra de la sección 2.
4. crate smali en crates.io — https://crates.io/api/v1/crates/smali Consultado el 12 de agosto de 2026. De aquí salen la licencia GPL-3.0-only y la versión 0.6.2 del 5 de agosto de 2026 de la fila correspondiente de la sección 2.2.
5. JEB Decompiler — página oficial de PNF Software — https://www.pnfsoftware.com/jeb/ Consultado el 12 de agosto de 2026. De aquí salen la naturaleza comercial, las ediciones y la versión 5.36 de enero de 2026 de la sección 2.1.
6. IDA Pro — página oficial de Hex-Rays — https://hex-rays.com/ida-pro Consultado el 12 de agosto de 2026. De aquí salen el modelo de suscripción y las ediciones de la sección 2.4.
7. Ejecuciones locales sobre el corpus y el SDK — realizadas el 12 de agosto de 2026 con build-tools 37.0.0 (aapt2 2.20-15087165, apksigner 0.9, zipalign, d8, dexdump), bundletool 1.18.3 y OpenJDK 21.0.10 sobre macOS Darwin 25.5.0. De aquí salen las versiones de las herramientas del SDK de la sección 2.3 y las comprobaciones de comportamiento que sostienen sus puntos ciegos, documentadas con salida real en Firma y empaquetado y en Desempaquetado y reempaquetado.
8. Documentos de este corpus — Alineación y zipalign (la fecha del 1 de febrero de 2027 para el requisito de páginas de 16 KB del hueco 3), Mapa del ecosistema (el estado de diffuse del hueco 6) y Tabla de recursos (el estado del ecosistema Rust de resources.arsc del hueco 8).