Descripción general del manifiesto de la app

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Todos los proyectos de apps deben tener un archivo AndroidManifest.xml, con ese nombre preciso, en la raíz del conjunto de orígenes del proyecto. El archivo de manifiesto describe información esencial sobre tu app para las herramientas de compilación de Android, el sistema operativo Android y Google Play.

Entre muchas otras cosas, el archivo de manifiesto debe declarar lo siguiente:

• Los componentes de la app, que incluyen todas las actividades, los servicios, los receptores de emisión y los proveedores de contenido. Cada componente debe definir propiedades básicas, como el nombre de su clase Kotlin o Java. También puede declarar capacidades, como las configuraciones de los dispositivos compatibles, además de filtros de intents que describen cómo se puede iniciar el componente. Obtén más información sobre los componentes de la app en la siguiente sección
• Los permisos que necesita la app para acceder a las partes protegidas del sistema o a otras apps. También declara cualquier permiso que otras apps deben tener si quieren acceder a contenido de la app. Obtén más información sobre los permisos en la siguiente sección
• Las funciones de hardware y software que requiere la app, que determinan qué dispositivos pueden instalar la app desde Google Play. Obtén más información sobre la compatibilidad de dispositivos en la siguiente sección

Si usas Android Studio para compilar tu app, el archivo de manifiesto se generará automáticamente, y la mayoría de sus elementos esenciales se irán agregando a medida que compiles la app (en especial, cuando uses plantillas de código).

Funciones del archivo

Las siguientes secciones describen cómo se reflejan algunas de las características más importantes de tu app en el archivo de manifiesto.

Componentes de la app

Por cada componente de la app que crees en ella, deberás declarar un elemento XML correspondiente en el archivo de manifiesto:

• <activity> para cada subclase de Activity
• <service> para cada subclase de Service
• <receiver> para cada subclase de BroadcastReceiver
• <provider> para cada subclase de ContentProvider

Si incluyes en subclases cualquiera de esos componentes sin declararlos en el archivo de manifiesto, el sistema no podrá iniciarlos.

Especifica el nombre de tu subclase con el atributo name, mediante la designación completa del paquete. Por ejemplo, una subclase Activity se declara de la siguiente manera:

<manifest ... >
    <application ... >
        <activity android:name="com.example.myapp.MainActivity" ... >
        </activity>
    </application>
</manifest>

Sin embargo, si el primer carácter del valor name es un punto, el espacio de nombres de la app (desde la propiedad namespace del archivo build.gradle del nivel del módulo) se adjunta como prefijo al nombre. Por ejemplo, si el espacio de nombres es "com.example.myapp", el siguiente nombre de actividad se resuelve en com.example.myapp.MainActivity:

<manifest ... >
    <application ... >
        <activity android:name=".MainActivity" ... >
            ...
        </activity>
    </application>
</manifest>

Si quieres obtener más información para configurar el nombre del paquete o el espacio de nombres, consulta Cómo configurar un espacio de nombres.

Si algunos componentes de la app se encuentran en subpaquetes (como en com.example.myapp.purchases), el valor name debe agregar los nombres de los subpaquetes que faltan (como ".purchases.PayActivity") o utilizar el nombre de paquete completamente calificado.

Filtros de intents

Las actividades, los servicios y los receptores de emisión de una app se activan a través de intents. Un intent es un mensaje definido por un objeto Intent que describe una acción que se realizará, así como los datos sobre los que se debe actuar, la categoría del componente que debe realizar la acción y otras instrucciones.

Cuando una app emite un intent al sistema, este último ubica un componente de la app que pueda procesar el intent según las declaraciones del filtro de intents en el archivo de manifiesto de cada app. El sistema lanza una instancia del componente correspondiente y pasa el objeto Intent a ese componente. Si más de una app puede procesar el intent, entonces el usuario podrá seleccionar cuál usar.

Un componente de app puede tener cualquier cantidad de filtros de intents (definidos con el elemento <intent-filter>), cada uno de los cuales describe una capacidad diferente de ese componente.

Para obtener más información, consulta el documento Intents y filtros de intents.

Íconos y etiquetas

Algunos elementos del manifiesto tienen atributos icon y label para mostrar a los usuarios un pequeño ícono y una etiqueta de texto, respectivamente, según el componente de app que corresponda.

En cada caso, el ícono y la etiqueta establecidos en un elemento superior se convierten en el valor predeterminado de icon y label para todos los elementos secundarios. Por ejemplo, el ícono y la etiqueta establecidos en el elemento <application> son aquellos predeterminados para cada componente de la app, como todas las actividades.

