Desarrolladores de Android | Android Developers

Google Play usa los elementos <uses-feature> declarados en el manifiesto de tu app para aplicarle filtrado y excluir dispositivos que no cumplan con sus requisitos de las funciones de software y hardware.

Cuando especificas las funciones que tu aplicación requiere, permites que Google Play presente tu app solo a los usuarios cuyos dispositivos cumplan con los requisitos de las funciones de tu aplicación en lugar de presentársela a todos.

Para obtener información importante sobre Google Play y el uso de funciones, como la base del filtrado, consulta Google Play y filtrado por funciones a continuación.

sintaxis:

<uses-feature
  android:name="string"
  android:required=["true" | "false"]
  android:glEsVersion="integer" />

se incluye en:

<manifest>

descripción:

Declara una sola función de hardware o software que usa la aplicación.

El objetivo de una declaración de <uses-feature> es informar a una entidad externa sobre el conjunto de funciones de hardware y software que la aplicación requiere. El elemento ofrece un atributo required que te permite especificar si tu aplicación requiere la función declarada, y no puede funcionar sin ella, o si prefiere contar con la aplicación y puede funcionar sin ella. Dado que la compatibilidad de funciones puede variar de un dispositivo Android a otro, el elemento <uses-feature> desempeña un papel importante porque permite que una aplicación describa las funciones que usa y que varían según el dispositivo.

El conjunto de funciones disponibles que tu aplicación declara corresponde al conjunto de constantes de funciones disponibles a través de PackageManager de Android. Las constantes de funciones se enumeran en la sección Referencia de las funciones al final de este documento.

Debes especificar cada función en un elemento <uses-feature> independiente. Por lo tanto, si tu aplicación requiere varias funciones, debe declarar varios elementos <uses-feature>. Por ejemplo, una aplicación que requiera las funciones de Bluetooth y cámara en el dispositivo debe declarar estos dos elementos:

<uses-feature android:name="android.hardware.bluetooth" android:required="true" />
<uses-feature android:name="android.hardware.camera.any" android:required="true" />

En general, debes asegurarte de declarar elementos <uses-feature> para todas las funciones que tu aplicación requiera.

Los elementos <uses-feature> declarados solo cumplen una función informativa: el sistema Android no comprueba que el dispositivo sea compatible con las funciones antes de instalar una aplicación. Sin embargo, es posible que otros servicios (como Google Play) u otras aplicaciones controlen las declaraciones <uses-feature> de tu aplicación como parte del funcionamiento o la interacción con ella. En consecuencia, es muy importante que declares todas las funciones (de la lista provista más adelante) que use tu aplicación.

Para algunas funciones, podría haber un atributo específico que te permita definir una versión de la función, como la versión de Open GL que se usó (declarada con glEsVersion). Otras funciones que existen o no en un dispositivo, como la cámara, se declaran con el atributo name.

A pesar de que el elemento <uses-feature> solo se activa para dispositivos con el nivel de API 4 o niveles superiores, incluye estos elementos para todas las aplicaciones, incluso si minSdkVersion es de la versión "3" o anterior. Los dispositivos con versiones anteriores de la plataforma simplemente ignoran el elemento.

Nota: Cuando declares una función, recuerda que también debes solicitar los permisos necesarios. Por ejemplo, no debes dejar de solicitar el permiso CAMERA para que tu aplicación pueda tener acceso a la API de cámara. La solicitud del permiso autoriza a tu aplicación a tener acceso al hardware y el software correspondientes. La declaración de las funciones que usa tu aplicación garantiza una correcta compatibilidad con el dispositivo.

atributos:

android:name

Especifica una función de hardware o software usada por tu aplicación como una cadena descriptora. Los valores válidos del atributo se enumeran en las secciones Funciones de hardware y Funciones de software. Para los valores de este atributo, se distinguen mayúsculas y minúsculas.

android:required

Valor booleano que indica si la aplicación requiere la función especificada en android:name.

Si declaras android:required="true" para una función, significa que la aplicación no puede funcionar, o no está diseñada para funcionar, cuando el dispositivo no cuenta con la función especificada.
Si declaras android:required="false" para una función, significa que la aplicación prioriza la función si está presente en el dispositivo, pero que está diseñada para funcionar sin la función especificada, en caso de que sea necesario.

Si no está declarado, el valor predeterminado de android:required es "true".

android:glEsVersion

Versión de OpenGL ES que requiere la aplicación. Los 16 bits superiores representan el número mayor, y los 16 bits inferiores, el número menor. Por ejemplo, para especificar que la versión de OpenGL ES es 2.0, debes establecer el valor en "0x00020000"; si quieres especificar OpenGL 3.2, debes establecer el valor en "0x00030002".

En el manifiesto, la aplicación no debería especificar más de un atributo android:glEsVersion. De lo contrario, se usará el valor numérico más alto de android:glEsVersion y se ignorará el resto.

Si una aplicación no especifica un atributo android:glEsVersion, se considerará que solo requiere OpenGL ES 1.0, que es compatible con todos los dispositivos que usan Android.

Si una plataforma es compatible con una determinada versión de OpenGL ES, la aplicación considera que es compatible con todas las versiones de OpenGL ES de menor numeración. Por lo tanto, una aplicación que requiera OpenGL ES 1.0 y OpenGL ES 2.0 deberá especificar que requiere OpenGL ES 2.0.

Una aplicación que pueda funcionar con varias versiones de OpenGL ES solo deberá especificar la versión de OpenGL ES de menor numeración que requiera (durante el tiempo de ejecución, puede verificar si se encuentra disponible una versión de OpenGL ES de nivel más alto).

Para obtener más información sobre el uso de OpenGL ES, incluida la manera de comprobar la versión de OpenGL ES compatible durante el tiempo de ejecución, consulta la guía de la API OpenGL ES.

primera inclusión:

Nivel de API 4

consulta también:

Google Play y filtrado por funciones

Google Play filtra las aplicaciones que son visibles para el usuario de manera que los usuarios puedan ver y descargar solo aquellas que sean compatibles con sus dispositivos. Una de las maneras en que filtra aplicaciones es por compatibilidad de las funciones.

