Visão geral de compatibilidade de dispositivos

O Android foi projetado para funcionar em vários dispositivos diferentes, como smartphones, tablets e televisões. A variedade de dispositivos oferece um enorme potencial público para seu app. Para que seu app tenha sucesso em todos os dispositivos, ele precisa toleram a variabilidade de atributos e fornecem uma interface do usuário flexível em diferentes configurações de tela.

Para ajudar na compatibilidade do dispositivo, o Android oferece um framework dinâmico de apps. em que é possível fornecer configurações específicas recursos de app em estáticas como diferentes layouts XML para tamanhos de tela diferentes. Android, então carrega os recursos apropriados com base na configuração atual do dispositivo. Com para o design do seu aplicativo e recursos adicionais do aplicativo, você pode publicar um um único pacote de aplicativo (APK) que otimiza a experiência do usuário em vários de dispositivos.

Se necessário, no entanto, é possível especificar os requisitos de recursos do aplicativo e controlar quais tipos de dispositivos podem instalar seu app a partir da Google Play Store. Este documento explica como controlar quais dispositivos têm acesso aos seus e como prepará-los para alcançar o público certo.

O que significa "compatibilidade"?

Com relação ao desenvolvimento para Android, existem dois tipos de compatibilidade: compatibilidade do dispositivo e compatibilidade do app.

Como o Android é um projeto de código aberto, qualquer fabricante de hardware pode criar um dispositivo que execute o sistema operacional Android. Mas 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 Android ambiente de execução são definidos pela No Android programa de compatibilidade. Cada dispositivo precisa passar no conjunto de teste de compatibilidade (CTS) para ser considerado compatível.

Como desenvolvedor de aplicativos, você não precisa se preocupar se um dispositivo Compatível com Android, porque apenas dispositivos compatíveis com Android incluem Google Play Store Assim, se um usuário instala seu aplicativo na Google Play Store, usam um dispositivo compatível com Android.

No entanto, é preciso considerar se o app é compatível com cada uma possíveis configurações do dispositivo. Como o Android é executado em vários configurações de rede, alguns recursos não estão disponíveis em todos os dispositivos. Por exemplo, algumas os dispositivos podem não ter um sensor de bússola. Se o recurso principal do app exigir um sensor de bússola, seu aplicativo será compatível apenas com dispositivos que incluem esse recurso.

Controlar a disponibilidade do app para dispositivos

O Android oferece suporte a vários recursos que seu app pode usar na plataforma APIs de terceiros. Alguns recursos são baseados em hardware, como um sensor de bússola. alguns são baseados em software, como widgets de apps, e outros dependem da versão da plataforma. Nem todos os dispositivos oferecem suporte a todos os recursos, portanto, talvez seja necessário controlar o comportamento disponibilidade para dispositivos com base nos recursos exigidos pelo app.

Para alcançar a maior base de usuários possível para seu app, ofereça suporte ao máximo as configurações de dispositivo possíveis usando um único APK ou AAB. Na maioria das situações, é possível fazer isso desativando recursos opcionais no tempo de execução e fornecendo aplicativo recursos com alternativas para configurações diferentes, como diferentes layouts para diferentes tamanhos de tela. Se necessário, é possível restringir o para determinados dispositivos na Google Play Store com base no seguinte características do dispositivo:

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

Recursos do dispositivo

Para gerenciar a disponibilidade do app com base nos recursos do dispositivo, o Android define IDs de recurso de qualquer recurso de hardware ou software que não esteja disponíveis em todos os dispositivos. Por exemplo, o ID de recurso do sensor da bússola é FEATURE_SENSOR_COMPASS, e o ID do recurso para widgets de app é FEATURE_APP_WIDGETS.

Se necessário, você pode impedir que os usuários instalem seu app quando o não fornecem um recurso necessário ao declarar o recurso usando uma <uses-feature> na tag do seu app arquivo de manifesto.

Por exemplo, se o app não fizer sentido em um dispositivo que não tem uma bússola. você pode declarar o sensor da bússola como um requisito com o seguinte tag do manifesto:

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

A Google Play Store compara os recursos necessários para o app com os disponíveis no dispositivo de cada usuário para determinar se seu aplicativo compatíveis com todos os dispositivos. Se o dispositivo não tiver todos os recursos app exigir, o usuário não poderá instalá-lo.

No entanto, se a funcionalidade principal do seu app não exigir uma do dispositivo, defina o required como "false" e verifique o recurso do dispositivo durante a execução. Se o recurso do aplicativo não estiver disponível no dispositivo atual, faça uma degradação suave do recurso do app correspondente. Por exemplo, é possível consultar se um atributo disponíveis chamando hasSystemFeature() assim:

Kotlin

if (!packageManager.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) {
    // This device doesn't have a compass. Turn off the compass feature.
    disableCompassFeature()
}

Java

PackageManager pm = getPackageManager();
if (!pm.hasSystemFeature(PackageManager.FEATURE_SENSOR_COMPASS)) {
    // This device doesn't have a compass. Turn off the compass feature.
    disableCompassFeature();
}

Para informações sobre todos os filtros que você pode usar para controlar a disponibilidade do seu app na Google Play Store, consulte a Filtros no Google Play na documentação do Google Cloud.

