Visão geral de compatibilidade de dispositivos

O Android foi feito para funcionar em vários tipos diferentes de dispositivos, como smartphones, tablets e televisões. Como desenvolvedor, a variedade de dispositivos oferece a possibilidade de um enorme público para seu app. Para que seu aplicativo tenha sucesso em todos esses dispositivos, ele precisa tolerar uma certa variabilidade de recursos e oferecer uma interface do usuário flexível que se adapte a diferentes configurações de tela.

Para facilitar seu trabalho, o Android oferece um framework de aplicativo dinâmico em que você pode fornecer recursos do aplicativo específicos para a configuração em arquivos estáticos, como diferentes layouts XML para diferentes tamanhos de tela. Em seguida, o Android carrega os recursos adequados com base na configuração atual do dispositivo. Com o planejamento do design do app e alguns recursos adicionais, você pode publicar um único pacote de apps (APK) que oferece uma experiência otimizada para o usuário em vários dispositivos.

Por outro lado, caso seja necessário, especifique os requisitos de recursos do seu app e controle que tipos de dispositivos podem instalar seu app na Google Play Store. Esta página explica como controlar os dispositivos que têm acesso ao seu app e como prepará-lo para que cheguem ao público certo. Para mais informações sobre como tornar seu app adaptável a vários dispositivos, consulte Compatibilidade com vários dispositivos.

O que significa "compatibilidade"?

Ao ler mais sobre o desenvolvimento para Android, você provavelmente verá o termo "compatibilidade" em várias situações. Há dois tipos de compatibilidade: compatibilidade com dispositivos e compatibilidade com apps.

Como o Android é um projeto de código aberto, qualquer fabricante de hardware pode criar um dispositivo que execute o sistema operacional Android. No entanto, um dispositivo é "compatível com Android" somente se puder executar corretamente aplicativos criados para o ambiente de execução do Android. Os detalhes exatos do ambiente de execução do Android são definidos pelo Programa de compatibilidade com Android e todos os dispositivos precisam passar pelo Teste de compatibilidade (CTS, na sigla em inglês) para ser considerado compatível.

Como desenvolvedor de aplicativos, você não precisa se preocupar se um dispositivo é compatível com o Android porque apenas os dispositivos compatíveis com o Android incluem a Google Play Store. Assim, você pode ter certeza de que os usuários que instalam seu aplicativo da Google Play Store estão usando um dispositivo compatível com Android.

Porém, você precisa considerar se seu app é compatível com cada configuração possível do dispositivo. Como o Android é executado em uma ampla gama de configurações de dispositivo, alguns recursos não estão disponíveis em todos os dispositivos. Por exemplo, alguns dispositivos podem não ter um sensor de bússola. Se a principal funcionalidade do aplicativo exigir o uso de um sensor de bússola, seu aplicativo será compatível apenas com dispositivos que incluem esse sensor.

Como controlar a disponibilidade do seu app aos dispositivos

O Android é compatível com vários recursos que seu aplicativo pode usar nas APIs da plataforma. Alguns recursos são baseados em hardware (como o sensor de bússola), alguns são baseados em software (como widgets de aplicativos) e outros dependem da versão da plataforma. Nem todos os dispositivos são compatíveis com todos os recursos. Por isso, talvez seja necessário controlar a disponibilidade do seu app para os dispositivos com base nos recursos obrigatórios do seu app.

Para alcançar a maior base de usuários possível para seu aplicativo, tente oferecer compatibilidade ao maior número possível de configurações de dispositivos usando um único APK. Na maioria das situações, é possível fazer isso desativando recursos opcionais no ambiente de execução e fornecendo recursos de aplicativo com alternativas para configurações diferentes (como diferentes layouts para diferentes tamanhos de tela). No entanto, se necessário, você pode restringir a disponibilidade do seu app para dispositivos na Google Play Store com base nas seguintes características do dispositivo:

• Recursos do dispositivo
• Versão da plataforma
• Configuração da tela

Recursos do dispositivo

