<uses-feature>

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 a todas as entidades externas sobre o conjunto de recursos de hardware e software de que o aplicativo depende. O elemento oferece um atributo required que possibilita especificar se o aplicativo exige e não funciona sem o recurso declarado ou se prefere ter o recurso, mas pode funcionar sem ele.

Como o suporte para recursos pode variar nos 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. As constantes de recursos estão listadas na seção Referência de recursos deste documento.

Você precisa especificar cada recurso em um elemento <uses-feature> separado. Portanto, se o aplicativo exigir vários recursos, ele 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" android:required="true" />
<uses-feature android:name="android.hardware.camera.any" android:required="true" />

Em geral, sempre declare 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 ao 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 usados pelo aplicativo.

Em alguns casos, pode haver 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 existem ou não em um dispositivo, como uma câmera, são declarados usando o atributo name.

Embora o elemento <uses-feature> seja ativado apenas para dispositivos com o nível 4 da API ou mais recente, inclua esses elementos em todos os aplicativos, mesmo se a minSdkVersion for 3 ou anterior. Os dispositivos com versões anteriores da plataforma ignoram o elemento.

Observação: ao declarar um recurso, você também precisa solicitar as permissões adequadas. Por exemplo, é necessário solicitar 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. A declaração dos recursos usados pelo aplicativo ajuda a garantir 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.

• Declarar android:required="true" em um recurso indica que o aplicativo não funciona ou não foi projetado para funcionar quando o recurso especificado não está presente no dispositivo.
• Declarar android:required="false" em um recurso indica que o aplicativo usa o recurso quando ele está presente no dispositivo, mas que foi projetado para funcionar sem o recurso especificado, se necessário.

O valor padrão de android:required é "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 a versão 2.0 do OpenGL ES, defina o valor como "0x00020000". Para especificar o OpenGL ES 3.2, defina o valor como "0x00030002".

Um aplicativo especifica 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 a todos os dispositivos com 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 especifica que exige o OpenGL ES 2.0.

Um aplicativo que pode trabalhar com diversas versões do OpenGL ES especifica 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:

Nível 4 da API

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 exigidos pelo aplicativo, conforme declarado nos elementos <uses-feature> no manifesto do aplicativo;
• recursos disponíveis no dispositivo, em hardware ou software, conforme relatado usando propriedades de sistema somente para leitura.

Para comparar os recursos de forma precisa, 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 na seção Referência de recursos deste documento e na documentação de classe para o PackageManager.

Quando o usuário inicializa o Google Play, o aplicativo consulta o gerenciador de pacotes 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 estão presentes no dispositivo, o Google Play permite que o usuário veja e faça o download desse aplicativo, se quiser.

Se o dispositivo não oferece suporte a algum recurso obrigatório, o Google Play faz uma filtragem para mostrar o aplicativo, impedindo a visualização 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. Confira mais informações nas seções a seguir.

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ê estiver compilando com uma API de nível 5 ou mais recente.

Isso permite especificar se o aplicativo exige o recurso e não funciona corretamente sem ele ("true") ou se usa o recurso quando disponível, mas foi projetado para ser executado sem ele ("false").

O Google Play processa recursos declarados explicitamente da seguinte forma:

• Se um recurso é declarado explicitamente como obrigatório, como mostrado no exemplo a seguir, o Google Play o adiciona à lista de recursos obrigatórios do aplicativo. Em seguida, ele filtra os aplicativos dos usuários com dispositivos que não fornecem esse recurso.

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

• Se um recurso é explicitamente declarado como não obrigatório, conforme mostrado no exemplo a seguir, 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.

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

Em geral, se o aplicativo é projetado para ser executado no Android 1.6 e 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.

Filtrar 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. Rigorosamente, é melhor que todos os aplicativos sempre declarem todos os recursos usados ou exigidos. Além disso, a ausência de uma declaração para um recurso usado por um aplicativo pode 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 recursos declarados explicitamente.

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

• o aplicativo foi compilado com uma versão antiga da biblioteca Android (Android 1.5 ou anterior), para a qual o elemento <uses-feature> não estava disponível;
• o desenvolvedor presume incorretamente que o recurso está presente em todos os dispositivos e que uma declaração é desnecessária;
• o desenvolvedor omite acidentalmente a declaração do recurso;
• o desenvolvedor declara o recurso explicitamente, mas a declaração não é vá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 invalida a declaração do recurso.

Para considerar esses casos, 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 existam declarações <uses-feature> correspondentes. 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, o Google Play presume que o aplicativo exige uma câmera traseira, mesmo que o app não declare um elemento <uses-feature> para android.hardware.camera. Como resultado, o Google Play filtra dispositivos que não têm uma câmera traseira.

Se você não quer que o Google Play filtre com base em um recurso implícito específico, declare explicitamente o recurso em um elemento <uses-feature> e inclua o atributo android:required="false". Por exemplo, para desativar o filtro implícito na permissão CAMERA, declare os seguintes recursos:

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