Para determinar si las funciones de una aplicación son compatibles con el dispositivo del usuario, Google Play compara lo siguiente:

Funciones que requiere la aplicación (las aplicaciones declaran funciones en los elementos <uses-feature> dentro del manifiesto)
con…
Funciones disponibles en el dispositivo, tanto de hardware como de software (los dispositivos informan las funciones compatibles como propiedades del sistema que son de solo lectura).

Para garantizar una comparación precisa de las funciones, el Administrador de paquetes de Android brinda un conjunto compartido de constantes de funciones que usan las aplicaciones y los dispositivos para declarar los requisitos y la compatibilidad de las funciones. Las constantes de funciones disponibles se enumeran en la sección Referencia de las funciones, al final de este documento, y en la documentación de clase para PackageManager.

Cuando el usuario inicia Google Play, la aplicación llama a getSystemAvailableFeatures() para solicitarle al Administrador de paquetes la lista de funciones disponibles en el dispositivo. Luego, la aplicación de Store le transmite a Google Play la lista de las funciones cuando se establece la sesión del usuario.

Cada vez que cargas una aplicación en Google Play Console, Google Play analiza el archivo de manifiesto de la aplicación. Busca elementos <uses-feature> y los evalúa junto a otros elementos (en algunos casos), como <uses-sdk> y <uses-permission>. Tras establecer el conjunto de funciones que requiere la aplicación, almacena la lista internamente como metadatos asociados al .apk y a la versión de la aplicación.

Cuando un usuario busca o explora aplicaciones con la aplicación de Google Play, el servicio compara las funciones que requiere cada aplicación con las funciones disponibles en el dispositivo del usuario. Si el dispositivo cuenta con todas las funciones que requiere la aplicación, Google Play le permite al usuario ver la aplicación y descargarla si lo desea. Si el dispositivo no es compatible con alguna de las funciones requeridas, Google Play filtra la aplicación a fin de que no sea visible para el usuario y no esté disponible para la descarga.

Debido a que las funciones que declaras en los elementos <uses-feature> influyen directamente en la manera en que Google Play filtra tu aplicación, es importante que entiendas la forma en que Google Play evalúa el manifiesto de la aplicación y establece el conjunto de funciones requeridas. Encontrarás más información en las próximas secciones.

Filtrado por funciones declaradas explícitamente

Una función declarada explícitamente es una función que tu aplicación declara en un elemento <uses-feature>. La declaración de la función puede incluir un atributo android:required=["true" | "false"] (si realizas compilaciones para el nivel de API 5 o un nivel superior), que te permite especificar si la aplicación requiere la función de forma obligatoria y no puede funcionar correctamente sin ella ("true"), o si prioriza la función (en caso de que esté disponible), pero está diseñada para funcionar sin ella ("false").

Google Play administra las funciones declaradas explícitamente de la siguiente forma:

Si se declara explícitamente que la función es necesaria, Google Play agrega la función a la lista de funciones requeridas por la aplicación. A continuación, filtra la aplicación y se la oculta a los usuarios cuyos dispositivos no son compatibles con la función. Por ejemplo:
```
<uses-feature android:name="android.hardware.camera.any" android:required="true" />
```
Si se declara explícitamente que la función no es necesaria, Google Play no agrega la función a la lista de funciones requeridas por la aplicación. En consecuencia, las funciones declaradas explícitamente como no necesarias nunca se tienen en cuenta durante el filtrado de la aplicación. Aun cuando el dispositivo no proporcione la función declarada, Google Play seguirá considerando la aplicación como compatible con este y se la mostrará al usuario, a menos que corresponda otra regla de filtrado. Por ejemplo:
```
<uses-feature android:name="android.hardware.camera" android:required="false" />
```
Si una función está declarada explícitamente, pero sin un atributo android:required, Google Play considera que la función es necesaria y aplica un filtro.

En general, si tu aplicación está diseñada para funcionar en Android 1.6 y versiones anteriores, el atributo android:required no estará disponible en la API y Google Play considerará todas las declaraciones <uses-feature> como necesarias.

Nota: Si declaras una función de forma explícita y también incluyes un atributo android:required="false", puedes inhabilitar de manera eficaz todos los filtros de la función especificada en Google Play.

Filtrado por funciones implícitas

Una función implícita es aquella que una aplicación requiere para poder funcionar correctamente, pero que no se declara en un elemento <uses-feature> del archivo de manifiesto. En sentido estricto, las aplicaciones siempre deben declarar todas las funciones que usen o requieran. Por lo tanto, el hecho de que no se declare una función empleada por una aplicación debe considerarse un error. Sin embargo, como medida de protección para los usuarios y desarrolladores, Google Play busca funciones implícitas en cada aplicación y establece filtros para estas funciones, tal como lo haría para una función declarada explícitamente.

Es posible que una aplicación requiera una función, pero no la declare por las siguientes razones:

La aplicación se compiló para una versión anterior de la biblioteca de Android (Android 1.5 o versiones anteriores) y el elemento <uses-feature> no estaba disponible.
El desarrollador consideró incorrectamente que la función estaría presente en todos los dispositivos y que era innecesario declararla.
El desarrollador omitió accidentalmente la declaración de la función.
El desarrollador declaró explícitamente la función, pero la declaración no fue válida. Por ejemplo, la declaración de una función se puede invalidar por un error en el nombre del elemento <uses-feature> o porque no se reconoció el valor de string del atributo android:name.

Para responder a los casos anteriores, Google Play intenta descubrir los requisitos de las funciones implícitas de la aplicación examinando otros elementos declarados en el archivo de manifiesto (en concreto, los elementos <uses-permission>).

Si una aplicación solicita permisos relacionados con hardware, Google Play considera que la aplicación usa las funciones de hardware subyacentes y, por lo tanto, requiere dichas funciones aunque no se correspondan con las declaraciones de <uses-feature>. Para estos permisos, Google Play agrega las funciones de hardware subyacentes a los metadatos que almacena para la aplicación y establece los filtros correspondientes.