Para que você gerencie a disponibilidade do seu app com base nos recursos do dispositivo, o Android define IDs de recurso para todo recurso de hardware ou software que pode não estar disponível em todos os dispositivos. Por exemplo, o ID de recurso para o sensor da bússola é FEATURE_SENSOR_COMPASS, e o ID de recurso para widgets do aplicativo é FEATURE_APP_WIDGETS.

Se necessário, você pode impedir que os usuários instalem seu aplicativo quando os dispositivos não tiverem um determinado recurso. Para fazer isso, declare o recurso com um elemento <uses-feature> no arquivo do manifesto do seu app.

Por exemplo, se seu app não funciona em um dispositivo sem sensor de bússola, declare o sensor da bússola como obrigatório com a seguinte tag de manifesto:

    <manifest ... >
        <uses-feature android:name="android.hardware.sensor.compass"
                      android:required="true" />
        ...
    </manifest>
    

A Google Play Store compara os recursos necessários para seu app com os recursos disponíveis em cada dispositivo usuário para determinar se o app é compatível com o dispositivo. Se o dispositivo não tiver todos os recursos exigidos pelo app, o usuário não poderá fazer a instalação.

No entanto, se a funcionalidade principal do aplicativo não exigir um recurso do dispositivo, defina o atributo required como "false" e verifique o recurso no ambiente de execução. Se o recurso do aplicativo não estiver disponível no dispositivo atual, o recurso correspondente terá uma degradação suave. Por exemplo, você pode consultar se um recurso está disponível chamando hasSystemFeature() da seguinte maneira:

    if (!packageManager.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) {
        // This device does not have a compass, turn off the compass feature
        disableCompassFeature()
    }
    

    PackageManager pm = getPackageManager();
    if (!pm.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) {
        // This device does not have a compass, turn off the compass feature
        disableCompassFeature();
    }
    

Para mais informações sobre todos os filtros que podem ser usados para controlar a disponibilidade do seu app aos usuários na Google Play Store, consulte o documento Filtros no Google Play.

Observação: algumas permissões do sistema exigem a disponibilidade de um recurso do dispositivo de forma implícita. Por exemplo, se seu app solicitar permissão para acessar BLUETOOTH, isso requer implicitamente o recurso FEATURE_BLUETOOTH. Você pode desativar o filtro com base nesse recurso e disponibilizar seu app para dispositivos sem Bluetooth definindo o atributo required como "false" na tag <uses-feature>. Para mais informações sobre recursos de dispositivos exigidos implicitamente, consulte Permissões que implicam requisitos de recursos.

Versão da plataforma

Dispositivos diferentes podem executar versões diferentes da plataforma Android, como o Android 4.0 ou o 4.4. Cada nova versão da plataforma geralmente adiciona novas APIs que não estavam disponíveis na versão anterior. Para indicar as APIs que estão disponíveis, cada versão da plataforma especifica um nível de API. Por exemplo, o Android 1.0 é API nível 1 e o Android 4.4 é API nível 19.

O nível da API permite que você declare a versão mínima com que seu aplicativo é compatível, usando a tag de manifesto <uses-sdk> e o atributo minSdkVersion. Por exemplo, as APIs Calendar Provider foram adicionadas no Android 4.0 (API nível 14). Se seu aplicativo não funcionar sem essas APIs, declare a API 14 como a versão mínima compatível com o aplicativo.

O atributo minSdkVersion declara a versão mínima com que seu aplicativo é compatível e o atributo targetSdkVersion declara a versão mais recente em que você otimizou seu aplicativo.

No entanto, lembre-se de que os atributos no elemento <uses-sdk> são modificados pelas propriedades correspondentes no arquivo build.gradle. Portanto, se você estiver usando o Android Studio, especifique os valores minSdkVersion e targetSdkVersion:

    android {
      defaultConfig {
        applicationId 'com.example.myapp'

        // Defines the minimum API level required to run the app.
        minSdkVersion 15

        // Specifies the API level used to test the app.
        targetSdkVersion 28

        ...
      }
    }
    

Para mais informações sobre o arquivo build.gradle, consulte como configurar sua versão.