El ícono y la etiqueta que se establecen en el <intent-filter> de un componente se muestran al usuario siempre que ese componente se presente como una opción para entregar un intent. De forma predeterminada, este ícono se hereda de cualquiera que se declare para el componente superior, ya sea el elemento <activity> o el elemento <application>.

Es posible que quieras cambiar el ícono por un filtro de intents si proporciona una acción única que te gustaría indicar mejor en el cuadro de diálogo del selector. Para obtener más información, consulta Cómo permitir que otras apps inicien tu actividad.

Permisos

Las apps para Android deben solicitar permiso para acceder a datos sensibles del usuario (como contactos y SMS) o a determinadas funciones del sistema (como la cámara y el acceso a Internet). Cada permiso se identifica con una etiqueta única. Por ejemplo, en el manifiesto de una app que necesite enviar mensajes SMS, debe incluirse la siguiente línea:

<manifest ... >
    <uses-permission android:name="android.permission.SEND_SMS"/>
    ...
</manifest>

A partir de Android 6.0 (nivel de API 23), el usuario puede aprobar o rechazar algunos permisos de las apps durante el tiempo de ejecución. No obstante, sin importar qué versión de Android admita tu app, debes declarar todas las solicitudes de permisos con un elemento <uses-permission> en el manifiesto. Si se otorga el permiso, la app podrá usar las funciones protegidas. De lo contrario, los intentos de acceder a esas funciones fallarán.

Tu app también puede proteger sus propios componentes mediante permisos. Puede usar cualquiera de los permisos definidos por Android, como se indica en android.Manifest.permission, o uno que esté declarado en otra app. Tu app también puede definir sus propios permisos. Un permiso nuevo se declara mediante el elemento <permission>.

Para obtener más información, consulta Permisos en Android.

Compatibilidad con dispositivos

En el archivo de manifiesto, también puedes declarar los tipos de funciones de hardware y software que requiere tu app y, por lo tanto, los dispositivos que esta admite. Google Play Store no permite que los usuarios instalen tu app en dispositivos que no tengan las funciones o la versión del sistema que requiere tu app.

Hay varias etiquetas de manifiesto que definen qué dispositivos son compatibles con tu app. Las siguientes son algunas de las más comunes.

<uses-feature>

El elemento <uses-feature> te permite declarar las funciones de hardware y software que necesita tu app. Por ejemplo, si la app no puede ofrecer una funcionalidad básica en dispositivos sin sensor de brújula, puedes declarar ese sensor como obligatorio mediante la siguiente etiqueta de manifiesto:

<manifest ... >
    <uses-feature android:name="android.hardware.sensor.compass"
                  android:required="true" />
    ...
</manifest>

Nota: Si quieres que tu app esté disponible en Chromebooks, debes tener en cuenta algunas limitaciones importantes de funciones de hardware y software. Para obtener más información, consulta Compatibilidad del manifiesto de la app para Chromebooks.

<uses-sdk>

Cada versión posterior de la plataforma suele agregar nuevas APIs que no están disponibles en la versión anterior. Para indicar la versión mínima con la que tu app es compatible, tu manifiesto deberá incluir la etiqueta <uses-sdk> y su atributo minSdkVersion.

Sin embargo, ten en cuenta que las propiedades correspondientes del archivo build.gradle anulan los atributos del elemento <uses-sdk>. Por lo tanto, si usas Android Studio, especifica los valores minSdkVersion y targetSdkVersion allí:

android {
    defaultConfig {
        applicationId 'com.example.myapp'

        // Defines the minimum API level required to run the app.
        minSdkVersion 21

        // Specifies the API level used to test the app.
        targetSdkVersion 33
        ...
    }
}

android {
    defaultConfig {
        applicationId = "com.example.myapp"

        // Defines the minimum API level required to run the app.
        minSdkVersion(21)

        // Specifies the API level used to test the app.
        targetSdkVersion(33)
        ...
    }
}

Para obtener más información sobre el archivo build.gradle, consulta cómo configurar tu compilación.

Si deseas obtener más información para declarar la compatibilidad de tu app con diferentes dispositivos, consulta Descripción general de la compatibilidad de dispositivos.

Convenciones del archivo

En esta sección, se describen las convenciones y reglas que generalmente se aplican a todos los elementos y atributos del archivo de manifiesto.

Elementos

