lightbulb_outline Help shape the future of the Google Play Console, Android Studio, and Firebase. Start survey

Filtros no Google Play

Quando um usuário pesquisa ou navega buscando aplicativos para baixar no Google Play, os resultados são filtrados com base nos aplicativos que são compatíveis com o dispositivo. Por exemplo, se um aplicativo exige uma câmera, o Google Play não mostra o aplicativo para dispositivos que não têm câmera. Essa filtragem ajuda os desenvolvedores a gerenciar a distribuição de seus aplicativos e a garantir a melhor experiência possível para o usuário.

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 Console do Desenvolvedor do Google Play, como alvo geográfico e preços, entre outros.

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 deve mostrar seu aplicativo a um usuário que estiver navegando ou pesquisando aplicativos pelo Google Play.

Ao determinar se deve exibir seu aplicativo, o Google Play verifica os requisitos de hardware e software do dispositivo, assim como a operadora, o local e outras características. Ele os compara com as restrições e dependências expressas pelo arquivo de manifesto e os detalhes de publicação do aplicativo.

Se o aplicativo for compatível com o dispositivo de acordo com as regras de filtragem, o Google Play exibirá o aplicativo ao usuário. Caso contrário, o Google Play ocultará o aplicativo dos resultados de pesquisa e de navegação de categoria, mesmo se o usuário solicitar especificamente o aplicativo clicando em um link direto que aponte diretamente para a ID do aplicativo dentro do Google Play.

Você pode usar qualquer combinação de filtros disponíveis para o aplicativo. Por exemplo, você pode definir um requisito minSdkVersion de "4" e definir smallScreens="false" no aplicativo. Ao carregar o aplicativo no Google Play, o alvo seria apenas de países europeus (operadoras). Os filtros do Google Play evitarão que o aplicativo seja disponibilizado para qualquer dispositivo que não atenda aos três requisitos.

Todas as restrições de filtragem são associadas à versão do aplicativo e podem mudar entre versões. Por exemplo, se o usuário instalou seu aplicativo e você publicou uma atualização que torna o aplicativo invisível para o usuário, ele não verá que uma atualização está disponível.

Filtragem no site do Google Play

Quando os usuários navegam no site do Google Play, eles conseguem ver todos os aplicativos publicados. O site do Google Play compara os requisitos do aplicativo com cada um dos dispositivos registrados do usuário por compatibilidade e permite a instalação do aplicativo apenas se ele for compatível com o dispositivo.

Filtragem baseada no manifesto do aplicativo

A maioria dos filtros é acionada por elementos dentro do arquivo de manifesto do aplicativo, AndroidManifest.xml (embora nem tudo no arquivo de manifesto possa acionar a filtragem). A Tabela 1 lista os elementos de manifesto que devem ser usados para acionar a filtragem e explica como a filtragem de cada elemento funciona.

Tabela 1. Elementos do 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 suporte configurando atributos do elemento <supports-screens>. Quando o aplicativo é publicado, o Google Play usa os atributos para determinar como mostrar o aplicativo aos usuários com base nos tamanhos de tela dos dispositivos.

Como regra geral, o Google Play assume que a plataforma no dispositivo pode adaptar layouts pequenos para telas maiores, mas não pode adaptar layouts grandes para telas menores. Se um aplicativo declara suporte apenas para o tamanho de tela “normal”, o Google Play disponibiliza o aplicativo para dispositivos de tela normal e grande, mas filtra o aplicativo para que não esteja disponível para dispositivos de tela pequena.

Se um aplicativo não declara atributos para <supports-screens>, o Google Play usa os valores padrão desses atributos, que variam por nível de API. Especificamente:

  • Para aplicativos que definem android: minSdkVersion ou android: targetSdkVersion para 3 ou menos, o próprio elemento <supports-screens> não é definido e nenhum atributo estará disponível. Nesse caso, o Google Play supõe que o aplicativo é projetado para telas de tamanho normal e mostra o aplicativo para dispositivos com tamanhos de tela normal ou maior.

  • Quando o android: minSdkVersion ou android: targetSdkVersion estiver definido para 4 ou maior, o padrão para todos os atributos é "true". Dessa forma, o aplicativo é considerado com suporte para 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 de um dispositivo de tela pequena, mas mostrará para usuários de dispositivos de tela grande e normal, a não ser 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 usuários em todos os dispositivos, a não ser 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 obter mais informações sobre como declarar suporte para tamanhos de tela no seu aplicativo, consulte <supports-screens> e Suporte a várias telas.

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

