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 dos quais depende o aplicativo. O elemento oferece um atributo required que permite especificar se o aplicativo exige e não funciona sem o recurso declarado ou se prefere dispor do recurso, mas pode funcionar sem ele. Como a compatibilidade a recursos pode variar entre dispositivos Android, o elemento <uses-feature> desempenha um papel importante, permitindo que o aplicativo descreva os recursos necessários que variam entre dispositivos.

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

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

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

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

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

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

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

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

atributos:

android:name

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

android:required

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

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

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

android:glEsVersion

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

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

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

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

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

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

introduzido na:

API de nível 4

veja também:

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

Google Play e filtragem baseada em recurso

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

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

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

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

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

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

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

Filtragem baseada em recursos declarados explicitamente

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

O Google Play processa recursos declarados explicitamente da seguinte forma:

• Se um recurso for explicitamente declarado como obrigatório, o Google Play adicionará o recurso à lista de recursos obrigatórios do aplicativo. Em seguida, filtrará os aplicativos dos usuários com dispositivos que não fornecem esse recurso. Por exemplo:

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

• Se um recurso for explicitamente declarado como não obrigatório, o Google Play não adicionará o recurso à lista de recursos obrigatórios. Por esse motivo, um recurso declarado explicitamente como não obrigatório nunca é considerado na filtragem do aplicativo. Mesmo que o dispositivo não ofereça o recurso declarado, o Google Play considerará o aplicativo compatível com o dispositivo e o mostrará ao usuário, a menos que sejam aplicadas outras regras de filtragem. Por exemplo:

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

• Se um recurso for declarado explicitamente, mas sem um atributo android:required, o Google Play suporá que o recurso é necessário e configura a filtragem por esse recurso.

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

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

Filtragem baseada em recursos implícitos

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

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

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

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

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

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

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

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

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

Processamento especial para o recurso Bluetooth

Para determinar a filtragem para Bluetooth, O Google Play aplica regras ligeiramente diferentes das descritas acima.

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

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

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

.

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

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

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

Resultado: O Google Play não filtra o aplicativo de nenhum dispositivo.

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

No segundo exemplo, abaixo, o mesmo aplicativo também declara uma API com nível direcionado de "5".

Resultado: O Google Play agora supõe que o recurso seja obrigatório e filtra o aplicativo de todos os dispositivos que não informam compatibilidade com Bluetooth, inclusive dispositivos que executam versões anteriores da plataforma.

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

Aqui, o mesmo aplicativo declara especificamente o recurso Bluetooth.

Resultado: Idêntico ao exemplo anterior (a filtragem é aplicada).

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

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

Resultado: O Google Play desativa a filtragem baseada na compatibilidade do recurso Bluetooth para todos os dispositivos.

<manifest ...>
    <uses-feature android:name="android.hardware.bluetooth" android:required="false" />
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
    <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
    ...
</manifest>

Testar os recursos obrigatórios do aplicativo

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

Para usar a ferramenta, siga estas etapas:

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

   Observação: Você deve usar a versão do aapt fornecida para o mais recente componente Platform-Tools disponível. Se você não tiver o componente Platform-Tools, baixe-o usando o Android SDK Manager.

3. Execute aapt usando esta sintaxe:

$ aapt dump badging <path_to_exported_.apk>

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

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

Referência de recursos

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

Recursos de hardware

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

Recursos de hardware de áudio

android.hardware.audio.low_latency

O aplicativo usa o fluxo de áudio de baixa latência do dispositivo, que reduz demoras e atrasos no processamento de entrada ou saída de som.

android.hardware.audio.output

O aplicativo transmite som usando os alto-falantes, a entrada para fone de ouvido, os recursos de streaming do Bluetooth ou mecanismos semelhantes do dispositivo.

android.hardware.audio.pro

O aplicativo usa a funcionalidade de áudio e os recursos de desempenho avançados do dispositivo.

android.hardware.microphone

O aplicativo grava áudio usando o microfone do dispositivo.

Recursos de hardware do Bluetooth

android.hardware.bluetooth

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

