Skip to content

Most visited

Recently visited

navigation

<uses-feature>

sintaxis:
<uses-feature
  android:name="string"
  android:required=["true" | "false"]
  android:glEsVersion="integer" />
contenido en:
<manifest>
descripción:
Declara una sola función de hardware o software usada por 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> juega 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, que se facilitan 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" />
<uses-feature android:name="android.hardware.camera" />

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 controla, por sí solo, 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, es posible que exista 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 existan 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, se recomienda incluir estos elementos para todas las aplicaciones, incluso si minSdkVersion es “3” o anterior. Los dispositivos con versiones anteriores de la plataforma simplemente ignorarán el elemento.

Nota: Cuando declares una función, recuerda que también debes solicitar permisos, según sea necesario. Por ejemplo, no debes dejar de solicitar el permiso CAMERA para que tu aplicación pueda tener acceso a la Camera API. La solicitud del permiso permite que tu aplicación tenga acceso al hardware y 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 string 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, el valor debe ser “0x00020000”; si la versión es 3.2, el valor debe ser “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á al resto.

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

Si una plataforma admite una determinada versión de OpenGL ES, la aplicación considera que admite todas las versiones de OpenGL ES de menor numeración. Por lo tanto, una aplicación que requiere OpenGL ES 1.0 y OpenGL ES 2.0 debe especificar que requiere OpenGL ES 2.0.

Una aplicación que puede funcionar con varias versiones de OpenGL ES solo debe 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 admitida durante el tiempo de ejecución, consulta la guía de la API OpenGL ES.

presentado en:
Nivel de API 4
consulta también:

Google Play y filtrado por funciones

Google Play filtra las aplicaciones que los usuarios pueden ver para que solo puedan ver y descargar 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:

Para garantizar una comparación precisa de las funciones, el Administrador de paquetes de Android comparte un conjunto 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. La aplicación Store luego le pasa a Google Play la lista de las funciones cuando se establece la sesión del usuario.

Cada vez que cargas una aplicación en la Google Play Developer 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 permite al usuario ver la aplicación y descargarla si así lo desea. Si el dispositivo no admite alguna de las funciones requeridas, Google Play filtra la aplicación a fin de que el usuario no la pueda ver y no esté disponible para la descarga.

Debido a que las funciones que declaras en los elementos <uses-feature> influyen directamente en la manera 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 secciones siguientes.

Filtrado basado en 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:

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: Declarando explícitamente una función e incluyendo un atributo android:required="false", puedes inhabilitar de manera eficaz todos los filtros en Google Play para la función especificada.

Filtrado basado en funciones implícitas

Una función implícita es una función 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 como 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:

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, pero no declara un elemento <uses-feature> para android.hardware.camera, Google Play considera que la aplicación requiere una cámara y no se le mostrará a los usuarios cuyos dispositivos no tengan cámara.

Si no quieres que Google Play aplique filtrado conforme a una determinada función implícita, puedes inhabilitar el comportamiento. Para hacerlo, declara la función explícitamente en un elemento <uses-feature> e incluye un atributo android:required="false". Por ejemplo, para inhabilitar el filtro a partir del permiso de CAMERA, debes declarar la función como se muestra a continuación.

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

Es importante saber que 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 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ónandroid.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 de la función Bluetooth por parte de Google Play.

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 un nivel de API 5 como nivel de destino.
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 trabajen 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 Android SDK, 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:

  1. Primero, desarrolla y exporta tu aplicación como un .apk sin firmar. Si realizas el desarrollo en Android Studio, usa Gradle para crear tu aplicación:
    1. Abre el proyecto y selecciona Run > Edit Configurations.
    2. Selecciona el signo más cercano a 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 seleccionar la configuración de ejecución Unsigned APK 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/.
  2. A continuación, busca la herramienta aapt si todavía no está en tu ruta de acceso. Si usas SDK Tools r8, o versiones superiores, aapt se encuentra en el directorio <SDK>/platform-tools/.

    Nota: Debes usar la versión de aapt que se proporciona para el último componente Platform-Tools disponible. Si no tienes el último componente Platform-Tools, descárgalo con Android SDK Manager.

  3. 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 app 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 app usa el proceso 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 app 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 app 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 app 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

android.hardware.camera
La app usa la cámara posterior del dispositivo. Los dispositivos que solo cuentan con una cámara frontal no indican esta función. Por lo tanto, usa la función android.hardware.camera.any en su lugar si tu app puede comunicarse con cualquier cámara independientemente de la dirección a la que apunte.
android.hardware.camera.any
La app usa una de las cámaras del dispositivo o una cámara externa que el usuario conecta a este. Usa este valor en lugar de android.hardware.camera si tu app no requiere que la cámara sea la posterior.
android.hardware.camera.autofocus

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

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

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 permite a tu app 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 permite 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 puede guardar archivos DNG (sin procesar) y que la cámara del dispositivo proporciona los metadatos relacionados con DNG necesarios para que tu app procese directamente estas imágenes sin procesar.