Por ejemplo, si una aplicación solicita el permiso CAMERA, Google Play asume que la aplicación requiere una cámara trasera (orientada al mundo), incluso si la app no declara <uses-feature> para el elemento android.hardware.camera. Como resultado, Google Play filtra los dispositivos que no tienen cámara trasera.

Si no quieres que Google Play aplique filtrado conforme a una determinada función implícita, debes declararlo explícitamente en un elemento <uses-feature> e incluir el atributo android:required="false". Por ejemplo, para inhabilitar el filtrado implícito por el permiso CAMERA, declara las siguientes funciones:

<uses-feature android:name="android.hardware.camera" android:required="false" />
<uses-feature android:name="android.hardware.camera.autofocus" android:required="false" />

Precaución: Los permisos que solicites en los elementos <uses-permission> pueden influir directamente en la forma en que Google Play filtre tu aplicación. En la sección de referencia Permisos que implican requisitos de funciones, se enumera el conjunto completo de permisos que implican requisitos de funciones y, en consecuencia, que producen filtros.

Tratamiento especial para la función Bluetooth

Cuando se trata del filtrado por Bluetooth, Google Play usa reglas un tanto diferentes de las descritas anteriormente.

Si una aplicación declara un permiso de Bluetooth en un elemento <uses-permission>, pero no declara explícitamente la función Bluetooth en un elemento <uses-feature>, Google Play revisa la versión de la plataforma Android para la que está diseñada la aplicación, según el elemento <uses-sdk>.

Como se muestra en la siguiente tabla, Google Play habilita el filtro para la función Bluetooth únicamente si la aplicación declara que la plataforma de destino, o la versión más antigua que puede usar, es Android 2.0 (nivel de API 5) o una versión posterior. Sin embargo, ten en cuenta que Google Play usa las reglas convencionales de filtrado cuando la aplicación declara explícitamente la función Bluetooth en un elemento <uses-feature>.

Tabla 1: Cómo determina Google Play el requisito de la función Bluetooth en una aplicación que solicita un permiso de Bluetooth, pero no declara la función Bluetooth en un elemento <uses-feature>

Si `minSdkVersion` es…	o `targetSdkVersion` es	Resultado
<=4 (o uses-sdk no declarado)	<=4	Google Play no filtrará la aplicación en ningún dispositivo según la compatibilidad con la función `android.hardware.bluetooth` que declare.
<=4	>=5	Google Play filtrará la aplicación en cualquier dispositivo que no admita la función `android.hardware.bluetooth` (incluso las versiones anteriores).
>=5	>=5

En los siguientes ejemplos, se muestran los efectos de las variaciones de filtrado según el tratamiento que hace Google Play de la función Bluetooth.

En el primer ejemplo, una aplicación diseñada para funcionar en niveles de API más antiguos declara un permiso de Bluetooth, pero no declara la función Bluetooth en un elemento <uses-feature>.: Resultado: Google Play no filtra la aplicación en ningún dispositivo.

<manifest ...>
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
    <uses-sdk android:minSdkVersion="3" />
    ...
</manifest>

En el segundo ejemplo, a continuación, la misma aplicación también declara el nivel de API objetivo en 5.: Resultado: Ahora, Google Play considera que la función es necesaria y filtrará la aplicación en todos los dispositivos que no informen compatibilidad con Bluetooth, incluso los que funcionen con versiones anteriores de la plataforma.

<manifest ...>
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
    <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
    ...
</manifest>

En este caso, la misma aplicación declara específicamente la función Bluetooth.: Resultado: Igual al del ejemplo anterior (se aplica filtrado).

<manifest ...>
    <uses-feature android:name="android.hardware.bluetooth" />
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
    <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
    ...
</manifest>

Por último, en el siguiente caso, la misma aplicación agrega un atributo android:required="false".: Resultado: Google Play inhabilita los filtros a partir de la compatibilidad con la función Bluetooth en todos los dispositivos.

<manifest ...>
    <uses-feature android:name="android.hardware.bluetooth" android:required="false" />
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
    <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
    ...
</manifest>

Pruebas de las funciones que requiere tu aplicación

Puedes usar la herramienta aapt, incluida en el SDK de Android, para determinar la forma en que Google Play filtrará tu aplicación según las funciones y los permisos declarados. Para hacerlo, ejecuta aapt con el comando dump badging. aapt analizará el manifiesto de tu aplicación y usará las mismas reglas que Google Play para determinar las funciones que esta requiera.

Para usar la herramienta, sigue estos pasos:

Primero, compila y exporta tu aplicación como un .apk sin firmar. Si realizas el desarrollo en Android Studio, usa Gradle para compilar tu aplicación:
1. Abre el proyecto y selecciona Run > Edit Configurations.
2. Selecciona el signo más cerca de la esquina superior izquierda de la ventana Run/Debug Configurations.
3. Selecciona Gradle.
4. Ingresa Unsigned APK en Name.
5. Elige el módulo en la sección Gradle project.
6. Ingresa assemble en Tasks.
7. Selecciona OK para completar la nueva configuración.
8. Asegúrate de que la configuración de ejecución Unsigned APK esté seleccionada en la barra de herramientas y selecciona Run > Run "Unsigned APK".
Puedes encontrar tu .apk sin firmar en el directorio <ProjectName>/app/build/outputs/apk/.
Luego, busca la herramienta aapt si todavía no está en tu ruta de acceso. Si usas SDK Tools r8 o versiones posteriores, aapt se encuentra en el directorio <SDK>/build-tools/<tools version number>.
Nota: Debes usar la versión de aapt que se proporciona para el componente de herramientas de compilación más reciente disponible. Si no tienes el componente Build-Tools más reciente, descárgalo con Android SDK Manager.
Ejecuta aapt con esta sintaxis:

$ aapt dump badging <path_to_exported_.apk>

Este es un ejemplo de la salida de comando correspondiente al segundo ejemplo con Bluetooth descrito anteriormente:

$ ./aapt dump badging BTExample.apk
package: name='com.example.android.btexample' versionCode='' versionName=''
uses-permission:'android.permission.BLUETOOTH_ADMIN'
uses-feature:'android.hardware.bluetooth'
sdkVersion:'3'
targetSdkVersion:'5'
application: label='BT Example' icon='res/drawable/app_bt_ex.png'
launchable activity name='com.example.android.btexample.MyActivity'label='' icon=''
uses-feature:'android.hardware.touchscreen'
main
supports-screens: 'small' 'normal' 'large'
locales: '--_--'
densities: '160'

Referencia de las funciones

En las siguientes secciones, se proporciona información de referencia sobre las funciones de hardware, las funciones de software y los conjuntos de permisos que implican requisitos de funciones específicas.

Funciones de hardware

En esta sección, se muestran las funciones de hardware compatibles con las versiones de plataformas más actuales. Para indicar que tu aplicación usa o requiere una función de hardware, declara el valor correspondiente (empieza por "android.hardware") en un atributo android:name. Cada vez que declares una función de hardware, usa un elemento <uses-feature> independiente.

Funciones de hardware para audio

android.hardware.audio.low_latency: La aplicación usa el flujo de procesamiento de audio de baja latencia del dispositivo, que disminuye los retrasos y las demoras cuando se procesan entradas y salidas de audio.
android.hardware.audio.output: La aplicación transmite sonido con los altavoces, el conector de audio y las capacidades de transmisión de Bluetooth, o un mecanismo similar.
android.hardware.audio.pro: La aplicación usa las capacidades de rendimiento y funcionalidad de audio de alta gama del dispositivo.
android.hardware.microphone: La app graba audio con el micrófono del dispositivo.

Funciones de hardware para Bluetooth

android.hardware.bluetooth: La aplicación usa las funciones de Bluetooth del dispositivo (generalmente, para comunicarse con otros dispositivos con Bluetooth).
android.hardware.bluetooth_le: La app usa las funciones de radio de Bluetooth de bajo consumo que usa el dispositivo.

Funciones de hardware para la cámara

Nota: Para evitar el filtrado innecesario de Google Play en tu app, agrega android:required="false" a cualquier función de la cámara que la app pueda prescindir. De lo contrario, Google Play considera que la función es necesaria y evita que los dispositivos que no la admiten accedan a tu app.

Compatibilidad con pantallas grandes

Algunos dispositivos de pantalla grande no admiten todas las funciones de la cámara. Las Chromebooks no suelen tener cámaras posteriores (orientadas al mundo) con enfoque automático ni de flash. Sin embargo, las Chromebooks tienen cámaras frontales (orientadas al usuario) y suelen conectarse a cámaras externas.

Para brindar compatibilidad básica con la cámara y hacer que tu app esté disponible para la mayor cantidad posible de dispositivos, agrega los siguientes parámetros de configuración a la función de cámara en manifiesto de tu app:

<uses-feature android:name="android.hardware.camera.any" android:required="false" />
<uses-feature android:name="android.hardware.camera" android:required="false" />
<uses-feature android:name="android.hardware.camera.autofocus" android:required="false" />
<uses-feature android:name="android.hardware.camera.flash" android:required="false" />

Modifica los parámetros de configuración de las funciones para admitir los casos de uso de tu app. Sin embargo, si quieres que tu app esté disponible para la mayor cantidad posible de dispositivos, incluye siempre el atributo required para especificar de forma explícita si una función es imprescindible.

Lista de funciones

android.hardware.camera.any

La app usa una de las cámaras del dispositivo o una cámara externa conectada al dispositivo. Usa esta función en lugar de android.hardware.camera o android.hardware.camera.front si tu app no requiere que una cámara trasera (orientada al mundo) o delantera (orientada al usuario) respectivamente.

El permiso CAMERA implica que tu app también usa android.hardware.camera. Una cámara trasera es una función necesaria, a menos que se declare android.hardware.camera con android:required="false".

android.hardware.camera

La app usa la cámara trasera (orientada al mundo) del dispositivo.

Precaución: Los dispositivos como las Chromebooks que solo tienen una cámara frontal (orientada al usuario) no admiten esta función. Usa android.hardware.camera.any si tu app puede usar cualquier cámara, independientemente de la dirección a la que apunte.

Nota: El permiso CAMERA implica que la cámara posterior es una función obligatoria. A fin de garantizar un filtrado adecuado en Google Play, cuando el manifiesto de tu app incluya el permiso CAMERA, especifica de forma explícita que tu app usa la función camera e indica si es necesaria para ejemplo:
<uses-feature android:name="android.hardware.camera" android:required="false" />

android.hardware.camera.front

La app usa la cámara frontal (orientada al usuario) del dispositivo.

Precaución: Si tu app usa android.hardware.camera.front, pero no declara explícitamente android.hardware.camera conandroid.required="false", Google Play filtra los dispositivos que no tienen una cámara trasera (como las Chromebooks). Si tu app solo admite cámaras frontales, declara android.hardware.camera con android.required="false" para evitar filtros innecesarios.

android.hardware.camera.external

La app se comunica con una cámara externa que el usuario conecta al dispositivo. Esta función no garantiza que haya una cámara externa disponible para la app.

android.hardware.camera.autofocus

La app usa la función de enfoque automático compatible con la cámara del dispositivo.

Nota: El permiso CAMERA implica que el enfoque automático es una función obligatoria. A fin de garantizar un filtrado adecuado en Google Play, cuando el manifiesto de tu app incluya el permiso CAMERA, especifica de forma explícita que tu app usa la función de enfoque automático e indica si es necesaria para ejemplo:
<uses-feature android:name="android.hardware.camera.autofocus" android:required="false" />.

android.hardware.camera.flash

La app usa la función de flash compatible con la cámara del dispositivo.

android.hardware.camera.capability.manual_post_processing

La app usa la función MANUAL_POST_PROCESSING compatible con la cámara del dispositivo.

Esta función habilita a tu app a anular la funcionalidad de balance de blancos automático de la cámara. Usa android.colorCorrection.transform, android.colorCorrection.gains y un android.colorCorrection.mode de TRANSFORM_MATRIX.

android.hardware.camera.capability.manual_sensor