Um aplicativo pode solicitar determinados recursos de hardware e o Google Play mostrará o aplicativo apenas em dispositivos com o hardware necessário.

Exemplo 1
O manifesto inclui <uses-configuration android:reqFiveWayNav="true" /> e o usuário está pesquisando aplicativos em um dispositivo que não tem um 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 a todos os usuários, a não ser que outros filtros sejam aplicados.

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

<uses-feature> Recursos do dispositivo
(name)

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

Exemplo 1
O manifesto inclui <uses-feature android:name="android.hardware.sensor.light" /> e um usuário está pesquisando aplicativos em um dispositivo que não tem um sensor de iluminação. 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 a todos os usuários, a não ser que outros filtros sejam aplicados.

Para obter informações completas, 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 àqueles declarados nos elementos <uses-feature>. Veja <uses-permission> abaixo.

Versão do OpenGL-ES
(openGlEsVersion)

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

Exemplo 1
Um aplicativo exige várias versões do OpenGL-ES especificando openGlEsVersion várias vezes no manifesto. Resultado: O Google Play supõe que o aplicativo exige a maior dentre as versões indicadas.

Exemplo 2
Um aplicativo solicita a versão 1.1 do OpenGL-ES e um usuário está pesquisando aplicativos em um dispositivo compatível com a versão 2.0 do OpenGL-ES. Resultado: O Google Play mostrará o aplicativo ao usuário, a não ser que outros filtros sejam aplicados. Se um dispositivo relata que suporta o OpenGL-ES versão X, o Google Play supõe que ele também suporta qualquer versão anterior ao 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 executando o Android 1.5 ou anterior). Resultado: O Google Play supõe que o dispositivo suporta apenas o OpenGL-ES 1.0. O Google Play mostrará aos usuários somente os aplicativos que não especificarem openGlEsVersion ou aplicativos que não especificarem um OpenGL-ES com versão posterior a 1.0.

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

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

<uses-library> Bibliotecas de software

Um aplicativo pode exigir que determinadas bibliotecas compartilhadas estejam presentes no dispositivo.

Exemplo 1
Um aplicativo exige a biblioteca com.google.android.maps e um usuário está pesquisando aplicativos em um dispositivo que não tem 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 a todos os usuários, a não ser que outros filtros sejam aplicados.

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

<uses-permission>   A rigor, o Google Play não filtra com base em elementos <uses-permission>. No entanto, ele lê os elementos para determinar se o aplicativo tem requisitos do recurso de hardware que podem não ter sido corretamente declarados nos elementos <uses-feature> . Por exemplo, se um aplicativo solicita a permissão CAMERA , mas não declara um elemento <uses-feature> para android.hardware.camera, o Google Play considera que o aplicativo exige uma câmera e não deve ser mostrado para usuários cujos dispositivos não oferecem câmera.

Em geral, se um aplicativo solicita permissões relacionadas a hardware, o Google Play supõe que o aplicativo exige recursos de hardware subjacentes, mesmo que não corresponda às declarações <uses-feature>. O Google Play define a filtragem com base nos recursos implícitos nas declarações <uses-feature> .

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

<uses-sdk> Versão mínima da estrutura de trabalho (minSdkVersion)

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

Exemplo 1
O manifesto contém <uses-sdk android:minSdkVersion="3"> e o aplicativo 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 não mostrará o aplicativo para o usuário.

Exemplo 2
O manifesto não contém minSdkVersion e o aplicativo 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 supõe que minSdkVersion é "1" e que o aplicativo é 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 desejamos evitar esse segundo caso, recomendamos que você sempre declare um minSdkVersion. Para obter detalhes, consulte android:minSdkVersion.

Versão máxima da estrutura de trabalho (maxSdkVersion)

Obsoleto. O Android 2.1 e posteriores não verificam nem forçam o atributo maxSdkVersion e o SDK não será compilado se maxSdkVersion estiver definido em um manifesto do aplicativo. Para dispositivos já compilados com o maxSdkVersion, o Google Play respeitará e usará para filtragem.