Solo se requieren los elementos <manifest> y <application>. Deben aparecer una sola vez. La mayoría de los demás elementos pueden aparecer cero o más veces. Sin embargo, algunos deben estar presentes de modo que el archivo de manifiesto resulte útil.

Todos los valores se establecen mediante atributos, en lugar de datos de caracteres en un elemento.

Por lo general, los elementos de un mismo nivel no están ordenados. Por ejemplo, los elementos <activity>, <provider> y <service> se pueden ubicar en cualquier orden. Hay dos excepciones importantes a esta regla:

• Un elemento <activity-alias> debe seguir la <activity> para la cual funciona como alias.
• El elemento <application> debe ser el último dentro del elemento <manifest>.

Atributos

Técnicamente, todos los atributos son opcionales. Sin embargo, varios deben especificarse para que un elemento pueda cumplir su propósito. En el caso de los atributos realmente opcionales, la documentación de referencia indica los valores predeterminados.

Excepto para algunos atributos del elemento raíz <manifest>, todos los nombres de los atributos comienzan con un prefijo android:, como android:alwaysRetainTaskState. Dado que el prefijo es universal, suele omitirse en la documentación cuando se hace referencia a los atributos por nombre.

Varios valores

Si se puede especificar más de un valor, el elemento se repite casi siempre, en lugar de que se enumeren varios valores en un único elemento. Por ejemplo, en un filtro de intents, se pueden enumerar varias acciones:

<intent-filter ... >
    <action android:name="android.intent.action.EDIT" />
    <action android:name="android.intent.action.INSERT" />
    <action android:name="android.intent.action.DELETE" />
    ...
</intent-filter>

Valores de recursos

Algunos atributos tienen valores que se muestran a los usuarios, como el título de una actividad o el ícono de la app. Es posible que el valor de esos atributos varíe en función del idioma del usuario y de otras configuraciones del dispositivo (como ofrecer otro tamaño de ícono según la densidad de píxeles del dispositivo), de modo que los valores deben establecerse desde un recurso o tema en lugar de codificarlos en el archivo de manifiesto. El valor real puede cambiar en función de recursos alternativos que proporcionas para diferentes configuraciones de los dispositivos.

Los recursos se expresan como valores con el siguiente formato:

"@[package:]type/name"

Puedes omitir el nombre package si tu app proporciona el recurso (incluso si lo proporciona una dependencia de biblioteca, ya que los recursos de biblioteca se combinan con los tuyos). El otro nombre de paquete válido es android, disponible cuando quieres usar un recurso del framework de Android.

El type es un tipo de recurso, como string o drawable, y el name es el nombre que identifica el recurso específico. A continuación, se muestra un ejemplo:

<activity android:icon="@drawable/smallPic" ... >

Si deseas obtener más información para agregar recursos a tu proyecto, lee la Descripción general de recursos de la app.

Si prefieres aplicar un valor definido en un tema, el primer carácter debe ser ? en lugar de @:

"?[package:]type/name"

Valores de cadenas

Cuando el valor de un atributo sea una cadena, usa doble barra inversa (\\) para escapar los caracteres, como \\n para un salto de línea o \\uxxxx para un carácter Unicode.

Referencia de los elementos del manifiesto

La siguiente tabla proporciona vínculos a los documentos de referencia de todos los elementos válidos del archivo AndroidManifest.xml.

Límites

Las siguientes etiquetas tienen un límite en la cantidad de ocurrencias en un archivo de manifiesto:

Los siguientes atributos tienen un límite de longitud máxima:

Ejemplo de archivo de manifiesto

El XML que aparece a continuación es un AndroidManifest.xml simple de ejemplo que declara dos actividades de la app.

<?xml version="1.0" encoding="utf-8"?>
<manifest
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="1"
    android:versionName="1.0">

    <!-- Beware that these values are overridden by the build.gradle file -->
    <uses-sdk android:minSdkVersion="15" android:targetSdkVersion="26" />

    <application
        android:allowBackup="true"
        android:icon="@mipmap/ic_launcher"
        android:roundIcon="@mipmap/ic_launcher_round"
        android:label="@string/app_name"
        android:supportsRtl="true"
        android:theme="@style/AppTheme">

        <!-- This name is resolved to com.example.myapp.MainActivity
             based on the namespace property in the build.gradle file -->
        <activity android:name=".MainActivity">
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>

        <activity
            android:name=".DisplayMessageActivity"
            android:parentActivityName=".MainActivity" />
    </application>
</manifest>