Mapa del ecosistema

1. Por qué hace falta un mapa

Quien llega al dominio se encuentra treinta nombres —jadx, apktool, APKEditor, ARSCLib, baksmali, dex2jar, MobSF, APKiD, JEB— sin ninguna forma evidente de saber cuáles siguen vivos, cuál hace qué y cuál puede usar dentro de un producto. Las listas que circulan por la red no ayudan: mezclan herramientas mantenidas con proyectos que llevan ocho años sin un commit, y casi nunca dicen la licencia.

Este documento pone eso en orden con datos medidos, no con opiniones: repositorio, licencia exacta, lenguaje, última release, última actividad y concentración de autoría, todo consultado el 12 de agosto de 2026 contra la API pública de GitHub y las páginas oficiales de cada proyecto. Los nombres de formato y de concepto que aparecen aquí —AXML, resources.arsc, DEX, smali, split, packer, mapping.txt— están definidos en el glosario y explicados en Anatomía de un APK.

De ese ejercicio salen tres conclusiones que conviene adelantar, porque cambian cómo se lee el resto:

1. El ecosistema tiene dos mitades con incentivos opuestos. Google construye para el que hace la aplicación; la comunidad, para el que la abre. Ninguna herramienta oficial está pensada para analizar código ajeno, y eso explica los huecos de la sección 5.
2. La mitad que importa depende de muy poca gente. Nueve de los proyectos medidos tienen un solo autor por encima del 85 % de los commits, y tres de los más usados llevan más de un año sin una sola línea nueva (sección 4).
3. La licencia decide la arquitectura, no el marketing. Que jadx sea Apache-2.0 y el crate smali sea GPL-3.0-only es la diferencia entre embeber y aislar en un subproceso (sección 6).

2. Las tres familias

2.1 Google y AOSP: el instrumental del que construye

Todo lo que hace falta para producir un APK lo publica Google, está en el SDK y funciona. Son las mismas herramientas que se han ejecutado en la sección 2.6 de Anatomía de un APK.

Dos matices que la versión corta de esta lista suele perder.

No todas son Apache-2.0. D8 y R8 son BSD-3-Clause («Copyright (c) 2016, the R8 project authors»), y smali/baksmali es BSD-3-Clause de Ben Gruver: Google adoptó el proyecto pero no lo relicenció. apksig, bundletool, aapt2, zipalign y dexdump sí son Apache-2.0. Para embeber, la diferencia importa poco —ambas familias son permisivas— pero para atribuir, no: BSD-3-Clause obliga a reproducir el aviso de copyright y Apache-2.0 añade la concesión de patentes y la obligación de señalar los cambios.

Y todas tienen el mismo sesgo: están hechas para el desarrollador que tiene el código fuente delante. aapt2 compila pero no descompila una tabla de recursos a un árbol res/ editable; apksigner firma y verifica pero no diagnostica por qué falló; bundletool genera splits pero no los fusiona. Google no publica ninguna herramienta para abrir una aplicación ajena, y esa ausencia es la razón de existir de la familia siguiente.

2.2 La comunidad: el instrumental del que analiza

Aquí está todo lo que Google no hace. Por función:

Tres cosas que conviene saber de esta familia antes de mirar la tabla de la sección 3.

No hay redundancia. Para casi cada función hay un proyecto de referencia y ninguna alternativa comparable. Solo la decompilación a Java tiene dos rutas de verdad, y la segunda —dex2jar más un decompilador de Java— depende de un proyecto sin commits desde julio de 2024.

Están encadenados. APKEditor es una interfaz de línea de órdenes sobre ARSCLib, y ambos son del mismo autor. APKLab orquesta Apktool, jadx y uber-apk-signer. Apk Studio orquesta Apktool y jadx. Un fallo en Apktool sale simultáneamente en cuatro herramientas.

Ninguna cierra el ciclo. Es la conclusión que la sección 5 desarrolla con datos.

2.3 Comercial

Los dos primeros son herramientas para el analista; los tres últimos son herramientas contra el analista, y aparecen en este corpus porque hay que saber identificarlas. Ver Ofuscadores comerciales y Packers y protectores.