android.hardware.camera.external
La app se comunica con una cámara externa que el usuario conecta al dispositivo. Sin embargo, esta función no garantiza que la cámara externa esté disponible para la app.
android.hardware.camera.flash

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

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

android.hardware.camera.front

La app usa la cámara frontal del dispositivo.

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

android.hardware.camera.level.full
La app usa la compatibilidad con captura de imágenes de nivel FULL que proporciona, al menos, una de las cámaras del dispositivo. Las cámaras con soporte FULL proporcionan capacidades de modo ráfaga, control marco por marco y control de procesamiento posterior manual.

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 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, puntero o 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, la muñeca). El usuario está muy cerca del dispositivo mientras interactúa con él.

Funciones de hardware para huellas dactilares

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 controlador para juegos desde el dispositivo mismo o desde un control de mando conectado.

Funciones de hardware para capacidades infrarrojas

android.hardware.consumerir
La app 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 usas 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 usas 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

Obsoleto.

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 ESinstalado 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 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 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 direcció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 estado físico puede 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 estado físico puede 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 puede mostrar uno de dos esquemas de colores diferentes 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 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 app usa el contador de pasos del dispositivo. Por ejemplo, una app de estado físico 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 estado físico 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 ejecutarse en una orientación específica mediante el atributo android:screenOrientation, esta declaración implica que tu app requiere dicha 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 compatibilidad con versiones anteriores, 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 usas 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 usas 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 solo 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 control remoto pueden hacer funcionar un cursor en pantalla. Si tu app requiere una interacción básica tipo “señalar 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: De forma predeterminada, las apps requieren la función android.hardware.touchscreen. Si deseas que tu app esté disponible para dispositivos que proporcionen una interfaz táctil falsa, también debes declarar explícitamente que no se requiere una pantalla táctil, como se muestra a continuación:

<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 solo dedo en dispositivos de este tipo mueven un cursor, los deslizamientos de dos dedos provocan eventos táctiles de un solo 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 admitir esta función.

android.hardware.faketouch.multitouch.jazzhand

La app realiza el 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 solo 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 admitir 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 para dispositivos que proporcionen solo una interfaz táctil emulada (“interfaz táctil falsa”) de forma predeterminada. 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, pero no requiere, una interfaz de pantalla táctil real.

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 porque son necesarias de forma predeterminada. Sin embargo, la mejor opción será declarar explícitamente todas las funciones que tu app use.

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 usas 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 usas 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 usas 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 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 Direct en el dispositivo.

Funciones de software

En esta sección, se muestran las funciones de software compatibles con las versiones de plataformas más actuales. 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 a 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. A través del VoIP, la app puede admitir operaciones telefónicas por Internet en tiempo real, como videoconferencias bidireccionales.

Si usas 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 gestió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 Verified Boot del dispositivo, que detecta cambios en la configuración del dispositivo durante una operación de reinicio.

Funciones de software para medios

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 presenta una IU diseñada para mostrarse en una pantalla grande, como la de una televisión.
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 Bluetooth API 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 apps 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 de BLUETOOTH en un elemento <uses-permission>. Para las apps heredadas, Google Play considera que la declaración del permiso significa que la aplicación requiere la función android.hardware.bluetooth subyacente y establece filtros para dicha función. 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 <uses-feature>, incluso cualquier atributo android:required declarado, siempre tienen prioridad sobre las funciones que se ven implícitas en los permisos de la tabla 2. En el caso de cualquiera de estos permisos, puedes inhabilitar los filtros para la función implícita: declara explícitamente la función implícita en un elemento <uses-feature> con un atributo android:required="false". Por ejemplo, para inhabilitar cualquier filtro debido a un permiso de CAMERA, debes agregar esta declaración <uses-feature> en el archivo de manifiesto:

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

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

Categoría Este permiso... ... implica el requisito de esta función
Bluetooth BLUETOOTH android.hardware.bluetooth

Para obtener información, consulta Tratamiento especial para la función Bluetooth.

BLUETOOTH_ADMIN android.hardware.bluetooth
Cámara CAMERA android.hardware.camera y
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.network y
android.hardware.location
ACCESS_FINE_LOCATION android.hardware.location.gps y
android.hardware.location
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
This site uses cookies to store your preferences for site-specific language and display options.

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

* Required Fields

Hooray!

Browse this site in ?

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

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

This class requires API level or higher

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

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

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