Observação:algumas permissões do sistema implicitamente exigem a disponibilidade de um recurso do dispositivo. Por exemplo, se o seu app solicita permissão para acessar BLUETOOTH, isso requer, implicitamente, FEATURE_BLUETOOTH do dispositivo. Você pode desativar o filtro com base nesse recurso e fazer seu app disponível para dispositivos sem Bluetooth configurando o atributo required para "false" no tag <uses-feature>. Para mais informações sobre o os recursos necessários do dispositivo, conferir Permissões que implicam requisitos de recurso.

Versão da plataforma

Dispositivos diferentes podem executar versões distintas da plataforma Android, como como o Android 12 ou o Android 13. Cada nova versão da plataforma geralmente adiciona APIs não estava disponível na versão anterior. Para indicar quais são as APIs disponível, cada versão de plataforma especifica uma Nível da API. Por exemplo, o Android 12 é o nível 31 da API, e o Android 13 é o nível 33 da API.

Você deve especificar o minSdkVersion e targetSdkVersion valores no seu arquivo build.gradle:

Kotlin

android {
    defaultConfig {
        applicationId = "com.example.myapp"

        // Defines the minimum API level required to run the app.
        minSdkVersion(30)

        // Specifies the API level used to test the app.
        targetSdkVersion(33)
        ...
    }
}

Groovy

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

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

        // Specifies the API level used to test the app.
        targetSdkVersion 33
        ...
    }
}

Para mais informações sobre o arquivo build.gradle, leia Configure seu build.

Cada versão sucessiva do Android oferece compatibilidade para apps criados usando as APIs de versões anteriores da plataforma, para que o aplicativo seja compatível com versões futuras do Android usando as APIs documentadas do Android.

Observação:o atributo targetSdkVersion não impede para que seu app não seja instalado em versões da plataforma mais recentes que as o valor especificado, mas é importante porque indica ao sistema se o app herda mudanças de comportamento nas versões mais recentes. Se você não atualize targetSdkVersion para a versão mais recente, o sistema pressupõe que o app exige compatibilidade com versões anteriores ao ser executado no versão mais recente.

No entanto, se seu aplicativo usa APIs adicionadas em uma versão mais recente da plataforma, mas para a funcionalidade principal, verifique o nível da API em o ambiente de execução e degradação suave dos recursos correspondentes quando o nível da API é é muito baixo. Nesse caso, defina minSdkVersion como o valor mais baixo. possível para a funcionalidade principal do seu app e, em seguida, compare as versão, SDK_INT, para a constante de codinome Build.VERSION_CODES correspondente ao nível da API que você quer verificar, conforme mostrado abaixo exemplo:

Kotlin

if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {
    // Running on something older than API level 11, so disable
    // the drag and drop features that use ClipboardManager APIs.
    disableDragAndDrop()
}

Java

if (Build.VERSION.SDK_INT < Build.VERSION_CODES.HONEYCOMB) {
    // Running on something older than API level 11, so disable
    // the drag and drop features that use ClipboardManager APIs.
    disableDragAndDrop();
}

Configuração da tela

O Android é executado em dispositivos de vários tamanhos, como smartphones, tablets e TVs. Para categorizam dispositivos pelo tipo de tela, o Android define duas características para cada dispositivo: tamanho da tela (o tamanho físico da tela) e densidade da tela (a densidade física dos pixels na tela, conhecida como DPI. Para simplificar as diferentes do Compute Engine, o Android generaliza essas variantes em grupos que as tornam mais fáceis de segmentar:

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

Por padrão, seu app é compatível com todos os tamanhos e densidades de tela, porque o sistema faz ajustes no layout da IU e nos recursos de imagem conforme necessários para cada tela. Fornecer imagens de bitmap otimizadas para telas comuns densidades

Otimize a experiência do usuário usando layouts flexíveis o máximo possível. Onde há layouts para grandes mudanças de configuração, como retrato e paisagem ou janelas grandes versus pequenas, considere oferecer alternativas layouts flexíveis para pequenas mudanças na configuração. Isso melhora a experiência do usuário em formatos como tablets, smartphones e dispositivos dobráveis. Ela também ajuda quando as janelas mudam de tamanho no modo de várias janelas.

Para informações sobre como criar recursos alternativos para diferentes telas e como restringir seu app a determinados tamanhos de tela, quando necessário, leia compatibilidade de tela visão geral e consulte a app de tela grande diretrizes de qualidade.

Controle a disponibilidade do app por motivos comerciais

Além de restringir a disponibilidade do app com base no dispositivo você precisa restringir a disponibilidade do app para empresas ou por motivos legais. Para esse tipo de situação, a Google Play Store oferece opções de filtragem no Play Console que permitem controlar as ações disponibilidade por motivos não técnicos, como localidade do usuário ou conexão sem fio operadora.

Filtragem para compatibilidade técnica (como o hardware necessário) são sempre baseados nas informações contidas no APK ou AAB. . Mas a filtragem por motivos não técnicos, como localização geográfica locale, sempre é tratada na Google Play Console:

Recursos adicionais:

Visão geral dos recursos de app

Informações sobre como os apps Android são estruturados para separá-los recursos do código do aplicativo, incluindo como você pode fornecer recursos para configurações específicas do dispositivo.

Filtros no Google Play

Informações sobre as diferentes maneiras como a Google Play Store pode impedir sua seja instalado em dispositivos diferentes.

Permissões no Android

Como o Android restringe o acesso de apps a determinadas APIs com um sistema de permissões que exige o consentimento do usuário para que o app use essas APIs.