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

A especificação dos recursos obrigatórios do aplicativo possibilita que o Google Play apresente o aplicativo somente aos usuários com dispositivos que atendem aos requisitos de recursos, e não 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 possibilita 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 o suporte para 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 declarados 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, no final deste documento.

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

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

Geralmente, você precisa 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 o suporte para o recurso correspondente no dispositivo antes de instalar um aplicativo. No entanto, outros serviços (como o Google Play) ou aplicativos podem verificar as declarações <uses-feature> do aplicativo como parte do processamento ou da interação dele. Por esse motivo, é muito importante declarar todos os recursos (da lista abaixo) usados pelo aplicativo.

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

Embora o elemento <uses-feature> seja ativado apenas para dispositivos executando o nível 4 da API ou versões mais recentes, recomendamos incluir esses elementos para todos os aplicativos, mesmo se minSdkVersion for “3” ou anterior. Os dispositivos que executam versões anteriores da plataforma simplesmente ignoram o elemento.

Observação: ao declarar um recurso, você também precisa 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 concede ao seu aplicativo acesso ao 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 uma string do 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 funciona ou não foi projetado para funcionar quando o recurso especificado não está presente no dispositivo.
• Quando você declara android:required="false" para um recurso, isso significa que o aplicativo prefere usar o recurso se ele estiver presente no dispositivo, mas foi projetado para funcionar sem ele, 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 o OpenGL ES versão 2.0, você precisa definir o valor como “0x00020000”. Para especificar o OpenGL ES 3.2, defina o valor como “0x00030002”.

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

Se um aplicativo não especificar nenhum atributo android:glEsVersion, presume-se que ele exige apenas o OpenGL ES 1.0, com suporte para todos os dispositivos que usam Android.

Um aplicativo pode supor que, se uma plataforma oferece suporte para determinada versão do OpenGL ES, ela também oferece para todas as versões do OpenGL ES numericamente menores. Portanto, um aplicativo que exige o OpenGL ES 1.0 e 2.0 precisa especificar que exige o OpenGL ES 2.0.

Um aplicativo que pode trabalhar com diversas versões do OpenGL ES precisa especificar apenas a versão numericamente menor do OpenGL ES necessária. Ele pode verificar no momento da execução se uma versão mais recente do OpenGL ES está disponível.

Para mais informações sobre como usar o OpenGL ES, inclusive como conferir a versão compatível no momento da execução, consulte o guia da API do OpenGL ES.

introduzido em:

API de nível 4

veja também:

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

Google Play e filtros com base em recurso

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

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

• recursos obrigatórios do aplicativo: um aplicativo declara recursos nos elementos <uses-feature> do 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 dos recursos, o gerenciador de pacotes do Android oferece um conjunto de constantes de recursos usados por aplicativos e dispositivos para declarar requisitos e suporte de recursos. As constantes de recursos disponíveis estão listadas nas seções Referência de recursos, no final deste documento, e na documentação de classe para o PackageManager.

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

Cada vez que você faz 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 em conjunto com outros elementos, como <uses-sdk> e <uses-permission>. Após 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 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 estão presentes no dispositivo, o Google Play permite que o usuário veja esse aplicativo e faça o download dele, se quiser. Se o dispositivo não oferece suporte para algum recurso obrigatório, 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 pode incluir um atributo android:required=["true" | "false"] (se você compilar com nível 5 da API ou versões mais recentes), o que permite especificar se o aplicativo realmente exige o recurso e não funciona sem ele ("true") ou se 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 é explicitamente declarado como obrigatório, o Google Play o adiciona à lista de recursos obrigatórios do aplicativo. Em seguida, filtra 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 é explicitamente declarado como não obrigatório, o Google Play não o adiciona à 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 considera o aplicativo compatível com o dispositivo e o mostra 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 é declarado explicitamente, mas sem um atributo android:required, o Google Play supõe que ele é obrigatório e configura o filtro para esse recurso.

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

Observação: ao declarar um recurso explicitamente e incluir um atributo android:required="false", você pode desativar toda a filtragem do recurso especificado no Google Play.

Filtros com base em recursos implícitos