Cuidado: permissões solicitadas em elementos <uses-permission> podem afetar diretamente a forma como o Google Play filtra o aplicativo. A seção Permissões que implicam requisitos de recurso lista as permissões que sugerem requisitos de recurso implicitamente 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 no exemplo anterior.

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

Como mostrado na tabela a seguir, o Google Play permite a filtragem do recurso Bluetooth apenas quando o aplicativo declara a plataforma mais baixa ou uma plataforma direcionada para o Android 2.0 (API de nível 5) ou mais recente. 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>.

Os exemplos a seguir 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 ser executado 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, 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ê pode usar a ferramenta aapt2, incluída no SDK do Android, para determinar como o Google Play filtra o aplicativo com base nos recursos e permissões declarados. Para fazer isso, execute aapt2 com o comando dump badging. Isso faz com que aapt2 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. Crie e exporte o aplicativo como um APK não assinado. Se você estiver desenvolvendo no Android Studio, crie o aplicativo com o Gradle, da seguinte maneira:
   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. Digite "Unsigned APK" em Name.
   5. Escolha o módulo na seção Gradle project.
   6. Digite "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'.
   O APK não assinado estará disponível no diretório <ProjectName>/app/build/outputs/apk/.
2. Localize a ferramenta aapt2, se ela ainda não estiver no seu PATH. Se você está usando as Ferramentas do SDK r8 ou mais recentes, pode encontrar aapt2 no diretório <SDK>/build-tools/<tools version number>.

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

3. Execute aapt2 usando esta sintaxe:

$ aapt2 dump badging <path_to_exported_.apk>

Confira uma resposta ao comando para o segundo exemplo de Bluetooth mostrado anteriormente:

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

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

Observação: para evitar a filtragem desnecessária do app pelo Google Play, adicione android:required="false" a qualquer recurso de câmera que o app possa funcionar sem. Caso contrário, o Google Play presume que o recurso é obrigatório e impede que dispositivos sem suporte para o recurso acessem seu app.

Suporte a telas grandes

Alguns dispositivos de tela grande não oferecem suporte para todos os recursos da câmera. Os Chromebooks geralmente não têm câmeras traseiras, autofoco ou flash. Porém, os Chromebooks têm câmeras frontais e geralmente estão conectados a câmeras externas.

Para oferecer suporte básico a câmeras e disponibilizar seu app para o maior número possível de dispositivos, adicione estas configurações de recursos da câmera ao manifesto do app:

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

Ajuste as configurações do recurso para oferecer suporte aos casos de uso do seu app. No entanto, para disponibilizar o app para o maior número de dispositivos possível, sempre inclua o atributo required para especificar explicitamente se um recurso é obrigatório.

Lista de recursos

android.hardware.camera.any

O app usa uma das câmeras do dispositivo ou uma câmera externa conectada ao dispositivo. Use esse recurso em vez de android.hardware.camera ou android.hardware.camera.front se o app não exigir que a câmera seja traseira ou frontal, respectivamente.

A permissão CAMERA implica que o app também usa android.hardware.camera. A câmera traseira é um recurso necessário, a menos que android.hardware.camera seja declarado com android:required="false".

android.hardware.camera

O app usa a câmera traseira do dispositivo.

Atenção: dispositivos como os Chromebooks, que têm apenas câmera frontal, não oferecem suporte a esse recurso. Use android.hardware.camera.any se o app puder usar qualquer câmera, seja qual for a direção dela.

Observação: a permissão CAMERA implica que a câmera traseira é um recurso necessário. Para ajudar a garantir a filtragem adequada no Google Play quando o manifesto do app incluir a permissão CAMERA, especifique explicitamente que o app usa o recurso camera e indique se ele é obrigatório, como:
<uses-feature android:name="android.hardware.camera" android:required="false" />

android.hardware.camera.front

O app usa a câmera frontal do dispositivo.

A permissão CAMERA implica que o app também usa android.hardware.camera. A câmera traseira é um recurso necessário, a menos que android.hardware.camera seja declarado com android:required="false".

Atenção: caso o app use android.hardware.camera.front, mas não declare explicitamente android.hardware.camera com android.required="false", dispositivos que não têm câmera traseira (como os Chromebooks) são filtrados pelo Google Play. Se o app oferece suporte a dispositivos que têm apenas câmeras frontais, declare android.hardware.camera com android.required="false" para evitar filtros desnecessários.

android.hardware.camera.external

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

A permissão CAMERA implica que o app também usa android.hardware.camera. A câmera traseira é um recurso necessário, a menos que android.hardware.camera seja declarado com android:required="false".

android.hardware.camera.autofocus

O app usa o recurso de autofoco com suporte da câmera do dispositivo.

Observação: a permissão CAMERA implica que o autofoco é um recurso obrigatório. Para garantir a filtragem adequada no Google Play quando o manifesto do app incluir a permissão CAMERA, especifique explicitamente que o app usa o recurso de autofoco e indique se ele é obrigatório ou não. Por exemplo:
<uses-feature android:name="android.hardware.camera.autofocus" android:required="false" />.

android.hardware.camera.flash

