Skip to content

Most visited

Recently visited

navigation

Aspectos fundamentales de la aplicación

Las aplicaciones de Android se escriben en lenguaje de programación Java. Las herramientas de Android SDK compilan tu código, junto con los archivos de recursos y datos, en un APK: un paquete de Android, que es un archivo de almacenamiento con el sufijo .apk. Un archivo de APK incluye todos los contenidos de una aplicación de Android y es el archivo que usan los dispositivos con tecnología Android para instalar la aplicación.

Una vez instalada en el dispositivo, cada aplicación de Android se aloja en su propia zona de pruebas de seguridad:

De esta manera, el sistema Android implementa el principio de mínimo privilegio. Es decir, de forma predeterminada, cada aplicación tiene acceso solo a los componentes que necesita para llevar a cabo su trabajo y nada más. Esto crea un entorno muy seguro en el que una aplicación no puede acceder a partes del sistema para las que no tiene permiso.

Sin embargo, hay maneras en las que una aplicación puede compartir datos con otras aplicaciones y en las que una aplicación puede acceder a servicios del sistema:

Esto cubre los aspectos básicos sobre cómo una aplicación de Android existe en el sistema. El resto de este documento te presenta lo siguiente:

Componentes de la aplicación

Los componentes de la aplicación son bloques de creación esenciales de una aplicación para Android. Cada componente es un punto diferente a través del cual el sistema puede ingresar a tu aplicación. No todos los componentes son puntos de entrada reales para el usuario y algunos son dependientes entre sí, pero cada uno existe como entidad individual y cumple un rol específico; cada uno es un bloque de creación único que ayuda a definir el comportamiento general de tu aplicación.

Hay cuatro tipos diferentes de componentes de una aplicación. Cada tipo tiene un fin específico y un ciclo de vida diferente que define cómo se crea y se destruye el componente.

Aquí te mostramos los cuatro tipos de componentes de una aplicación:

Actividades
Una actividad representa una pantalla con interfaz de usuario. Por ejemplo, una aplicación de correo electrónico tiene una actividad que muestra una lista de los correos electrónicos nuevos, otra actividad para redactar el correo electrónico y otra actividad para leer correos electrónicos. Si bien las actividades trabajan juntas para proporcionar una experiencia de usuario consistente en la aplicación de correo electrónico, cada una es independiente de las demás. De esta manera, una aplicación diferente puede inicial cualquiera de estas actividades (si la aplicación de correo electrónico lo permite). Por ejemplo, una aplicación de cámara puede iniciar la actividad en la aplicación de correo electrónico que redacta el nuevo mensaje para que el usuario comparta una imagen.

Una actividad se implementa como una subclase de Activity y puedes obtener más información acerca de este tema en la guía para desarrolladores Actividades .

Servicios
Un servicio es un componente que se ejecuta en segundo plano para realizar operaciones prolongadas o tareas para procesos remotos. Un servicio no proporciona una interfaz de usuario. Por ejemplo, un servicio podría reproducir música en segundo plano mientras el usuario se encuentra en otra aplicación, o podría capturar datos en la red sin bloquear la interacción del usuario con una actividad. Otro componente, como una actividad, puede iniciar el servicio y permitir que se ejecute o enlazarse a él para interactuar.

Un servicio se implementa como una subclase de Service y puedes obtener más información acerca de este tema en la guía para desarrolladores Servicios.

Proveedores de contenido
Un proveedor de contenido administra un conjunto compartido de datos de la app. Puedes almacenar los datos en el sistema de archivos, en una base de datos SQLite, en la Web o en cualquier otra ubicación de almacenamiento persistente a la que tu aplicación pueda acceder. A través del proveedor de contenido, otras aplicaciones pueden consultar o incluso modificar los datos (si el proveedor de contenido lo permite). Por ejemplo, el sistema Android proporciona un proveedor de contenido que administra la información de contacto del usuario. De esta manera, cualquier app con los permisos correspondientes puede consultar parte del proveedor de contenido (como ContactsContract.Data) para la lectura y escritura de información sobre una persona específica.

Los proveedores de contenido también son útiles para leer y escribir datos privados de tu aplicación y que no se comparten. Por ejemplo, la aplicación de ejemplo Bloc de notas usa un proveedor de contenido para guardar notas.

Un proveedor de contenido se implementa como una subclase de ContentProvider y debe implementar un conjunto estándar de API que permitan a otras aplicaciones realizar transacciones. Para obtener más información, lee la guía para desarrolladores Proveedores de contenido .