Precios verificados. PNF Software publica los suyos: JEB Android 1.200 $ por usuario y año, JEB Pro 2.000 $, JEB Pro Floating 4.000 $ por asiento y JEB Pro OEM 8.000 $ por servidor y año. ⚠️ sin verificar: los precios de IDA Pro, DexGuard, DexProtector y Virbox no son públicos —Hex-Rays sirve su tabla por JavaScript y los otros tres piden contacto comercial—, así que este documento no da ninguna cifra para ellos.

3. Tabla maestra verificada

3.1 Cómo se ha medido

• Licencia, lenguaje, fecha del último push, estado de archivado y número de issues abiertas: endpoint GET /repos/{org}/{repo} de la API de GitHub, consultado el 12 de agosto de 2026.
• Última release: GET /repos/{org}/{repo}/releases/latest. Cuando un proyecto no publica releases, la columna dice —.
• Licencias que GitHub clasifica como NOASSERTION: resueltas leyendo el fichero de licencia del propio repositorio.
• Fechas en formato ISO AAAA-MM-DD.

Tres avisos sobre lo que estos números no dicen. pushed_at marca el último empujón a cualquier rama, y puede ser un commit de un bot de dependencias: la sección 4 separa las dos cosas. open_issues_count de la API suma issues y pull requests abiertos, así que la columna «Issues» es una cota superior. Y las estrellas miden notoriedad, no salud; están en la tabla porque calibran el tamaño de la comunidad, no porque signifiquen que algo funcione.

3.2 Google y AOSP

zipalign y dexdump no tienen release propia: se versionan con las build-tools. Las fechas «(Maven)» son la de lastUpdated del maven-metadata.xml del artefacto, que es lo más cercano a una fecha de publicación que expone maven.google.com.

3.3 Comunidad

Cuatro lecturas inmediatas de esa tabla:

• CFR lleva casi cinco años sin release (0.152, diciembre de 2021) pero recibió commits en junio de 2026. Es el caso que demuestra que mirar solo la fecha de release engaña, y también al revés.
• dex2jar y uber-apk-signer están congelados. Uno es la mitad de la ruta alternativa de decompilación; el otro, el firmador que embeben APKLab y Apk Studio.
• APKEditor y ARSCLib son el mismo autor. Es el único camino del ecosistema para fusionar splits, y depende de una persona.
• Cuatro proyectos están formalmente archivados —JesusFreke/smali, Obfuscapk, ClassyShark— o inactivos de hecho —enjarify—, y los tres primeros aún aparecen como recomendación en listas y tutoriales que circulan hoy.

4. Bus factor y salud del ecosistema

Es la sección con más valor de este documento, y la que sostiene su tesis más incómoda: el bus factor es lo que ha matado a buena parte de las herramientas que aparecen en este mapa.

4.1 La medida

Tres números por proyecto, todos del endpoint de contribuidores y del listado de commits de la API de GitHub, consultados el 12 de agosto de 2026:

• Concentración histórica: porcentaje de commits del autor principal sobre el total de todos los contribuidores del repositorio.
• Commits en los últimos 12 meses: desde el 12 de agosto de 2025, sobre la rama por defecto.
• Autores humanos en esos 12 meses: cuántas personas distintas han hecho al menos un commit. Los bots se descuentan, porque un repositorio con 116 commits de renovate[bot] y 5 de su autor no está más vivo que uno con 5 commits.

4.2 La tabla

4.3 Qué dice, leída de arriba abajo

Tres proyectos están muertos y aún se recomiendan. APK Editor Studio, dex2jar y uber-apk-signer tienen cero commits en doce meses. Y los tres son casos distintos de lo mismo:

• APK Editor Studio lleva desde enero de 2025 sin un commit, con su rama por defecto llamada 1.8.0, una versión que nunca salió. Un único autor, con el 100 % de los commits. Además embebe Apktool en vez de descargarlo, así que sus usuarios están anclados a una versión congelada que ya falla al reempaquetar aplicaciones modernas.
• dex2jar tiene 13.132 estrellas, 379 issues abiertas y ningún commit desde julio de 2024. Es la puerta de entrada de toda la ruta «DEX → .jar → decompilador de Java», que sigue siendo la alternativa estándar a jadx.
• uber-apk-signer es el firmador que embeben APKLab y Apk Studio. Su última release es de febrero de 2023. Un cambio en los esquemas de firma de Android no llega a sus usuarios.

Los dos proyectos críticos para la fusión de splits son de una sola persona. ARSCLib concentra el 97 % de los commits en REAndroid y tuvo dos autores humanos en un año; APKEditor, el 93 % y tres. Y no son dos proyectos independientes: APKEditor está construido sobre ARSCLib y ambos son del mismo autor, así que en la práctica es un bus factor de 1 para la única herramienta del ecosistema que fusiona splits. La app de Android más usada para des-splitear, AntiSplit-M, también está construida sobre ARSCLib. Es una dependencia de tres niveles sobre una persona.

Los proyectos sanos comparten un patrón. jadx (31 autores humanos en un año), Vineflower (12), MobSF (12) y Apktool (8) tienen una comunidad real por debajo del mantenedor principal. No es casualidad que sean también los que tienen gobernanza visible: jadx y MobSF publican código de conducta y guía de contribución; Apktool, guía de contribución. Ninguno de los tres proyectos muertos tenía nada de eso. Matiz honesto: en MobSF, once de esos doce autores aportaron un solo commit en todo el año, así que la anchura de la base es menor de lo que parece; en Vineflower y en jadx la carga sí está repartida de verdad.

Los números altos de commits no siempre son vida. diffuse acumula 135 commits en doce meses, de los que 116 son de renovate[bot] y 5 de su autor. Su última release es de febrero de 2024. El repositorio se mantiene al día en dependencias mientras el producto no avanza; y un observador que solo mire pushed_at lo clasificaría como activo.

Y hay un caso de sucesión bien hecha, que conviene señalar porque es el único: cuando Ben Gruver dejó smali/baksmali, Google adoptó el proyecto en google/smali conservando la licencia BSD-3-Clause original, y el repositorio de origen se archivó apuntando al nuevo. Es lento —16 commits en doce meses, y la última release es de mayo de 2024— pero está vivo y tiene respaldo institucional.

4.4 Qué pasa cuando uno muere

No desaparece de golpe: se degrada en cuatro fases, y reconocerlas ahorra tiempo.

1. Las issues dejan de responderse y siguen abriéndose. Es la primera señal, y es visible: 379 issues abiertas en dex2jar, 441 en jadx —que sí responde—, 55 en APK Editor Studio.
2. Las dependencias se congelan. El proyecto sigue funcionando pero con la versión de Apktool, de aapt2 o del SDK que tenía el día que se paró.
3. Empieza a fallar sobre entradas nuevas. Un targetSdk nuevo, un esquema de firma nuevo, un formato de contenedor nuevo. El usuario lo vive como «esta herramienta ya no funciona con esta app», sin saber por qué.
4. Alguien forkea, o nadie. Lo primero pasó con APKToolGUI, cuyo fork de AndnixSH desplazó al original y es el que sigue publicando releases (sección 3.3). Lo segundo es lo normal.

La mitigación conocida es aburrida y funciona: CI pública, gobernanza abierta y no embeber los motores externos, sino descargarlos. APKLab hace lo último y por eso hereda las correcciones de Apktool y jadx sin re-empaquetarlas; APK Editor Studio hace lo contrario y por eso arrastró a sus usuarios a un Apktool congelado.

5. Los huecos del ecosistema

Cruzar las funciones de la sección 2.2 con la tabla de la sección 3 lleva a una conclusión incómoda: ninguna herramienta cierra el ciclo completo.

5.1 Quién fusiona y quién decompila

La casilla que falta en todas las filas es la misma. Las que unen splits no decompilan a Java; las que decompilan a Java no unen splits. Para un APK moderno descargado como .xapk o .apks —que es la forma normal de conseguir una aplicación de Play fuera de Play— hay que encadenar dos herramientas.

