<uses-feature>

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

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 cualquier entidad externa sobre el conjunto de funciones de hardware y software de las que depende tu aplicación. 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 función, pero 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 las variaciones 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 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 requiere las funciones de Bluetooth y cámara en el dispositivo declara 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, siempre debes declarar elementos <uses-feature> para todas las funciones que requiere tu aplicación.

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) y 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 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 usada (declarada con glEsVersion). Otras funciones que existen o no en un dispositivo, como una 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 uno superior, incluye estos elementos para todas las aplicaciones, incluso si la minSdkVersion es 3 o una anterior. Los dispositivos que ejecutan versiones anteriores de la plataforma ignoran el elemento.

Nota: Cuando declares una función, recuerda que también debes solicitar los permisos necesarios. Por ejemplo, debes solicitar el permiso CAMERA para que tu aplicación pueda tener acceso a la API de la 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

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

• La declaración de android:required="true" para una función indica que la aplicación no puede funcionar, o no está diseñada para funcionar, cuando el dispositivo no cuenta con la función especificada.
• La declaración de android:required="false" para una función indica que la aplicación usa 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.

El valor predeterminado para android:required es "true".

android:glEsVersion

Es la 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, establece el valor en "0x00020000"; si quieres especificar OpenGL ES 3.2, establece el valor en "0x00030002".

Como máximo, una aplicación especifica un atributo android:glEsVersion en su manifiesto. 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, para una aplicación que requiera OpenGL ES 1.0 y OpenGL ES 2.0, especifica que requiere OpenGL ES 2.0.

Para una aplicación que puede funcionar con varias versiones de OpenGL ES, solo especifica 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:

• PackageManager
• FeatureInfo
• ConfigurationInfo
• <uses-permission>
• Filtros en Google Play

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 su dispositivo. 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, como se declara en los elementos <uses-feature> del manifiesto de la aplicación
• Funciones disponibles en el dispositivo, tanto de hardware como de software, según lo informado mediante las propiedades del sistema de solo lectura

Para comparar de forma precisa 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, en 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>. Luego de 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 para 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. En las siguientes secciones, se proporciona más información.

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 uno superior.

Esto te permite especificar si la aplicación requiere la función y no puede funcionar correctamente sin ella ("true"), o si usa la función si está disponible, pero está diseñada para ejecutarse 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, como se muestra en el siguiente ejemplo, Google Play agrega la función a la lista de funciones requeridas por la aplicación. Luego, filtra la aplicación y se la oculta a los usuarios cuyos dispositivos no son compatibles con la función.

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

• Si se declara explícitamente que la función no es necesaria, como se muestra en el siguiente ejemplo, Google Play no agrega la función a la lista de funciones requeridas. En consecuencia, las funciones declaradas explícitamente como no necesarias nunca se tienen en cuenta durante el filtrado de la aplicación. Incluso si el dispositivo no proporciona 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.

  <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, es mejor que cada aplicación siempre declare todas las funciones que usa o requiere, y la ausencia de una declaración para una función utilizada por una aplicación puede 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 hace para funciones declaradas 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), para la que el elemento <uses-feature> no está disponible.
• El desarrollador supone de forma incorrecta que la función está presente en todos los dispositivos y que no es necesaria una declaración.
• El desarrollador omite de forma accidental la declaración de la función.
• El desarrollador declara explícitamente la función, pero la declaración no es 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 la cadena del atributo android:name.

Para responder a estos casos, 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 posterior.

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 filtra tu aplicación. En la sección Permisos que implican requisitos de funciones, se enumera el conjunto completo de permisos que implican requisitos de funciones y, por lo tanto, activan el filtrado.

Tratamiento especial para la función Bluetooth

Cuando se trata del filtrado por Bluetooth, Google Play usa reglas un tanto diferentes de las descritas en el ejemplo anterior.

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 las versiones de la plataforma Android para las que está diseñada la aplicación, según el elemento <uses-sdk>.

Como se muestra en la siguiente tabla, Google Play habilita el filtrado por la función Bluetooth solo si la aplicación declara que la plataforma de segmentación, 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>.

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, 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>

Prueba las funciones que requiere tu aplicación

Puedes usar la herramienta aapt2, 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 aapt2 con el comando dump badging. aapt2 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:

1. Compila y exporta tu aplicación como un APK sin firmar. Si desarrollas en Android Studio, usa Gradle para compilar tu aplicación, como se indica a continuació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 el APK sin firmar en el directorio <ProjectName>/app/build/outputs/apk/.
2. Busca la herramienta aapt2, si aún no está en tu ruta de acceso. Si usas SDK Tools r8 o versiones posteriores, aapt2 se encuentra en el directorio <SDK>/build-tools/<tools version number>.

   Nota: Debes usar la versión de aapt2 que se proporciona para el componente de herramientas de compilación más reciente disponible. Si no lo tienes, descárgalo con Android SDK Manager.

