Estructura de una aplicación Android

3,2,1 … Empezamos!

Nueva entrada en el blog en la cual vamos a explicar las partes que componen una aplicación Android.

Una aplicación Android está compuesta por varios elementos esenciales que interactúan entre sí para proporcionar funcionalidad y experiencia al usuario. Desde un punto de vista técnico y de seguridad, basándonos en el estándar OWASP MAS (Mobile Application Security), esta estructura incluye una variedad de componentes clave, cada uno con un propósito específico.

A continuación, explicamos los componentes clave de una aplicación:

AndroidManifest.xml

El archivo AndroidManifest.xml es el núcleo de cualquier aplicación Android. Define la estructura y los componentes esenciales, así como sus configuraciones. Este archivo es fundamental para garantizar que la aplicación funcione correctamente y cumpla con las políticas de seguridad. Contiene:

• Declaración de componentes: Define las Activities, Services, Broadcast Receivers y Content Providers.
• Permisos: Enumera los permisos necesarios, como acceso a la cámara, almacenamiento o ubicación.
• Configuraciones específicas: Indica la versión mínima del SDK, el tema por defecto y configuraciones de hardware/software.
• Protección de componentes: Las propiedades android:exported y los intent-filters controlan cómo los componentes interactúan con otras aplicaciones para evitar accesos no autorizados.

Activities (Actividades)

Las Activities constituyen la parte visible de cualquier aplicación. Cada Activity corresponde a una pantalla; por lo tanto, una aplicación con tres pantallas diferentes implementa tres actividades distintas. Las actividades se declaran extendiendo la clase Activity. Estas contienen todos los elementos de la interfaz de usuario, como fragmentos (fragments), vistas (views) y diseños (layouts).

Cada actividad debe ser declarada en el archivo Android Manifest con la siguiente sintaxis:

<activity android:name="NombreDeLaActividad">
</activity>

Fragments (Fragmentos)

Un Fragment es un componente modular en Android que representa un comportamiento o una parte de la interfaz de usuario dentro de una actividad (Activity). Fueron introducidos en Android 3.0 (Honeycomb, API nivel 11) para mejorar la reutilización y la adaptabilidad de las interfaces en dispositivos con diferentes tamaños de pantalla.

Aunque los Fragments son entidades autónomas que pueden incluir su propio diseño (layout), botones y lógica de comportamiento, no pueden existir de manera independiente. Siempre necesitan estar integrados en una actividad que los controle.

Content Providers

Los Content Providers son componentes que permiten a una aplicación ofrecer sus datos a otras aplicaciones de manera controlada y eficiente. Por ejemplo, si una aplicación maneja una base de datos, puede usar un Content Provider para permitir que otra aplicación lea o modifique esos datos. A pesar de que los datos se almacenan en SQLite o archivos planos, los Content Providers proporcionan un punto de acceso único para interactuar con esos datos.

Los Content Providers funcionan en un esquema de URI con el prefijo content://, independientemente de si los datos provienen de una base de datos SQLite, un archivo de texto o cualquier otra fuente de datos. Esto abstrae la complejidad de la fuente de datos y ofrece a los desarrolladores una forma uniforme de acceder a ellos.

Services (Services)

Los Services son componentes del sistema operativo Android basados en la clase Service. Son utilizados para realizar tareas en segundo plano sin necesidad de mostrar una interfaz de usuario. Estas tareas pueden incluir procesamiento de datos, manejo de notificaciones, gestión de conexiones a redes o cualquier otra operación que deba ejecutarse mientras la aplicación sigue funcionando en segundo plano.

Inter-Process Communication (IPC)

La comunicación entre procesos (IPC) en Android juega un papel muy importante al permitir que las aplicaciones intercambien datos y se comuniquen entre sí. IPC es necesario porque las aplicaciones de Android generalmente están aisladas entre sí para mantener la seguridad y el rendimiento.

Uno de los mecanismos principales de IPC en Android son los Intents, que permiten a una aplicación solicitar acciones de otras aplicaciones, como abrir una actividad específica, iniciar un servicio o enviar datos. Los Intents pueden ser explícitos (dirigiéndose a componentes específicos) o implícitos (pidiendo al sistema encontrar el componente apropiado según ciertos criterios, como una acción).

Otro método de IPC son los Broadcast Receivers permiten la comunicación entre diferentes aplicaciones o entre el sistema y las aplicaciones mediante mensajes de difusión. Las aplicaciones pueden escuchar transmisiones a nivel de sistema (como cuando la batería del dispositivo está baja o Wi-Fi está conectado) o enviar sus propias transmisiones para notificar a otras aplicaciones.

Otro métodos de IPC son los Content Providers junto a Services, explicados anteriormente.

La IPC está estrictamente controlada por el modelo de seguridad de Android, garantizando que las aplicaciones tengan acceso controlado a recursos sensibles. Por ejemplo, el uso de Permisos asegura que solo las aplicaciones autorizadas puedan acceder a datos o recursos específicos. Además, el sistema operativo aísla las aplicaciones mediante el control de acceso basado en usuarios del núcleo de Linux, y medidas de seguridad adicionales como SELinux imponen políticas estrictas sobre qué procesos pueden acceder a recursos.

Recursos (Carpeta /res)

Esta carpeta contiene todos los recursos no ejecutables utilizados por la app. Su estructura incluye:

• Layouts (/res/layout): Archivos XML que definen la estructura visual de las interfaces.
• Strings (/res/values/strings.xml): Texto reutilizable en la app, soportando traducciones y cambios centralizados.
• Imágenes (/res/drawable): Archivos gráficos utilizados en la interfaz.
• Temas y estilos (/res/values/styles.xml): Configuran la apariencia y coherencia visual de la app.

Archivos de compilación y ejecución

• build.gradle: Configura las dependencias y el entorno de compilación.
  • Nivel del proyecto: Define configuraciones globales, como repositorios y versiones de plugins.
  • Nivel del módulo: Incluye dependencias específicas de la app, configuración del SDK y firmas.
• /bin y /build: Contienen los artefactos generados durante la compilación, como el archivo APK final.
• classes.dex: Archivo ejecutable de Dalvik que contiene el bytecode optimizado.
• libs/ y assets/: Incluyen librerías externas y recursos sin procesar.

Destacar que esto es un resumen y que, a lo largo de futuras publicaciones se entrará en detalle con ejemplos prácticos.

En la próxima entrada abordaremos la arquitectura de un dispositivo iOS.

¡Nos vemos en el próximo! 😊

Referencias:

• https://mas.owasp.org/MASTG/0x05a-Platform-Overview/