<uses-feature>

O Google Play usa os elementos de <uses-feature> declarados no manifesto do aplicativo para filtrá-lo de dispositivos que não cumprem os requisitos de recursos de hardware e software.

A especificação dos recursos obrigatórios do aplicativo permite que o Google Play apresente o aplicativo somente aos usuários com dispositivos que cumprem os requisitos de recursos do aplicativo, em vez de apresentá-lo a todos os usuários.

Para saber informações importantes de como o Google Play usa recursos como base para filtrar, leia Google Play e filtros com base em recurso abaixo.

sintaxe:

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

contido em:

<manifest>

descrição:

Declara um único recurso de hardware ou software usado pelo aplicativo.

O propósito de uma declaração <uses-feature> é informar todas as entidades externas sobre o conjunto de recursos de hardware e software de que depende o aplicativo. O elemento oferece um atributo required que permite especificar se o aplicativo exige e não funciona sem o recurso declarado ou se prefere dispor do recurso, mas pode funcionar sem ele. Como a compatibilidade com recursos pode variar entre dispositivos Android, o elemento <uses-feature> desempenha um papel importante, permitindo que o aplicativo descreva os recursos necessários que variam entre dispositivos.

O conjunto de recursos disponíveis declarado pelo aplicativo corresponde ao conjunto de constantes de recurso disponibilizado pelo PackageManager do Android, que são listadas por conveniência nas seções Referência de recursos, na parte final deste documento.

Você deve especificar cada recurso em um elemento <uses-feature> separado. Portanto, se o aplicativo exigir vários recursos, deverá declarar vários elementos <uses-feature>. Por exemplo, um aplicativo que exige recursos de Bluetooth e câmera no dispositivo deve declarar estes dois elementos:

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

Geralmente, você deve sempre declarar elementos <uses-feature> para todos os recursos obrigatórios do aplicativo.

Elementos <uses-feature> declarados são somente para informação, o que significa que o próprio sistema Android não verifica a compatibilidade do recurso correspondente no dispositivo antes de instalar um aplicativo. No entanto, outros serviços (como Google Play) ou aplicativos podem verificar as declarações <uses-feature> do aplicativo como parte do processamento ou interação dele. Por esse motivo, é muito importante declarar todos os recursos (da lista abaixo) usados pelo aplicativo.

Para alguns recursos, pode existir um atributo específico que permite definir uma versão do recurso, como a versão do OpenGL usada (declarada com glEsVersion). Outros recursos que podem existir ou não para um dispositivo, como uma câmera, são declarados usando o atributo name.

Embora o elemento <uses-feature> seja ativado somente para dispositivos executando a API de nível 4 ou posterior, recomendamos incluir esses elementos para todos os aplicativos, mesmo se minSdkVersion for “3” ou anterior. Os dispositivos executando versões anteriores da plataforma simplesmente ignorarão o elemento.

Observação: ao declarar um recurso, lembre-se de que você também deve solicitar as permissões adequadas. Por exemplo, é necessário solicitar também a permissão CAMERA antes que o aplicativo possa acessar a API da câmera. A solicitação da permissão permite que seu aplicativo acesse o hardware e software adequados, e a declaração dos recursos usados pelo aplicativo garante a compatibilidade de dispositivo correta.

atributos:

android:name

Especifica um único recurso de hardware ou software usado pelo aplicativo, como um string de descritor. Os valores de atributo válidos são listados nas seções Recursos de hardware e Recursos de software. Esses valores de atributo diferenciam minúsculas de maiúsculas.

android:required

Valor booleano que indica se o aplicativo exige o recurso especificado no android:name.

Ao declarar android:required="true" para um recurso, você está especificando que o aplicativo não funcionará ou não foi projetado para funcionar quando o recurso especificado não estiver presente no dispositivo.
Quando você declara android:required="false" para um recurso, isso significa que o aplicativo prefere usar o recurso se presente no dispositivo, mas foi processado para funcionar sem o recurso especificado, se necessário.

Quando android:required não é declarado, o valor padrão é "true".

android:glEsVersion

É a versão do OpenGL ES exigida pelo aplicativo. Os 16 bits mais altos representam o número principal e os 16 bits mais baixos, o número secundário. Por exemplo, para especificar OpenGL ES versão 2.0, defina o valor como “0x00020000” ou, para especificar OpenGL ES 3.2, defina o valor como “0x00030002”.

Um aplicativo deve especificar no máximo um atributo android:glEsVersion no manifesto. Se mais de um atributo for especificado, será usado o android:glEsVersion com o valor numérico mais alto e todos os demais valores serão ignorados.

Se um aplicativo não especificar nenhum atributo android:glEsVersion, supostamente o aplicativo exige somente o OpenGL ES 1.0, compatível com todos os dispositivos que usam Android.

Um aplicativo pode supor que, se uma plataforma for compatível com uma determinada versão do OpenGL ES, também será compatível com todas as versões do OpenGL ES numericamente menores. Portanto, um aplicativo que exige OpenGL ES 1.0 e 2.0 deve especificar que exige OpenGL ES 2.0.

Um aplicativo que pode trabalhar com diversas versões do OpenGL ES deve especificar somente a versão numericamente menor do OpenGL ES necessária. Ele pode verificar em tempo de execução se uma versão superior do OpenGL ES está disponível.

Para mais informações sobre como usar o OpenGL ES, inclusive como verificar a versão do OpenGL ES compatível em tempo de execução, consulte o guia da API do OpenGL ES.

introduzido na:

API de nível 4

veja também:

Google Play e filtros com base em recurso

O Google Play filtra os aplicativos visíveis para os usuários para que eles possam ver e fazer o download somente dos aplicativos compatíveis com os dispositivos. Uma das formas de filtrar aplicativos é por compatibilidade de recursos.

Para determinar a compatibilidade de recursos de um aplicativo com um determinado dispositivo do usuário, o Google Play compara:

recursos obrigatórios do aplicativo — um aplicativo declara recursos nos elementos <uses-feature> no manifesto
com...
recursos disponíveis no dispositivo, em hardware ou software — um dispositivo informa os recursos permitidos como propriedades de sistema somente para leitura.

Para garantir uma comparação precisa de recursos, o Android Package Manager oferece um conjunto de constantes de recursos usados por aplicativos e dispositivos para declarar requisitos e compatibilidade de recursos. As constantes de recursos disponíveis estão listadas nas seções Referência de recursos, na parte inferior deste documento, e na documentação de classe para PackageManager.

Quando o usuário inicializa o Google Play, o aplicativo consulta o Package Manager para ter a lista de recursos disponíveis no dispositivo chamando getSystemAvailableFeatures(). O aplicativo Store passa a lista de recursos ao Google Play ao estabelecer a sessão para o usuário.

Cada vez que você fizer upload de um aplicativo para o Google Play Console, o Google Play analisa o arquivo de manifesto do aplicativo. Ele procura elementos <uses-feature> e, em alguns casos, os avalia juntamente com outros elementos, como elementos <uses-sdk> e <uses-permission>. Depois de estabelecer o conjunto de recursos obrigatórios do aplicativo, ele armazena a lista internamente como metadados associados ao .apk e à versão do aplicativo.

Quando um usuário pesquisa ou navega por aplicativos usando o aplicativo Google Play, o serviço compara os recursos necessários para cada aplicativo com os recursos disponíveis no dispositivo do usuário. Se todos os recursos obrigatórios de um aplicativo estiverem presentes no dispositivo, o Google Play permitirá que o usuário veja esse aplicativo e faça o download dele, se quiser. Se algum recurso obrigatório não for compatível com o dispositivo, o Google Play filtra o aplicativo, impedindo a visualização pelo usuário e o download.

Como os recursos declarados em elementos <uses-feature> afetam diretamente a forma como o Google Play filtra os aplicativos, é importante entender como o Google Play avalia o manifesto do aplicativo e define o conjunto de recursos obrigatórios. As seções a seguir oferecem mais informações.

Filtros com base em recursos declarados explicitamente

Um recurso declarado explicitamente é um que o aplicativo declara em um elemento <uses-feature>. A declaração do recurso poderá incluir um atributo android:required=["true" | "false"] (se você compilar com a API de nível 5 ou posterior), o que permitirá especificar se o aplicativo realmente exige o recurso e não funciona sem ele ("true") ou se o aplicativo prefere usar o recurso, se disponível, mas foi projetado para ser executado sem ele ("false").

O Google Play processa recursos declarados explicitamente da seguinte forma:

Se um recurso for explicitamente declarado como obrigatório, o Google Play adicionará o recurso à lista de recursos obrigatórios do aplicativo. Em seguida, filtrará os aplicativos dos usuários com dispositivos que não fornecem esse recurso. Por exemplo:
```
<uses-feature android:name="android.hardware.camera" android:required="true" />
```
Se um recurso for explicitamente declarado como não obrigatório, o Google Play não adicionará o recurso à lista de recursos obrigatórios. Por esse motivo, um recurso declarado explicitamente como não obrigatório nunca é considerado ao filtrar o aplicativo. Mesmo que o dispositivo não ofereça o recurso declarado, o Google Play considerará o aplicativo compatível com o dispositivo e o mostrará ao usuário, a menos que sejam aplicadas outras regras de filtro. Por exemplo:
```
<uses-feature android:name="android.hardware.camera" android:required="false" />
```
Se um recurso for declarado explicitamente, mas sem um atributo android:required, o Google Play suporá que o recurso é necessário e configurará o filtro por esse recurso.

Geralmente, se o aplicativo for projetado para executar com o Android 1.6 ou versões anteriores, o atributo android:required não estará disponível na API e o Google Play suporá que todas as declarações <uses-feature> são obrigatórias.

Observação: a declaração explicita de um recurso e a inclusão de um atributo android:required="false" permite desativar eficazmente todos os filtros do Google Play para o recurso especificado.

Filtros com base em recursos implícitos

Recurso implícito é um recurso obrigatório do aplicativo para o funcionamento correto, mas que não é declarado em um elemento <uses-feature> no arquivo de manifesto. Se formos rigorosos, todos os aplicativos devem sempre declarar todos os recursos usados ou obrigatórios. Portanto, a ausência de uma declaração para um recurso usado por um aplicativo deve ser considerada um erro. No entanto, como proteção para usuários e desenvolvedores, o Google Play procura recursos implícitos em cada aplicativo e define filtros para esses recursos da mesma forma que para um recurso declarado explicitamente.

Um aplicativo pode exigir um recurso, mas não declará-lo, porque:

o aplicativo foi compilado com uma versão antiga da biblioteca do Android (Android 1.5 ou anterior) e o elemento <uses-feature> não estava disponível;
o desenvolvedor supôs incorretamente que o recurso estaria presente em todos os dispositivos e que, portanto, a declaração era desnecessária;
o desenvolvedor omitiu acidentalmente a declaração do recurso;
o desenvolvedor declarou o recurso explicitamente, mas a declaração era inválida. Por exemplo, um erro ortográfico no nome do <uses-feature> ou um valor de string não reconhecido para o atributo android:name invalidaria a declaração do recurso.