La app usa la función MANUAL_SENSOR compatible con la cámara del dispositivo.

Esta función implica compatibilidad con el bloqueo de exposición automática (android.control.aeLock), que habilita fijar la sensibilidad y el tiempo de exposición de la cámara en valores específicos.

android.hardware.camera.capability.raw

La app usa la función RAW compatible con la cámara del dispositivo.

Esta función implica que el dispositivo pueda guardar archivos DNG (sin procesar) y que la cámara del dispositivo proporcionar los metadatos relacionados con DNG necesarios para que tu app procese directamente estas imágenes.

android.hardware.camera.level.full

La app usa el nivel FULL de compatibilidad con captura de imágenes que proporcionan al menos una de las cámaras del dispositivo. La compatibilidad con FULL proporciona capacidades de modo ráfaga, control por marco y control de procesamiento trasero manual. Consulta INFO_SUPPORTED_HARDWARE_LEVEL_FULL.

Funciones de hardware para la IU del dispositivo

android.hardware.type.automotive

La app está diseñada para mostrar su IU en un conjunto de pantallas dentro de un vehículo. El usuario interactúa con la app mediante botones físicos, el tacto, controles rotativos e interfaces tipo mouse. Por lo general, las pantallas del vehículo aparecen en la consola central o en el panel de instrumentos. Normalmente, estas pantallas tienen resoluciones y tamaños limitados.

Nota: Es importante tener en cuenta que, debido a que el usuario conduce mientras usa este tipo de IU de app, la app debe minimizar la distracción del conductor.

android.hardware.type.television

(Obsoleto; usa android.software.leanback en su lugar.)

La app está diseñada para mostrar su IU en una televisión. Esta función define "televisión" como una típica experiencia de televisión en una sala de estar: se muestra en una pantalla grande, con el usuario sentado lejos; la forma de entrada predominante es un control de dirección (o un elemento similar); y, generalmente, no se usa un mouse, un puntero ni un dispositivo táctil.

android.hardware.type.watch

La app está diseñada para mostrar su IU en un reloj. Los relojes se usan en el cuerpo (por ejemplo, en la muñeca). El usuario está muy cerca del dispositivo mientras interactúa con él.

Funciones de hardware de huella dactilar

android.hardware.fingerprint: La app realiza una lectura de las huellas dactilares con el hardware biométrico del dispositivo.

Funciones de hardware para controles de mando

android.hardware.gamepad: La app captura la entrada de un control para juegos desde el dispositivo mismo o desde un control de juegos conectado.

Funciones de hardware para capacidades infrarrojas

android.hardware.consumerir: La aplicación usa las capacidades infrarrojas (IR) del dispositivo. Por lo general, las usa para comunicarse con otros dispositivos infrarrojos de consumidor.

Funciones de hardware para ubicación

android.hardware.location

La app usa una o más funciones en el dispositivo para determinar una ubicación, como de GPS, red o celular.

android.hardware.location.gps

La app usa coordenadas de ubicación precisa obtenidas del sistema de posicionamiento global (GPS) del dispositivo.

Si usa esta función, la app implica que también usa la función android.hardware.location, a menos que esta función principal se declare con el atributo android:required="false".

android.hardware.location.network

La app usa coordenadas de ubicaciones comunes que obtiene de un sistema de ubicación geográfica basado en red compatible con el dispositivo.

Si usa esta función, la app implica que también usa la función android.hardware.location, a menos que esta función principal se declare con el atributo android:required="false".

Funciones de hardware para NFC

android.hardware.nfc: La app usa las funciones de radio de comunicación de campo cercano (NFC) del dispositivo.
android.hardware.nfc.hce: La app usa la emulación de tarjeta NFC alojada en el dispositivo.

Funciones de hardware para OpenGL ES

android.hardware.opengles.aep: La app usa el Android Extension Pack para OpenGL ES instalado en el dispositivo.

Funciones de hardware para sensores

android.hardware.sensor.accelerometer: La app usa lecturas de movimiento del acelerómetro del dispositivo para detectar la orientación actual del dispositivo. Por ejemplo, una app puede usar lecturas del acelerómetro para determinar el momento en que debe alternar la orientación vertical y la horizontal.
android.hardware.sensor.ambient_temperature: La app usa el sensor de temperatura ambiente (del entorno) del dispositivo. Por ejemplo, una app meteorológica puede informar la temperatura interior y la exterior.
android.hardware.sensor.barometer: La app usa el barómetro del dispositivo. Por ejemplo, una app meteorológica puede informar la presión del aire.
android.hardware.sensor.compass: La app usa el magnetómetro del dispositivo (la brújula). Por ejemplo, una app de navegación puede mostrar la orientación actual del usuario.
android.hardware.sensor.gyroscope: La app usa el giroscopio del dispositivo para detectar rotaciones y giros; en consecuencia, crea un sistema de orientación de seis ejes. Usando este sensor, la app puede determinar con mayor precisión si debe alternar entre la orientación vertical y la horizontal.
android.hardware.sensor.hifi_sensors: La app usa los sensores de alta fidelidad (Hi-Fi) del dispositivo. Por ejemplo, una app de juego puede detectar los movimientos precisos del usuario.
android.hardware.sensor.heartrate: La app usa el monitor de frecuencia cardíaca del dispositivo. Por ejemplo, una app de fitness puede informar tendencias en el ritmo cardíaco del usuario en un período.
android.hardware.sensor.heartrate.ecg: La app usa el sensor de ritmo cardíaco ECG (electrocardiograma) del dispositivo. Por ejemplo, una app de fitness puede brindar información más detallada sobre el ritmo cardíaco del usuario.
android.hardware.sensor.light: La app usa el sensor de luz del dispositivo. Por ejemplo, una app puede mostrar uno de dos esquemas de colores diferentes según las condiciones lumínicas del ambiente.
android.hardware.sensor.proximity: La aplicación usa el sensor de proximidad del dispositivo. Por ejemplo, una app telefónica puede apagar la pantalla del dispositivo cuando detecta que el usuario sujeta el dispositivo cerca del cuerpo.
android.hardware.sensor.relative_humidity: La app usa el sensor de humedad relativa del dispositivo. Por ejemplo, una app meteorológica puede usar la humedad para calcular el punto de rocío actual y proporcionar información.
android.hardware.sensor.stepcounter: La aplicación usa el contador de pasos del dispositivo. Por ejemplo, una app de fitness puede informar la cantidad de pasos que necesita un usuario para alcanzar su objetivo diario de pasos.
android.hardware.sensor.stepdetector: La app usa el detector de pasos del dispositivo. Por ejemplo, una app de fitness puede usar el intervalo entre pasos para inferir el tipo de ejercicio que realiza el usuario.

