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 atributorequired
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 atributoname
.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 seminSdkVersion
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"
. - Ao declarar
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, oandroid: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:
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 atributoandroid: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>
.
minSdkVersion for ... |
targetSdkVersion for |
Resultado |
---|---|---|
<=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:
- 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:- Abra o projeto e selecione Run > Edit Configurations.
- Selecione o sinal de mais ao lado do canto superior esquerdo da janela Run/Debug Configurations.
- Selecione Gradle.
- Insira
Unsigned APK
em Name. - Escolha o módulo na seção Gradle project.
- Insira
assemble
em Tasks. - Selecione OK para concluir a nova configuração.
- Confira se a configuração de execução Unsigned APK está selecionada na barra de ferramentas e selecione Run > Run 'Unsigned APK'.
.apk
não assinado no diretório<ProjectName>/app/build/outputs/apk/
. - Em seguida, localize a ferramenta
aapt
, se não estiver no seu PATH. Se você está usando as Ferramentas do SDK r8 ou mais recentes, pode encontraraapt
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. - 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 comandroid: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 umandroid.colorCorrection.mode
deTRANSFORM_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 comandroid: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 comandroid: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 paraFULL
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 atributoandroid: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 atributoandroid: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ê declararandroid: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 usandoandroid:screenOrientation
sem que isso seja necessário, vai poder declarar a orientação com um elemento<uses-feature>
e incluirandroid: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 comandroid: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 comandroid: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 comandroid.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
comandroid: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 exigemandroid.hardware.touchscreen
explicitamente também funcionam em dispositivos comandroid.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 comandroid: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 comandroid: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 comandroid: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" />
ConsulteFEATURE_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" />
ConsulteFEATURE_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" />
ConsulteFEATURE_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 comandroid: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 |
|
|
ACCESS_FINE_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 |