Declarar maxSdkVersion não é recomendado. Para obter 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 apenas casos de uso excepcionais. Eles são projetados para determinados tipos de jogos de alto desempenho e aplicativos semelhantes que exigem controles restritos sobre a distribuição de aplicativos. A maioria dos aplicativos nunca deve usar esses filtros.

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

Elemento de manifestoResumo
<compatible-screens>

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

Atenção: Normalmente, não se deve usar esse elemento de manifesto. Usar esse elemento pode reduzir muito a base de usuários possível para o aplicativo, excluindo todas as combinações de tamanho de tela e densidade não listadas. Em vez disso, use o elemento <supports-screens> do manifesto (descrito na Tabela 1 acima) para habilitar ativar o modo de compatibilidade de tela para configurações de tela que você não levou em conta para recursos alternativos.

<supports-gl-texture>

O Google Play filtra o aplicativo, a não ser que um ou mais formatos de compactação de textura do GL suportados pelo aplicativo também sejam suportados pelo dispositivo.

Outros filtros

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

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

Nome do filtro Como funciona
Status da publicação

Apenas aplicativos publicados aparecerão nas pesquisas e na navegação dentro do Google Play.

Mesmo se um aplicativo não estiver publicado, ele poderá ser instalado se os usuários puderem vê-lo na área Downloads entre os aplicativos comprados, instalados ou recentemente desinstalados.

Se um aplicativo foi suspenso, os usuários não poderão reinstalá-lo nem atualizá-lo, mesmo se aparecer nos Downloads.

Status dos aplicativos pagos

Nem todos os usuários podem ver aplicativos pagos. Para mostrar aplicativos pagos, um dispositivo deve ter um cartão SIM e estar executando o Android 1.1 ou posterior, além de precisar estar em um país (conforme determinado pela operadora do SIM) onde aplicativos pagos estão disponíveis.

Segmentação de país

Ao carregar o aplicativo no Google Play, é possível selecionar os países para distribuição em Pricing and Distribution. O aplicativo estará disponível para os usuários apenas nos países selecionados.

Arquitetura o CPU (ABI)

Um aplicativo que inclui bibliotecas nativas orientadas para uma arquitetura de CPU específica (por exemplo, ARM EABI v7 ou x86) estará visível apenas em dispositivos que suportam essa arquitetura. Para obter detalhes sobre o NDK e o uso de bibliotecas nativas, consulte O que é o Android NDK?

Aplicativos protegidos contra cópia

O Google Play não suporta mais o recurso de Proteção contra Cópia no Console do Desenvolvedor e não filtra aplicativos com base nisso. Para proteger o aplicativo, use o Application Licensing. Consulte Substituição para a proteção contra cópia para obter mais informações.

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

Alguns filtros específicos do Google Play permitem publicar vários APKs para o mesmo aplicativo para fornecer um APK específico para diferentes configurações de dispositivo. Por exemplo, se você está criando um jogo que usa ativos de gráfico de alta fidelidade, é possível criar dois APKs que suportam formatos de compactação de textura diferentes. Dessa forma, você pode reduzir o tamanho do arquivo APK incluindo apenas texturas necessárias para cada configuração de dispositivo. Dependendo do suporte de cada dispositivo para formatos de compactação de textura, o Google Play fornecerá o APK declarado para suportar esse dispositivo.

Atualmente, o Google Play permite publicar vários APKs para o mesmo aplicativo apenas quando cada APK fornece diferentes filtros 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 o <compatible-screens>.

  • Nível de API

    Usando o elemento <uses-sdk>.

  • Arquitetura de CPU (ABI)

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

Todos os outros filtros ainda funcionam da mesma forma, mas esses quatro são os únicos filtros que podem distinguir um APK do outro dentro da mesma lista de aplicativos no Google Play. Por exemplo, você não pode publicar vários APKs para o mesmo aplicativo se os APKs diferem apenas no fato de o dispositivo ter uma câmera.

Atenção: Publicar vários APKs para o mesmo aplicativo é considerado um recurso avançado e a maioria dos aplicativos deve publicar apenas um APK que suporte uma ampla variedade de configurações de dispositivo. Publicar vários APKs exige que sejam seguidas regras específicas dentro dos filtros e muita atenção aos códigos de versão para cada APK para garantir caminhos de atualização adequados para cada configuração.

Para obter mais informações sobre como publicar vários APKs no Google Play, leia Suporte para vários APK.