Funciones de hardware para pantallas

android.hardware.screen.landscape

android.hardware.screen.portrait

La app requiere que el dispositivo use la orientación vertical u horizontal. Si tu app admite ambas orientaciones, no hace falta que declares ninguna de las funciones.

Por ejemplo, si tu app requiere la orientación vertical, debes declarar la siguiente función para que solo aquellos dispositivos que admitan la orientación vertical (siempre o por elección del usuario) puedan ejecutar la app:

<uses-feature android:name="android.hardware.screen.portrait" />

De forma predeterminada, no se consideran necesarias ambas orientaciones. En consecuencia, tu app puede instalarse en dispositivos que admitan una orientación o las dos. Sin embargo, si alguna de tus actividades solicita que se ejecuten en una orientación específica con el atributo android:screenOrientation, esta declaración implica que la app requiere esa orientación. Por ejemplo, si declaras android:screenOrientation con "landscape", "reverseLandscape" o "sensorLandscape", tu app solo estará disponible en dispositivos que admitan orientación horizontal.

Como práctica recomendada, no olvides usar el elemento <uses-feature> para declarar que requieres esta orientación. Si declaras una orientación para tu actividad con android:screenOrientation, pero no es absolutamente necesaria, puedes inhabilitar el requisito declarando la orientación con un elemento <uses-feature> e incluir android:required="false".

Para garantizar la retrocompatibilidad, todos los dispositivos con Android 3.1 (nivel de API 12) o versiones anteriores admiten orientación tanto vertical como horizontal.

Funciones de hardware para telefonía

android.hardware.telephony

La app usa las funciones telefónicas del dispositivo, como la radiotelefonía con servicios de comunicación de datos.

android.hardware.telephony.cdma

La app usa el sistema de radiotelefonía de acceso múltiple por división de códigos (CDMA).

Si usa esta función, la app implica que también usa la función android.hardware.telephony, a menos que esta función principal se declare con android:required="false".

android.hardware.telephony.gsm

La app usa el sistema de radiotelefonía del sistema de telefonía global para comunicaciones móviles (GSM).

Si usa esta función, la app implica que también usa la función android.hardware.telephony, a menos que esta función principal se declare con android:required="false".

Funciones de hardware para pantalla táctil

android.hardware.faketouch

La aplicación usa eventos básicos de interacción táctil, como los de presión y arrastre.

Si se declara como necesaria, esta función indica que la aplicación es compatible con un dispositivo solo si este emula una pantalla táctil (interfaz "táctil falsa") o realmente tiene una.

Un dispositivo que ofrece una interfaz táctil falsa proporciona al usuario un sistema de entrada que emula un subconjunto de capacidades de pantalla táctil. Por ejemplo, un mouse o un control remoto pueden hacer funcionar un cursor en pantalla. Si tu app requiere una interacción básica tipo "apuntar y hacer clic" (es decir, no funcionará solo con un control de dirección), debes declarar esta función. Dado que se trata del mínimo nivel de interacción táctil, también puedes usar una app que declare esta función en dispositivos con interfaces táctiles más complejas.

Nota: Las apps requieren la función android.hardware.faketouch de forma predeterminada. Si quieres que tu app se limite a dispositivos que solo tengan pantalla táctil, debes declarar explícitamente que se requiere una pantalla táctil de la siguiente manera:

<uses-feature android:name="android.hardware.touchscreen"
    android:required="true" />

Todas las apps que no requieran explícitamente android.hardware.touchscreen también funcionarán en dispositivos con android.hardware.faketouch.

<uses-feature android:name="android.hardware.touchscreen" android:required="false" />

android.hardware.faketouch.multitouch.distinct

La app realiza el seguimiento de dos o más "dedos" distintos en una interfaz táctil falsa. Es un superconjunto de la función android.hardware.faketouch. Si se declara como necesaria, esta función indica que la app es compatible con un dispositivo solo si este emula el seguimiento de dos o más dedos distintos, o si realmente tiene una pantalla táctil.

A diferencia de la función multitáctil diferenciada que define android.hardware.touchscreen.multitouch.distinct, los dispositivos de entrada que admiten la función multitáctil diferenciada con una interfaz táctil falsa no son compatibles con todos los gestos de dos dedos porque la entrada se transforma en movimiento de cursor en pantalla. Es decir, los gestos de un dedo en dispositivos de este tipo mueven un cursor, los deslizamientos de dos dedos provocan eventos táctiles de un dedo y otros gestos de dos dedos inician los correspondientes eventos táctiles de dos dedos.

Un dispositivo que proporciona una superficie táctil de dos dedos para el movimiento del cursor puede ser compatible con esta función.

android.hardware.faketouch.multitouch.jazzhand

La app realiza un seguimiento de cinco o más "dedos" distintos en una interfaz táctil falsa. Es un superconjunto de la función android.hardware.faketouch. Si se declara como necesaria, esta función indica que la app es compatible con un dispositivo solo si este emula el seguimiento de cinco o más dedos distintos, o si realmente tiene una pantalla táctil.

A diferencia de la función multitáctil diferenciada que define android.hardware.touchscreen.multitouch.jazzhand, los dispositivos de entrada que admiten la función multitáctil tipo jazzhand con una interfaz táctil falsa no son compatibles con todos los gestos de cinco dedos porque la entrada se transforma en movimiento de cursor en pantalla. Es decir, los gestos de un dedo en dispositivos de este tipo mueven un cursor, los gestos de varios dedos generan eventos táctiles de un solo dedo y otros gestos de varios dedos inician los correspondientes eventos táctiles de varios dedos.

