Participe do evento ⁠#Android11: apresentação de lançamento da versão Beta no dia 3 de junho.

Filtros no Google Play

Quando um usuário pesquisa ou navega em busca de apps para download no Google Play, os resultados são filtrados com base nos aplicativos compatíveis com o dispositivo. Por exemplo, se um aplicativo exigir uma câmera, ele não será exibido no Google Play para dispositivos sem câmera. Essa filtragem ajuda os desenvolvedores a gerenciar a distribuição de apps e a garantir a melhor experiência possível para os usuários.

A filtragem no Google Play é baseada em vários tipos de metadados do aplicativo e definições de configuração, incluindo declarações de manifesto, bibliotecas necessárias, dependências de arquitetura e controles de distribuição definidos no Google Play Console, como segmentação geográfica, preços e muito mais.

A filtragem do Google Play é baseada, em parte, nas declarações de manifesto e outros aspectos de estrutura de trabalho do Android, mas o comportamento da filtragem real é diferente da estrutura de trabalho e não é vinculado a níveis de API específicos. Este documento especifica as regras de filtragem atuais usadas pelo Google Play.

Como funcionam os filtros no Google Play

O Google Play usa as restrições de filtro descritas abaixo para determinar se seu aplicativo será exibido para um usuário que está navegando ou pesquisando apps no aplicativo Google Play.

Ao determinar se exibirá seu aplicativo, o Google Play verifica os requisitos de hardware e software do dispositivo, além da sua operadora, localização e outras características. Em seguida, compara essas informações com as restrições e dependências expressas pelo arquivo de manifesto do aplicativo e pelos detalhes de publicação.

Se o aplicativo for compatível com o dispositivo de acordo com as regras de filtragem, o Google Play exibirá o app para o usuário. Caso contrário, o Google Play ocultará seu aplicativo dos resultados da pesquisa e da navegação por categoria, mesmo que um usuário solicite especificamente o aplicativo, clicando em um link direto que aponta diretamente para o código do app no Google Play.

Você pode usar qualquer combinação dos filtros disponíveis para o app. Por exemplo, você pode definir um requisito minSdkVersion de "4" e definir smallScreens="false" no app. Então, ao fazer upload do app no Google Play, é possível direcioná-lo para países (operadoras) europeus apenas. Assim, os filtros do Google Play impedirão que o aplicativo fique disponível em dispositivos que não atendam a esses três requisitos.

Todas as restrições de filtragem estão associadas à versão de um aplicativo e podem mudar entre as versões. Por exemplo, se um usuário tiver instalado seu app e você publicar uma atualização que torne o app invisível para o usuário, ele não verá essa atualização.

Filtragem no site do Google Play

Quando os usuários navegam no site do Google Play, eles podem ver todos os aplicativos publicados. O site do Google Play compara os requisitos do app com cada um dos dispositivos registrados do usuário para verificar a compatibilidade e permite que ele apenas instale o app se esse for compatível com o dispositivo.

Filtragem com base no manifesto do app

A maioria dos filtros é acionada por elementos no arquivo de manifesto de um aplicativo, AndroidManifest.xml, embora nem tudo no arquivo de manifesto possa acionar a filtragem. A Tabela 1 lista os elementos de manifesto que você precisa usar para acionar a filtragem e explica como a filtragem de cada elemento funciona.

Tabela 1. Elementos de manifesto que acionam a filtragem no Google Play.

Elemento de manifesto Nome do filtro Como funciona
<supports-screens> Tamanho da tela

Um aplicativo indica os tamanhos de tela com que ele é compatível, pela definição de atributos do elemento <supports-screens>. Ao publicar o aplicativo, o Google Play usa esses atributos para determinar quando mostrar o app aos usuários, com base nos tamanhos de tela dos dispositivos.

Como regra geral, o Google Play supõe que a plataforma no dispositivo pode adaptar layouts menores a telas maiores, mas não pode adaptar layouts maiores a telas menores. Assim, se um aplicativo declara apenas ser compatível com tamanho de tela "normal", o Google Play disponibiliza o aplicativo para dispositivos de tela normal e grande. No entanto, filtra o aplicativo para que ele não apareça para dispositivos de tela pequena.