android.hardware.bluetooth_le

O aplicativo usa os recursos de rádio Low Energy do Bluetooth do dispositivo.

Recursos de hardware da câmera

android.hardware.camera

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

android.hardware.camera.any

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

android.hardware.camera.autofocus

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

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

android.hardware.camera.capability.manual_post_processing

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

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

android.hardware.camera.capability.manual_sensor

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

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

android.hardware.camera.capability.raw

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

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

android.hardware.camera.external

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

android.hardware.camera.flash

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

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

android.hardware.camera.front

O aplicativo usa a câmera frontal do dispositivo.

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

android.hardware.camera.level.full

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

Recursos de hardware da IU do dispositivo

android.hardware.type.automotive

O aplicativo foi projetado para mostrar sua IU em um conjunto de telas dentro de um veículo. O usuário interage com o aplicativo usando botões físicos, toque, controles giratórios e interfaces semelhantes ao mouse. Normalmente, as telas do veículo aparecem no console central ou no 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 aplicativo, este deve minimizar as distrações do motorista.

android.hardware.type.television

(Obsoleto; em vez disso, use android.software.leanback.)

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

android.hardware.type.watch

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

Recursos de hardware de impressão digital

android.hardware.fingerprint

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

Recursos de hardware de gamepad

android.hardware.gamepad

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

Recursos de hardware de infravermelho

android.hardware.consumerir

O aplicativo usa os recursos de infravermelho (IR) do dispositivo, normalmente para comunicação com outros dispositivos IR do consumidor.

Recursos de hardware de localização

android.hardware.location

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

android.hardware.location.gps

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

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

android.hardware.location.network

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

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

Recursos de hardware de NFC

android.hardware.nfc

O aplicativo usa recursos de rádio de Near-Field Communication (NFC) do dispositivo.

android.hardware.nfc.hce

(Obsoleto.)

O aplicativo usa emulação de cartão NFC, hospedada no dispositivo.

Recursos de hardware de OpenGL ES

android.hardware.opengles.aep

O aplicativo usa o OpenGL ES Android Extension Pack instalado no dispositivo.

Recursos de hardware de sensor

android.hardware.sensor.accelerometer

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

android.hardware.sensor.ambient_temperature

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

android.hardware.sensor.barometer

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

android.hardware.sensor.compass

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

android.hardware.sensor.gyroscope

O aplicativo usa o giroscópio do dispositivo para detectar a rotação e o giro, criando um sistema de orientação em seis eixos. Usado esse sensor, o aplicativo pode detectar mais suavemente se é necessário alternar entre as orientações retrato e paisagem.

android.hardware.sensor.hifi_sensors

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

android.hardware.sensor.heartrate

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

android.hardware.sensor.heartrate.ecg

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

android.hardware.sensor.light

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

android.hardware.sensor.proximity

O aplicativo usa o sensor de proximidade do dispositivo. Por exemplo, um aplicativo de telefonia pode desligar a tela do dispositivo quando detectar que o usuário está mantendo o dispositivo próximo ao corpo.

android.hardware.sensor.relative_humidity

O aplicativo usa o sensor de umidade relativa do dispositivo. Por exemplo, um aplicativo meteorológico pode usar a umidade para calcular e informar o ponto de orvalho atual.

android.hardware.sensor.stepcounter

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

android.hardware.sensor.stepdetector

O aplicativo usa o detector de passos dos dispositivos. Por exemplo, um aplicativo de boa forma pode usar o intervalo de tempo entre passos para deduzir o tipo de exercício que o usuário está fazendo.

Recursos de hardware de tela

android.hardware.screen.landscape

android.hardware.screen.portrait

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

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

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

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

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

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

Recursos de hardware de telefonia

android.hardware.telephony

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

android.hardware.telephony.cdma

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

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

android.hardware.telephony.gsm

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

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

Recursos de hardware de tela tátil

android.hardware.faketouch

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

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

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

Observação: Os aplicativos exigem o recurso android.hardware.touchscreen por padrão. Se quiser que o aplicativo fique disponível para dispositivos que oferecem uma interface de toque simulada, você também deve declarar explicitamente que o tela tátil não é obrigatório, da seguinte forma:

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