Receptores de mensajes
Un receptor de mensajes es un componente que responde a los anuncios de mensajes en todo el sistema. Muchos mensajes son originados por el sistema; por ejemplo, un mensaje que anuncie que se apagó la pantalla, que la batería tiene poca carga o que se tomó una foto. Las aplicaciones también pueden iniciar mensajes; por ejemplo, para permitir que otras aplicaciones sepan que se descargaron datos al dispositivo y están disponibles para usarlos. Si bien los receptores de mensajes no exhiben una interfaz de usuario, pueden crear una notificación de la barra de estado para alertar al usuario cuando se produzca un evento de mensaje. Aunque, comúnmente, un receptor de mensajes es simplemente una "puerta de enlace" a otros componentes y está destinado a realizar una cantidad mínima de trabajo. Por ejemplo, podría iniciar un servicio para que realice algunas tareas en función del evento.

Un receptor de mensajes se implementa como una subclase de BroadcastReceiver y cada receptor de mensajes se proporciona como un objeto Intent. Para obtener más información, consulta la clase BroadcastReceiver.

Un aspecto exclusivo del diseño del sistema Android es que cualquier aplicación puede iniciar un componente de otra aplicación. Por ejemplo, si quieres que el usuario tome una foto con la cámara del dispositivo, probablemente haya otra aplicación para eso y tu aplicación pueda usarla, en lugar de desarrollar una actividad para tomar una foto. No necesitas incorporar ni establecer un enlace con el código de la aplicación de cámara. En su lugar, puedes simplemente iniciar la actividad en la aplicación de cámara que toma la foto. Cuando termines, la foto aparecerá en tu aplicación para que puedas usarla. Al usuario le parecerá que la cámara en realidad forma parte de tu aplicación.

Cuando el sistema inicia un componente, inicia el proceso para esa aplicación (si es que no se está ejecutando) y crea una instancia de las clases necesarias para el componente. Por ejemplo, si tu app inicia la actividad en la app de cámara que toma una foto, esa actividad se ejecuta en el proceso que pertenece a la app de cámara, no en el proceso de tu app. Por lo tanto, a diferencia de lo que sucede con las apps en la mayoría de los demás sistemas, las apps de Android no tienen un solo punto de entrada (por ejemplo, no existe la función main()).

Como el sistema ejecuta cada aplicación en un proceso independiente con permisos de archivo que limitan el acceso a otras aplicaciones, tu aplicación no puede activar directamente un componente de otra aplicación. Sin embargo, el sistema Android sí puede hacerlo. Por lo tanto, para activar un componente en otra aplicación, debes enviar un mensaje al sistema que especifique tu intent de iniciar un componente específico. Luego, el sistema activa ese componente por ti.

Activación de componentes

Tres de los cuatro tipos de componentes (actividades, servicios y receptores de mensajes) se activan mediante un mensaje asincrónico llamado intent. Las intents enlazan componentes individuales en tiempo de ejecución (son como mensajeros que solicitan una acción de otros componentes), ya sea que el componente le pertenezca a tu aplicación o a otra.

Una intent se crea con un objeto Intent, que define un mensaje para activar un componente específico o un tipo específico de componente; una intent puede ser explícita o implícita, respectivamente.

Para actividades y servicios, una intent define la acción a realizar (por ejemplo, "ver" o "enviar" algo) y puede especificar el URI de los datos en los que debe actuar (entre otras cosas que el componente que se está iniciando podría necesitar saber). Por ejemplo, una intent podría transmitir una solicitud para que una actividad muestre una imagen o abra una página web. En algunos casos, puedes iniciar una actividad para recibir un resultado; en cuyo caso, la actividad también devuelve el resultado en una Intent (por ejemplo, puedes emitir una intent para que el usuario elija un contacto personal y te lo devuelva; la intent de devolución incluye un URI que apunta al contacto seleccionado).

Para los receptores de mensajes, la intent simplemente define el anuncio que se está transmitiendo (por ejemplo, un mensaje para indicar que la batería del dispositivo tiene poca carga incluye solo una string de acción conocida que indica “batería baja”).

El otro tipo de componente, proveedor de contenido, no se activa mediante intents, sino a través de solicitudes de un ContentResolver. El solucionador de contenido aborda todas las transacciones directas con el proveedor de contenido, de modo que el componente que realiza las transacciones con el proveedor no deba hacerlo y, en su lugar, llame a los métodos del objeto ContentResolver. Esto deja una capa de abstracción entre el proveedor de contenido y el componente que solicita información (por motivos de seguridad).

Existen métodos independientes para activar cada tipo de componente:

Para obtener más información acerca de cómo usar intents, lee el documento Intents y filtros de intents. Puedes obtener más información acerca de cómo activar componentes específicos en los siguientes documentos: Actividades, Servicios, BroadcastReceiver y Proveedores de contenido.

El archivo de manifiesto

Para que el sistema Android pueda iniciar un componente de la app, el sistema debe reconocer la existencia de ese componente leyendo el archivo AndroidManifest.xml de la app (el archivo de “manifiesto”). Tu aplicación debe declarar todos sus componentes en este archivo, que debe encontrarse en la raíz del directorio de proyectos de la aplicación.