Se um aplicativo não declarar atributos para <supports-screens>, o Google Play usará os valores padrão desses atributos, que variam de acordo com o nível da API. São eles:

  • Para aplicativos que definem android: minSdkVersion ou android: targetSdkVersion como 3 ou menos, o próprio elemento <supports-screens> é indefinido e não há atributos disponíveis. Nesse caso, o Google Play presume que o aplicativo foi projetado para telas de tamanho normal e mostra o app para dispositivos que possuem telas normais ou maiores.

  • Quando android: minSdkVersion ou android: targetSdkVersion for definido como 4 ou mais, o padrão para todos os atributos será "true". Dessa forma, o aplicativo é considerado compatível com todos os tamanhos de tela por padrão.

Exemplo 1
O manifesto declara <uses-sdk android:minSdkVersion="3"> e não inclui um elemento <supports-screens>. Resultado: o Google Play não mostrará o app para um usuário que tem um dispositivo de tela pequena, mas mostrará para usuários que têm dispositivos com tela normal e grande, a menos que outros filtros sejam aplicados.

Exemplo 2
O manifesto declara <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="4"> e não inclui um elemento <supports-screens>. Resultado: o Google Play mostrará o app para usuários em todos os dispositivos, a menos que outros filtros sejam aplicados.

Exemplo 3
O manifesto declara <uses-sdk android:minSdkVersion="4"> e não inclui um elemento <supports-screens>. Resultado: o Google Play mostrará o app a todos os usuários, a não ser que outros filtros sejam aplicados.

Para ver mais informações sobre como declarar a compatibilidade com tamanhos de tela no aplicativo, consulte <supports-screens> e Compatibilidade com várias telas.

<uses-configuration> Configuração do dispositivo:
teclado, navegação, touchscreen

Um aplicativo pode solicitar determinados recursos de hardware, e o Google Play mostrará o aplicativo somente em dispositivos que possuam o hardware necessário.

Exemplo 1
O manifesto inclui <uses-configuration android:reqFiveWayNav="true" />, e um usuário está procurando por apps em um dispositivo que não tem controle de navegação de cinco direções. Resultado: o Google Play não mostrará o app para o usuário.

Exemplo 2
O manifesto não inclui um elemento <uses-configuration>. Resultado: o Google Play mostrará o app a todos os usuários, a não ser que outros filtros sejam aplicados.

Para ver mais detalhes, consulte <uses-configuration>.

<uses-feature> Recursos do dispositivo
(name)

Um aplicativo pode exigir que determinados recursos do dispositivo estejam presentes nele. Essa funcionalidade foi introduzida no Android 2.0 (API Nível 5).

Exemplo 1
O manifesto inclui <uses-feature android:name="android.hardware.sensor.light" /> e um usuário está procurando apps em um dispositivo que não tem um sensor de luz. Resultado: o Google Play não mostrará o app para o usuário.

Exemplo 2
O manifesto não inclui um elemento <uses-feature>. Resultado: o Google Play mostrará o app a todos os usuários, a não ser que outros filtros sejam aplicados.

Para saber mais, consulte <uses-feature> .

Filtragem com base em recursos implícitos: em alguns casos, o Google Play interpreta permissões solicitadas por meio de elementos <uses-permission> como requisitos de recursos equivalentes aos declarados em elementos <uses-feature>. Veja <uses-permission> abaixo.

Versão do OpenGL ES
(openGlEsVersion)

Um app pode exigir que o dispositivo seja compatível com uma versão específica do OpenGL-ES usando o atributo <uses-feature android:openGlEsVersion="int">.

Exemplo 1
Um app solicita várias versões do OpenGL-ES especificando openGlEsVersion várias vezes no manifesto. Resultado: o Google Play supõe que o app exige a versão mais recente.

Exemplo 2
Um app solicita o OpenGL-ES versão 1.1 e um usuário está procurando apps em um dispositivo que é compatível com o OpenGL-ES versão 2.0. Resultado: o Google Play mostrará o app ao usuário, a não ser que outros filtros sejam aplicados. Se um dispositivo informar que é compatível com a versão OpenGL-ES X, o Google Play presumirá que ele também é compatível com qualquer versão anterior a X.

Exemplo 3
Um usuário está pesquisando apps em um dispositivo que não informa a versão do OpenGL-ES, por exemplo, um dispositivo que executa o Android 1.5 ou anterior. Resultado: o Google Play supõe que o dispositivo é compatível apenas com o OpenGL-ES 1.0. O Google Play mostrará ao usuário apenas os apps que não especificam o openGlEsVersion ou que não especificam uma versão do OpenGL-ES posterior a 1.0.