Un dispositivo que proporciona una superficie táctil de cinco dedos para el movimiento del cursor puede ser compatible con esta función.

android.hardware.touchscreen

La app usa las capacidades de pantalla táctil del dispositivo para los gestos que son más interactivos que los eventos táctiles básicos, como un desplazamiento. Es un superconjunto de la función android.hardware.faketouch.

Tu app requiere esta función de forma predeterminada. Como tal, tu app no está disponible de manera predeterminada para dispositivos que proporcionan solo una interfaz táctil emulada ("táctil falsa"). Si deseas que tu app esté disponible en dispositivos que proporcionen una interfaz táctil falsa (o, incluso, en dispositivos que proporcionen únicamente un control de dirección), debes declarar explícitamente que no es necesaria una pantalla táctil. Para hacerlo, declara android.hardware.touchscreen con android:required="false". Debes agregar esta declaración si tu app usa una interfaz de pantalla táctil real, pero no la necesita. Todas las apps que no requieran explícitamente android.hardware.touchscreen también funcionarán en dispositivos con android.hardware.faketouch.

Si tu app realmente necesita una interfaz táctil (para realizar gestos táctiles más avanzados, como desplazamientos), no hace falta que declares ninguna función de interfaz táctil, ya que se requieren de forma predeterminada. Sin embargo, la mejor opción será declarar explícitamente todas las funciones que use tu app.

Si requieres interacciones táctiles más complejas, como gestos de varios dedos, debes declarar que tu app usa funciones de pantalla táctil avanzadas.

android.hardware.touchscreen.multitouch

La app usa las capacidades multitáctiles básicas de dos puntos del dispositivo, como las de los gestos para pellizcar, pero no necesita realizar el seguimiento de los eventos táctiles de forma independiente. Es un superconjunto de la función android.hardware.touchscreen.

Si usa esta función, la app implica que también usa la función android.hardware.touchscreen, a menos que esta función principal se declare con android:required="false".

android.hardware.touchscreen.multitouch.distinct

La app usa las capacidades multitáctiles avanzadas del dispositivo para realizar el seguimiento de dos o más puntos de forma independiente. Esta función es un superconjunto de la función android.hardware.touchscreen.multitouch.

Si usa esta función, la app implica que también usa la función android.hardware.touchscreen.multitouch, a menos que esta función principal se declare con android:required="false".

android.hardware.touchscreen.multitouch.jazzhand

La app usa las capacidades multitáctiles avanzadas del dispositivo para realizar el seguimiento de cinco o más puntos de forma independiente. Esta función es un superconjunto de la función android.hardware.touchscreen.multitouch.

Si usa esta función, la app implica que también usa la función android.hardware.touchscreen.multitouch, a menos que esta función principal se declare con android:required="false".

Funciones de hardware para USB

android.hardware.usb.accessory: La app funciona como el dispositivo USB y se conecta a hosts USB.
android.hardware.usb.host: La app usa los accesorios USB que se conectan al dispositivo. El dispositivo funciona como el host USB.

Funciones de hardware para Vulkan

android.hardware.vulkan.compute

La app usa las funciones de cálculo de Vulkan. Esta función indica que la app requiere la implementación de Vulkan con aceleración de hardware. La versión de la función indica qué nivel de funciones de cálculo opcionales requiere la aplicación, más allá de los requisitos de Vulkan 1.0. Por ejemplo, si tu app requiere el nivel 0 de compatibilidad con las funciones de cálculo de Vulkan, debes declarar la siguiente función:

<uses-feature
    android:name="android.hardware.vulkan.compute"
    android:version="0"
    android:required="true" />

Si quieres obtener más detalles sobre el nivel de función, consulta


    FEATURE_VULKAN_HARDWARE_COMPUTE

android.hardware.vulkan.level

La app usa las funciones del nivel de Vulkan. Esta función indica que la app requiere la implementación de Vulkan con aceleración de hardware. La versión de la función indica el nivel de funciones de hardware opcionales que requiere la app. Por ejemplo, si tu app requiere el nivel 0 de compatibilidad con el hardware de cálculo de Vulkan, debes declarar la siguiente función:

<uses-feature
    android:name="android.hardware.vulkan.level"
    android:version="0"
    android:required="true" />

Si quieres obtener más detalles sobre el nivel de función, consulta


    FEATURE_VULKAN_HARDWARE_LEVEL

android.hardware.vulkan.version

La app usa Vulkan. Esta función indica que la app requiere la implementación de Vulkan con aceleración de hardware. La versión de la función indica la versión mínima compatible con la API de Vulkan que requiere la app. Por ejemplo, si tu app requiere compatibilidad con Vulkan 1.0, debes declarar la siguiente función:

<uses-feature
    android:name="android.hardware.vulkan.version"
    android:version="0x400003"
    android:required="true" />

Si quieres obtener más detalles sobre el nivel de función, consulta


    FEATURE_VULKAN_HARDWARE_VERSION

Funciones de hardware para Wi-Fi

android.hardware.wifi: La app usa funciones de red 802.11 (Wi-Fi) en el dispositivo.
android.hardware.wifi.direct: La app usa las funciones de red Wi-Fi directo en el dispositivo.

Funciones de software

En esta sección, se muestran las funciones de software compatibles con las versiones de plataformas más recientes. Para indicar que tu aplicación usa o requiere una función de software, declara el valor correspondiente (empieza por "android.software") en un atributo android:name. Cada vez que declares una función de software, usa un elemento <uses-feature> independiente.

Funciones de software para comunicaciones

android.software.sip

La app usa los servicios del protocolo de inicio de sesión (SIP). Gracias al SIP, la app puede admitir operaciones telefónicas por Internet, como videoconferencias y mensajería instantánea.

android.software.sip.voip

La app usa servicios de protocolo de voz a través de Internet (VoIP) basados en SIP. Gracias al VoIP, la app puede admitir operaciones telefónicas por Internet en tiempo real, como videoconferencias bidireccionales.

