Android Dev Summit, October 23-24: two days of technical content, directly from the Android team. Sign-up for livestream updates.

Filtros no Google Play

Quando um usuário pesquisa ou navega em busca de aplicativos 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, o Google Play não mostrará o app para dispositivos sem câmera. Essa filtragem ajuda os desenvolvedores a gerenciar a distribuição de aplicativos 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 de filtros disponíveis para o aplicativo. Por exemplo, é possível definir um requisito de minSdkVersion de "4" e configurar smallScreens="false" no app. Depois, ao fazer upload do aplicativo no Google Play, é possível segmentar apenas países europeus (operadoras). Assim, os filtros do Google Play impedirão que o aplicativo fique disponível em dispositivos que não correspondam 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 aplicativo

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, definindo 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 de seus 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 configuram o 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 o android: minSdkVersion ou android: targetSdkVersion é definido como 4 ou mais, o padrão para todos os atributos é "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 aplicativo para um usuário que tem um dispositivo de tela pequena, mas o 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 aplicativo para os 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 aplicativo a todos os usuários, a não ser que outros filtros sejam aplicados.

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

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

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 aplicativos em um dispositivo que não tenha controle de navegação de cinco direções. Resultado: o Google Play não mostrará o aplicativo para o usuário.

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

Para 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 o <uses-feature android:name="android.hardware.sensor.light" /> e um usuário está procurando por apps em um dispositivo que não possui um sensor de luz. Resultado: o Google Play não mostrará o aplicativo para o usuário.

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

Para ver todas as informações, consulte <uses-feature> .

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

Versão OpenGL-ES
(openGlEsVersion)

Um aplicativo 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 aplicativo 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 aplicativo 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 aplicativo ao usuário, a não ser que outros filtros sejam aplicados. Se um dispositivo relatar que é compatível com a versão X do OpenGL-ES, o Google Play presumirá que ele também é compatível com qualquer versão anterior à X.

Exemplo 3
Um usuário está pesquisando aplicativos em um dispositivo que não relata uma 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á apenas os apps de usuário que não especificam o openGlEsVersion ou os aplicativos que não especificarem uma versão do OpenGL-ES posterior a 1.0.

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

Para 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 aplicativo requer a biblioteca com.google.android.maps, e um usuário está pesquisando apps em um dispositivo que não tenha a biblioteca com.google.android.maps. Resultado: o Google Play não mostrará o aplicativo para o usuário.

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

Para mais detalhes, consulte <uses-library>.

<uses-permission>  

Estritamente, o Google Play não filtra com base nos elementos <uses-permission>. No entanto, ele lê os elementos para determinar se o aplicativo possui 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 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>. O Google Play, em seguida, configura a filtragem com base nos recursos implícitos pelas declarações <uses-feature>.

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

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

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

Exemplo 1
O manifesto inclui <uses-sdk android:minSdkVersion="3">, e o aplicativo usa APIs que foram introduzidas na API 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 aplicativo para o usuário.

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

Como é conveniente evitar esse segundo cenário, recomendamos que você sempre declare uma minSdkVersion. Para ver os detalhes, consulte android:minSdkVersion.

Versão de framework máxima (maxSdkVersion)

Obsoleto. O Android 2.1 e posterior não verifica ou aplica o atributo maxSdkVersion, e o SDK não compilará se maxSdkVersion estiver definido no manifesto de um aplicativo. Para dispositivos já compilados com maxSdkVersion, o Google Play observará esse dado e o usará para filtragem.

A declaração do maxSdkVersion não é recomendada. Para ver os detalhes, consulte android:maxSdkVersion.

Filtros de manifesto avançados

Além dos elementos de manifesto 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, é recomendável 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 você não considerou 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 ter 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 de 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