O app usa o recurso de flash com suporte da câmera do dispositivo.

android.hardware.camera.capability.manual_post_processing

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

Esse recurso permite que o app substitua 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 com suporte da câmera do dispositivo.

Esse recurso implica suporte ao 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). A câmera do dispositivo informa os metadados relacionados a DNG necessários para que o app processe diretamente as imagens brutas.

android.hardware.camera.level.full

O app usa o nível FULL de suporte a captura de imagem fornecido por pelo menos uma das câmeras do dispositivo. O suporte a FULL inclui recursos de captura em sequência, controle por frame e controle manual pós-processamento. Consulte INFO_SUPPORTED_HARDWARE_LEVEL_FULL.

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.

Observação : consulte Distribuir para carros para mais informações sobre o uso desse recurso e orientações para criar apps para carros.

android.hardware.type.television

(Descontinuado. Em vez disso, use android.software.leanback.)

O aplicativo foi projetado para mostrar a interface em uma televisão. Esse recurso define "televisão" como uma experiência típica de televisão na sala de estar: o app espelhado em uma tela grande, com o usuário sentado a certa distância, e o formato predominante de entrada é algo como um botão direcional em vez de um mouse, ponteiro ou tela touchscreen.

android.hardware.type.watch

O app foi projetado para mostrar a interface 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.

android.hardware.type.pc

O app foi projetado para mostrar a interface em Chromebooks. Esse recurso desativa a emulação de entrada para mouse e touchpad, já que os Chromebooks usam esses acessórios em hardware. Consulte Entrada do mouse.

Observação: defina required="false" para esse elemento. Caso contrário, a Google Play Store vai deixar seu app indisponível para dispositivos que não sejam Chromebooks.

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 o 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 o 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) 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 do 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 de eletrocardiograma (ECG) do dispositivo. Por exemplo, um app fitness pode mostrar 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, um app pode mostrar um de 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 abaixo para que apenas os dispositivos com suporte a essa orientação (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 aceitam as orientações ou uma delas. 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 ficará disponível apenas em dispositivos com suporte à orientação de paisagem.

Como prática recomendada, use um elemento <uses-feature> para declarar o requisito para essa orientação. Se você declara uma orientação para a atividade usando android:screenOrientation sem que isso seja necessário, pode 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 versão 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 oferece suporte a um dispositivo apenas se esse dispositivo emula uma tela touchscreen "simulada" ou uma tela touchscreen real.

Dispositivos que oferecem uma interface de toque simulada fornecem um sistema de entrada do usuário 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 exige interação básica do tipo apontar e clicar e não funciona somente 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.

Os apps exigem o recurso android.hardware.faketouch por padrão. Se você quer 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 apps que não exigem android.hardware.touchscreen explicitamente, como mostrado no exemplo a seguir, 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 oferece suporte a 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, dispositivos de entrada com suporte a multitoque distinto em uma interface de toque simulada não oferecem suporte a 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 oferece suporte a 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, dispositivos de entrada com suporte a multitoque "jazzhand" em uma interface de toque simulada não oferecem suporte a 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, gestos com vários dedos fazem 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, todos os apps exigem esse recurso e, portanto, não estão disponíveis para dispositivos que oferecem apenas uma interface de toque simulada. É possível disponibilizar o app em dispositivos que oferecem uma interface de toque simulada ou até mesmo em dispositivos que fornecem apenas um controlador D-pad, declarando explicitamente que a tela touchscreen não é necessária usando android.hardware.touchscreen com android:required="false". Adicione essa declaração se o app usa, mas não exige, uma interface real de tela touchscreen. 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, por exemplo, para executar gestos de toque mais avançados, como deslizar rapidamente, você não precisa declarar nenhum recurso de interface de toque, porque eles são obrigatórios por padrão. No entanto, é melhor 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, declare que ele usa recursos avançados de tela 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 de 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 seguinte recurso:

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

Para saber mais sobre a versão do recurso, consulte FEATURE_VULKAN_HARDWARE_COMPUTE.

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 seguinte recurso:

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

Para saber mais sobre a versão do recurso, consulte FEATURE_VULKAN_HARDWARE_LEVEL.

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 seguinte recurso:

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

Para saber mais sobre a versão do recurso, consulte FEATURE_VULKAN_HARDWARE_VERSION.

Recursos de hardware de 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 Voz sobre IP (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 o 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 local parecido em que 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 sugerem requisitos de recurso

Algumas constantes de recurso de hardware e software são disponibilizadas para os aplicativos após a API correspondente. Por isso, alguns apps podem usar a API antes de declararem 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, aplicativos que usam Bluetooth precisam 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 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 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 o filtro com base no recurso implícito, declarando explicitamente o recurso em um elemento <uses-feature> com o atributo required definido como false.

Por exemplo, para desativar o filtro com base na permissão CAMERA, adicione as seguintes declarações <uses-feature> ao arquivo de manifesto:

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

Atenção: caso seu app seja direcionado ao Android 5.0 (API de nível 21) ou mais recente 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.