O Google Play usa os elementos de <uses-feature>
declarados no manifesto do aplicativo para filtrá-lo de dispositivos que não cumprem os requisitos de recursos de hardware e software.
A especificação dos recursos obrigatórios do aplicativo permite que o Google Play apresente o aplicativo somente aos usuários com dispositivos que cumprem os requisitos de recursos do aplicativo, em vez de apresentá-lo a todos os usuários.
Para saber informações importantes de como o Google Play usa recursos como base para filtrar, leia Google Play e filtros com base em recurso abaixo.
- sintaxe:
-
<uses-feature android:name="string" android:required=["true" | "false"] android:glEsVersion="integer" />
- contido em:
<manifest>
- descrição:
- Declara um único recurso de hardware ou software usado pelo aplicativo.
O propósito de uma declaração
<uses-feature>
é informar todas as entidades externas sobre o conjunto de recursos de hardware e software de que depende o aplicativo. O elemento oferece um atributorequired
que permite especificar se o aplicativo exige e não funciona sem o recurso declarado ou se prefere dispor do recurso, mas pode funcionar sem ele. Como a compatibilidade com recursos pode variar entre dispositivos Android, o elemento<uses-feature>
desempenha um papel importante, permitindo que o aplicativo descreva os recursos necessários que variam entre dispositivos.O conjunto de recursos disponíveis declarado pelo aplicativo corresponde ao conjunto de constantes de recurso disponibilizado pelo
PackageManager
do Android, que são listadas por conveniência nas seções Referência de recursos, na parte final deste documento.Você deve especificar cada recurso em um elemento
<uses-feature>
separado. Portanto, se o aplicativo exigir vários recursos, deverá declarar vários elementos<uses-feature>
. Por exemplo, um aplicativo que exige recursos de Bluetooth e câmera no dispositivo deve declarar estes dois elementos:<uses-feature android:name="android.hardware.bluetooth" /> <uses-feature android:name="android.hardware.camera" />
Geralmente, você deve sempre declarar elementos
<uses-feature>
para todos os recursos obrigatórios do aplicativo.Elementos
<uses-feature>
declarados são somente para informação, o que significa que o próprio sistema Android não verifica a compatibilidade do recurso correspondente no dispositivo antes de instalar um aplicativo. No entanto, outros serviços (como Google Play) ou aplicativos podem verificar as declarações<uses-feature>
do aplicativo como parte do processamento ou interação dele. Por esse motivo, é muito importante declarar todos os recursos (da lista abaixo) usados pelo aplicativo.Para alguns recursos, pode existir um atributo específico que permite definir uma versão do recurso, como a versão do OpenGL usada (declarada com
glEsVersion
). Outros recursos que podem existir ou não para um dispositivo, como uma câmera, são declarados usando o atributoname
.Embora o elemento
<uses-feature>
seja ativado somente para dispositivos executando a API de nível 4 ou posterior, recomendamos incluir esses elementos para todos os aplicativos, mesmo seminSdkVersion
for “3” ou anterior. Os dispositivos executando versões anteriores da plataforma simplesmente ignorarão o elemento.Observação: ao declarar um recurso, lembre-se de que você também deve solicitar as permissões adequadas. Por exemplo, é necessário solicitar também a permissão
CAMERA
antes que o aplicativo possa acessar a API da câmera. A solicitação da permissão permite que seu aplicativo acesse o hardware e software adequados, e a declaração dos recursos usados pelo aplicativo garante a compatibilidade de dispositivo correta. - atributos:
-
-
android:name
- Especifica um único recurso de hardware ou software usado pelo aplicativo, como um string de descritor. Os valores de atributo válidos são listados nas seções Recursos de hardware e Recursos de software. Esses valores de atributo diferenciam minúsculas de maiúsculas.
-
android:required
-
Valor booleano que indica se o aplicativo exige o recurso especificado no
android:name
.- Ao declarar
android:required="true"
para um recurso, você está especificando que o aplicativo não funcionará ou não foi projetado para funcionar quando o recurso especificado não estiver presente no dispositivo. - Quando você declara
android:required="false"
para um recurso, isso significa que o aplicativo prefere usar o recurso se presente no dispositivo, mas foi processado para funcionar sem o recurso especificado, se necessário.
Quando
android:required
não é declarado, o valor padrão é"true"
. - 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 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 oandroid:glEsVersion
com o valor numérico mais alto e todos os demais valores serão ignorados.Se um aplicativo não especificar nenhum atributo
android:glEsVersion
, supostamente o aplicativo exige somente o OpenGL ES 1.0, compatível com todos os dispositivos que usam Android.Um aplicativo pode supor que, se uma plataforma for compatível com uma determinada versão do OpenGL ES, também será compatível com todas as versões do OpenGL ES numericamente menores. Portanto, um aplicativo que exige OpenGL ES 1.0 e 2.0 deve especificar que exige OpenGL ES 2.0.
Um aplicativo que pode trabalhar com diversas versões do OpenGL ES deve especificar somente a versão numericamente menor do OpenGL ES necessária. Ele pode verificar em tempo de execução se uma versão superior do OpenGL ES está disponível.
Para mais informações sobre como usar o OpenGL ES, inclusive como verificar a versão do OpenGL ES compatível em tempo de execução, consulte o guia da API do OpenGL ES.
-
- introduzido na:
- API de nível 4
- veja também:
Google Play e filtros com base em recurso
O Google Play filtra os aplicativos visíveis para os usuários para que eles possam ver e fazer o download somente dos aplicativos compatíveis com os dispositivos. Uma das formas de filtrar aplicativos é por compatibilidade de recursos.
Para determinar a compatibilidade de recursos de um aplicativo com um determinado dispositivo do usuário, o Google Play compara:
- recursos obrigatórios do aplicativo — um aplicativo declara recursos nos elementos
<uses-feature>
no manifesto
com... - recursos disponíveis no dispositivo, em hardware ou software — um dispositivo informa os recursos permitidos como propriedades de sistema somente para leitura.
Para garantir uma comparação precisa de recursos, o Android Package Manager oferece um conjunto de constantes de recursos usados por aplicativos e dispositivos para declarar requisitos e compatibilidade de recursos. As constantes de recursos disponíveis estão listadas nas seções Referência de recursos, na parte inferior deste documento, e na documentação de classe para PackageManager
.
Quando o usuário inicializa o Google Play, o aplicativo consulta o Package Manager para ter a lista de recursos disponíveis no dispositivo chamando getSystemAvailableFeatures()
. O aplicativo Store passa a lista de recursos ao Google Play ao estabelecer a sessão para o usuário.
Cada vez que você fizer upload de um aplicativo para o Google Play Console, o Google Play analisa o arquivo de manifesto do aplicativo. Ele procura elementos <uses-feature>
e, em alguns casos, os avalia juntamente com outros elementos, como elementos <uses-sdk>
e <uses-permission>
. Depois de estabelecer o conjunto de recursos obrigatórios do aplicativo, ele armazena a lista internamente como metadados associados ao .apk
e à versão do aplicativo.
Quando um usuário pesquisa ou navega por aplicativos usando o aplicativo Google Play, o serviço compara os recursos necessários para cada aplicativo com os recursos disponíveis no dispositivo do usuário. Se todos os recursos obrigatórios de um aplicativo estiverem presentes no dispositivo, o Google Play permitirá que o usuário veja esse aplicativo e faça o download dele, se quiser. Se algum recurso obrigatório não for compatível com o dispositivo, o Google Play filtra o aplicativo, impedindo a visualização pelo usuário e o download.
Como os recursos declarados em elementos <uses-feature>
afetam diretamente a forma como o Google Play filtra os aplicativos, é importante entender como o Google Play avalia o manifesto do aplicativo e define o conjunto de recursos obrigatórios. As seções a seguir oferecem mais informações.
Filtros com base em recursos declarados explicitamente
Um recurso declarado explicitamente é um que o aplicativo declara em um elemento <uses-feature>
. A declaração do recurso poderá incluir um atributo android:required=["true" | "false"]
(se você compilar com a API de nível 5 ou posterior), o que permitirá especificar se o aplicativo realmente exige o recurso e não funciona sem ele ("true"
) ou se o aplicativo prefere usar o recurso, se disponível, mas foi projetado para ser executado sem ele ("false"
).
O Google Play processa recursos declarados explicitamente da seguinte forma:
- Se um recurso for explicitamente declarado como obrigatório, o Google Play adicionará o recurso à lista de recursos obrigatórios do aplicativo. Em seguida, filtrará os aplicativos dos usuários com dispositivos que não fornecem esse recurso. Por exemplo:
<uses-feature android:name="android.hardware.camera" android:required="true" />
- Se um recurso for explicitamente declarado como não obrigatório, o Google Play não adicionará o recurso à lista de recursos obrigatórios. Por esse motivo, um recurso declarado explicitamente como não obrigatório nunca é considerado ao filtrar o aplicativo. Mesmo que o dispositivo não ofereça o recurso declarado, o Google Play considerará o aplicativo compatível com o dispositivo e o mostrará ao usuário, a menos que sejam aplicadas outras regras de filtro. Por exemplo:
<uses-feature android:name="android.hardware.camera" android:required="false" />
- Se um recurso for declarado explicitamente, mas sem um atributo
android:required
, o Google Play suporá que o recurso é necessário e configurará o filtro por esse recurso.
Geralmente, se o aplicativo for projetado para executar com o Android 1.6 ou versões anteriores, o atributo android:required
não estará disponível na API e o Google Play suporá que todas as declarações <uses-feature>
são obrigatórias.
Observação: a declaração explicita de um recurso e a inclusão de um atributo android:required="false"
permite desativar eficazmente todos os filtros do Google Play para o recurso especificado.
Filtros com base em recursos implícitos
Recurso implícito é um recurso obrigatório do aplicativo para o funcionamento correto, mas que não é declarado em um elemento <uses-feature>
no arquivo de manifesto. Se formos rigorosos, todos os aplicativos devem sempre declarar todos os recursos usados ou obrigatórios. Portanto, a ausência de uma declaração para um recurso usado por um aplicativo deve ser considerada um erro. No entanto, como proteção para usuários e desenvolvedores, o Google Play procura recursos implícitos em cada aplicativo e define filtros para esses recursos da mesma forma que para um recurso declarado explicitamente.
Um aplicativo pode exigir um recurso, mas não declará-lo, porque:
- o aplicativo foi compilado com uma versão antiga da biblioteca do Android (Android 1.5 ou anterior) e o elemento
<uses-feature>
não estava disponível; - o desenvolvedor supôs incorretamente que o recurso estaria presente em todos os dispositivos e que, portanto, a declaração era desnecessária;
- o desenvolvedor omitiu acidentalmente a declaração do recurso;
- o desenvolvedor declarou o recurso explicitamente, mas a declaração era inválida. Por exemplo, um erro ortográfico no nome do
<uses-feature>
ou um valor de string não reconhecido para o 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 solicitar permissões relacionadas a hardware, o Google Play suporá que o aplicativo usa os recursos de hardware subjacentes e, portanto, exige esses recursos, mesmo que não correspondam a declarações <uses-feature>
. Para essas permissões, o Google Play adiciona os recursos de hardware subjacentes aos metadados armazenados para o aplicativo e define filtros para eles.
Por exemplo: se um aplicativo solicitar a permissão CAMERA
, mas não declarar um elemento <uses-feature>
para android.hardware.camera
, o Google Play considerará que o aplicativo exige uma câmera e não deverá ser mostrado para usuários cujos dispositivos não oferecem câmera.
Se não quiser que o Google Play filtre com base em um recurso implícito específico, você pode desativar esse comportamento. Para fazer isso, declare o recurso explicitamente em um elemento <uses-feature>
e inclua um atributo android:required="false"
. Por exemplo, para desativar o filtro derivado da permissão CAMERA
, declare o recurso como mostrado abaixo.
<uses-feature android:name="android.hardware.camera" android:required="false" />
É importante compreender que as permissões solicitadas nos elementos <uses-permission>
podem afetar diretamente a forma com que o Google Play filtra o aplicativo. A seção de referência Permissões que implicam requisitos de recurso lista o conjunto completo de permissões que sugerem requisitos de recurso e, portanto, acionam os filtros.
Processamento especial para o recurso Bluetooth
Para determinar o filtro para Bluetooth, o Google Play aplica regras ligeiramente diferentes das descritas acima.
Se um aplicativo declarar uma permissão Bluetooth em um elemento <uses-permission>
, mas não declarar explicitamente o recurso Bluetooth em um elemento <uses-feature>
, o Google Play verificará as versões da plataforma Android em que o aplicativo foi projetado para executar, conforme especificado no elemento <uses-sdk>
.
Conforme mostrado na tabela abaixo, o Google Play permite o filtro do recurso Bluetooth somente se o aplicativo declarar sua plataforma mais baixa ou direcionada como Android 2.0 (API de nível 5) ou posterior. Observe, no entanto, que o Google Play aplica as regras normais de filtro quando o aplicativo declara explicitamente o recurso Bluetooth em um elemento <uses-feature>
.
Tabela 1. Como o Google Play determina o requisito de recurso Bluetooth para um aplicativo que seleciona uma permissão Bluetooth, mas não declara o recurso Bluetooth em um elemento <uses-feature>
.
minSdkVersion for... |
targetSdkVersion for |
Resultado |
---|---|---|
<=4 | O Google Play não filtrará o aplicativo de nenhum dispositivo com base nas permissões informadas para o recurso android.hardware.bluetooth . |
|
<=4 | >=5 | O Google Play filtrará o aplicativo de todos os dispositivos que não permitam o recurso android.hardware.bluetooth (inclusive versões anteriores). |
>=5 | >=5 |
Os exemplos abaixo mostram os diferentes efeitos de filtros com base na forma como o Google Play processa o recurso Bluetooth.
- No primeiro exemplo, um aplicativo projetado para executar em APIs de níveis anteriores declara uma permissão Bluetooth, mas não declara o recurso Bluetooth em um elemento
<uses-feature>
. - Resultado: o Google Play não filtra o aplicativo de nenhum dispositivo.
<manifest ...> <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" /> <uses-sdk android:minSdkVersion="3" /> ... </manifest>
- No segundo exemplo, abaixo, o mesmo aplicativo também declara uma API com nível direcionado de “5”.
- Resultado: o Google Play agora supõe que o recurso seja obrigatório e filtra o aplicativo de todos os dispositivos que não informam compatibilidade com Bluetooth, inclusive dispositivos que executam versões anteriores da plataforma.
<manifest ...> <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" /> <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" /> ... </manifest>
- Aqui, o mesmo aplicativo declara especificamente o recurso Bluetooth.
- Resultado: idêntico ao exemplo anterior (o filtro é aplicado).
<manifest ...> <uses-feature android:name="android.hardware.bluetooth" /> <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" /> <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" /> ... </manifest>
- Finalmente, no caso a seguir, o mesmo aplicativo adiciona um atributo
android:required="false"
. - Resultado: o Google Play desativa o filtro com base na compatibilidade do recurso Bluetooth para todos os dispositivos.
<manifest ...> <uses-feature android:name="android.hardware.bluetooth" android:required="false" /> <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" /> <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" /> ... </manifest>
Testar os recursos obrigatórios do aplicativo
Você também pode usar a ferramenta aapt
, incluída no Android SDK, para determinar como o Google Play filtrará o aplicativo, com base nas permissões e nos recursos declarados. Para isso, execute aapt
com o comando dump
badging
. Isso faz com que aapt
analise o manifesto do aplicativo e aplique as mesmas regras usadas pelo Google Play para determinar os recursos exigidos pelo aplicativo.
Para usar a ferramenta, siga estas etapas:
- Primeiro, compile e exporte o aplicativo como um
.apk
não assinado. Se você estiver desenvolvendo no Android Studio, compile o aplicativo com o Gradle:- 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.
- Verifique 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ê estiver usando o SDK Tools r8 ou superior, poderá encontraraapt
no diretório<SDK>/build-tools/<tools version number>
.Observação: você deve usar a versão do
aapt
fornecida para o mais recente componente Build-Tools disponível. Se você não tiver o componente Build-Tools, faça o download usando o Android SDK Manager. - Execute
aapt
usando esta sintaxe:
$ aapt dump badging <path_to_exported_.apk>
Veja a seguir um exemplo da saída do comando para o segundo exemplo de Bluetooth acima:
$ ./aapt dump badging BTExample.apk package: name='com.example.android.btexample' versionCode='' versionName='' uses-permission:'android.permission.BLUETOOTH_ADMIN' uses-feature:'android.hardware.bluetooth' sdkVersion:'3' targetSdkVersion:'5' application: label='BT Example' icon='res/drawable/app_bt_ex.png' launchable activity name='com.example.android.btexample.MyActivity'label='' icon='' uses-feature:'android.hardware.touchscreen' main supports-screens: 'small' 'normal' 'large' locales: '--_--' densities: '160'
Referência de recursos
As seções a seguir oferecem informações de referência sobre recursos de hardware, recursos de software e conjuntos de permissões que implicam requisitos específicos de recurso.
Recursos de hardware
Esta seção apresenta os recursos de hardware permitidos pela versão de plataforma mais atual. Para indicar que o aplicativo usa ou exige um recurso de hardware, declare o valor correspondente (começando com "android.hardware"
) em um atributo android:name
. Sempre que você declarar um recurso de hardware, use um elemento <uses-feature>
separado.
Recursos de hardware de áudio
-
android.hardware.audio.low_latency
- O aplicativo usa o canal de áudio de baixa latência do dispositivo, que reduz demoras e atrasos no processamento de entrada ou saída de som.
-
android.hardware.audio.output
- O aplicativo transmite som usando os alto-falantes, a entrada para fone de ouvido, os recursos de streaming do Bluetooth ou mecanismos semelhantes do dispositivo.
-
android.hardware.audio.pro
- O aplicativo usa a funcionalidade de áudio e os recursos de desempenho avançados do dispositivo.
-
android.hardware.microphone
- O aplicativo grava áudio usando o microfone do dispositivo.
Recursos de hardware do Bluetooth
-
android.hardware.bluetooth
- O aplicativo usa os recursos de Bluetooth do dispositivo. Normalmente, para comunicação com outros dispositivos com Bluetooth ativado.
-
android.hardware.bluetooth_le
- O aplicativo usa os recursos de rádio Low Energy do Bluetooth do dispositivo.
Recursos de hardware da câmera
-
android.hardware.camera
-
O aplicativo usa a câmera traseira do dispositivo. Os dispositivos com somente uma câmera frontal não listam esse recurso. Portanto, em vez disso, use o recurso
android.hardware.camera.any
se o aplicativo puder se comunicar com qualquer câmera, independentemente de sua direção. -
android.hardware.camera.any
-
O aplicativo usa uma das câmeras do dispositivo ou uma câmera externa conectada ao dispositivo pelo usuário. Use esse valor em vez de
android.hardware.camera
se o aplicativo não exigir que a câmera seja a traseira. -
android.hardware.camera.autofocus
-
O aplicativo usa o recurso de foco automático permitido pela câmera do dispositivo.
Ao usar este recurso, um aplicativo implica que também usa o recurso
android.hardware.camera
, a menos que este recurso pai seja declarado comandroid: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 umandroid.colorCorrection.mode
deTRANSFORM_MATRIX
. -
android.hardware.camera.capability.manual_sensor
-
O aplicativo usa o recurso
MANUAL_SENSOR
permitido pela câmera do dispositivo.Esse recurso implica compatibilidade com bloqueio de exposição automática (
android.control.aeLock
), que permite que o tempo e a sensitividade de exposição da câmera fiquem fixos em valores específicos. -
android.hardware.camera.capability.raw
-
O aplicativo usa o recurso
RAW
permitido pela câmera do dispositivo.Este recurso implica que o dispositivo pode salvar arquivos DNG (brutos) e que a câmera do dispositivo informa os metadados relacionados a DNG necessários para que o aplicativo processe diretamente essas imagens brutas.
-
android.hardware.camera.external
- O aplicativo se comunica com uma câmera externa que o usuário conecta ao dispositivo. Esse recurso não garante, no entanto, que a câmera externa esteja disponível para o aplicativo usar.
-
android.hardware.camera.flash
-
O aplicativo usa o recurso de flash permitido pela câmera do dispositivo.
Ao usar este recurso, um aplicativo implica que também usa o recurso
android.hardware.camera
, a menos que este recurso pai seja declarado comandroid: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 comandroid: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 comFULL
oferecem recursos de captura em rajada, controle por frame e controle de pós-processamento manual.
Recursos de hardware da IU do dispositivo
-
android.hardware.type.automotive
-
O aplicativo foi projetado para mostrar sua IU em um conjunto de telas dentro de um veículo. O usuário interage com o aplicativo usando botões físicos, toque, controles giratórios e interfaces semelhantes ao mouse. Normalmente, as telas do veículo aparecem no console central ou no cluster de instrumentos de um veículo. Essas telas normalmente têm tamanho e resolução limitados.
Observação: é importante lembrar que, como o usuário está dirigindo enquanto usa esse tipo de IU de aplicativo, este deve minimizar as distrações do motorista.
-
android.hardware.type.television
-
Obsoleto. Em vez disso, use
android.software.leanback
.O aplicativo foi projetado para mostrar a IU em uma televisão. Esse recurso define “televisão” como uma experiência típica de televisão na sala de estar: exibida em uma tela grande, com o usuário sentado distante, e o formato predominante de entrada é algo como um botão direcional e geralmente sem dispositivos como mouse, ponteiro e telas táteis.
-
android.hardware.type.watch
- O aplicativo foi projetado para mostrar a IU em um relógio de pulso. O relógio é usado no corpo, como no pulso. O usuário fica muito próximo ao dispositivo durante a interação.
Recursos de hardware de impressão digital
-
android.hardware.fingerprint
- O aplicativo lê impressões digitais usando o hardware biométrico do dispositivo.
Recursos de hardware de gamepad
-
android.hardware.gamepad
- O aplicativo captura a entrada do controlador de jogos do próprio dispositivo ou de um gamepad conectado.
Recursos de hardware de infravermelho
-
android.hardware.consumerir
- O aplicativo usa os recursos de infravermelho (IR, na sigla em inglês) do dispositivo, normalmente para comunicação com outros dispositivos IR do consumidor.
Recursos de hardware de localização
-
android.hardware.location
- O aplicativo usa um ou mais recursos do dispositivo para determinar a localização, como localização GPS, localização da rede ou localização celular.
-
android.hardware.location.gps
-
O aplicativo usa coordenadas de localização precisa vindas de um receptor do Sistema de Posicionamento Global (GPS) do dispositivo.
Ao usar este recurso, um aplicativo implica que também usa o recurso
android.hardware.location
, a menos que este recurso pai seja declarado com o atributoandroid:required="false"
. -
android.hardware.location.network
-
O aplicativo usa coordenadas de localização aproximada vindas de um sistema de geolocalização com base em rede compatível com o dispositivo.
Ao usar este recurso, um aplicativo implica que também usa o recurso
android.hardware.location
, a menos que este recurso pai seja declarado com o atributoandroid:required="false"
.
Recursos de hardware de NFC
-
android.hardware.nfc
- O aplicativo usa recursos de rádio de Near-Field Communication (NFC) do dispositivo.
-
android.hardware.nfc.hce
-
O aplicativo usa emulação de cartão NFC hospedada no dispositivo.
Recursos de hardware de OpenGL ES
-
android.hardware.opengles.aep
- O aplicativo usa o OpenGL ES Android Extension Packinstalado no dispositivo.
Recursos de hardware de sensor
-
android.hardware.sensor.accelerometer
- O aplicativo usa leituras de movimento do acelerômetro do dispositivo para detectar a orientação atual do dispositivo. Por exemplo, um aplicativo pode usar leituras do acelerômetro para determinar quando alternar a orientação entre retrato e paisagem.
-
android.hardware.sensor.ambient_temperature
- O aplicativo usa o sensor de temperatura ambiente (ambiental) do dispositivo. Por exemplo, um aplicativo meteorológico pode informar temperaturas internas ou externas.
-
android.hardware.sensor.barometer
- O aplicativo usa o barômetro do dispositivo. Por exemplo, um aplicativo meteorológico pode informar a pressão do ar.
-
android.hardware.sensor.compass
- O aplicativo usa o magnetômetro (bússola) do dispositivo. Por exemplo, um aplicativo de navegação pode mostrar a direção para onde o usuário está voltado no momento.
-
android.hardware.sensor.gyroscope
- O aplicativo usa o giroscópio do dispositivo para detectar a rotação e o giro, criando um sistema de orientação em seis eixos. Usando esse sensor, o aplicativo pode detectar mais suavemente se é necessário alternar entre as orientações de retrato e paisagem.
-
android.hardware.sensor.hifi_sensors
- O aplicativo usa os sensores de alta fidelidade (Hi-Fi) do dispositivo. Por exemplo, um aplicativo de jogos pode detectar os movimentos do usuário com alta precisão.
-
android.hardware.sensor.heartrate
- O aplicativo usa o monitor de frequência cardíaca do dispositivo. Por exemplo, um aplicativo de boa forma pode informar tendências na frequência cardíaca do usuário.
-
android.hardware.sensor.heartrate.ecg
- O aplicativo usa o sensor de frequência cardíaca de eletrocardiograma (ECG) do dispositivo. Por exemplo, um aplicativo de boa forma pode fornecer informações mais detalhadas sobre a taxa cardíaca do usuário.
-
android.hardware.sensor.light
- O aplicativo usa o sensor de luz do dispositivo. Por exemplo, o aplicativo pode exibir um dentre dois esquemas de cores com base nas condições de iluminação ambiente.
-
android.hardware.sensor.proximity
- O aplicativo usa o sensor de proximidade do dispositivo. Por exemplo, um aplicativo de telefonia pode desligar a tela do dispositivo quando detectar que o usuário está mantendo o dispositivo próximo ao corpo.
-
android.hardware.sensor.relative_humidity
- O aplicativo usa o sensor de umidade relativa do dispositivo. Por exemplo, um aplicativo meteorológico pode usar a umidade para calcular e informar o ponto de orvalho atual.
-
android.hardware.sensor.stepcounter
- O aplicativo usa o contador de passos do dispositivo. Por exemplo, um aplicativo de boa forma pode informar o número de passos que um usuário deve dar para alcançar a meta diária de número de passos.
-
android.hardware.sensor.stepdetector
- O aplicativo usa o detector de passos do dispositivo. Por exemplo, um aplicativo de boa forma pode usar o intervalo de tempo entre passos para deduzir o tipo de exercício que o usuário está fazendo.
Recursos de hardware de tela
-
android.hardware.screen.landscape
-
android.hardware.screen.portrait
-
O aplicativo exige que o dispositivo use a orientação de retrato ou paisagem. Se o aplicativo permitir ambas as orientações, você não precisa declarar nenhum dos recursos.
Por exemplo, se o aplicativo exige orientação de retrato, você deve declarar o recurso a seguir para que somente os dispositivos que permitem orientação de retrato (sempre ou mediante escolha do usuário) possam executar o aplicativo:
<uses-feature android:name="android.hardware.screen.portrait" />
O padrão é que nenhuma orientação é obrigatória. Portanto, o aplicativo poderá ser instalado em dispositivos que permitem uma ou ambas as orientações. No entanto, se qualquer uma das atividades solicitar a execução em uma orientação específica, usando o atributo
android:screenOrientation
, essa declaração implicará que o aplicativo exige essa orientação. Por exemplo: se você declararandroid:screenOrientation
com"landscape"
,"reverseLandscape"
ou"sensorLandscape"
, o aplicativo estará disponível somente em dispositivos compatíveis com orientação de paisagem.Como prática recomendada, deve-se usar um elemento
<uses-feature>
para declarar o requisito para essa orientação. Se você declarar uma orientação para a atividade comandroid:screenOrientation
sem que isso seja necessário, 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 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 comandroid: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 comandroid:required="false"
.
Recursos de hardware de tela tátil
-
android.hardware.faketouch
-
O aplicativo usa eventos de interação por toque básicos, como tocar e arrastar.
Quando declarado como obrigatório, esse recurso indica que o aplicativo será compatível com um dispositivo somente se esse dispositivo emular uma touchscreen (“interface de toque simulada”) ou tiver uma touchscreen real.
Dispositivos que oferecem uma interface de toque simulada fornecem um sistema de entrada que emula um subconjunto dos recursos de uma touchscreen. Por exemplo, um mouse ou controle remoto pode acionar um cursor na tela. Se o aplicativo exigir interação básica do tipo apontar e clicar (em outras palavras, não funciona só com um controlador de botão direcional), declare esse recurso. Como esse é o nível mínimo de interação de toque, você pode usar um aplicativo que declara esse recurso em dispositivos que oferecem interfaces de toque mais complexas.
Observação: os aplicativos exigem o recurso
android.hardware.faketouch
por padrão. Se você quiser que o aplicativo seja limitado a dispositivos que só tenham uma touchscreen, é necessário declarar explicitamente essa obrigatoriedade da seguinte forma:<uses-feature android:name="android.hardware.touchscreen" android:required="true" />
Todos os aplicativos que não exigem
android.hardware.touchscreen
explicitamente também funcionarão em dispositivos comandroid.hardware.faketouch
.<uses-feature android:name="android.hardware.touchscreen" android:required="false" />
-
android.hardware.faketouch.multitouch.distinct
-
O aplicativo rastreia dois ou mais “dedos” distintos em uma interface de toque simulada. Esse recurso é um superconjunto do recurso
android.hardware.faketouch
. Quando declarado como obrigatório, esse recurso indica que o aplicativo será compatível com um dispositivo somente se esse dispositivo emular o rastreamento distinto de dois ou mais dedos ou tiver uma touchscreen real.Ao contrário do multitoque distinto definido por
android.hardware.touchscreen.multitouch.distinct
, os dispositivos de entrada que permitem multitoque distinto com uma interface de toque simulada não são compatíveis com todos os gestos de dois dedos porque a entrada é transformada em movimento de cursor na tela. Ou seja, gestos de um único dedo nesse dispositivo movem um cursor, o deslizar de dois dedos faz com que ocorram eventos de toque de um único dedo e outros gestos de dois dedos acionam os eventos correspondentes de toque de dois dedos.Um dispositivo que fornece um trackpad de toque de dois dedos para movimento de cursor pode permitir esse recurso.
-
android.hardware.faketouch.multitouch.jazzhand
-
O aplicativo rastreia cinco ou mais “dedos” distintos em uma interface de toque simulada. Esse recurso é um superconjunto do recurso
android.hardware.faketouch
. Quando declarado como obrigatório, esse recurso indica que o aplicativo será compatível com um dispositivo somente se esse dispositivo emular o rastreamento distinto de cinco ou mais dedos ou tiver uma touchscreen real.Ao contrário do multitoque distinto definido por
android.hardware.touchscreen.multitouch.jazzhand
, os dispositivos de entrada que permitem multitoque “jazzhand” com uma interface de toque simulada não são compatíveis com todos os gestos de cinco dedos porque a entrada é transformada em movimento de cursor na tela. Ou seja, gestos de um único dedo nesse dispositivo movem um cursor, o deslizar de vários dedos faz com que ocorram eventos de toque de um único dedo e outros gestos de vários dedos acionam os eventos correspondentes de toque de vários dedos.Dispositivos que fornecem um trackpad de toque de cinco dedos para movimento de cursor podem permitir esse recurso.
-
android.hardware.touchscreen
-
O aplicativo usa os recursos de tela tátil do dispositivo para gestos mais interativos que os eventos de toque básicos, como uma navegação. Esse recurso é um superconjunto do recurso
android.hardware.faketouch
.Por padrão, o aplicativo exige esse recurso. Portanto, o aplicativo não está disponível para dispositivos que fornecem somente uma interface de toque simulada por padrão. Se quiser que o aplicativo esteja disponível em dispositivos que oferecem uma interface de toque simulada (ou até mesmo em dispositivos que fornecem só um controlador de botão direcional), você deve declarar explicitamente que a touchscreen não é obrigatória, declarando
android.hardware.touchscreen
comandroid:required="false"
. Essa declaração deverá ser adicionada se o aplicativo usar, mas não exigir, uma interface de touchscreen real. Todos os aplicativos que não exigemandroid.hardware.touchscreen
explicitamente também funcionarão em dispositivos comandroid.hardware.faketouch
.Se o aplicativo realmente exigir uma interface tátil (para executar gestos de toque mais avançados, como navegar), você não precisará declarar nenhum recurso de interface de toque porque eles são obrigatórios por padrão. No entanto, é melhor se você declarar explicitamente todos os recursos usados pelo aplicativo.
Se você exigir uma interação de toques mais complexa, como gestos de vários dedos, precisará declarar que o aplicativo usa recursos avançados de touchscreen.
-
android.hardware.touchscreen.multitouch
-
O aplicativo usa os recursos básicos de multitoque de dois pontos do dispositivo, como os gestos de pinça, mas o aplicativo não precisa rastrear os toques de forma independente. Esse recurso é um superconjunto do recurso
android.hardware.touchscreen
.Ao usar este recurso, um aplicativo implica que também usa o recurso
android.hardware.touchscreen
, a menos que este recurso pai seja declarado comandroid: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 comandroid: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 comandroid:required="false"
.
Recursos de hardware USB
-
android.hardware.usb.accessory
- O aplicativo se comporta como dispositivo USB e se conecta a hosts USB.
-
android.hardware.usb.host
- O aplicativo usa acessórios USB conectados ao dispositivo. O dispositivo atua como host USB.
Recursos de hardware Vulkan
-
android.hardware.vulkan.compute
-
O aplicativo usa recursos computacionais Vulkan. Esse recurso indica que o aplicativo exige o hardware de implementação Vulkan acelerado. A versão do recurso indica qual nível de recurso de computação opcional o aplicativo exige além dos requisitos do Vulkan 1.0. Por exemplo, se o aplicativo exigir suporte computacional Vulkan de nível 0, declare o recurso a seguir:
<uses-feature android:name="android.hardware.vulkan.compute" android:version="0" android:required="true" />
ConsulteFEATURE_VULKAN_HARDWARE_COMPUTE
para mais detalhes sobre a versão do recurso. -
android.hardware.vulkan.level
-
O aplicativo usa recursos de nível Vulkan. Esse recurso indica que o aplicativo exige o hardware de implementação Vulkan acelerado. A versão do recurso indica qual nível de recurso de hardware opcional é exigido pelo aplicativo. Por exemplo, se o aplicativo exigir suporte de hardware Vulkan de nível 0, declare o recurso a seguir:
<uses-feature android:name="android.hardware.vulkan.level" android:version="0" android:required="true" />
ConsulteFEATURE_VULKAN_HARDWARE_LEVEL
para mais detalhes sobre a versão do recurso. -
android.hardware.vulkan.version
-
O aplicativo usa o Vulkan. Esse recurso indica que o aplicativo exige o hardware de implementação Vulkan acelerado. A versão do recurso indica a versão mínima do suporte da API Vulkan exigida pelo aplicativo. Por exemplo, se o aplicativo exigir Vulkan de nível 1.0, declare o recurso a seguir:
<uses-feature android:name="android.hardware.vulkan.version" android:version="0x400003" android:required="true" />
ConsulteFEATURE_VULKAN_HARDWARE_VERSION
para mais detalhes sobre a versão do recurso.
Recursos de hardware Wi-Fi
-
android.hardware.wifi
- O aplicativo usa recursos de redes 802.11 (Wi-Fi) do dispositivo.
-
android.hardware.wifi.direct
- O aplicativo usa os recursos de rede Wi-Fi Direct do dispositivo.
Recursos de software
Esta seção apresenta os recursos de software permitidos pela versão de plataforma mais atual. Para indicar que o aplicativo usa ou exige um recurso de software, declare o valor correspondente (começando com "android.software"
) em um atributo android:name
. Sempre que você declarar um recurso de software, use um elemento <uses-feature>
separado.
Recursos de software de comunicação
-
android.software.sip
- O aplicativo usa serviços de Session Initiation Protocol (SIP). O uso de SIP permite que o aplicativo seja compatível com operações de telefonia na internet, como videoconferências e mensagens instantâneas.
-
android.software.sip.voip
-
O aplicativo usa serviços de Voice Over Internet Protocol (VoIP) com base no SIP. O uso de VoIP permite que o aplicativo seja compatível com operações de telefonia na internet em tempo real, como videoconferência bidirecional.
Ao usar este recurso, um aplicativo implica que também usa o recurso
android.software.sip
, a menos que este recurso pai seja declarado comandroid:required="false"
. -
android.software.webview
- O aplicativo exibe conteúdo da internet.
Recursos de software de entrada personalizada
-
android.software.input_methods
-
O aplicativo usa um novo método de entrada, definido pelo desenvolvedor em um
InputMethodService
.
Recursos de software de gerenciamento de dispositivos
-
android.software.backup
- O aplicativo inclui lógica para processar uma operação de backup e restauração.
-
android.software.device_admin
- O aplicativo usa administradores do dispositivo para aplicar uma política do dispositivo.
-
android.software.managed_users
- O aplicativo é compatível com usuários secundários e perfis gerenciados.
-
android.software.securely_removes_users
- O aplicativo pode remover permanentemente usuários e dados associados a eles.
-
android.software.verified_boot
- O aplicativo inclui lógica para processar resultados do recurso de inicialização verificada do dispositivo, que detecta se a configuração do dispositivo muda durante uma operação de reinício.
Recursos de software de mídia
-
android.software.midi
- O aplicativo se conecta a instrumentos musicais ou gera sons usando o protocolo Musical Instrument Digital Interface (MIDI).
-
android.software.print
- O aplicativo inclui comandos para imprimir documentos exibidos no dispositivo.
-
android.software.leanback
- O aplicativo é projetado para execução em dispositivos Android TV.
-
android.software.live_tv
- O aplicativo faz streaming de programas de televisão ao vivo.
Recursos de software de interface de tela
-
android.software.app_widgets
- O aplicativo usa ou fornece widgets de aplicativo e deve ser instalado somente em dispositivos que incluem uma tela inicial ou localização similar onde os usuários podem incorporar widgets de aplicativo.
-
android.software.home_screen
- O aplicativo se comporta como uma substituição da tela inicial do dispositivo.
-
android.software.live_wallpaper
- O aplicativo usa ou fornece planos de fundo que incluem animação.
Permissões que implicam requisitos de recursos
Algumas constantes de recurso de hardware e software foram disponibilizadas a aplicativos depois da API correspondente. Por exemplo, o recurso android.hardware.bluetooth
foi adicionado no Android 2.2 (API de nível 8), mas a API Bluetooth que ele referencia foi adicionada no Android 2.0 (API de nível 5). Por isso, alguns aplicativos puderam usar a API antes de poder declarar que exigem a API usando o sistema <uses-feature>
.
Para evitar que esses aplicativos sejam disponibilizados acidentalmente, o Google Play supõe que algumas permissões relacionadas a hardware indicam que os recursos subjacentes de hardware são obrigatórios por padrão. Por exemplo, aplicativos que usam Bluetooth devem solicitar a permissão BLUETOOTH
em um elemento <uses-permission>
. Em aplicativos legados, o Google Play supõe que a declaração de permissão significa que o recurso android.hardware.bluetooth
subjacente é exigido pelo aplicativo e define o filtro de acordo com esse recurso. A tabela 2 lista as permissões que implicam requisitos de recurso equivalentes às declaradas em elementos <uses-feature>
.
As declarações <uses-feature>
, incluindo todos os atributos android:required
declarados, sempre têm precedência sobre recursos implícitos pelas permissões na tabela 2. Em qualquer uma dessas permissões, você pode desativar o filtro de acordo com o recurso implícito, declarando explicitamente o recurso implícito em um elemento <uses-feature>
com um atributo android:required="false"
. Por exemplo, para desativar todos os filtros com base na permissão CAMERA
, adicione esta declaração <uses-feature>
ao arquivo de manifesto:
<uses-feature android:name="android.hardware.camera" android:required="false" />
Atenção: se seu aplicativo for direcionado ao Android 5.0 (API de nível 21) ou superior e usa a permissão ACCESS_COARSE_LOCATION
ou ACCESS_FINE_LOCATION
para receber atualizações de locais da rede ou de um GPS, respectivamente, também será necessário declarar explicitamente que o aplicativo usa os recursos de hardware android.hardware.location.network
ou android.hardware.location.gps
.
Tabela 2. Permissões de dispositivo que implicam o uso de hardware do dispositivo.
Categoria | Esta permissão... | ... implica este requisito de recurso. |
---|---|---|
Bluetooth | BLUETOOTH |
android.hardware.bluetooth
Consulte Processamento especial para o recurso Bluetooth para mais detalhes. |
BLUETOOTH_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 |
|
|
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 |