Para considerar os casos acima, o Google Play tenta descobrir os requisitos de recurso implícitos de um aplicativo examinando os outros elementos declarados no arquivo de manifesto, mais especificamente, os elementos <uses-permission>.

Se um aplicativo solicitar permissões relacionadas a hardware, o Google Play suporá que o aplicativo usa os recursos de hardware subjacentes e, portanto, exige esses recursos, mesmo que não correspondam a declarações <uses-feature>. Para essas permissões, o Google Play adiciona os recursos de hardware subjacentes aos metadados armazenados para o aplicativo e define filtros para eles.

Por exemplo: se um aplicativo solicitar a permissão CAMERA, mas não declarar um elemento <uses-feature> para android.hardware.camera, o Google Play considerará que o aplicativo exige uma câmera e não deverá ser mostrado para usuários cujos dispositivos não oferecem câmera.

Se não quiser que o Google Play filtre com base em um recurso implícito específico, você pode desativar esse comportamento. Para fazer isso, declare o recurso explicitamente em um elemento <uses-feature> e inclua um atributo android:required="false". Por exemplo, para desativar o filtro derivado da permissão CAMERA, declare o recurso como mostrado abaixo.

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

É importante compreender que as permissões solicitadas nos elementos <uses-permission> podem afetar diretamente a forma com que o Google Play filtra o aplicativo. A seção de referência Permissões que implicam requisitos de recurso lista o conjunto completo de permissões que sugerem requisitos de recurso e, portanto, acionam os filtros.

Processamento especial para o recurso Bluetooth

Para determinar o filtro para Bluetooth, o Google Play aplica regras ligeiramente diferentes das descritas acima.

Se um aplicativo declarar uma permissão Bluetooth em um elemento <uses-permission>, mas não declarar explicitamente o recurso Bluetooth em um elemento <uses-feature>, o Google Play verificará as versões da plataforma Android em que o aplicativo foi projetado para executar, conforme especificado no elemento <uses-sdk>.

Conforme mostrado na tabela abaixo, o Google Play permite o filtro do recurso Bluetooth somente se o aplicativo declarar sua plataforma mais baixa ou direcionada como Android 2.0 (API de nível 5) ou posterior. Observe, no entanto, que o Google Play aplica as regras normais de filtro quando o aplicativo declara explicitamente o recurso Bluetooth em um elemento <uses-feature>.

Tabela 1. Como o Google Play determina o requisito de recurso Bluetooth para um aplicativo que seleciona uma permissão Bluetooth, mas não declara o recurso Bluetooth em um elemento <uses-feature>.

Se `minSdkVersion` for...	ou `targetSdkVersion` for	Resultado
<=4 (ou uses-sdk não for declarado)	<=4	O Google Play não filtrará o aplicativo de nenhum dispositivo com base nas permissões informadas para o recurso `android.hardware.bluetooth`.
<=4	>=5	O Google Play filtrará o aplicativo de todos os dispositivos que não permitam o recurso `android.hardware.bluetooth` (inclusive versões anteriores).
>=5	>=5

Os exemplos abaixo mostram os diferentes efeitos de filtros com base na forma como o Google Play processa o recurso Bluetooth.

No primeiro exemplo, um aplicativo projetado para executar em APIs de níveis anteriores declara uma permissão Bluetooth, mas não declara o recurso Bluetooth em um elemento <uses-feature>.: Resultado: o Google Play não filtra o aplicativo de nenhum dispositivo.

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

No segundo exemplo, abaixo, o mesmo aplicativo também declara uma API com nível direcionado de “5”.: Resultado: o Google Play agora supõe que o recurso seja obrigatório e filtra o aplicativo de todos os dispositivos que não informam compatibilidade com Bluetooth, inclusive dispositivos que executam versões anteriores da plataforma.

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

Aqui, o mesmo aplicativo declara especificamente o recurso Bluetooth.: Resultado: idêntico ao exemplo anterior (o filtro é aplicado).

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

Finalmente, no caso a seguir, o mesmo aplicativo adiciona um atributo android:required="false".: Resultado: o Google Play desativa o filtro com base na compatibilidade do recurso Bluetooth para todos os 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>

Testar os recursos obrigatórios do aplicativo

Você também pode usar a ferramenta aapt, incluída no Android SDK, para determinar como o Google Play filtrará o aplicativo, com base nas permissões e nos recursos declarados. Para isso, execute aapt com o comando dump badging. Isso faz com que aapt analise o manifesto do aplicativo e aplique as mesmas regras usadas pelo Google Play para determinar os recursos exigidos pelo aplicativo.

Para usar a ferramenta, siga estas etapas:

Primeiro, compile e exporte o aplicativo como um .apk não assinado. Se você estiver desenvolvendo no Android Studio, compile o aplicativo com o Gradle:
1. Abra o projeto e selecione Run > Edit Configurations.
2. Selecione o sinal de mais ao lado do canto superior esquerdo da janela Run/Debug Configurations.
3. Selecione Gradle.
4. Insira Unsigned APK em Name.
5. Escolha o módulo na seção Gradle project.
6. Insira assemble em Tasks.
7. Selecione OK para concluir a nova configuração.
8. Verifique se a configuração de execução Unsigned APK está selecionada na barra de ferramentas e selecione Run > Run 'Unsigned APK'.
Você pode encontrar o .apk não assinado no diretório <ProjectName>/app/build/outputs/apk/.
Em seguida, localize a ferramenta aapt, se não estiver no seu PATH. Se você estiver usando o SDK Tools r8 ou superior, poderá encontrar aapt no diretório <SDK>/build-tools/<tools version number>.
Observação: você deve usar a versão do aapt fornecida para o mais recente componente Build-Tools disponível. Se você não tiver o componente Build-Tools, faça o download usando o Android SDK Manager.
Execute aapt usando esta sintaxe:

$ aapt dump badging <path_to_exported_.apk>

Veja a seguir um exemplo da saída do comando para o segundo exemplo de Bluetooth acima:

$ ./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'

Referência de recursos

As seções a seguir oferecem informações de referência sobre recursos de hardware, recursos de software e conjuntos de permissões que implicam requisitos específicos de recurso.

Recursos de hardware

Esta seção apresenta os recursos de hardware permitidos pela versão de plataforma mais atual. Para indicar que o aplicativo usa ou exige um recurso de hardware, declare o valor correspondente (começando com "android.hardware") em um atributo android:name. Sempre que você declarar um recurso de hardware, use um elemento <uses-feature> separado.

Recursos de hardware de áudio

android.hardware.audio.low_latency: O aplicativo usa o canal de áudio de baixa latência do dispositivo, que reduz demoras e atrasos no processamento de entrada ou saída de som.
android.hardware.audio.output: O aplicativo transmite som usando os alto-falantes, a entrada para fone de ouvido, os recursos de streaming do Bluetooth ou mecanismos semelhantes do dispositivo.
android.hardware.audio.pro: O aplicativo usa a funcionalidade de áudio e os recursos de desempenho avançados do dispositivo.
android.hardware.microphone: O aplicativo grava áudio usando o microfone do dispositivo.

Recursos de hardware do Bluetooth

android.hardware.bluetooth: O aplicativo usa os recursos de Bluetooth do dispositivo. Normalmente, para comunicação com outros dispositivos com Bluetooth ativado.
android.hardware.bluetooth_le: O aplicativo usa os recursos de rádio Low Energy do Bluetooth do dispositivo.

Recursos de hardware da câmera

android.hardware.camera

O aplicativo usa a câmera traseira do dispositivo. Os dispositivos com somente uma câmera frontal não listam esse recurso. Portanto, em vez disso, use o recurso android.hardware.camera.any se o aplicativo puder se comunicar com qualquer câmera, independentemente de sua direção.

android.hardware.camera.any

O aplicativo usa uma das câmeras do dispositivo ou uma câmera externa conectada ao dispositivo pelo usuário. Use esse valor em vez de android.hardware.camera se o aplicativo não exigir que a câmera seja a traseira.

android.hardware.camera.autofocus

O aplicativo usa o recurso de foco automático permitido pela câmera do dispositivo.

Ao usar este recurso, um aplicativo implica que também usa o recurso android.hardware.camera, a menos que este recurso pai seja declarado com android:required="false".

android.hardware.camera.capability.manual_post_processing

O aplicativo usa o recurso MANUAL_POST_PROCESSING permitido pela câmera do dispositivo.

O recurso permite que o aplicativo modifique a funcionalidade de balanço automático de branco da câmera. Use android.colorCorrection.transform, android.colorCorrection.gains e um android.colorCorrection.mode de TRANSFORM_MATRIX.

android.hardware.camera.capability.manual_sensor

O aplicativo usa o recurso MANUAL_SENSOR permitido pela câmera do dispositivo.

Esse recurso implica compatibilidade com bloqueio de exposição automática (android.control.aeLock), que permite que o tempo e a sensitividade de exposição da câmera fiquem fixos em valores específicos.

android.hardware.camera.capability.raw

O aplicativo usa o recurso RAW permitido pela câmera do dispositivo.

Este recurso implica que o dispositivo pode salvar arquivos DNG (brutos) e que a câmera do dispositivo informa os metadados relacionados a DNG necessários para que o aplicativo processe diretamente essas imagens brutas.

android.hardware.camera.external

O aplicativo se comunica com uma câmera externa que o usuário conecta ao dispositivo. Esse recurso não garante, no entanto, que a câmera externa esteja disponível para o aplicativo usar.

android.hardware.camera.flash

O aplicativo usa o recurso de flash permitido pela câmera do dispositivo.

Ao usar este recurso, um aplicativo implica que também usa o recurso android.hardware.camera, a menos que este recurso pai seja declarado com android:required="false".

android.hardware.camera.front

O aplicativo usa a câmera frontal do dispositivo.

Ao usar este recurso, um aplicativo implica que também usa o recurso android.hardware.camera, a menos que este recurso pai seja declarado com android:required="false".

android.hardware.camera.level.full

O aplicativo usa a compatibilidade com captura de imagens no nível FULL fornecida por pelo menos uma das câmeras do dispositivo. As câmeras compatíveis com FULL oferecem recursos de captura em rajada, controle por frame e controle de pós-processamento manual.

Recursos de hardware da IU do dispositivo

android.hardware.type.automotive

O aplicativo foi projetado para mostrar sua IU em um conjunto de telas dentro de um veículo. O usuário interage com o aplicativo usando botões físicos, toque, controles giratórios e interfaces semelhantes ao mouse. Normalmente, as telas do veículo aparecem no console central ou no cluster de instrumentos de um veículo. Essas telas normalmente têm tamanho e resolução limitados.