3. Ejecuta aapt2 con esta sintaxis:

$ aapt2 dump badging <path_to_exported_.apk>

Este es un ejemplo del resultado del comando correspondiente al segundo ejemplo de Bluetooth que se mostró antes:

$ ./aapt2 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 una cámara trasera (orientada al mundo) o una frontal (orientada al usuario), respectivamente.

El permiso CAMERA implica que tu app también usa android.hardware.camera. Una cámara posterior 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. Para garantizar un filtrado adecuado en Google Play cuando el manifiesto de tu app incluye el permiso CAMERA, especifica de forma explícita que tu app usa la función camera y, luego, indica si es necesaria para ciertas situaciones. Por 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.

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

Precaución: Si tu app usa android.hardware.camera.front, pero no declara explícitamente android.hardware.camera con android.required="false", Google Play filtrará los dispositivos que no tienen una cámara trasera (como las Chromebooks). Si tu app solo admite dispositivos con 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.

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

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. Para 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 y, luego, indica si es necesaria. Por 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.

Nota: Consulta Cómo distribuir apps para vehículos para obtener más información sobre el uso de esta función y orientación para compilar apps para vehículos.

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: la app se muestra en una pantalla grande, con el usuario sentado lejos, y la forma de entrada predominante es un pad direccional (o un elemento similar), en lugar de un mouse, un puntero o 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.

android.hardware.type.pc

La app está diseñada para mostrar su IU en Chromebooks. Esta función inhabilita la emulación de entrada para el mouse y el panel táctil, ya que las Chromebooks usan el hardware del mouse y el panel táctil. Consulta Entrada del mouse.

Nota: Configura required="false" para este elemento. De lo contrario, Google Play Store hará que tu app no esté disponible para dispositivos que no sean Chromebooks.

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 podría 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 podría 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 cuando deba 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 podría 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 podría informar tendencias en la frecuencia cardíaca del usuario en un período.

android.hardware.sensor.heartrate.ecg

La app usa el sensor de frecuencia cardíaca ECG (electrocardiograma) del dispositivo. Por ejemplo, una app de fitness podría brindar información más detallada sobre la frecuencia cardíaca del usuario.

android.hardware.sensor.light

La app usa el sensor de luz del dispositivo. Por ejemplo, una app podría mostrar uno de dos esquemas de colores según las condiciones lumínicas del ambiente.

android.hardware.sensor.proximity

La app usa el sensor de proximidad del dispositivo. Por ejemplo, una app telefónica podría 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 podría usar la humedad para calcular e informar el punto de rocío actual.

android.hardware.sensor.stepcounter

La app usa el contador de pasos del dispositivo. Por ejemplo, una app de fitness podría informar la cantidad de pasos que necesita dar un usuario para alcanzar su objetivo diario de recuento de pasos.

android.hardware.sensor.stepdetector

La app usa el detector de pasos del dispositivo. Por ejemplo, una app de fitness podría 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" />

Se supone que ambas orientaciones no son obligatorias de forma predeterminada, de modo que tu app puede instalarse en dispositivos que admiten una orientación o ambas. 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, usa 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 app 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 app es compatible con un dispositivo solamente si este tiene una pantalla "táctil falsa" emulada o si tiene una pantalla táctil real.

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 "señalar y hacer clic" y no funciona con un control de pad direccional, declara 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.

De forma predeterminada, las apps requieren la función android.hardware.faketouch. 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, como se muestra en el siguiente ejemplo, también funcionan 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.

De forma predeterminada, todas las apps requieren esta función y, por lo tanto, no están disponibles para los dispositivos que proporcionan solo una interfaz "táctil falsa" emulada. Puedes hacer que tu app esté disponible en dispositivos que proporcionen una interfaz táctil falsa o, incluso, en dispositivos que proporcionen solo un control de pad direccional; para ello, declara explícitamente que no se requiere una pantalla táctil mediante android.hardware.touchscreen con android:required="false". Agrega esta declaración si tu app usa, pero no requiere, una interfaz de pantalla táctil real. Todas las apps que no requieren explícitamente android.hardware.touchscreen también funcionan en dispositivos con android.hardware.faketouch.

Si tu app realmente necesita una interfaz táctil (por ejemplo, para realizar gestos táctiles más avanzados, como deslizamientos), 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, declara 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 de pellizco, 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 un 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 app, 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, declara la siguiente función:

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

Para obtener más detalles sobre la versión de la 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, declara la siguiente función:

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

Para obtener más información sobre la versión de la 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, declara la siguiente función:

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

Para obtener más detalles sobre la versión de la 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 app 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 o proporciona widgets de app y está destinada solo a dispositivos que incluyen una pantalla principal o una ubicación similar donde los usuarios pueden 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 están disponibles para las aplicaciones después de la API correspondiente. En consecuencia, algunas apps podrían usar la API antes de poder declarar que necesitan 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>.

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 de manera explícita 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.