El manifiesto puede hacer ciertas cosas además de declarar los componentes de la aplicación, como por ejemplo:

Declaración de componentes

La tarea principal del manifiesto es informarle al sistema acerca de los componentes de la aplicación. Por ejemplo, un archivo de manifiesto puede declarar una actividad de la siguiente manera:

<?xml version="1.0" encoding="utf-8"?>
<manifest ... >
    <application android:icon="@drawable/app_icon.png" ... >
        <activity android:name="com.example.project.ExampleActivity"
                  android:label="@string/example_label" ... >
        </activity>
        ...
    </application>
</manifest>

En el elemento <application>, el atributo android:icon señala los recursos para un ícono que identifica la app.

En el elemento <activity>, el atributo android:name especifica el nombre de clase plenamente calificado de la subclase Activity y el atributo android:label especifican una string para usar como etiqueta de la actividad visible para el usuario.

Debes declarar todos los componentes de la aplicación de esta manera:

Las actividades, los servicios y los proveedores de contenido que incluyas en tu archivo de origen pero que no declares en el manifiesto no estarán visibles para el sistema y, por consiguiente, no se podrán ejecutar. No obstante, los receptores de mensajes pueden declararse en el manifiesto o crearse dinámicamente en forma de código (como objetos BroadcastReceiver) y registrarse en el sistema llamando a registerReceiver().

Para obtener más información acerca de cómo estructurar el archivo de manifiesto para tu aplicación lee la documentación Archivo AndroidManifest.xml .

Declaración de capacidades de los componentes

Como se discutió anteriormente, en Activación de componentes, puedes usar una Intent para iniciar actividades, servicios y receptores de mensajes. Puedes hacerlo al denominar explícitamente el componente objetivo (usando el nombre de clase del componente) en la intent. Sin embargo, el poder real de las intents se encuentra en el concepto de intents implícitas. Una intent simplemente describe el tipo de acción a realizar (y, opcionalmente, los datos en función de los cuales quieres realizar la acción) y le permite al sistema buscar un componente en el dispositivo que pueda realizar la acción e iniciarla. Si hay múltiples componentes que pueden realizar la acción que describe la intent, el usuario selecciona la que quiere usar.

El sistema identifica los componentes que pueden responder a una intent comparando la intent recibida con los filtros de intents que se proporcionan en el archivo de manifiesto de otras apps en el dispositivo.

Cuando declaras una actividad en el manifiesto de tu aplicación, tienes la posibilidad de incluir filtros de intents que declaran las capacidades de la actividad de modo que pueda responder a intents desde otras aplicaciones. Puedes declarar un filtro de intents para tu componente agregando un elemento <intent-filter> como campo secundario del elemento de declaración del componente.

Por ejemplo, si compilaste una aplicación de correo electrónico con una actividad para redactar un nuevo mensaje de correo electrónico, puedes declarar un filtro de intents para responder a las intents "enviar" (a fin de enviar un nuevo correo electrónico) de esta manera:

<manifest ... >
    ...
    <application ... >
        <activity android:name="com.example.project.ComposeEmailActivity">
            <intent-filter>
                <action android:name="android.intent.action.SEND" />
                <data android:type="*/*" />
                <category android:name="android.intent.category.DEFAULT" />
            </intent-filter>
        </activity>
    </application>
</manifest>

Luego, si app crea una intent con la acción ACTION_SEND y la pasa a startActivity(), el sistema puede iniciar tu actividad para que el usuario pueda redactar y enviar un correo electrónico.

Para obtener más información acerca de cómo crear filtros de intents, lee el documento Intents y filtros de intents.

Declaración de requisitos de la aplicación

Existen muchos dispositivos con tecnología Android, pero no todos ofrecen las mismas funciones y capacidades. Para evitar que se instale tu aplicación en dispositivos que no tienen las funciones que tu aplicación necesita, es importante que definas claramente un perfil para los tipos de dispositivos que admite la aplicación al declarar los requisitos de dispositivos y software en tu archivo de manifiesto. La mayoría de esas declaraciones son solo informativas y el sistema no las lee, pero servicios externos como Google Play sí lo hacen para ofrecerles a los usuarios opciones de filtrado cuando buscan aplicaciones desde sus dispositivos.

Por ejemplo, si tu aplicación requiere una cámara y usa API introducidas en Android 2.1 (nivel de API 7), debes declarar esto como requisitos en tu archivo de manifiesto de la siguiente manera:

<manifest ... >
    <uses-feature android:name="android.hardware.camera.any"
                  android:required="true" />
    <uses-sdk android:minSdkVersion="7" android:targetSdkVersion="19" />
    ...
</manifest>