Observação: é importante lembrar que, como o usuário está dirigindo enquanto usa esse tipo de IU de aplicativo, este deve minimizar as distrações do motorista.

android.hardware.type.television

Obsoleto. Em vez disso, use android.software.leanback.

O aplicativo foi projetado para mostrar a IU em uma televisão. Esse recurso define “televisão” como uma experiência típica de televisão na sala de estar: exibida em uma tela grande, com o usuário sentado distante, e o formato predominante de entrada é algo como um botão direcional e geralmente sem dispositivos como mouse, ponteiro e telas táteis.

android.hardware.type.watch

O aplicativo foi projetado para mostrar a IU em um relógio de pulso. O relógio é usado no corpo, como no pulso. O usuário fica muito próximo ao dispositivo durante a interação.

Recursos de hardware de impressão digital

android.hardware.fingerprint: O aplicativo lê impressões digitais usando o hardware biométrico do dispositivo.

Recursos de hardware de gamepad

android.hardware.gamepad: O aplicativo captura a entrada do controlador de jogos do próprio dispositivo ou de um gamepad conectado.

Recursos de hardware de infravermelho

android.hardware.consumerir: O aplicativo usa os recursos de infravermelho (IR, na sigla em inglês) do dispositivo, normalmente para comunicação com outros dispositivos IR do consumidor.

Recursos de hardware de localização

android.hardware.location

O aplicativo usa um ou mais recursos do dispositivo para determinar a localização, como localização GPS, localização da rede ou localização celular.

android.hardware.location.gps

O aplicativo usa coordenadas de localização precisa vindas de um receptor do Sistema de Posicionamento Global (GPS) do dispositivo.

Ao usar este recurso, um aplicativo implica que também usa o recurso android.hardware.location, a menos que este recurso pai seja declarado com o atributo android:required="false".

android.hardware.location.network

O aplicativo usa coordenadas de localização aproximada vindas de um sistema de geolocalização com base em rede compatível com o dispositivo.

Ao usar este recurso, um aplicativo implica que também usa o recurso android.hardware.location, a menos que este recurso pai seja declarado com o atributo android:required="false".

Recursos de hardware de NFC

android.hardware.nfc: O aplicativo usa recursos de rádio de Near-Field Communication (NFC) do dispositivo.
android.hardware.nfc.hce: O aplicativo usa emulação de cartão NFC hospedada no dispositivo.

Recursos de hardware de OpenGL ES

android.hardware.opengles.aep: O aplicativo usa o OpenGL ES Android Extension Packinstalado no dispositivo.

Recursos de hardware de sensor

android.hardware.sensor.accelerometer: O aplicativo usa leituras de movimento do acelerômetro do dispositivo para detectar a orientação atual do dispositivo. Por exemplo, um aplicativo pode usar leituras do acelerômetro para determinar quando alternar a orientação entre retrato e paisagem.
android.hardware.sensor.ambient_temperature: O aplicativo usa o sensor de temperatura ambiente (ambiental) do dispositivo. Por exemplo, um aplicativo meteorológico pode informar temperaturas internas ou externas.
android.hardware.sensor.barometer: O aplicativo usa o barômetro do dispositivo. Por exemplo, um aplicativo meteorológico pode informar a pressão do ar.
android.hardware.sensor.compass: O aplicativo usa o magnetômetro (bússola) do dispositivo. Por exemplo, um aplicativo de navegação pode mostrar a direção para onde o usuário está voltado no momento.
android.hardware.sensor.gyroscope: O aplicativo usa o giroscópio do dispositivo para detectar a rotação e o giro, criando um sistema de orientação em seis eixos. Usando esse sensor, o aplicativo pode detectar mais suavemente se é necessário alternar entre as orientações de retrato e paisagem.
android.hardware.sensor.hifi_sensors: O aplicativo usa os sensores de alta fidelidade (Hi-Fi) do dispositivo. Por exemplo, um aplicativo de jogos pode detectar os movimentos do usuário com alta precisão.
android.hardware.sensor.heartrate: O aplicativo usa o monitor de frequência cardíaca do dispositivo. Por exemplo, um aplicativo de boa forma pode informar tendências na frequência cardíaca do usuário.
android.hardware.sensor.heartrate.ecg: O aplicativo usa o sensor de frequência cardíaca de eletrocardiograma (ECG) do dispositivo. Por exemplo, um aplicativo de boa forma pode fornecer informações mais detalhadas sobre a taxa cardíaca do usuário.
android.hardware.sensor.light: O aplicativo usa o sensor de luz do dispositivo. Por exemplo, o aplicativo pode exibir um dentre dois esquemas de cores com base nas condições de iluminação ambiente.
android.hardware.sensor.proximity: O aplicativo usa o sensor de proximidade do dispositivo. Por exemplo, um aplicativo de telefonia pode desligar a tela do dispositivo quando detectar que o usuário está mantendo o dispositivo próximo ao corpo.
android.hardware.sensor.relative_humidity: O aplicativo usa o sensor de umidade relativa do dispositivo. Por exemplo, um aplicativo meteorológico pode usar a umidade para calcular e informar o ponto de orvalho atual.
android.hardware.sensor.stepcounter: O aplicativo usa o contador de passos do dispositivo. Por exemplo, um aplicativo de boa forma pode informar o número de passos que um usuário deve dar para alcançar a meta diária de número de passos.
android.hardware.sensor.stepdetector: O aplicativo usa o detector de passos do dispositivo. Por exemplo, um aplicativo de boa forma pode usar o intervalo de tempo entre passos para deduzir o tipo de exercício que o usuário está fazendo.

