O Google Play usa os elementos <uses-feature>
declarados no manifesto do app para fazer um filtro que mostre seu app em dispositivos
que não cumprem os 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 conferir informações importantes sobre como o Google Play usa recursos como base para filtragem, consulte a seção Google Play e filtros com base em recurso.
- Sintaxe:
-
<uses-feature android:name="string" android:required=["true" | "false"] android:glEsVersion="integer" />
- contido em:
<manifest>
- descrição:
Declara um único recurso de hardware ou software usado pelo aplicativo.
O propósito de uma declaração
<uses-feature>
é informar a todas as entidades externas sobre o conjunto de recursos de hardware e software de que o aplicativo depende. O elemento oferece um atributorequired
que possibilita especificar se o aplicativo exige e não funciona sem o recurso declarado ou se prefere ter o recurso, mas pode funcionar sem ele.Como o suporte para recursos pode variar nos dispositivos Android, o elemento
<uses-feature>
desempenha um papel importante, permitindo que o aplicativo descreva os recursos necessários que variam entre dispositivos.O conjunto de recursos disponíveis declarados pelo aplicativo corresponde ao conjunto de constantes de recurso disponibilizado pelo
PackageManager
do Android. As constantes de recursos estão listadas na seção Referência de recursos deste documento.Você precisa especificar cada recurso em um elemento
<uses-feature>
separado. Portanto, se o aplicativo exigir vários recursos, ele precisará declarar vários elementos<uses-feature>
. Por exemplo, um aplicativo que exige recursos de Bluetooth e câmera no dispositivo precisa declarar estes dois elementos:<uses-feature android:name="android.hardware.bluetooth" android:required="true" /> <uses-feature android:name="android.hardware.camera.any" android:required="true" />
Em geral, sempre declare elementos
<uses-feature>
para todos os recursos obrigatórios do aplicativo.Elementos
<uses-feature>
declarados são somente para informação, o que significa que o próprio sistema Android não verifica o suporte ao recurso correspondente no dispositivo antes de instalar um aplicativo.No entanto, outros serviços (como o Google Play) ou aplicativos podem verificar as declarações
<uses-feature>
do aplicativo como parte do processamento ou da interação dele. Por esse motivo, é muito importante declarar todos os recursos usados pelo aplicativo.Em alguns casos, pode haver um atributo específico que permite definir uma versão do recurso, como a versão do OpenGL usada (declarada com
glEsVersion
). Outros recursos que existem ou não em um dispositivo, como uma câmera, são declarados usando o atributoname
.Embora o elemento
<uses-feature>
seja ativado apenas para dispositivos com o nível 4 da API ou mais recente, inclua esses elementos em todos os aplicativos, mesmo se aminSdkVersion
for 3 ou anterior. Os dispositivos com versões anteriores da plataforma ignoram o elemento.Observação: ao declarar um recurso, você também precisa solicitar as permissões adequadas. Por exemplo, é necessário solicitar a permissão
CAMERA
antes que o aplicativo possa acessar a API da câmera. A solicitação da permissão concede ao seu aplicativo acesso ao hardware e software adequados. A declaração dos recursos usados pelo aplicativo ajuda a garantir a compatibilidade de dispositivo correta.- atributos:
-
-
android:name
- Especifica um único recurso de hardware ou software usado pelo aplicativo como uma string do descritor. Os valores de atributo válidos são listados nas seções Recursos de hardware e Recursos de software. Esses valores de atributo diferenciam minúsculas de maiúsculas.
-
android:required
-
Valor booleano que indica se o aplicativo exige o recurso
especificado no
android:name
.- Declarar
android:required="true"
em um recurso indica que o aplicativo não funciona ou não foi projetado para funcionar quando o recurso especificado não está presente no dispositivo. - Declarar
android:required="false"
em um recurso indica que o aplicativo usa o recurso quando ele está presente no dispositivo, mas que foi projetado para funcionar sem o recurso especificado, se necessário.
O valor padrão de
android:required
é"true"
. - 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 a versão 2.0 do OpenGL ES, defina o valor como
"0x00020000". Para especificar o OpenGL ES 3.2, defina o valor como "0x00030002".
Um aplicativo especifica no máximo um atributo
android:glEsVersion
no manifesto. Se mais de um atributo é especificado, 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 a todos os dispositivos com Android.Um aplicativo pode supor que, se uma plataforma oferece suporte para determinada versão do OpenGL ES, ela também oferece para todas as versões do OpenGL ES numericamente menores. Portanto, um aplicativo que exige o OpenGL ES 1.0 e 2.0 especifica que exige o OpenGL ES 2.0.
Um aplicativo que pode trabalhar com diversas versões do OpenGL ES especifica apenas a versão numericamente menor do OpenGL ES necessária. Ele pode verificar no momento da execução se uma versão mais recente do OpenGL ES está disponível.
Para mais informações sobre como usar o OpenGL ES, inclusive como conferir a versão compatível no momento da execução, consulte o guia da API do OpenGL ES.
-
- introduzido em:
- Nível 4 da API
- veja também:
Google Play e filtros com base em recurso
O Google Play filtra os aplicativos que ficam visíveis para os usuários, para que eles possam ver e fazer o download apenas dos apps compatíveis com os dispositivos deles. Uma das formas de filtrar aplicativos é pela compatibilidade de recursos.
Para determinar a compatibilidade de recursos de um aplicativo com determinado dispositivo do usuário, o Google Play compara:
- recursos exigidos pelo aplicativo, conforme declarado nos elementos
<uses-feature>
no manifesto do aplicativo; - recursos disponíveis no dispositivo, em hardware ou software, conforme relatado usando propriedades de sistema somente para leitura.
Para comparar os recursos de forma precisa, o gerenciador de pacotes do Android
oferece um conjunto de constantes de recursos usados por aplicativos e dispositivos
para declarar requisitos e suporte de recursos. As constantes de recursos disponíveis
estão listadas na seção Referência de recursos
deste documento e na documentação de classe para o
PackageManager
.
Quando o usuário inicializa o Google Play, o aplicativo consulta o
gerenciador de pacotes para ver a lista de recursos disponíveis no dispositivo chamando
getSystemAvailableFeatures()
. O
aplicativo Store passa a lista de recursos para o Google Play
ao estabelecer a sessão para o usuário.
Cada vez que você faz upload de um aplicativo para o Google Play Console,
o Google Play analisa o arquivo de manifesto do aplicativo. Ele procura
elementos <uses-feature>
e, em alguns casos, os avalia
em conjunto com outros elementos, como <uses-sdk>
e
<uses-permission>
. Após estabelecer o
conjunto de recursos obrigatórios do aplicativo, ele armazena a lista internamente como
metadados associados ao APK e à versão
do aplicativo.
Quando um usuário pesquisa ou navega por aplicativos usando o Google Play, o serviço compara os recursos necessários para cada aplicativo com os recursos disponíveis no dispositivo do usuário. Se todos os recursos obrigatórios estão presentes no dispositivo, o Google Play permite que o usuário veja e faça o download desse aplicativo, se quiser.
Se o dispositivo não oferece suporte a algum recurso obrigatório, o Google Play faz uma filtragem para mostrar o aplicativo, impedindo a visualização e o download.
Como os recursos declarados em elementos
<uses-feature>
afetam diretamente a forma como o Google Play filtra os aplicativos, é importante entender como o Google Play avalia o manifesto do aplicativo
e define o conjunto de recursos obrigatórios. Confira mais informações nas seções
a seguir.
Filtros com base em recursos declarados explicitamente
Um recurso declarado explicitamente é um que o aplicativo declara em um
elemento <uses-feature>
. A declaração do recurso pode incluir
um atributo android:required=["true" | "false"]
se você estiver
compilando com uma API de nível 5 ou mais recente.
Isso permite especificar se o
aplicativo exige o recurso e não funciona corretamente sem
ele ("true"
) ou se usa o recurso
quando disponível, mas foi projetado para ser executado sem ele ("false"
).
O Google Play processa recursos declarados explicitamente da seguinte forma:
- Se um recurso é declarado explicitamente como obrigatório, como mostrado no exemplo
a seguir, o Google Play o adiciona
à lista de recursos obrigatórios do aplicativo. Em seguida,
ele filtra os aplicativos dos usuários com dispositivos que não fornecem esse recurso.
<uses-feature android:name="android.hardware.camera.any" android:required="true" />
- Se um recurso é explicitamente declarado como não obrigatório, conforme mostrado no
exemplo a seguir, o Google
Play não o adiciona à lista de recursos obrigatórios. Por
esse motivo, um recurso declarado explicitamente como não obrigatório nunca é considerado
ao filtrar o aplicativo. Mesmo que o dispositivo não ofereça o recurso
declarado, o Google Play considera o aplicativo compatível com o
dispositivo e o mostra ao usuário, a menos que sejam aplicadas outras regras de filtro.
<uses-feature android:name="android.hardware.camera" android:required="false" />
- Se um recurso é declarado explicitamente, mas sem um
atributo
android:required
, o Google Play supõe que ele é obrigatório e configura o filtro para esse recurso.
Em geral, se o aplicativo é projetado para ser executado no Android 1.6 e versões anteriores,
o atributo android:required
não fica disponível na
API, e o Google Play supõe que todas as
declarações <uses-feature>
são obrigatórias.
Observação: ao declarar um recurso explicitamente e
incluir um atributo android:required="false"
, você pode
desativar toda a filtragem do recurso especificado no Google Play.
Filtrar com base em recursos implícitos
Recurso implícito é um recurso necessário para o aplicativo
funcionar corretamente, mas que não é declarado em um
elemento <uses-feature>
no arquivo de manifesto. Rigorosamente,
é melhor que todos os aplicativos sempre declarem todos os recursos
usados ou exigidos. Além disso, a ausência de uma declaração para um recurso usado por um
aplicativo pode ser considerada um erro.
No entanto, como proteção para usuários e desenvolvedores, o Google Play procura recursos implícitos em cada aplicativo e define filtros para eles da mesma forma que para recursos declarados explicitamente.
Um aplicativo pode exigir um recurso, mas não declará-lo, por motivos como:
- o aplicativo foi compilado com uma versão antiga da biblioteca Android
(Android 1.5 ou anterior), para a qual o elemento
<uses-feature>
não estava disponível; - o desenvolvedor presume incorretamente que o recurso está presente em todos os dispositivos e que uma declaração é desnecessária;
- o desenvolvedor omite acidentalmente a declaração do recurso;
- o desenvolvedor declara o recurso explicitamente, mas a declaração não é
válida. Por exemplo, um erro ortográfico no nome do elemento
<uses-feature>
ou um valor de string não reconhecido para o atributoandroid:name
invalida a declaração do recurso.
Para considerar esses casos, o Google Play tenta descobrir os
requisitos de recurso implícitos de um aplicativo examinando os outros elementos
declarados no arquivo de manifesto, mais especificamente
os elementos <uses-permission>
.
Se um aplicativo solicita permissões relacionadas a hardware, o Google Play
supõe que o aplicativo usa os recursos de hardware implícitos e,
portanto, exige esses recursos, mesmo que não
existam declarações <uses-feature>
correspondentes. Para essas
permissões, o Google Play adiciona os recursos de hardware implícitos aos
metadados armazenados para o aplicativo e define filtros para eles.
Por exemplo, se um app solicita a permissão CAMERA
,
o Google Play presume que o aplicativo exige uma câmera traseira, mesmo
que o app não declare um elemento <uses-feature>
para
android.hardware.camera
. Como resultado, o Google Play filtra dispositivos
que não têm uma câmera traseira.
Se você não quer que o Google Play filtre com base em um recurso implícito
específico, declare explicitamente o recurso em um elemento <uses-feature>
e inclua o atributo android:required="false"
. Por
exemplo, para desativar o filtro implícito na permissão CAMERA
,
declare os seguintes recursos:
<uses-feature android:name="android.hardware.camera" android:required="false" /> <uses-feature android:name="android.hardware.camera.autofocus" android:required="false" />
Cuidado: permissões solicitadas em elementos
<uses-permission>
podem afetar diretamente a forma como o Google Play
filtra o aplicativo. A seção
Permissões que implicam requisitos de recurso lista as
permissões que sugerem requisitos de recurso implicitamente e, portanto, acionam os
filtros.
Processamento especial para o recurso Bluetooth
Para determinar o filtro para Bluetooth, o Google Play aplica regras ligeiramente diferentes das descritas no exemplo anterior.
Se um aplicativo declara uma permissão Bluetooth em um
elemento <uses-permission>
, mas não declara explicitamente
o recurso Bluetooth em um elemento <uses-feature>
, o Google
Play confere as versões da plataforma Android em que o aplicativo foi
projetado para ser executado, conforme especificado no elemento <uses-sdk>
.
Como mostrado na tabela a seguir, o Google Play permite a filtragem do
recurso Bluetooth apenas quando o aplicativo declara a plataforma mais baixa ou uma plataforma
direcionada para o Android 2.0 (API de nível 5) ou mais recente. No entanto, o Google
Play aplica as regras normais de filtro quando o aplicativo declara explicitamente
o recurso Bluetooth em um elemento <uses-feature>
.
Tabela 1. Como o Google Play determina o
requisito do recurso Bluetooth para um aplicativo que seleciona uma permissão
Bluetooth, mas não declara esse recurso em um
elemento <uses-feature>
.
minSdkVersion for ... |
targetSdkVersion for |
Resultado |
---|---|---|
<uses-sdk> não serão declarados |
<=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 o recurso android.hardware.bluetooth , incluindo
versões anteriores. |
>=5 | >=5 |
Os exemplos a seguir mostram os diferentes efeitos de filtros com base na forma como o Google Play gerencia o recurso Bluetooth.
-
No primeiro exemplo, um aplicativo projetado para ser executado em APIs de níveis anteriores
declara uma permissão Bluetooth, mas não declara o recurso em um
elemento
- Resultado: o Google Play não filtra o aplicativo de nenhum dispositivo.
<uses-feature>
.
<manifest ...> <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" /> <uses-sdk android:minSdkVersion="3" /> ... </manifest>
-
No segundo exemplo, o mesmo aplicativo também declara uma
API de nível "5".
- Resultado:o Google Play agora supõe que o recurso é obrigatório e filtra o aplicativo de todos os dispositivos que não relatam compatibilidade com Bluetooth, incluindo dispositivos que executam versões mais antigas 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 uma
- Resultado:o Google Play desativa o filtro por Bluetooth suporte a recursos para todos os dispositivos.
android:required="false"
.
<manifest ...> <uses-feature android:name="android.hardware.bluetooth" android:required="false" /> <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" /> <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" /> ... </manifest>
Testar os recursos obrigatórios do aplicativo
Você pode usar a ferramenta aapt2
, incluída no SDK do Android, para
determinar como o Google Play filtra o aplicativo com base nos recursos
e permissões declarados. Para fazer isso, execute aapt2
com o comando dump
badging
. Isso faz com que aapt2
analise o
manifesto do aplicativo e aplique as mesmas regras usadas pelo Google Play para
determinar os recursos exigidos pelo aplicativo.
Para usar a ferramenta, siga estas etapas:
- Crie e exporte o aplicativo como um APK não assinado.
Se você estiver desenvolvendo no Android Studio, crie o aplicativo com o Gradle, da seguinte maneira:
- 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.
- Digite "Unsigned APK" em Name.
- Escolha o módulo na seção Gradle project.
- Digite "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'.
<ProjectName>/app/build/outputs/apk/
. - Localize a ferramenta
aapt2
, se ela ainda não estiver no seu PATH. Se você está usando as Ferramentas do SDK r8 ou mais recentes, pode encontraraapt2
no diretório<SDK>/build-tools/<tools version number>
.Observação: é necessário usar a versão do
aapt2
fornecida para o mais recente componente Build-Tools disponível. Se você não tiver o componente Build-Tools, faça o download dele usando o Android SDK Manager. - Execute
aapt2
usando esta sintaxe:
$ aapt2 dump badging <path_to_exported_.apk>
Confira uma resposta ao comando para o segundo exemplo de Bluetooth mostrado anteriormente:
$ ./aapt2 dump badging BTExample.apk package: name='com.example.android.btexample' versionCode='' versionName='' uses-permission:'android.permission.BLUETOOTH_ADMIN' uses-feature:'android.hardware.bluetooth' sdkVersion:'3' targetSdkVersion:'5' application: label='BT Example' icon='res/drawable/app_bt_ex.png' launchable activity name='com.example.android.btexample.MyActivity'label='' icon='' uses-feature:'android.hardware.touchscreen' main supports-screens: 'small' 'normal' 'large' locales: '--_--' densities: '160'
Referência de recursos
As seções a seguir oferecem informações de referência sobre recursos de hardware, de software e conjuntos de permissões que implicam requisitos específicos de recurso.
Recursos de hardware
Esta seção apresenta os recursos de hardware permitidos pela versão mais
atual da plataforma. Para indicar que o app usa ou exige um recurso de hardware,
declare o valor correspondente, começando com
"android.hardware"
, em um atributo android:name
.
Sempre que você declarar um recurso de hardware, use um elemento
<uses-feature>
separado.
Recursos de hardware de áudio
-
android.hardware.audio.low_latency
- O app usa o canal de áudio de baixa latência do dispositivo, que reduz demoras e atrasos no processamento de entrada ou saída de som.
-
android.hardware.audio.output
- O app transmite som usando os alto-falantes, a entrada para fone de ouvido, os recursos de streaming do Bluetooth ou mecanismos semelhantes do dispositivo.
-
android.hardware.audio.pro
- O app usa a funcionalidade de áudio sofisticada e os recursos de desempenho avançados do dispositivo.
-
android.hardware.microphone
- O app grava áudio usando o microfone do dispositivo.
Recursos de hardware do Bluetooth
-
android.hardware.bluetooth
- O app usa os recursos de Bluetooth do dispositivo. Normalmente, para comunicação com outros dispositivos com o Bluetooth ativado.
-
android.hardware.bluetooth_le
- O app usa os recursos de rádio Bluetooth de baixa energia do dispositivo.
Recursos de hardware da câmera
Observação: para evitar a filtragem desnecessária do app pelo
Google Play, adicione android:required="false"
a qualquer recurso de câmera
que o app possa funcionar sem. Caso contrário, o Google Play presume que o recurso é
obrigatório e impede que dispositivos sem suporte para o recurso acessem seu
app.
Suporte a telas grandes
Alguns dispositivos de tela grande não oferecem suporte para todos os recursos da câmera. Os Chromebooks geralmente não têm câmeras traseiras, autofoco ou flash. Porém, os Chromebooks têm câmeras frontais e geralmente estão conectados a câmeras externas.
Para oferecer suporte básico a câmeras e disponibilizar seu app para o maior número possível de dispositivos, adicione estas configurações de recursos da câmera ao manifesto do app:
<uses-feature android:name="android.hardware.camera.any" android:required="false" /> <uses-feature android:name="android.hardware.camera" android:required="false" /> <uses-feature android:name="android.hardware.camera.autofocus" android:required="false" /> <uses-feature android:name="android.hardware.camera.flash" android:required="false" />
Ajuste as configurações do recurso para oferecer suporte aos casos de uso do seu app. No entanto, para disponibilizar
o app para o maior número de dispositivos possível, sempre inclua o
atributo required
para especificar explicitamente se um recurso é
obrigatório.
Lista de recursos
-
android.hardware.camera.any
-
O app usa uma das câmeras do dispositivo ou uma câmera externa conectada ao dispositivo. Use esse recurso em vez de
android.hardware.camera
ouandroid.hardware.camera.front
se o app não exigir que a câmera seja traseira ou frontal, respectivamente.A permissão
CAMERA
implica que o app também usaandroid.hardware.camera
. A câmera traseira é um recurso necessário, a menos queandroid.hardware.camera
seja declarado comandroid:required="false"
. -
android.hardware.camera
-
O app usa a câmera traseira do dispositivo.
Atenção: dispositivos como os Chromebooks, que têm apenas câmera frontal, não oferecem suporte a esse recurso. Use
android.hardware.camera.any
se o app puder usar qualquer câmera, seja qual for a direção dela.Observação: a permissão
CAMERA
implica que a câmera traseira é um recurso necessário. Para ajudar a garantir a filtragem adequada no Google Play quando o manifesto do app incluir a permissãoCAMERA
, especifique explicitamente que o app usa o recursocamera
e indique se ele é obrigatório, como:
<uses-feature android:name="android.hardware.camera" android:required="false" />
-
android.hardware.camera.front
-
O app usa a câmera frontal do dispositivo.
A permissão
CAMERA
implica que o app também usaandroid.hardware.camera
. A câmera traseira é um recurso necessário, a menos queandroid.hardware.camera
seja declarado comandroid:required="false"
.Atenção: caso o app use
android.hardware.camera.front
, mas não declare explicitamenteandroid.hardware.camera
comandroid.required="false"
, dispositivos que não têm câmera traseira (como os Chromebooks) são filtrados pelo Google Play. Se o app oferece suporte a dispositivos que têm apenas câmeras frontais, declareandroid.hardware.camera
comandroid.required="false"
para evitar filtros desnecessários. -
android.hardware.camera.external
-
O app se comunica com uma câmera externa que o usuário conecta ao dispositivo. Esse recurso não garante que uma câmera externa esteja disponível para o app usar.
A permissão
CAMERA
implica que o app também usaandroid.hardware.camera
. A câmera traseira é um recurso necessário, a menos queandroid.hardware.camera
seja declarado comandroid:required="false"
. -
android.hardware.camera.autofocus
-
O app usa o recurso de autofoco com suporte da câmera do dispositivo.
Observação: a permissão
CAMERA
implica que o autofoco é um recurso obrigatório. Para garantir a filtragem adequada no Google Play quando o manifesto do app incluir a permissãoCAMERA
, especifique explicitamente que o app usa o recurso de autofoco e indique se ele é obrigatório ou não. Por exemplo:
<uses-feature android:name="android.hardware.camera.autofocus" android:required="false" />
. -
android.hardware.camera.flash
-
O app usa o recurso de flash com suporte da câmera do dispositivo.
-
android.hardware.camera.capability.manual_post_processing
-
O app usa o recurso
MANUAL_POST_PROCESSING
permitido pela câmera do dispositivo.Esse recurso permite que o app substitua a funcionalidade de balanço automático de branco da câmera. Use
android.colorCorrection.transform
,android.colorCorrection.gains
e umandroid.colorCorrection.mode
deTRANSFORM_MATRIX
. -
android.hardware.camera.capability.manual_sensor
-
O app usa o recurso
MANUAL_SENSOR
com suporte da câmera do dispositivo.Esse recurso implica suporte ao bloqueio de exposição automática (
android.control.aeLock
), que permite que o tempo e a sensibilidade de exposição da câmera fiquem fixos em valores específicos. -
android.hardware.camera.capability.raw
-
O app usa o recurso
RAW
permitido pela câmera do dispositivo.Esse recurso implica que o dispositivo pode salvar arquivos DNG (brutos). A câmera do dispositivo informa os metadados relacionados a DNG necessários para que o app processe diretamente as imagens brutas.
-
android.hardware.camera.level.full
-
O app usa o nível
FULL
de suporte a captura de imagem fornecido por pelo menos uma das câmeras do dispositivo. O suporte aFULL
inclui recursos de captura em sequência, controle por frame e controle manual pós-processamento. ConsulteINFO_SUPPORTED_HARDWARE_LEVEL_FULL
.
Recursos de hardware da IU do dispositivo
-
android.hardware.type.automotive
-
O aplicativo foi projetado para mostrar sua IU em um conjunto de telas dentro de um veículo. O usuário interage com o app usando botões físicos, toque, controles giratórios e interfaces parecidas com um mouse. Normalmente, as telas do veículo aparecem no console central ou no painel de instrumentos de um veículo. Essas telas normalmente têm tamanho e resolução limitados.
Observação: como o usuário está dirigindo enquanto usa esse tipo de interface 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 interface em uma televisão. Esse recurso define "televisão" como uma experiência típica de televisão na sala de estar: o app espelhado em uma tela grande, com o usuário sentado a certa distância, e o formato predominante de entrada é algo como um botão direcional em vez de um mouse, ponteiro ou tela touchscreen.
-
android.hardware.type.watch
- O app foi projetado para mostrar a interface em um relógio de pulso. O relógio é usado no corpo, como no pulso. O usuário fica muito próximo ao dispositivo durante a interação.
-
android.hardware.type.pc
-
O app foi projetado para mostrar a interface em Chromebooks. Esse recurso desativa a emulação de entrada para mouse e touchpad, já que os Chromebooks usam esses acessórios em hardware. Consulte Entrada do mouse.
Observação: defina
required="false"
para esse elemento. Caso contrário, a Google Play Store vai deixar seu app indisponível para dispositivos que não sejam Chromebooks.
Recursos de hardware de impressão digital
-
android.hardware.fingerprint
- O app lê impressões digitais usando o hardware biométrico do dispositivo.
Recursos de hardware de gamepad
-
android.hardware.gamepad
- O app captura a entrada do controle de jogo do próprio dispositivo ou de um gamepad conectado.
Recursos de hardware de infravermelho
-
android.hardware.consumerir
- O app usa os recursos de infravermelho (IR, na sigla em inglês) do dispositivo, normalmente para comunicação com outros dispositivos IR do consumidor.
Recursos de hardware de localização
-
android.hardware.location
- O app usa um ou mais recursos do dispositivo para determinar a localização, como a localização por GPS, da rede ou do celular.
-
android.hardware.location.gps
-
O app usa coordenadas de localização precisa vindas de um receptor do Sistema de Posicionamento Global (GPS) do dispositivo.
Ao usar esse recurso, o app implica que também usa o recurso
android.hardware.location
, a menos que o recurso pai seja declarado com o 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 o 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) do dispositivo.
-
android.hardware.nfc.hce
-
O aplicativo usa emulação de cartão NFC hospedada no dispositivo.
Recursos de hardware de OpenGL ES
-
android.hardware.opengles.aep
- O app usa o pacote de extensões para Android do OpenGL ES instalado no dispositivo.
Recursos de hardware de sensor
-
android.hardware.sensor.accelerometer
- O app usa leituras de movimento do acelerômetro do dispositivo para detectar a orientação atual do dispositivo. Por exemplo, um app pode usar leituras do acelerômetro para determinar quando alternar a orientação entre retrato e paisagem.
-
android.hardware.sensor.ambient_temperature
- O app usa o sensor de temperatura ambiente (ambiental) do dispositivo. Por exemplo, um app meteorológico pode informar temperaturas internas ou externas.
-
android.hardware.sensor.barometer
- O app usa o barômetro do dispositivo. Por exemplo, um app meteorológico pode informar a pressão do ar.
-
android.hardware.sensor.compass
- O app usa o magnetômetro (bússola) do dispositivo. Por exemplo, um app de navegação pode mostrar a direção para onde o usuário está voltado no momento.
-
android.hardware.sensor.gyroscope
- O app usa o giroscópio do dispositivo para detectar a rotação e o giro, criando um sistema de orientação em seis eixos. Usando esse sensor, o app pode detectar mais facilmente se é necessário alternar entre as orientações de retrato e paisagem.
-
android.hardware.sensor.hifi_sensors
- O app usa os sensores de alta fidelidade (Hi-Fi) do dispositivo. Por exemplo, um app de jogo pode detectar os movimentos do usuário com alta precisão.
-
android.hardware.sensor.heartrate
- O app usa o monitor de frequência cardíaca do dispositivo. Por exemplo, um app fitness pode informar tendências na frequência cardíaca do usuário.
-
android.hardware.sensor.heartrate.ecg
- O app usa o sensor de frequência cardíaca de eletrocardiograma (ECG) do dispositivo. Por exemplo, um app fitness pode mostrar informações mais detalhadas sobre a frequência cardíaca do usuário.
-
android.hardware.sensor.light
- O app usa o sensor de luz do dispositivo. Por exemplo, um app pode mostrar um de dois esquemas de cores com base nas condições de iluminação do ambiente.
-
android.hardware.sensor.proximity
- O app usa o sensor de proximidade do dispositivo. Por exemplo, um app de telefonia pode desligar a tela do dispositivo quando detectar que o usuário está mantendo o dispositivo próximo ao corpo.
-
android.hardware.sensor.relative_humidity
- O app usa o sensor de umidade relativa do dispositivo. Por exemplo, um app meteorológico pode usar a umidade para calcular e informar o ponto de orvalho atual.
-
android.hardware.sensor.stepcounter
- O app usa o contador de passos do dispositivo. Por exemplo, um app fitness pode informar o número de passos que um usuário precisa dar para alcançar a meta de passos diária.
-
android.hardware.sensor.stepdetector
- O app usa o detector de passos do dispositivo. Por exemplo, um app fitness pode usar o intervalo de tempo entre passos para deduzir o tipo de exercício que o usuário está fazendo.
Recursos de hardware de tela
-
android.hardware.screen.landscape
-
android.hardware.screen.portrait
-
O aplicativo exige que o dispositivo use a orientação de retrato ou paisagem. Se o app oferece suporte para ambas as orientações, você não precisa declarar nenhum dos recursos.
Por exemplo, se o app exige a orientação retrato, você precisa declarar o recurso abaixo para que apenas os dispositivos com suporte a essa orientação (sempre ou mediante escolha do usuário) possam executar o app:
<uses-feature android:name="android.hardware.screen.portrait" />
Por padrão, nenhuma orientação é obrigatória. Portanto, o app pode ser instalado em dispositivos que aceitam as orientações ou uma delas. No entanto, se qualquer uma das atividades solicita a execução em uma orientação específica, usando o atributo
android:screenOrientation
, essa declaração implica que o app exige essa orientação.Por exemplo: se você declarar
android:screenOrientation
com"landscape"
,"reverseLandscape"
ou"sensorLandscape"
, o app ficará disponível apenas em dispositivos com suporte à orientação de paisagem.Como prática recomendada, use um elemento
<uses-feature>
para declarar o requisito para essa orientação. Se você declara uma orientação para a atividade usandoandroid:screenOrientation
sem que isso seja necessário, pode 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 versão anterior oferecem suporte para as orientações de paisagem e retrato.
Recursos de hardware de telefonia
-
android.hardware.telephony
- O app usa os recursos de telefonia do dispositivo, como radiotelefonia, com serviços de comunicação de dados.
-
android.hardware.telephony.cdma
-
O app usa o sistema de radiotelefonia Code Division Multiple Access (CDMA).
Ao usar esse recurso, o app implica que também usa o recurso
android.hardware.telephony
, a menos que este recurso pai seja declarado 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 oferece suporte a um dispositivo apenas se esse dispositivo emula uma tela touchscreen "simulada" ou uma tela touchscreen real.
Dispositivos que oferecem uma interface de toque simulada fornecem um sistema de entrada do usuário que emula um subconjunto dos recursos de uma tela touchscreen. Por exemplo, um mouse ou controle remoto pode acionar um cursor na tela.
Se o app exige interação básica do tipo apontar e clicar e não funciona somente com um controlador D-pad, declare esse recurso. Como esse é o nível mínimo de interação de toque, você pode usar um app que declara esse recurso em dispositivos que oferecem interfaces de toque mais complexas.
Os apps exigem o recurso
android.hardware.faketouch
por padrão. Se você quer que o app seja limitado a dispositivos que só tenham uma tela touchscreen, é necessário declarar explicitamente essa obrigatoriedade da seguinte forma:<uses-feature android:name="android.hardware.touchscreen" android:required="true" />
Todos os apps que não exigem
android.hardware.touchscreen
explicitamente, como mostrado no exemplo a seguir, também funcionam em dispositivos 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 oferece suporte a um dispositivo somente se esse dispositivo emula o rastreamento de dois ou mais dedos ou tem uma tela touchscreen real.Ao contrário do multitoque distinto definido por
android.hardware.touchscreen.multitouch.distinct
, dispositivos de entrada com suporte a multitoque distinto em uma interface de toque simulada não oferecem suporte a todos os gestos de dois dedos, porque a entrada é transformada em movimento de cursor na tela. Ou seja, gestos de um único dedo nesse dispositivo movem um cursor, o deslizar de dois dedos faz com que ocorram eventos de toque de um único dedo, e outros gestos de dois dedos acionam os eventos de toque de dois dedos correspondentes.Um dispositivo que fornece um trackpad de toque de dois dedos para movimento de cursor tem suporte para esse recurso.
-
android.hardware.faketouch.multitouch.jazzhand
-
O app rastreia cinco ou mais "dedos" diferentes em uma interface de toque simulada. Esse recurso é um superconjunto do recurso
android.hardware.faketouch
. Quando declarado como obrigatório, esse recurso indica que o app oferece suporte a um dispositivo apenas se esse dispositivo emula o rastreamento distinto de cinco ou mais dedos ou tem uma tela touchscreen real.Ao contrário do multitoque distinto definido por
android.hardware.touchscreen.multitouch.jazzhand
, dispositivos de entrada com suporte a multitoque "jazzhand" em uma interface de toque simulada não oferecem suporte a todos os gestos de cinco dedos, porque a entrada é transformada em movimento de cursor na tela. Ou seja, gestos de um único dedo nesse dispositivo movem um cursor, gestos com vários dedos fazem com que ocorram eventos de toque de um único dedo, e outros gestos com vários dedos acionam os eventos correspondentes a eles.Dispositivos que fornecem um trackpad de toque de cinco dedos para movimento de cursor tem suporte para esse recurso.
-
android.hardware.touchscreen
-
O app usa os recursos de tela touchscreen do dispositivo para gestos mais interativos que os eventos de toque básicos, como deslizar rapidamente. Esse recurso é um superconjunto do recurso
android.hardware.faketouch
.Por padrão, todos os apps exigem esse recurso e, portanto, não estão disponíveis para dispositivos que oferecem apenas uma interface de toque simulada. É possível disponibilizar o app em dispositivos que oferecem uma interface de toque simulada ou até mesmo em dispositivos que fornecem apenas um controlador D-pad, declarando explicitamente que a tela touchscreen não é necessária usando
android.hardware.touchscreen
comandroid:required="false"
. Adicione essa declaração se o app usa, mas não exige, uma interface real de tela touchscreen. Todos os apps que não exigemandroid.hardware.touchscreen
explicitamente também funcionam em dispositivos comandroid.hardware.faketouch
.Se o app realmente exige uma interface de toque, por exemplo, para executar gestos de toque mais avançados, como deslizar rapidamente, você não precisa declarar nenhum recurso de interface de toque, porque eles são obrigatórios por padrão. No entanto, é melhor declarar explicitamente todos os recursos usados pelo app.
Se o app exige uma interação de toque mais complexa, como gestos com vários dedos, declare que ele usa recursos avançados de tela touchscreen.
-
android.hardware.touchscreen.multitouch
-
O app usa os recursos básicos de multitoque de dois pontos do dispositivo, como os gestos de pinça, mas não precisa rastrear os toques de forma independente. Esse recurso é um superconjunto do recurso
android.hardware.touchscreen
.Ao usar esse recurso, o app implica que também usa o recurso
android.hardware.touchscreen
, a menos que este recurso pai seja declarado 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 de USB
-
android.hardware.usb.accessory
- O app se comporta como um dispositivo USB e se conecta a hosts USB.
-
android.hardware.usb.host
- O app usa acessórios USB conectados ao dispositivo. O dispositivo atua como host USB.
Recursos de hardware Vulkan
-
android.hardware.vulkan.compute
-
O app usa recursos computacionais do Vulkan. Esse recurso indica que o app exige a aceleração de hardware da
implementação do Vulkan. A versão do recurso indica qual nível de computação
opcional o app exige além dos requisitos do Vulkan 1.0. Por exemplo, se o app
exige suporte computacional Vulkan de nível 0, declare o seguinte recurso:
Para saber mais sobre a versão do recurso, consulte<uses-feature android:name="android.hardware.vulkan.compute" android:version="0" android:required="true" />
FEATURE_VULKAN_HARDWARE_COMPUTE
. -
android.hardware.vulkan.level
-
O app usa recursos de nível do Vulkan. Esse recurso indica que o app exige a
aceleração de hardware da implementação do Vulkan. A versão do recurso indica qual nível
de hardware opcional é exigido pelo app. Por exemplo, se o app exige suporte de hardware para o Vulkan
de nível 0, declare o seguinte recurso:
Para saber mais sobre a versão do recurso, consulte<uses-feature android:name="android.hardware.vulkan.level" android:version="0" android:required="true" />
FEATURE_VULKAN_HARDWARE_LEVEL
. -
android.hardware.vulkan.version
-
O app usa o Vulkan. Esse recurso indica que o app exige a aceleração de hardware da
implementação do Vulkan. A versão do recurso indica a versão mínima de suporte da API Vulkan
exigida pelo app. Por exemplo, se o app exige o Vulkan de nível 1.0, declare o
seguinte recurso:
Para saber mais sobre a versão do recurso, consulte<uses-feature android:name="android.hardware.vulkan.version" android:version="0x400003" android:required="true" />
FEATURE_VULKAN_HARDWARE_VERSION
.
Recursos de hardware de Wi-Fi
-
android.hardware.wifi
- O app usa os recursos de rede 802.11 (Wi-Fi) do dispositivo.
-
android.hardware.wifi.direct
- O app usa os recursos de rede Wi-Fi Direct do dispositivo.
Recursos de software
Esta seção apresenta os recursos de software com suporte para a versão da plataforma
mais atual. Para indicar que o app usa ou exige um recurso
de software, declare o valor correspondente, começando com
"android.software"
, em um atributo android:name
.
Sempre que você declarar um recurso de software, use um elemento
<uses-feature>
separado.
Recursos de software de comunicação
-
android.software.sip
- O app usa serviços do Session Initiation Protocol (SIP). Ao usar o SIP, o app pode oferecer suporte para operações de telefonia na Internet, como videoconferências e mensagens instantâneas.
-
android.software.sip.voip
-
O aplicativo usa serviços de Voz sobre IP (VoIP) com base no SIP. Ao usar VoIP, o app oferece suporte para operações de telefonia na internet em tempo real, como videoconferência bidirecional.
Ao usar esse recurso, o app implica que também usa o recurso
android.software.sip
, a menos que o recurso pai seja declarado 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 local parecido em que os usuários podem incorporar widgets.
-
android.software.home_screen
- O app se comporta como um substituto da tela inicial do dispositivo.
-
android.software.live_wallpaper
- O app usa ou fornece planos de fundo que incluem animação.
Permissões que sugerem requisitos de recurso
Algumas constantes de recurso de hardware e software são disponibilizadas para os
aplicativos após a API correspondente. Por isso, alguns apps podem usar a API antes de
declararem que exigem a API usando o
sistema <uses-feature>
.
Para evitar que esses apps sejam disponibilizados acidentalmente, o Google Play
supõe que algumas permissões relacionadas ao hardware indicam que os
recursos implícitos de hardware são obrigatórios por padrão. Por exemplo,
aplicativos que usam Bluetooth precisam solicitar a permissão
BLUETOOTH
em um elemento <uses-permission>
.
Em apps
legados, o Google Play supõe que a declaração de permissão significa que o
recurso android.hardware.bluetooth
subjacente é exigido pelo
aplicativo e define o filtro de acordo com esse recurso. A Tabela 2 lista
as permissões que implicam requisitos de recurso equivalentes às declaradas nos
elementos <uses-feature>
.
As declarações <uses-feature>
, incluindo todos os
atributos android:required
declarados, sempre têm precedência sobre
recursos implícitos pelas permissões na Tabela 2. Em qualquer uma dessas permissões,
é possível desativar o filtro com base no recurso implícito, declarando
explicitamente o recurso em um elemento <uses-feature>
com o atributo required
definido como false
.
Por exemplo, para
desativar o filtro com base na permissão CAMERA
, adicione as
seguintes declarações <uses-feature>
ao arquivo de manifesto:
<uses-feature android:name="android.hardware.camera" android:required="false" /> <uses-feature android:name="android.hardware.camera.autofocus" android:required="false" />
Atenção: caso seu app seja direcionado ao Android 5.0 (API de nível 21) ou
mais recente e use a permissão ACCESS_COARSE_LOCATION
ou
ACCESS_FINE_LOCATION
para receber atualizações
de locais da rede ou de um GPS, respectivamente, você também precisa declarar
explicitamente que o app usa os recursos
de hardware android.hardware.location.network
ou android.hardware.location.gps
.
Tabela 2. Permissões que implicam o uso de hardware do dispositivo.
Categoria | Permissão | Requisito do recurso implícito |
---|---|---|
Bluetooth | BLUETOOTH |
android.hardware.bluetooth
Consulte Processamento especial para o recurso Bluetooth para saber mais. |
BLUETOOTH_ADMIN |
android.hardware.bluetooth |
|
Câmera | CAMERA |
android.hardware.camera 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 |