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 muestrario: 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  (ver nota)
     │                    │           └── ¿tampoco? ──▶ baksmali: el smali nunca falla
     │                    └── no ──▶ listo
     │
     └── .so ──▶ Ghidra   (radare2/rizin si son muchos y hay que automatizar)

Nota: el estudio de la fuente 1 encontró que, en el ~96 % de los métodos en que jadx falló, al menos uno de CFR, Fernflower o Procyon lo decompiló. Se midió solo sobre F-Droid, sin Vineflower, y el propio estudio pide tomarlo como orientativo («indicative, rather than exact»).

«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 16 -f 4   ← SIEMPRE antes de firmar
                                        │
                                        ▼
              apksigner sign --v2-signing-enabled true \
                             --v3-signing-enabled true
                                        │      ↑ v1 sola NO se instala
                                        ▼
                          apksigner verify --verbose
                                        │
                                        ▼
              adb uninstall <paquete> && adb install app.apk
                  ↑ refirmado = otra clave: no se puede actualizar
                    encima, y desinstalar borra los datos

«Quiero fusionar splits»

  ¿qué tengo delante?
     │
     ├── un .aab ──▶ bundletool build-apks --mode=universal ──▶ universal.apk
     │                    (sin --ks: firma de depuración, o ninguna; --mode por defecto + extract-apks
     │                     da varios APK para un dispositivo, no uno fusionado)
     │
     └── .xapk / .apks / .apkm / carpeta 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 de la evaluación de origen

«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: la evaluación de trece herramientas de manipulación de APK que hay detrás de esta documentación, 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 evaluadas, 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 depende de qué se quiera, y afecta al caso de uso más común de 2026. Para leer el código de un APK moderno descargado como XAPK, APKS o APKM basta jadx, que abre esos contenedores directamente («sección 2.1 · Leer código»). Para sacar de él un APK único e instalable, además de leerlo, hay que encadenar dos herramientas: no existe la opción de elegir una.

La tabla maestra de la «sección 2 · Tabla maestra» confirma que el hueco no se ha cerrado desde entonces. jadx —«sección 2.1 · Leer código»— no fusiona; APKEditor —«sección 2.2 · Desensamblar y editar»— 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

La evaluación 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 · Por qué firmar solo en v1 hoy es no firmar» 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 de la evaluación:

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. Es lo que ha matado a la mitad del lote evaluado.

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 la evaluación de origen y la verificación 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. El Cyber Resilience Act europeo lo exige entre sus obligaciones principales, que se aplican desde el 11 de diciembre de 2027; desde el 11 de septiembre de 2026 solo rigen las de notificación. 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 hay escritor de resources.arsc en Rust mantenido ni con adopción. Existir, existen dos: el crate arsc (0.1.5) escribe, pero lleva abandonado desde abril de 2022; y resand (0.3.0, mayo de 2026) lee y escribe arsc y AXML, pero es un proyecto de un solo autor, en Codeberg y sin adopción. Los cinco visores restantes solo leen. Y sin un escritor fiable de tabla de recursos no hay editor: hay un visor.

Fuentes

1. 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 · Leer código» y en el árbol de decisión.
2. 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 · Tabla maestra».
3. 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 · Desensamblar y editar».
4. 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 · Leer código».
5. 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 · Analizar».
6. Ejecuciones locales sobre el «muestrario» 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 · Empaquetar, firmar e instalar» y las comprobaciones de comportamiento que sostienen sus puntos ciegos, documentadas con salida real en «Firma y empaquetado» y en «Desempaquetado y reempaquetado».