Recursos de hardware de tela

android.hardware.screen.landscape

android.hardware.screen.portrait

O aplicativo exige que o dispositivo use a orientação de retrato ou paisagem. Se o aplicativo permitir ambas as orientações, você não precisa declarar nenhum dos recursos.

Por exemplo, se o aplicativo exige orientação de retrato, você deve declarar o recurso a seguir para que somente os dispositivos que permitem orientação de retrato (sempre ou mediante escolha do usuário) possam executar o aplicativo:

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

O padrão é que nenhuma orientação é obrigatória. Portanto, o aplicativo poderá ser instalado em dispositivos que permitem uma ou ambas as orientações. No entanto, se qualquer uma das atividades solicitar a execução em uma orientação específica, usando o atributo android:screenOrientation, essa declaração implicará que o aplicativo exige essa orientação. Por exemplo: se você declarar android:screenOrientation com "landscape", "reverseLandscape" ou "sensorLandscape", o aplicativo estará disponível somente em dispositivos compatíveis com orientação de paisagem.

Como prática recomendada, deve-se usar um elemento <uses-feature> para declarar o requisito para essa orientação. Se você declarar uma orientação para a atividade com android:screenOrientation sem que isso seja necessário, poderá declarar a orientação com um elemento <uses-feature> e incluir android:required="false" para desativar o requisito.

Para compatibilidade com versões anteriores, todos os dispositivos que executam o Android 3.1 (API de nível 12) ou anterior permitem as orientações de paisagem e retrato.

Recursos de hardware de telefonia

android.hardware.telephony

O aplicativo usa os recursos de telefonia do dispositivo, como radiotelefonia, com serviços de comunicação de dados.

android.hardware.telephony.cdma

O aplicativo usa o sistema de radiotelefonia Code Division Multiple Access (CDMA).

Ao usar este recurso, um aplicativo implica que também usa o recurso android.hardware.telephony, a menos que este recurso pai seja declarado com android:required="false".

android.hardware.telephony.gsm

O aplicativo usa o sistema de radiotelefonia do Global System for Mobile Communications (GSM).

Ao usar este recurso, um aplicativo implica que também usa o recurso android.hardware.telephony, a menos que este recurso pai seja declarado com android:required="false".

Recursos de hardware de tela tátil

android.hardware.faketouch

O aplicativo usa eventos de interação por toque básicos, como tocar e arrastar.

Quando declarado como obrigatório, esse recurso indica que o aplicativo será compatível com um dispositivo somente se esse dispositivo emular uma touchscreen (“interface de toque simulada”) ou tiver uma touchscreen real.

Dispositivos que oferecem uma interface de toque simulada fornecem um sistema de entrada que emula um subconjunto dos recursos de uma touchscreen. Por exemplo, um mouse ou controle remoto pode acionar um cursor na tela. Se o aplicativo exigir interação básica do tipo apontar e clicar (em outras palavras, não funciona só com um controlador de botão direcional), declare esse recurso. Como esse é o nível mínimo de interação de toque, você pode usar um aplicativo que declara esse recurso em dispositivos que oferecem interfaces de toque mais complexas.

Observação: os aplicativos exigem o recurso android.hardware.faketouch por padrão. Se você quiser que o aplicativo seja limitado a dispositivos que só tenham uma touchscreen, é necessário declarar explicitamente essa obrigatoriedade da seguinte forma:

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

Todos os aplicativos que não exigem android.hardware.touchscreen explicitamente também funcionarão em dispositivos com android.hardware.faketouch.

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

android.hardware.faketouch.multitouch.distinct

O aplicativo rastreia dois ou mais “dedos” distintos em uma interface de toque simulada. Esse recurso é um superconjunto do recurso android.hardware.faketouch. Quando declarado como obrigatório, esse recurso indica que o aplicativo será compatível com um dispositivo somente se esse dispositivo emular o rastreamento distinto de dois ou mais dedos ou tiver uma touchscreen real.

Ao contrário do multitoque distinto definido por android.hardware.touchscreen.multitouch.distinct, os dispositivos de entrada que permitem multitoque distinto com uma interface de toque simulada não são compatíveis com todos os gestos de dois dedos porque a entrada é transformada em movimento de cursor na tela. Ou seja, gestos de um único dedo nesse dispositivo movem um cursor, o deslizar de dois dedos faz com que ocorram eventos de toque de um único dedo e outros gestos de dois dedos acionam os eventos correspondentes de toque de dois dedos.

Um dispositivo que fornece um trackpad de toque de dois dedos para movimento de cursor pode permitir esse recurso.

android.hardware.faketouch.multitouch.jazzhand

O aplicativo rastreia cinco ou mais “dedos” distintos em uma interface de toque simulada. Esse recurso é um superconjunto do recurso android.hardware.faketouch. Quando declarado como obrigatório, esse recurso indica que o aplicativo será compatível com um dispositivo somente se esse dispositivo emular o rastreamento distinto de cinco ou mais dedos ou tiver uma touchscreen real.

Ao contrário do multitoque distinto definido por android.hardware.touchscreen.multitouch.jazzhand, os dispositivos de entrada que permitem multitoque “jazzhand” com uma interface de toque simulada não são compatíveis com todos os gestos de cinco dedos porque a entrada é transformada em movimento de cursor na tela. Ou seja, gestos de um único dedo nesse dispositivo movem um cursor, o deslizar de vários dedos faz com que ocorram eventos de toque de um único dedo e outros gestos de vários dedos acionam os eventos correspondentes de toque de vários dedos.

