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 deActivity
<service>
para cada subclase deService
<receiver>
para cada subclase deBroadcastReceiver
<provider>
para cada subclase deContentProvider
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í:
Groovy
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 ... } }
Kotlin
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>
.
-
Un elemento
- 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 prefijoandroid:
, comoandroid: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
odrawable
, 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
.
<action> |
Agrega una acción a un filtro de intents. |
<activity> |
Declara el componente de una actividad. |
<activity-alias> |
Declara el alias de una actividad. |
<application> |
Declara la aplicación. |
<category> |
Agrega un nombre de categoría a un filtro de intents. |
<compatible-screens> |
Especifica cada configuración de pantalla compatible con la aplicación. |
<data> |
Agrega una especificación de datos a un filtro de intents. |
<grant-uri-permission> |
Especifica los subconjuntos de datos de app a los que el proveedor de contenido superior tiene permiso para acceder. |
<instrumentation> |
Declara una clase Instrumentation que te permite supervisar la interacción de una aplicación con el sistema. |
<intent-filter> |
Especifica los tipos de intents a los que puede responder una actividad, un servicio o un receptor de emisión. |
<manifest> |
Es el elemento raíz del archivo AndroidManifest.xml . |
<meta-data> |
Es un par nombre-valor de un elemento de datos arbitrarios adicionales que se puede suministrar al componente superior. |
<path-permission> |
Define la ruta de acceso y los permisos que requiere un subconjunto específico de datos dentro de un proveedor de contenido. |
<permission> |
Declara un permiso de seguridad que puede usarse para limitar el acceso a funciones o componentes específicos de esta y otras aplicaciones. |
<permission-group> |
Declara un nombre para una agrupación lógica de permisos relacionados. |
<permission-tree> |
Declara el nombre base para un árbol de permisos. |
<provider> |
Declara un componente de proveedor de contenido. |
<queries> |
Declara el conjunto de otras apps a las que tu app accederá. Obtén más información en la guía sobre el filtrado de visibilidad de paquetes. |
<receiver> |
Declara el componente de un receptor de emisión. |
<service> |
Declara el componente de un servicio. |
<supports-gl-texture>
| Declara el único formato de compresión de texturas GL que admite la app. |
<supports-screens> |
Declara los tamaños de pantalla que admite tu app y habilita el modo de compatibilidad de pantalla para aquellas más grandes que las admitidas. |
<uses-configuration> |
Indica las funciones específicas de entrada que requiere la aplicación. |
<uses-feature> |
Declara una sola función de hardware o software que usa la aplicación. |
<uses-library> |
Especifica una biblioteca compartida con la que debe estar vinculada la aplicación. |
<uses-native-library> |
Especifica una biblioteca compartida nativa que proporciona el proveedor con la que se debe vincular la app. |
<uses-permission> |
Especifica un permiso de sistema que debe conceder el usuario para que la aplicación funcione correctamente. |
<uses-permission-sdk-23> |
Especifica que una app requiera un permiso particular, pero solo si esta se encuentra instalada en un dispositivo que ejecuta Android 6.0 (nivel de API 23) o versiones posteriores. |
<uses-sdk> |
Te permite expresar la compatibilidad de una aplicación con una o más versiones de la plataforma de Android, a través de un valor entero de nivel de API. |
Límites
Las siguientes etiquetas tienen un límite para la cantidad de casos en un archivo de manifiesto:
Nombre de la etiqueta | Límite |
---|---|
<package> |
1000 |
<meta-data> |
1000 |
<uses-library> |
1000 |
Los siguientes atributos tienen un límite en cuanto a su longitud máxima:
Atributo | Límite |
---|---|
name |
1024 |
versionName |
1024 |
host |
255 |
mimeType |
255 |
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>