android.hardware.faketouch.multitouch.distinct

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

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

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

android.hardware.faketouch.multitouch.jazzhand

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

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

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

android.hardware.touchscreen

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

Por padrão, o aplicativo exige esse recurso. Portanto, o aplicativo não está disponível para dispositivos que fornecem apenas uma interface de toque simulada por padrão. Se quiser que o aplicativo esteja disponível em dispositivos que oferecem uma interface de toque simulada (ou até mesmo em dispositivos que fornecem apenas um controlador d-pad), você deve declarar explicitamente que a tela tátil não é exigida, declarando android.hardware.touchscreen com android:required="false". Essa declaração deverá ser adicionada se o aplicativo usar, mas não exigir, uma interface de tela tátil real.

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

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

android.hardware.touchscreen.multitouch

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

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

android.hardware.touchscreen.multitouch.distinct

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

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

android.hardware.touchscreen.multitouch.jazzhand

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

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

Recursos de hardware USB

android.hardware.usb.accessory

O aplicativo se comporta como dispositivo USB e se conecta a hosts USB.

android.hardware.usb.host

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

Recursos de hardware Wi-Fi

android.hardware.wifi

O aplicativo usa recursos de redes 802.11 (Wi-Fi) do dispositivo.

android.hardware.wifi.direct

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

Recursos de software

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

Recursos de software de comunicação

android.software.sip

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

android.software.sip.voip

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

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

android.software.webview

O aplicativo exibe conteúdo da internet.

Recursos de software de entrada personalizada

android.software.input_methods

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

Recursos de software de gerenciamento de dispositivos

android.software.backup

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

android.software.device_admin

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

android.software.managed_users

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

android.software.securely_removes_users

O aplicativo pode remover permanentemente usuários e seus dados associados.

android.software.verified_boot

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

Recursos de software de mídia

android.software.midi

O aplicativo se conecta a instrumentos musicais ou gera sons usando o protocolo Musical Instrument Digital Interface (MIDI).

android.software.print

O aplicativo inclui comandos para imprimir documentos exibidos no dispositivo.

android.software.leanback

O aplicativo apresenta uma IU que foi projetada para exibição em uma tela grande, como uma televisão.

android.software.live_tv

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

Recursos de software de interface de tela

android.software.app_widgets

O aplicativo usa ou fornece widgets de aplicativo e deve ser instalado apenas em dispositivos que incluem uma tela inicial ou localização similar onde os usuários podem incorporar widgets de aplicativo.

android.software.home_screen

O aplicativo se comporta como uma substituição da tela inicial do dispositivo.

android.software.live_wallpaper

O aplicativo usa ou fornece planos de fundo que incluem animação.

Permissões que implicam em requisitos de recurso

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

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

Observe que as declarações <uses-feature>, incluindo todos os atributos android:required declarados, sempre têm precedência sobre recursos implícitos pelas permissões na tabela 2. Em qualquer uma dessas permissões, você pode desativar a filtragem de acordo com o recurso implícito, declarando explicitamente o recurso implícito em um elemento <uses-feature> com um atributo android:required="false". Por exemplo, para desativar toda a filtragem 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" />

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

Categoria	Esta permissão...	... implica neste requisito de recurso
Bluetooth	BLUETOOTH	android.hardware.bluetooth (Consulte Processamento especial para o recurso Bluetooth para obter mais detalhes.)
	BLUETOOTH_ADMIN	android.hardware.bluetooth
Câmera	CAMERA	android.hardware.camera e android.hardware.camera.autofocus
Localização	ACCESS_MOCK_LOCATION	android.hardware.location
	ACCESS_LOCATION_EXTRA_COMMANDS	android.hardware.location
	INSTALL_LOCATION_PROVIDER	android.hardware.location
	ACCESS_COARSE_LOCATION	android.hardware.location.network e android.hardware.location
	ACCESS_FINE_LOCATION	android.hardware.location.gps e android.hardware.location
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