Dispositivos que fornecem um trackpad de toque de cinco dedos para movimento de cursor podem permitir esse recurso.

android.hardware.touchscreen

O aplicativo usa os recursos de tela tátil do dispositivo para gestos mais interativos que os eventos de toque básicos, como uma navegação. Esse recurso é um superconjunto do recurso android.hardware.faketouch.

Por padrão, o aplicativo exige esse recurso. Portanto, o aplicativo não está disponível para dispositivos que fornecem somente uma interface de toque simulada por padrão. Se quiser que o aplicativo esteja disponível em dispositivos que oferecem uma interface de toque simulada (ou até mesmo em dispositivos que fornecem só um controlador de botão direcional), você deve declarar explicitamente que a touchscreen não é obrigatória, declarando android.hardware.touchscreen com android:required="false". Essa declaração deverá ser adicionada se o aplicativo usar, mas não exigir, uma interface de touchscreen real. Todos os aplicativos que não exigem android.hardware.touchscreen explicitamente também funcionarão em dispositivos com android.hardware.faketouch.

Se o aplicativo realmente exigir uma interface tátil (para executar gestos de toque mais avançados, como navegar), você não precisará declarar nenhum recurso de interface de toque porque eles são obrigatórios por padrão. No entanto, é melhor se você declarar explicitamente todos os recursos usados pelo aplicativo.

Se você exigir uma interação de toques mais complexa, como gestos de vários dedos, precisará declarar que o aplicativo usa recursos avançados de touchscreen.

android.hardware.touchscreen.multitouch

O aplicativo usa os recursos básicos de multitoque de dois pontos do dispositivo, como os gestos de pinça, mas o aplicativo não precisa rastrear os toques de forma independente. Esse recurso é um superconjunto do recurso android.hardware.touchscreen.

Ao usar este recurso, um aplicativo implica que também usa o recurso android.hardware.touchscreen, a menos que este recurso pai seja declarado com android:required="false".

android.hardware.touchscreen.multitouch.distinct

O aplicativo usa os recursos avançados de multitoque do dispositivo para rastrear dois ou mais pontos de forma independente. Esse recurso é um superconjunto do recurso android.hardware.touchscreen.multitouch.

Ao usar este recurso, um aplicativo implica que também usa o recurso android.hardware.touchscreen.multitouch, a menos que este recurso pai seja declarado com android:required="false".

android.hardware.touchscreen.multitouch.jazzhand

O aplicativo usa os recursos avançados de multitoque do dispositivo para rastrear cinco ou mais pontos de forma independente. Esse recurso é um superconjunto do recurso android.hardware.touchscreen.multitouch.

Ao usar este recurso, um aplicativo implica que também usa o recurso android.hardware.touchscreen.multitouch, a menos que este recurso pai seja declarado com android:required="false".

Recursos de hardware USB

android.hardware.usb.accessory: O aplicativo se comporta como dispositivo USB e se conecta a hosts USB.
android.hardware.usb.host: O aplicativo usa acessórios USB conectados ao dispositivo. O dispositivo atua como host USB.

Recursos de hardware Vulkan

android.hardware.vulkan.compute

O aplicativo usa recursos computacionais Vulkan. Esse recurso indica que o aplicativo exige o hardware de implementação Vulkan acelerado. A versão do recurso indica qual nível de recurso de computação opcional o aplicativo exige além dos requisitos do Vulkan 1.0. Por exemplo, se o aplicativo exigir suporte computacional Vulkan de nível 0, declare o recurso a seguir:

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

Consulte


    FEATURE_VULKAN_HARDWARE_COMPUTE

para mais detalhes sobre a versão do recurso.

android.hardware.vulkan.level

O aplicativo usa recursos de nível Vulkan. Esse recurso indica que o aplicativo exige o hardware de implementação Vulkan acelerado. A versão do recurso indica qual nível de recurso de hardware opcional é exigido pelo aplicativo. Por exemplo, se o aplicativo exigir suporte de hardware Vulkan de nível 0, declare o recurso a seguir:

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

Consulte


    FEATURE_VULKAN_HARDWARE_LEVEL

para mais detalhes sobre a versão do recurso.

android.hardware.vulkan.version

O aplicativo usa o Vulkan. Esse recurso indica que o aplicativo exige o hardware de implementação Vulkan acelerado. A versão do recurso indica a versão mínima do suporte da API Vulkan exigida pelo aplicativo. Por exemplo, se o aplicativo exigir Vulkan de nível 1.0, declare o recurso a seguir:

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

Consulte


    FEATURE_VULKAN_HARDWARE_VERSION

para mais detalhes sobre a versão do recurso.

Recursos de hardware Wi-Fi

android.hardware.wifi: O aplicativo usa recursos de redes 802.11 (Wi-Fi) do dispositivo.
android.hardware.wifi.direct: O aplicativo usa os recursos de rede Wi-Fi Direct do dispositivo.

Recursos de software

Esta seção apresenta os recursos de software permitidos pela versão de plataforma mais atual. Para indicar que o aplicativo usa ou exige um recurso de software, declare o valor correspondente (começando com "android.software") em um atributo android:name. Sempre que você declarar um recurso de software, use um elemento <uses-feature> separado.

Recursos de software de comunicação

android.software.sip