Recurso implícito é um recurso necessário para o aplicativo funcionar corretamente, mas que não é declarado em um elemento <uses-feature> no arquivo de manifesto. Se formos rigorosos, todos os aplicativos precisam 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 eles 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 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 elemento <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 solicita permissões relacionadas a hardware, o Google Play supõe que o aplicativo usa os recursos de hardware implícitos e, portanto, exige esses recursos, mesmo que não correspondam às declarações <uses-feature>. Para essas permissões, o Google Play adiciona os recursos de hardware implícitos aos metadados armazenados para o aplicativo e define filtros para eles.

Por exemplo, se um app solicita a permissão CAMERA, mas não declara um elemento <uses-feature> para android.hardware.camera, o Google Play considera que o aplicativo exige uma câmera e não pode ser mostrado para usuários cujos dispositivos não tenham uma.

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 conforme mostrado abaixo.

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

É importante entender que as permissões solicitadas nos elementos <uses-permission> podem afetar diretamente a forma como 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 declara uma permissão Bluetooth em um elemento <uses-permission>, mas não declara explicitamente o recurso Bluetooth em um elemento <uses-feature>, o Google Play confere as versões da plataforma Android em que o aplicativo foi projetado para ser executado, conforme especificado no elemento <uses-sdk>.

Conforme mostrado na tabela abaixo, o Google Play permite o filtro do recurso Bluetooth apenas se o aplicativo declarar a plataforma mais baixa ou direcionada como Android 2.0 (API de nível 5) ou versões mais recentes. No entanto, 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 do recurso Bluetooth para um aplicativo que seleciona uma permissão Bluetooth, mas não declara esse recurso em um elemento <uses-feature>.

Se minSdkVersion for ...	ou targetSdkVersion for	Resultado
<=4 (ou o uses-sdk não for declarado)	<=4	O Google Play não vai filtrar o aplicativo de nenhum dispositivo com base no suporte informado para o recurso android.hardware.bluetooth.
<=4	>=5	O Google Play vai filtrar o aplicativo de todos os dispositivos que não oferecem suporte para recurso android.hardware.bluetooth, incluindo versões anteriores.
>=5	>=5

Os exemplos abaixo mostram os diferentes efeitos de filtros com base na forma como o Google Play gerencia 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 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 desejado 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 suporte para 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>

Por fim, no caso a seguir, o mesmo aplicativo adiciona um atributo android:required="false".

Resultado: o Google Play desativa o filtro com base no suporte para o 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 SDK do Android, para determinar como o Google Play vai filtrar o aplicativo, com base nas permissões e nos recursos declarados. Para fazer 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:

1. Primeiro, crie e exporte o aplicativo como um .apk não assinado. Se você estiver desenvolvendo no Android Studio, crie 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. Confira 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/.
2. Em seguida, localize a ferramenta aapt, se não estiver no seu PATH. Se você está usando as Ferramentas do SDK r8 ou mais recentes, pode encontrar aapt no diretório <SDK>/build-tools/<tools version number>.

   Observação: é necessário usar a versão do aapt fornecida para o mais recente componente Build-Tools disponível. Caso você não tenha o componente Build-Tools, faça o download dele usando o Android SDK Manager.

3. Execute aapt usando esta sintaxe:

$ aapt dump badging <path_to_exported_.apk>

Veja a seguir um exemplo da resposta ao 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, 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 mais atual da plataforma. 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 app 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 app 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 app usa a funcionalidade de áudio sofisticada e os recursos de desempenho avançados do dispositivo.

android.hardware.microphone

O app grava áudio usando o microfone do dispositivo.

Recursos de hardware do Bluetooth

android.hardware.bluetooth

O app usa os recursos de Bluetooth do dispositivo. Normalmente, para comunicação com outros dispositivos com o Bluetooth ativado.

android.hardware.bluetooth_le

O app usa os recursos de rádio Bluetooth de baixa energia do dispositivo.

Recursos de hardware da câmera

android.hardware.camera

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

android.hardware.camera.any

O app 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 app não exigir que a câmera seja a traseira.

android.hardware.camera.autofocus

O app usa o recurso de foco automático compatível com a câmera do dispositivo.

Ao usar esse recurso, um app 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 app 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 app usa o recurso MANUAL_SENSOR permitido pela câmera do dispositivo.

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

android.hardware.camera.capability.raw

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

Esse 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 app processe diretamente essas imagens brutas.

android.hardware.camera.external

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