Ahora, los dispositivos que no tengan cámara y tengan una versión de Android anterior a 2.1 no podrán instalar tu aplicación desde Google Play.

No obstante, también puedes declarar que tu aplicación usa la cámara, pero no la exige. En ese caso, tu app debe fijar el atributo required en "false" y comprobar durante el tiempo de ejecución si el dispositivo tiene cámara e inhabilitar las funciones de cámara según corresponda.

Encontrarás más información acerca de cómo administrar la compatibilidad de tu aplicación con diferentes dispositivos en el documento Compatibilidad con dispositivos .

Recursos de la aplicación

En Android, una aplicación está compuesta por más que simplemente código; requiere recursos independientes del código fuente, como imágenes, archivos de audio y otros elementos relacionados con la presentación de la aplicación. Por ejemplo, debes definir animaciones, menús, estilos, colores y el diseño de las interfaces de usuario de la actividad con archivos XML. El uso de recursos de la aplicación facilita la actualización de varias características de tu aplicación sin necesidad de modificar el código y, al proporcionar conjuntos de recursos alternativos, puedes optimizar tu aplicación para una variedad de configuraciones de dispositivos (como diferentes idiomas y tamaños de pantalla).

Por cada recurso que incluyes en tu proyecto para Android, las herramientas de compilación del SDK definen un ID con número entero que puedes usar para hacer referencia al recurso desde el código de tu aplicación o desde otros recursos definidos en XML. Por ejemplo, si tu app contiene un archivo de imagen denominado logo.png (guardado en el directorio res/drawable/), las herramientas del SDK generan un ID de recurso llamado R.drawable.logo que puedes usar para hacer referencia a la imagen e insertarla en tu interfaz de usuario.

Uno de los aspectos más importantes de proporcionar recursos independientes de tu código fuente es la capacidad de ofrecer recursos alternativos para diferentes configuraciones de dispositivos. Por ejemplo, al definir strings de IU en XML, puedes traducir las strings a otros idiomas y guardarlas en archivos independientes. Luego, en función de un calificador de idioma que anexes al nombre del directorio de recursos (como res/values-fr/ para los valores de la string Francés) y a la configuración de idioma del usuario, el sistema Android aplica las strings de idioma correspondientes a tu IU.

Android admite muchos calificadores diferentes para tus recursos alternativos. El calificador es una string corta que incluyes en el nombre de tus directorios de recursos para definir la configuración de dispositivo en la que se deben usar esos recursos. Para darte otro ejemplo, debes crear con frecuencia diferentes diseños para tus actividades, según la orientación y el tamaño de pantalla del dispositivo. Por ejemplo, cuando la orientación de la pantalla del dispositivo es vertical (a lo alto), podrías usar un diseño en el que los botones estén alineados de forma vertical, pero cuando es horizontal (a lo ancho), los botones deben alinearse horizontalmente. Para cambiar el diseño según la orientación, puedes definir dos diseños diferentes y aplicar el calificador adecuado al nombre de directorio de cada diseño. El sistema luego aplicará automáticamente el diseño adecuado según la orientación actual del dispositivo.

Para obtener más información acerca de los diferentes tipos de recursos que puedes incluir en tu aplicación y cómo crear recursos alternativos para diferentes configuraciones de dispositivos, lee Provisión de recursos.

Continúa leyendo:

Intents y filtros de intents
Información acerca de cómo usar las Intent API para activar componentes de la aplicación, como actividades y servicios, y cómo hacer para que los componentes de tu aplicación estén disponibles para que los usen otras apps.
Actividades
Información acerca de cómo crear una instancia de la clase Activity, que proporciona una pantalla independiente en tu aplicación con una interfaz de usuario.
Provisión de recursos
Información acerca de cómo se estructuran las aplicaciones de Android para recursos independientes de la aplicación desde el código de la aplicación, incluido cómo puedes proporcionar recursos alternativos parea configuraciones de dispositivo específicas.

También te puede interesar:

Compatibilidad con dispositivos
Información acerca de cómo funciona Android en diferentes tipos de dispositivos y una introducción a cómo puedes optimizar tu aplicación para cada dispositivo o restringir la disponibilidad de tu aplicación para diferentes dispositivos.
Permisos del sistema
Información acerca de cómo Android restringe el acceso de la aplicación a determinadas API mediante un sistema de permisos que requiere el consentimiento del usuario para que tu aplicación pueda usar esas API.
This site uses cookies to store your preferences for site-specific language and display options.

Get the latest Android developer news and tips that will help you find success on Google Play.

* Required Fields

Hooray!

Follow Google Developers on WeChat

Browse this site in ?

You requested a page in , but your language preference for this site is .

Would you like to change your language preference and browse this site in ? If you want to change your language preference later, use the language menu at the bottom of each page.

This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.

Take a short survey?
Help us improve the Android developer experience.
(Sep 2017 survey)