O aplicativo usa serviços de Session Initiation Protocol (SIP). O uso de SIP permite que o aplicativo seja compatível com operações de telefonia na internet, como videoconferências e mensagens instantâneas.

android.software.sip.voip

O aplicativo usa serviços de Voice Over Internet Protocol (VoIP) com base no SIP. O uso de VoIP permite que o aplicativo seja compatível com operações de telefonia na internet em tempo real, como videoconferência bidirecional.

Ao usar este recurso, um aplicativo implica que também usa o recurso android.software.sip, a menos que este recurso pai seja declarado com android:required="false".

android.software.webview

O aplicativo exibe conteúdo da internet.

Recursos de software de entrada personalizada

android.software.input_methods: O aplicativo usa um novo método de entrada, definido pelo desenvolvedor em um InputMethodService.

Recursos de software de gerenciamento de dispositivos

android.software.backup: O aplicativo inclui lógica para processar uma operação de backup e restauração.
android.software.device_admin: O aplicativo usa administradores do dispositivo para aplicar uma política do dispositivo.
android.software.managed_users: O aplicativo é compatível com usuários secundários e perfis gerenciados.
android.software.securely_removes_users: O aplicativo pode remover permanentemente usuários e dados associados a eles.
android.software.verified_boot: O aplicativo inclui lógica para processar resultados do recurso de inicialização verificada do dispositivo, que detecta se a configuração do dispositivo muda durante uma operação de reinício.

Recursos de software de mídia

android.software.midi: O aplicativo se conecta a instrumentos musicais ou gera sons usando o protocolo Musical Instrument Digital Interface (MIDI).
android.software.print: O aplicativo inclui comandos para imprimir documentos exibidos no dispositivo.
android.software.leanback: O aplicativo é projetado para execução em dispositivos Android TV.
android.software.live_tv: O aplicativo faz streaming de programas de televisão ao vivo.

Recursos de software de interface de tela

android.software.app_widgets: O aplicativo usa ou fornece widgets de aplicativo e deve ser instalado somente em dispositivos que incluem uma tela inicial ou localização similar onde os usuários podem incorporar widgets de aplicativo.
android.software.home_screen: O aplicativo se comporta como uma substituição da tela inicial do dispositivo.
android.software.live_wallpaper: O aplicativo usa ou fornece planos de fundo que incluem animação.

Permissões que implicam requisitos de recursos

Algumas constantes de recurso de hardware e software foram disponibilizadas a aplicativos depois da API correspondente. Por exemplo, o recurso android.hardware.bluetooth foi adicionado no Android 2.2 (API de nível 8), mas a API Bluetooth que ele referencia foi adicionada no Android 2.0 (API de nível 5). Por isso, alguns aplicativos puderam usar a API antes de poder declarar que exigem a API usando o sistema <uses-feature>.

Para evitar que esses aplicativos sejam disponibilizados acidentalmente, o Google Play supõe que algumas permissões relacionadas a hardware indicam que os recursos subjacentes de hardware são obrigatórios por padrão. Por exemplo, aplicativos que usam Bluetooth devem solicitar a permissão BLUETOOTH em um elemento <uses-permission>. Em aplicativos legados, o Google Play supõe que a declaração de permissão significa que o recurso android.hardware.bluetooth subjacente é exigido pelo aplicativo e define o filtro de acordo com esse recurso. A tabela 2 lista as permissões que implicam requisitos de recurso equivalentes às declaradas em elementos <uses-feature>.

As declarações <uses-feature>, incluindo todos os atributos android:required declarados, sempre têm precedência sobre recursos implícitos pelas permissões na tabela 2. Em qualquer uma dessas permissões, você pode desativar o filtro de acordo com o recurso implícito, declarando explicitamente o recurso implícito em um elemento <uses-feature> com um atributo android:required="false". Por exemplo, para desativar todos os filtros com base na permissão CAMERA, adicione esta declaração <uses-feature> ao arquivo de manifesto:

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

Atenção: se seu aplicativo for direcionado ao Android 5.0 (API de nível 21) ou superior e usa a permissão ACCESS_COARSE_LOCATION ou ACCESS_FINE_LOCATION para receber atualizações de locais da rede ou de um GPS, respectivamente, também será necessário declarar explicitamente que o aplicativo usa os recursos de hardware android.hardware.location.network ou android.hardware.location.gps.

Tabela 2. Permissões de dispositivo que implicam o uso de hardware do dispositivo.

Categoria	Esta permissão...	... implica este requisito de recurso.
Bluetooth	`BLUETOOTH`	`android.hardware.bluetooth` Consulte Processamento especial para o recurso Bluetooth para mais detalhes.
Bluetooth	`BLUETOOTH_ADMIN`	`android.hardware.bluetooth`
Câmera	`CAMERA`	`android.hardware.camera` e `android.hardware.camera.autofocus`
Localização	`ACCESS_MOCK_LOCATION`	`android.hardware.location`
	`ACCESS_LOCATION_EXTRA_COMMANDS`	`android.hardware.location`
	`INSTALL_LOCATION_PROVIDER`	`android.hardware.location`
	`ACCESS_COARSE_LOCATION`	`android.hardware.location` `android.hardware.location.network` (Somente quando o nível da API de destino é 20 ou anterior)
	`ACCESS_FINE_LOCATION`	`android.hardware.location` `android.hardware.location.gps` (Somente quando o nível da API de destino é 20 ou anterior)
Microfone	`RECORD_AUDIO`	`android.hardware.microphone`
Telefonia	`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`