5.2 Interfaz gráfica frente a modo desatendido

Buena parte del instrumental de manipulación son interfaces gráficas o extensiones de editor sin modo desatendido de verdad: APKLab vive dentro de VS Code, Apk Studio es un IDE de escritorio, APKToolGUI es una GUI de Windows y APK Editor Studio una GUI de metadatos (sección 3.3). Eso las descarta para CI, para análisis por lotes y para cualquier flujo automatizado, y deja el trabajo guionizable en los motores que envuelven. Ghidra, radare2, MobSF y APKiD sí tienen modo headless, pero ninguno de los cuatro hace merge, edición ni reempaquetado.

5.3 Lo que no hace nadie

Estos son los huecos que ninguna herramienta del ecosistema cubre, cada uno con lo más cercano que existe:

Ese conjunto de casillas vacías es el diagnóstico honesto del ecosistema: los huecos están ahí lo use quien los use, y quien vaya a trabajar con APK se lleva de esta tabla la lista de lo que va a tener que resolver a mano.

6. Licencias y sus consecuencias prácticas

Es un tema que pilla tarde: se elige la herramienta por lo que hace, se construye alrededor, y al ir a distribuir el producto aparece el problema. La regla que lo resume: la licencia no decide si puedes usar algo, decide cómo tienes que integrarlo.

El caso que hay que entender es el del crate smali. Es un ensamblador y desensamblador DEX completo escrito en Rust —lo único de su clase— y es GPL-3.0-only con licencia comercial de pago. Enlazarlo desde un motor con licencia permisiva convierte el motor entero en GPL-3.0. La salida practicable es usarlo como binario aislado en proceso separado, con una frontera de licencia limpia. Lo mismo aplica a jadx aunque su licencia no lo exija, y ahí el motivo es otro: un fallo de memoria en el subproceso no se lleva la aplicación por delante.

El caso de licencia doble. APKiD se distribuye bajo GPL-3.0 o bajo una licencia comercial perpetua y sin royalties que permite redistribuir el binario pero prohíbe redistribuir el fuente. Es el patrón clásico del open core de herramienta de seguridad, y hay que reconocerlo: la presencia de un LICENSE.GPL junto a un LICENSE.COMMERCIAL en la raíz del repositorio significa que la opción libre existe pero tiene condiciones.

7. Cómo se financia todo esto

La respuesta corta: casi nada de esto se financia, y por eso la sección 4 sale como sale.

La clasificación siguiente sale de mirar el fichero FUNDING.yml de cada repositorio y el producto comercial de cada organización, el 12 de agosto de 2026.

Dos lecturas incómodas de esa tabla. La primera: jadx —el decompilador de referencia, 50.030 estrellas, presente en MobSF, APKLab, Apk Studio y en la mayoría de los flujos de trabajo del mundo— no tiene fichero de patrocinio, y ARSCLib y APKEditor, de los que depende toda la fusión de splits del ecosistema, tampoco.

La segunda desmonta la solución fácil: APK Editor Studio sí tenía cuatro vías de donación declaradas —Patreon, Ko-fi, Liberapay y PayPal— y murió igual. Las donaciones no compran tiempo de un mantenedor que ya no está; lo que lo habría salvado es lo de la sección 4.4, que es un segundo mantenedor.

A eso se suman tres factores agravantes propios del dominio:

1. El suelo de cero. MobSF, jadx, Apktool y Ghidra son gratuitos y buenos. Cualquier producto de pago que intente cobrar por el escaneo estático básico compite contra ellos, y pierde. La monetización viable está en lo que ellos no dan: cumplimiento, ejecución gestionada, trabajo en equipo.
2. Los falsos positivos de antivirus. Es el dolor transversal del sector: son herramientas que desempaquetan y firman APK, y los motores de detección las marcan. Varias piden explícitamente desactivar el antivirus antes de instalar, lo que las descalifica en cualquier entorno corporativo y estrecha aún más su base de usuarios de pago.
3. La cadena de suministro. Parte del instrumental que circula —las herramientas de foro de la sección 6, sin licencia declarada— son binarios cerrados de autor anónimo distribuidos como ZIP en adjuntos y rehosteados por blogs de terceros. Son herramientas que firman APK. La diferencia entre un falso positivo verificable y un binario anónimo rehosteado es exactamente la auditabilidad.