Exemplo 4
O manifesto não especifica openGlEsVersion. Resultado: o Google Play mostrará o app a todos os usuários, a não ser que outros filtros sejam aplicados.

Para ver mais detalhes, consulte <uses-feature>.

<uses-library> Bibliotecas de software

Um aplicativo pode exigir que bibliotecas compartilhadas específicas estejam presentes no dispositivo.

Exemplo 1
Um app requer a biblioteca com.google.android.maps, e um usuário está pesquisando apps em um dispositivo que não tem a biblioteca com.google.android.maps. Resultado: o Google Play não mostrará o app para o usuário.

Exemplo 2
O manifesto não inclui um elemento <uses-library>. Resultado: o Google Play mostrará o app a todos os usuários, a não ser que outros filtros sejam aplicados.

Para ver mais detalhes, consulte <uses-library>.

<uses-permission>  

Estritamente, o Google Play não realiza filtragem com base em elementos <uses-permission>. No entanto, ele lê os elementos para determinar se o aplicativo tem requisitos de recursos de hardware que podem não ter sido declarados corretamente nos elementos <uses-feature>. Por exemplo, se um app 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 deve ser exibido para usuários cujos dispositivos não tenham uma câmera.

Em geral, se um aplicativo solicitar permissões relacionadas a hardware, o Google Play presumirá que ele requer os recursos de hardware subjacentes, mesmo que não haja declarações correspondentes a <uses-feature>. Em seguida, o Google Play configura a filtragem com base nos recursos implícitos pelas declarações <uses-feature>.

Para ver uma lista de permissões que exigem recursos de hardware, consulte a documentação do elemento <uses-feature>.

<uses-sdk> Versão mínima do framework (minSdkVersion)

Um aplicativo pode exigir um nível de API mínimo.

Exemplo 1
O manifesto inclui <uses-sdk android:minSdkVersion="3">, e o app usa APIs que foram introduzidas na API de nível 3. Um usuário está pesquisando aplicativos em um dispositivo com uma API de nível 2. Resultado: o Google Play não mostrará o app para o usuário.

Exemplo 2
O manifesto não inclui minSdkVersion, e o app usa APIs que foram introduzidas no nível 3. Um usuário está pesquisando aplicativos em um dispositivo com uma API de nível 2. Resultado: o Google Play assume que minSdkVersion é "1" e que o app é compatível com todas as versões do Android. O Google Play mostra o app ao usuário e permite que ele faça o download do app. O app falha durante a execução.

Para evitar esse segundo cenário, recomendamos que você sempre declare um minSdkVersion. Para ver mais detalhes, consulte android:minSdkVersion.

Versão máxima do framework (maxSdkVersion)

Obsoleto. O Android 2.1 e versões posteriores não verificam nem aplicam o atributo maxSdkVersion, e o SDK não será compilado se maxSdkVersion for definido no manifesto de um app. Para dispositivos já compilados com maxSdkVersion, o Google Play observará esse dado e o usará para filtragem.

Não é recomendado declarar maxSdkVersion. Para ver mais detalhes, consulte android:maxSdkVersion.

Filtros avançados de manifesto

Além dos elementos na tabela 1, o Google Play também pode filtrar aplicativos com base nos elementos de manifesto avançados na tabela 2.

Esses elementos de manifesto e a filtragem que eles acionam são usados apenas em casos excepcionais. Eles são projetados para determinados tipos de jogos de alto desempenho e aplicativos similares que exigem controles rigorosos na distribuição de apps. É recomendável que a maioria dos aplicativos nunca use esses filtros.

Tabela 2. Elementos de manifesto avançados para a filtragem do Google Play.

Elemento de manifestoResumo
<compatible-screens>

O Google Play filtrará o aplicativo se o tamanho e a densidade da tela do dispositivo não corresponder a nenhuma das configurações de tela (declaradas por um elemento <screen>) no elemento <compatible-screens>.

Atenção: normalmente, não é recomendável usar este elemento de manifesto. Ele pode reduzir muito a base de usuários em potencial do seu aplicativo, excluindo todas as combinações de tamanho e densidade de tela que você não listou. Em vez disso, é necessário usar o elemento de manifesto <supports-screens> (descrito acima na tabela 1) para ativar o modo de compatibilidade de tela para configurações de tela que não foram consideradas com recursos alternativos.

<supports-gl-texture>

O Google Play só não filtrará o aplicativo se um ou mais formatos de compactação de textura GL compatíveis com o aplicativo também forem compatíveis com o dispositivo.