Cada nova versão do Android oferece compatibilidade com aplicativos criados com as APIs de versões anteriores da plataforma. Portanto, apps desenvolvidos com APIs Android documentadas continuarão compatíveis com versões futuras do Android.

Observação: o atributo targetSdkVersion não impede que seu aplicativo seja instalado em versões de plataforma posteriores ao valor especificado, mas é importante porque indica ao sistema se seu aplicativo precisa herdar alterações de comportamento em versões mais recentes. Se o targetSdkVersion não for atualizado para a versão mais recente, o sistema considerará que seu aplicativo exige alguns comportamentos de compatibilidade com versões anteriores ao ser executado na versão mais recente. Por exemplo, entre as alterações de comportamento no Android 4.4, os alarmes criados com as APIs AlarmManager agora são imprecisos por padrão para que o sistema possa armazenar os alarmes de aplicativos em lote e preservar a energia do sistema. Mas o sistema manterá o comportamento da API anterior para seu aplicativo se o nível da API de destino for menor que "19".

No entanto, se o aplicativo usa APIs adicionadas em uma versão mais recente da plataforma, mas não as exige para a funcionalidade principal, verifique o nível de API no ambiente de execução e faça uma degradação suave dos recursos correspondentes quando o nível da API for muito baixo. Nesse caso, defina minSdkVersion como o valor mais baixo possível para a funcionalidade principal do aplicativo e compare a versão atual do sistema, SDK_INT, com as constantes de codinome em Build.VERSION_CODES que corresponde ao nível da API que você quer verificar. Exemplo:

    if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {
        // Running on something older than API level 11, so disable
        // the drag/drop features that use <code><a href="/reference/android/content/ClipboardManager.html">ClipboardManager</a></code> APIs
        disableDragAndDrop()
    }
    

    if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {
        // Running on something older than API level 11, so disable
        // the drag/drop features that use <code><a href="/reference/android/content/ClipboardManager.html">ClipboardManager</a></code> APIs
        disableDragAndDrop();
    }
    

Configuração da tela

O Android é executado em dispositivos de vários tamanhos, de smartphones a tablets e TVs. Para categorizar dispositivos por tipo de tela, o Android define duas características para cada dispositivo: tamanho da tela (tamanho físico da tela) e densidade da tela (densidade física dos pixels na tela, conhecida como DPI na sigla em inglês). Para simplificar as diferentes configurações, o Android generaliza essas variantes em grupos que facilitam a orientação:

• Quatro tamanhos generalizados: pequeno, normal, grande e extra grande.
• Várias densidades generalizadas: mdpi (média), hdpi (alta), xhdpi (extra alta), xxhdpi (extra-extra-alta) e outros.

Por padrão, seu aplicativo é compatível com todos os tamanhos e densidades de tela, já que o sistema faz os ajustes adequados ao layout da IU e aos recursos de imagem necessários para cada tela. No entanto, é importante otimizar a experiência do usuário para cada configuração de tela adicionando layouts especializados para diferentes tamanhos de tela e imagens de bitmap otimizadas para densidades de tela comuns.

Para mais informações sobre como criar recursos alternativos para diferentes telas e como restringir seu aplicativo a determinados tamanhos de tela quando necessário, leia Compatibilidade com telas diferentes.

Como controlar a disponibilidade do seu app por motivos comerciais

Além de restringir a disponibilidade do seu app com base nas características do dispositivo, talvez seja necessário restringir a disponibilidade do app por motivos comerciais ou legais. Por exemplo, é improvável que um aplicativo que exibe horários de trens para o Metrô de Londres seja útil para usuários fora do Reino Unido. Para esse tipo de situação, a Google Play Store oferece opções de filtragem no Play Console que permitem controlar a disponibilidade do app por motivos não técnicos, como a localidade ou a operadora sem fio do usuário.

A filtragem de compatibilidade técnica (como componentes de hardware obrigatórios) sempre é baseada nas informações contidas no arquivo APK. No entanto, a filtragem por motivos não técnicos (como localidade geográfica) sempre é feita no Google Play Console.