La conclusión práctica, para quien vaya a apoyarse en algo de este mapa: mira la fecha del último commit y el número de autores humanos antes que las estrellas, y prefiere el proyecto que descarga sus motores al que los embebe. Los dos datos están en las tablas de las secciones 3 y 4, y volverlos a medir cuesta dos llamadas a la API de GitHub.

Fuentes

1. API pública de GitHub — https://api.github.com/repos/{org}/{repo}, /releases/latest, /contributors, /commits?since=…, /community/profile y /contents/{fichero} Consultada el 12 de agosto de 2026 para los 28 repositorios de las secciones 3 y 4. De aquí salen íntegras la licencia, el lenguaje, la versión y fecha de la última release, la fecha del último push, el estado de archivado, el número de estrellas y de issues abiertas de la sección 3; los porcentajes de concentración y los recuentos de autores de la sección 4; y el contenido de los ficheros FUNDING.yml de la sección 7.
2. Fichero LICENSE de R8 — https://r8.googlesource.com/r8/+/refs/heads/main/LICENSE Consultado el 12 de agosto de 2026. De aquí sale que D8 y R8 son BSD-3-Clause y no Apache-2.0, corrigiendo la suposición habitual (secciones 2.1 y 3.2).
3. Fichero LICENSE de apksig en AOSP — https://android.googlesource.com/platform/tools/apksig/+/refs/heads/main/LICENSE Consultado el 12 de agosto de 2026. Confirma Apache-2.0 para apksig/apksigner.
4. Fichero LICENSE de google/smali — https://github.com/google/smali/blob/master/LICENSE Consultado el 12 de agosto de 2026. De aquí sale la atribución a Ben Gruver y la licencia BSD-3-Clause conservada tras la adopción por Google (secciones 2.1, 3.2 y 4.3).
5. LICENSE.COMMERCIAL de APKiD — https://github.com/rednaga/APKiD/blob/master/LICENSE.COMMERCIAL Consultado el 12 de agosto de 2026. De aquí salen los términos de la licencia comercial perpetua y sin royalties que conviven con LICENSE.GPL (secciones 3.3 y 6).
6. Índice de artefactos de maven.google.com — com/android/tools/build/gradle, .../aapt2, .../apksig y com/android/tools/r8, ficheros maven-metadata.xml Consultados el 12 de agosto de 2026. De aquí salen las versiones estables 9.3.1 de AGP, aapt2 y apksig, la 9.3.17 de R8 y sus fechas de lastUpdated (sección 3.2).
7. JEB Decompiler — PNF Software — https://www.pnfsoftware.com/jeb/ y https://www.pnfsoftware.com/jeb/buy Consultados el 12 de agosto de 2026. De aquí salen la descripción del decompilador Dalvik y los cuatro precios de licencia de la sección 2.3.
8. IDA Pro — Hex-Rays — https://hex-rays.com/ida-pro y https://hex-rays.com/pricing Consultados el 12 de agosto de 2026. De aquí sale la descripción del producto. La tabla de precios se sirve por JavaScript y no se ha podido leer, de ahí la marca de la sección 2.3.
9. DexGuard — Guardsquare — https://www.guardsquare.com/dexguard Consultado el 12 de agosto de 2026. De aquí sale la descripción del producto y su relación con ProGuard.
10. DexProtector — Licel — https://licelus.com/products/dexprotector Consultado el 12 de agosto de 2026. De aquí salen las capacidades declaradas —obfuscación, cifrado, virtualización, RASP, atestación— y la versión 16.1.31 (sección 2.3).
11. Virbox / 深盾科技 — https://virbox.com/ (redirige a https://lm.virbox.com/) Consultado el 12 de agosto de 2026. De aquí salen la existencia de Virbox Protector y del módulo de hardening de APK de Android (sección 2.3).