android.hardware.camera.flash

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

Ao usar esse recurso, um app 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 app usa a câmera frontal do dispositivo.

Ao usar esse recurso, um app 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 app usa o suporte para a captura de imagens no nível FULL fornecido por pelo menos uma das câmeras do dispositivo. As câmeras com suporte para FULL oferecem recursos de captura em sequência, 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 app usando botões físicos, toque, controles giratórios e interfaces parecidas com um mouse. Normalmente, as telas do veículo aparecem no console central ou no painel 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 app, é preciso minimizar as distrações do motorista.

android.hardware.type.television

(Descontinuado. 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: a tela espelhada 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 tela touchscreen.

android.hardware.type.watch

O app 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 app lê impressões digitais usando o hardware biométrico do dispositivo.

Recursos de hardware de gamepad

android.hardware.gamepad

O app captura a entrada do controle de jogo do próprio dispositivo ou de um gamepad conectado.

Recursos de hardware de infravermelho

android.hardware.consumerir

O app 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 app usa um ou mais recursos do dispositivo para determinar a localização, como a localização por GPS, da rede ou do celular.

android.hardware.location.gps

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

Ao usar esse recurso, o app 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 app usa as coordenadas da localização aproximada vindas de um sistema de geolocalização com base em rede com suporte para o dispositivo.

Ao usar esse recurso, o app 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 app usa recursos de rádio de comunicação a curta distância (NFC, na sigla em inglês) 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 app usa o pacote de extensões para Android OpenGL ES instalado no dispositivo.

Recursos de hardware de sensor

android.hardware.sensor.accelerometer

O app usa leituras de movimento do acelerômetro do dispositivo para detectar a orientação atual do dispositivo. Por exemplo, um app pode usar leituras do acelerômetro para determinar quando alternar a orientação entre retrato e paisagem.

android.hardware.sensor.ambient_temperature

O app usa o sensor de temperatura ambiente (ambiental) do dispositivo. Por exemplo, um app meteorológico pode informar temperaturas internas ou externas.

android.hardware.sensor.barometer

O app usa o barômetro do dispositivo. Por exemplo, um app meteorológico pode informar a pressão do ar.

android.hardware.sensor.compass

O app usa o magnetômetro (bússola) do dispositivo. Por exemplo, um app de navegação pode mostrar a direção para onde o usuário está voltado no momento.

android.hardware.sensor.gyroscope

O app 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 app pode detectar mais facilmente se é necessário alternar entre as orientações de retrato e paisagem.

android.hardware.sensor.hifi_sensors

O app usa os sensores de alta fidelidade (Hi-Fi) do dispositivo. Por exemplo, um app de jogo pode detectar os movimentos do usuário com alta precisão.

android.hardware.sensor.heartrate

O app usa o monitor de frequência cardíaca do dispositivo. Por exemplo, um app fitness pode informar tendências na frequência cardíaca do usuário.

android.hardware.sensor.heartrate.ecg

O app usa o sensor de frequência cardíaca do eletrocardiograma (ECG) do dispositivo. Por exemplo, um app fitness pode fornecer informações mais detalhadas sobre a frequência cardíaca do usuário.

android.hardware.sensor.light

O app usa o sensor de luz do dispositivo. Por exemplo, o app pode mostrar um dentre dois esquemas de cores com base nas condições de iluminação do ambiente.

android.hardware.sensor.proximity

O app usa o sensor de proximidade do dispositivo. Por exemplo, um app 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 app usa o sensor de umidade relativa do dispositivo. Por exemplo, um app meteorológico pode usar a umidade para calcular e informar o ponto de orvalho atual.

android.hardware.sensor.stepcounter

O app usa o contador de passos do dispositivo. Por exemplo, um app fitness pode informar o número de passos que um usuário precisa dar para alcançar a meta de passos diária.

android.hardware.sensor.stepdetector

O app usa o detector de passos do dispositivo. Por exemplo, um app fitness 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 app oferece suporte para ambas as orientações, você não precisa declarar nenhum dos recursos.

Por exemplo, se o app exige a orientação retrato, você precisa declarar o recurso a seguir para que apenas os dispositivos compatíveis com a orientação de retrato (sempre ou mediante escolha do usuário) possam executar o app:

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

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

Como prática recomendada, use um elemento <uses-feature> para declarar o requisito para essa orientação. Se você declarar uma orientação para a atividade usando android:screenOrientation sem que isso seja necessário, vai 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 oferecem suporte para as orientações de paisagem e retrato.

Recursos de hardware de telefonia

android.hardware.telephony

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

android.hardware.telephony.cdma

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

Ao usar esse recurso, o app 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 app usa o sistema de radiotelefonia do Global System for Mobile Communications (GSM).

Ao usar esse recurso, o app 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 app usa eventos de interação por toque básicos, como tocar e arrastar.

Quando declarado como obrigatório, esse recurso indica que o app é compatível com um dispositivo apenas se ele emula uma tela touchscreen (“interface de toque simulada”) ou tem uma tela touchscreen real.

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

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

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

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

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

android.hardware.faketouch.multitouch.distinct

O app rastreia dois ou mais "dedos" diferentes em uma interface de toque simulada. Esse recurso é um superconjunto do recurso android.hardware.faketouch. Quando declarado como obrigatório, ele indica que o app é compatível com um dispositivo somente se esse dispositivo emula o rastreamento de dois ou mais dedos ou tem uma tela touchscreen real.

Ao contrário do multitoque distinto definido por android.hardware.touchscreen.multitouch.distinct, os dispositivos de entrada com suporte para multitoque distinto em 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 de toque de dois dedos correspondentes.

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

android.hardware.faketouch.multitouch.jazzhand

O app rastreia cinco ou mais "dedos" diferentes 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 app é compatível com um dispositivo apenas se esse dispositivo emula o rastreamento distinto de cinco ou mais dedos ou tem uma tela touchscreen real.

Ao contrário do multitoque distinto definido por android.hardware.touchscreen.multitouch.jazzhand, os dispositivos de entrada com suporte para multitoque “jazzhand” em 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 gesto com vários dedos faz com que ocorram eventos de toque de um único dedo e outros gestos com vários dedos acionam os eventos correspondentes a eles.

Dispositivos que fornecem um trackpad de toque de cinco dedos para movimento de cursor tem suporte para esse recurso.

android.hardware.touchscreen

O app usa os recursos de tela touchscreen do dispositivo para gestos mais interativos que os eventos de toque básicos, como deslizar rapidamente. Esse recurso é um superconjunto do recurso android.hardware.faketouch.

Por padrão, o aplicativo exige esse recurso. Assim, seu app não está disponível para dispositivos que oferecem apenas uma interface de toque emulada ("toque simulado") por padrão. Se quiser que o app esteja disponível em dispositivos que oferecem uma interface de toque simulada ou até mesmo em dispositivos que fornecem apenas um controlador D-pad, você precisa declarar explicitamente que a tela touchscreen não é obrigatória, declarando android.hardware.touchscreen com android:required="false". Essa declaração precisa ser adicionada se o app usa, mas não exige, uma interface de tela touchscreen real. Todos os apps que não exigem android.hardware.touchscreen explicitamente também funcionam em dispositivos com android.hardware.faketouch.

Se o app realmente exige uma interface de toque para realizar gestos de toque mais avançados, como navegar, você não precisa 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 app.

Se o app exige uma interação de toque mais complexa, como gestos com vários dedos, é preciso declarar que ele usa recursos avançados de touchscreen.

android.hardware.touchscreen.multitouch

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

Ao usar esse recurso, o app 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 app 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 esse recurso, o app 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 app 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 esse recurso, o app 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 app se comporta como um dispositivo USB e se conecta a hosts USB.

android.hardware.usb.host

O app usa acessórios USB conectados ao dispositivo. O dispositivo atua como host USB.

Recursos de hardware Vulkan

android.hardware.vulkan.compute

O app usa recursos computacionais do Vulkan. Esse recurso indica que o app exige a aceleração de hardware da implementação do Vulkan. A versão do recurso indica qual nível de computação opcional o app exige além dos requisitos do Vulkan 1.0. Por exemplo, se o app exige 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 ver mais detalhes sobre a versão do recurso.

android.hardware.vulkan.level

O app usa recursos de nível do Vulkan. Esse recurso indica que o app exige a aceleração de hardware da implementação do Vulkan. A versão do recurso indica qual nível de hardware opcional é exigido pelo app. Por exemplo, se o app exige suporte de hardware para o 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 ver mais detalhes sobre a versão do recurso.

android.hardware.vulkan.version

O app usa o Vulkan. Esse recurso indica que o app exige a aceleração de hardware da implementação do Vulkan. A versão do recurso indica a versão mínima de suporte da API Vulkan exigida pelo app. Por exemplo, se o app exige o 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 ver mais detalhes sobre a versão do hardware.

Recursos de hardware Wi-Fi

android.hardware.wifi

O app usa os recursos de rede 802.11 (Wi-Fi) do dispositivo.

android.hardware.wifi.direct

O app usa os recursos de rede Wi-Fi Direct do dispositivo.

Recursos de software

Esta seção apresenta os recursos de software com suporte para a versão da plataforma mais atual. Para indicar que o app 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 app usa serviços do Session Initiation Protocol (SIP). Ao usar o SIP, o app pode oferecer suporte para 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. Ao usar VoIP, o app oferece suporte para operações de telefonia na internet em tempo real, como videoconferência bidirecional.

Ao usar esse recurso, o app 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 app mostra conteúdo da internet.

Recursos de software de entrada personalizada

android.software.input_methods

O app usa um novo método de entrada, definido pelo desenvolvedor em um InputMethodService.

Recursos de software de gerenciamento de dispositivos

android.software.backup

O app inclui lógica para processar uma operação de backup e restauração.

android.software.device_admin

O app usa administradores do dispositivo para aplicar uma política do dispositivo.

android.software.managed_users

O app é compatível com usuários secundários e perfis gerenciados.

android.software.securely_removes_users

O app pode remover permanentemente usuários e dados associados a eles.

android.software.verified_boot

O app inclui lógica para processar resultados do recurso de inicialização verificada do dispositivo, que detecta se a configuração dele muda durante uma operação de reinício.

Recursos de software de mídia

android.software.midi

O app se conecta a instrumentos musicais ou gera sons usando o protocolo Musical Instrument Digital Interface (MIDI, na sigla em inglês).

android.software.print

O app inclui comandos para imprimir documentos mostrados no dispositivo.

android.software.leanback

O app é projetado para ser executado em dispositivos Android TV.

android.software.live_tv

O app faz streaming de programas de televisão ao vivo.

Recursos de software de interface de tela

android.software.app_widgets

O app usa ou fornece widgets de apps e precisa ser instalado apenas em dispositivos que incluem uma tela inicial ou localização parecida na qual os usuários podem incorporar widgets.

android.software.home_screen

O app se comporta como um substituto da tela inicial do dispositivo.

android.software.live_wallpaper

O app 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 apps 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 apps puderam utilizar a API antes de poder declarar que exigem a API usando o sistema <uses-feature>.

Para evitar que esses apps sejam disponibilizados acidentalmente, o Google Play supõe que algumas permissões relacionadas ao hardware indicam que os recursos implícitos de hardware são obrigatórios por padrão. Por exemplo, apps que usam Bluetooth precisar solicitar a permissão BLUETOOTH em um elemento <uses-permission>. Em apps legados, o Google Play supõe que a declaração de permissão significa que o recurso android.hardware.bluetooth implícito é exigido pelo app e define o filtro de acordo com esse recurso. A Tabela 2 lista as permissões que implicam requisitos de recurso equivalentes às declaradas nos 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, é possível desativar a filtragem com base no recurso implícito, declarando explicitamente esse recurso em um elemento <uses-feature> com um atributo android:required="false". Por exemplo, para desativar qualquer um dos 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: caso seu app seja direcionado ao Android 5.0 (API de nível 21) ou versões mais recentes e use a permissão ACCESS_COARSE_LOCATION ou ACCESS_FINE_LOCATION para receber atualizações de locais da rede ou de um GPS, respectivamente, você também precisa declarar explicitamente que o app usa os recursos de hardware android.hardware.location.network ou android.hardware.location.gps.

Tabela 2. Permissões 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_ADMIN	android.hardware.bluetooth
Câmera	CAMERA	android.hardware.camera e android.hardware.camera.autofocus
Local	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 (Apenas quando o nível desejado da API é 20 ou anterior)
	ACCESS_FINE_LOCATION	android.hardware.location android.hardware.location.gps (Apenas quando nível desejado da API é 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