Estructura de una app Android: qué trae el paquete y por dónde se empieza

Un paquete de Android es un archivo comprimido. Dentro van el código ya compilado (archivos con extensión dex, y a veces más de uno cuando la aplicación es grande), los recursos como diseños y textos, un archivo que indexa esos recursos, las bibliotecas nativas por arquitectura de procesador, la carpeta de firma y el manifiesto. Abrirlo no exige descifrar nada: la firma prueba quién lo publicó y que nadie lo alteró, pero no esconde su contenido.

El manifiesto viaja en un formato binario compacto y las herramientas de lectura lo convierten otra vez a texto. Esa es la razón de que un analista pueda leerlo entero sin tocar la aplicación: lo que declara la app ante el sistema está a la vista de cualquiera que tenga el paquete.

La ficha del paquete resume lo que el manifiesto declara: el identificador de la aplicación, su versión, el nivel mínimo de Android en el que corre y el nivel de API para el que se compiló y probó (el nivel objetivo). Ese último dato importa para la revisión porque el sistema aplica reglas distintas según para qué nivel declara estar preparada una app. Por ejemplo, desde Android 12 (nivel de API 31) una aplicación que apunta a ese nivel o a uno posterior tiene que declarar de forma explícita si un componente con filtros de intención queda exportado; antes, el valor por omisión lo decidía el propio filtro.

Un nivel objetivo viejo no es un hallazgo por sí mismo, pero cambia lo que hay que comprobar a mano: un manifiesto que no declara nada explícito puede estar exponiendo algo por omisión.

Además del código compilado en dex, un paquete puede traer bibliotecas nativas, archivos con extensión so que viven en una carpeta por arquitectura. Es código ya compilado para el procesador y se revisa aparte del resto. Una misma biblioteca suele aparecer repetida, una vez por arquitectura, con el mismo nombre; lo que cambia es la carpeta. Para un listado de revisión basta con anotar cuántas bibliotecas distintas hay, cuál es su nombre y a qué función de la app sirven, porque cada una trae sus propias dependencias que mantener actualizadas.

El listado del paquete no dice para qué sirve cada archivo, pero el nombre y el contexto de la app suelen orientar: una biblioteca de lectura de códigos QR en una app de recibos tiene sentido.

Con el paquete abierto hay mucho que leer y poco tiempo, así que el orden importa. El manifiesto se lee primero porque responde las preguntas que fijan el alcance: qué componentes quedan expuestos, qué permisos pide, si admite copias de seguridad y si acepta depuración. Después viene el código, guiado por lo que el manifiesto señaló, y no al revés. Leer el código completo sin saber qué es alcanzable desde fuera es la manera más lenta de llegar al mismo sitio.

En la práctica, el analista que empieza por el manifiesto llega a su primera hipótesis en minutos. El que empieza por las cadenas del código llega a muchas, la mayoría sin relación con lo que un tercero puede alcanzar.