Si usa esta función, la app implica que también usa la función android.software.sip, a menos que esta función principal se declare con android:required="false".

android.software.webview

La app muestra contenido de Internet.

Funciones de software para entradas personalizadas

android.software.input_methods: La app usa un nuevo método de entrada, que el desarrollador define en un InputMethodService.

Funciones de software para la administración de dispositivos

android.software.backup: La app incluye la lógica necesaria para gestionar una operación de copia de seguridad y restauración.
android.software.device_admin: La app usa administradores de dispositivos para aplicar una política de dispositivo.
android.software.managed_users: La app admite usuarios secundarios y perfiles administrados.
android.software.securely_removes_users: La app puede quitar usuarios y sus datos asociados de forma permanente.
android.software.verified_boot: La app incluye la lógica necesaria para gestionar los resultados de la función de inicio verificado del dispositivo, que detecta cambios en la configuración del dispositivo durante una operación de reinicio.

Funciones de software para contenido multimedia

android.software.midi: La app se conecta a instrumentos musicales o reproduce sonido con el protocolo de interfaz digital para instrumentos musicales (MIDI).
android.software.print: La app incluye comandos para imprimir documentos que se muestran en el dispositivo.
android.software.leanback: La app está diseñada para ejecutarse en dispositivos Android TV.
android.software.live_tv: La app transmite programas de televisión en vivo.

Funciones de software para interfaces de pantalla

android.software.app_widgets: La app usa y proporciona widgets de app, y debe instalarse solamente en dispositivos con una pantalla principal o ubicación similar donde los usuarios puedan incorporar estos widgets.
android.software.home_screen: La app se comporta como alternativa a la pantalla principal del dispositivo.
android.software.live_wallpaper: La app usa o proporciona fondos de pantalla que incluyen animaciones.

Permisos que implican requisitos de funciones

Algunas constantes de funciones de hardware y software se habilitaron para aplicaciones después que la API correspondiente. Por ejemplo, la función android.hardware.bluetooth se agregó en Android 2.2 (nivel de API 8), pero la API de Bluetooth a la que hace referencia se agregó en Android 2.0 (nivel de API 5). En consecuencia, algunas apps podían usar la API antes de poder declarar que necesitaban la API mediante el sistema <uses-feature>.

Para evitar que estas aplicaciones estén disponibles accidentalmente, Google Play considera que ciertos permisos de hardware indican que las funciones de hardware subyacentes se requieren de forma predeterminada. Por ejemplo, las aplicaciones que usan Bluetooth deben solicitar el permiso BLUETOOTH en un elemento <uses-permission>. En el caso de las apps heredadas, Google Play supone que la declaración de permisos significa que la aplicación requiere la función subyacente android.hardware.bluetooth y configura el filtrado en función de ella. En la Tabla 2, se enumeran los permisos que implican requisitos de funciones equivalentes a los declarados en elementos <uses-feature>.

Ten en cuenta que las declaraciones de <uses-feature>, incluido cualquier atributo android:required declarado, siempre tienen prioridad sobre las funciones implícitas en los permisos de la Tabla 2. Para cualquiera de estos permisos, puedes inhabilitar el filtrado basado en la función implícita si declaras explícitamente la función en un elemento <uses-feature> con el atributo required establecido en false. Por ejemplo, para inhabilitar el filtrado según el permiso CAMERA, agrega las siguientes declaraciones <uses-feature> al archivo de manifiesto:

<uses-feature android:name="android.hardware.camera" android:required="false" />
<uses-feature android:name="android.hardware.camera.autofocus" android:required="false" />

Precaución: Si tu app está orientada a Android 5.0 (nivel de API 21) o versiones posteriores y usa el permiso ACCESS_COARSE_LOCATION o ACCESS_FINE_LOCATION para recibir actualizaciones de ubicación de la red o de un sistema GPS (respectivamente), también debes declarar explícitamente que tu app usa las funciones de hardware android.hardware.location.network o android.hardware.location.gps.

Tabla 2: Permisos del dispositivo que implican el uso de hardware del dispositivo

Categoría	Permiso	Requisito de función implícita
Bluetooth	`BLUETOOTH`	`android.hardware.bluetooth` Para obtener información detallada, consulta Tratamiento especial para la función Bluetooth.
Bluetooth	`BLUETOOTH_ADMIN`	`android.hardware.bluetooth`
Cámara	`CAMERA`	`android.hardware.camera` `android.hardware.camera.autofocus`
Ubicación	`ACCESS_MOCK_LOCATION`	`android.hardware.location`
	`ACCESS_LOCATION_EXTRA_COMMANDS`	`android.hardware.location`
	`INSTALL_LOCATION_PROVIDER`	`android.hardware.location`
	`ACCESS_COARSE_LOCATION`	`android.hardware.location` `android.hardware.location.network` (solo cuando el nivel de API objetivo es 20 o inferior)
	`ACCESS_FINE_LOCATION`	`android.hardware.location` `android.hardware.location.gps` (solo cuando el nivel de API objetivo es 20 o inferior)
Micrófono	`RECORD_AUDIO`	`android.hardware.microphone`
Telefonía	`CALL_PHONE`	`android.hardware.telephony`
	`CALL_PRIVILEGED`	`android.hardware.telephony`
	`MODIFY_PHONE_STATE`	`android.hardware.telephony`
	`PROCESS_OUTGOING_CALLS`	`android.hardware.telephony`
	`READ_SMS`	`android.hardware.telephony`
	`RECEIVE_SMS`	`android.hardware.telephony`
	`RECEIVE_MMS`	`android.hardware.telephony`
	`RECEIVE_WAP_PUSH`	`android.hardware.telephony`
	`SEND_SMS`	`android.hardware.telephony`
	`WRITE_APN_SETTINGS`	`android.hardware.telephony`
	`WRITE_SMS`	`android.hardware.telephony`
Wi-Fi	`ACCESS_WIFI_STATE`	`android.hardware.wifi`
	`CHANGE_WIFI_STATE`	`android.hardware.wifi`
	`CHANGE_WIFI_MULTICAST_STATE`	`android.hardware.wifi`