Outros filtros

O Google Play usa outras características do aplicativo para determinar se mostrará ou ocultará um aplicativo para determinado usuário em um dispositivo específico, conforme descrito na tabela abaixo.

Tabela 3. Características de aplicação e publicação que afetam a filtragem no Google Play.

Nome do filtro Como funciona
Status da publicação

Apenas os apps publicados aparecerão nas pesquisas e na navegação no Google Play.

Mesmo se um app não for publicado, ele poderá ser instalado se os usuários puderem vê-lo na área de downloads entre os apps comprados, instalados ou desinstalados recentemente.

Se um app tiver sido suspenso, os usuários não poderão reinstalá-lo ou atualizá-lo, mesmo se ele aparecer nos downloads.

Status com preço

Nem todos os usuários podem ver aplicativos pagos. Para mostrá-los, é necessário que um dispositivo esteja executando o Android 1.1 ou posterior e deve estar em um país em que apps pagos estejam disponíveis. Se um dispositivo tiver um cartão SIM, a operadora desse cartão determinará se os aplicativos pagos estão disponíveis. Se um dispositivo não tiver um cartão SIM, o endereço IP do dispositivo será usado para determinar se ele está em um país onde os aplicativos pagos estão disponíveis.

País de destino

Ao fazer upload do seu app para o Google Play, é possível selecionar os países para distribuir seu aplicativo em Preço e distribuição. O aplicativo estará disponível para os usuários apenas nos países selecionados.

Arquitetura de CPU (ABI)

Um app que inclui bibliotecas nativas orientadas para uma arquitetura de CPU específica (ARM EABI v7 ou x86, por exemplo) é visível apenas em dispositivos compatíveis com essa arquitetura. Para ver detalhes sobre o NDK e usar bibliotecas nativas, consulte O que é o Android NDK?

Aplicativos protegidos contra cópia

O Google Play não é mais compatível com o recurso de proteção contra cópia no Play Console e não filtra mais aplicativos com base nele. Para proteger seu aplicativo, use o Licenciamento do app. Consulte Substituição para proteção contra cópia para ver mais informações.

Publicação de vários APKs com filtros diferentes

Alguns filtros específicos do Google Play permitem que você publique vários APKs para o mesmo aplicativo para que ofereça um APK diferente para diferentes configurações de dispositivos. Por exemplo, se você estiver criando um videogame que use recursos gráficos de alta fidelidade, é possível criar dois APKs compatíveis com diferentes formatos de compactação de textura. Dessa forma, é possível reduzir o tamanho do arquivo APK incluindo apenas as texturas necessárias para cada configuração de dispositivo. Dependendo da compatibilidade de cada dispositivo para seus formatos de compactação de textura, o Google Play entregará o APK que você declarou ser compatível com esse dispositivo.

Atualmente, o Google Play permite publicar vários APKs para o mesmo aplicativo somente quando cada APK oferece filtros diferentes com base nas seguintes configurações:

  • Formatos de compactação de textura do OpenGL

    Usando o elemento <supports-gl-texture>.

  • Tamanho da tela (e, opcionalmente, densidade da tela)

    Usando o elemento <supports-screens> ou <compatible-screens>.

  • Nível da API

    Usando o elemento <uses-sdk>.

  • Arquitetura de CPU (ABI)

    Incluindo bibliotecas nativas construídas com o Android NDK que está orientado para uma arquitetura de CPU específica (ARM EABI v7 ou x86, por exemplo).

Todos os outros filtros ainda funcionam como de costume, mas esses quatro são os únicos filtros que podem distinguir um APK de outro na mesma listagem de apps no Google Play. Por exemplo, não é possível publicar vários APKs para o mesmo aplicativo se os APKs forem diferentes apenas com base no fato de o dispositivo ter uma câmera.

Cuidado: a publicação de vários APKs para o mesmo aplicativo é considerada um recurso avançado, e é necessário que a maioria dos aplicativos publique apenas um APK compatível com uma ampla variedade de configurações de dispositivos. A publicação de vários APKs exige que você siga regras específicas nos seus filtros e preste mais atenção aos códigos de versão de cada APK para garantir os caminhos de atualização adequados para cada configuração.

Se precisar de mais informações sobre como publicar vários APKs no Google Play, leia Suporte para vários APKs.

Veja também

  1. Compatibilidade com Android
  2. Suporte a vários APKs