Omówienie zgodności urządzeń

Android jest przeznaczony do działania na wielu różnych urządzeniach, takich jak telefony, tablety i telewizory. Różnorodność urządzeń zapewnia Twojej aplikacji ogromną potencjalną grupę odbiorców. Aby aplikacja była skuteczna na wszystkich urządzeniach, musi uwzględniać zmienność funkcji i zapewnić elastyczny interfejs użytkownika, który dostosowuje się do różnych konfiguracji ekranu.

Aby ułatwić zgodność z urządzeniami, Android udostępnia dynamiczną platformę aplikacji, w której możesz udostępniać zasoby aplikacji zależne od konfiguracji w plikach statycznych, takich jak różne układy XML dla różnych rozmiarów ekranu. Następnie Android pobiera odpowiednie zasoby na podstawie bieżącej konfiguracji urządzenia. Biorąc pod uwagę wygląd aplikacji i dodatkowe zasoby, możesz opublikować pojedynczy pakiet aplikacji (APK), który zapewni użytkownikom większą wygodę korzystania z różnych urządzeń.

W razie potrzeby możesz jednak określić wymagania dotyczące funkcji aplikacji i określić, na jakich typach urządzeń można instalować aplikację ze Sklepu Google Play. Z tego dokumentu dowiesz się, jak kontrolować, które urządzenia mają dostęp do Twoich aplikacji, oraz jak przygotować aplikacje, aby docierały do właściwych odbiorców.

Co oznacza „zgodność”?

W przypadku tworzenia aplikacji na Androida występują 2 rodzaje zgodności: zgodność z urządzeniemzgodność z aplikacją.

Ponieważ Android jest projektem typu open source, każdy producent sprzętu może zbudować urządzenie z systemem operacyjnym Android. Urządzenie jest jednak „zgodne z Androidem” tylko wtedy, gdy może prawidłowo uruchamiać aplikacje napisane pod kątem środowiska wykonawczego Androida. Szczegółowe informacje o środowisku wykonywania aplikacji na Androida są określone w programie zgodności z Androidem. Aby urządzenie zostało uznane za zgodne, musi przejść test Compatibility Test Suite (CTS).

Jako deweloper aplikacji nie musisz się martwić o to, czy urządzenie jest zgodne z Androidem, ponieważ tylko zgodne urządzenia mają dostęp do Sklepu Google Play. Jeśli użytkownik zainstaluje Twoją aplikację ze Sklepu Google Play, oznacza to, że korzysta z urządzenia zgodnego z Androidem.

Musisz jednak zastanowić się, czy Twoja aplikacja jest zgodna z każdą potencjalną konfiguracją urządzenia. Android działa na wielu urządzeniach z różnymi konfiguracjami, dlatego niektóre funkcje są niedostępne na niektórych urządzeniach. Na przykład niektóre urządzenia nie mają czujnika kompasu. Jeśli jedna z kluczowych funkcji aplikacji wymaga użycia czujnika kompasu, aplikacja jest zgodna tylko z urządzeniami, które mają tę funkcję.

Zarządzanie dostępnością aplikacji na urządzeniach

Android obsługuje szereg funkcji, z których Twoja aplikacja może korzystać za pomocą interfejsów API platformy. Niektóre funkcje są oparte na sprzęcie (np. czujnik kompasu), inne (np. widżety) aplikacji, a inne zależą od wersji platformy. Nie wszystkie urządzenia obsługują wszystkie funkcje, więc może być konieczne kontrolowanie dostępności aplikacji na urządzeniach na podstawie wymaganych funkcji.

Aby Twoja aplikacja miała jak największą liczbę użytkowników, zadbaj o obsługę jak największej liczby konfiguracji urządzeń za pomocą jednego pliku APK lub pakietu aplikacji na Androida. W większości przypadków możesz to zrobić, wyłączając opcjonalne funkcje w czasie wykonywania i udostępniając zasoby aplikacji z alternatywami dla różnych konfiguracji, np. różne układy dla różnych rozmiarów ekranu. Jeśli to konieczne, możesz ograniczyć dostępność aplikacji w Sklepie Google Play na określonych urządzeniach na podstawie tych cech urządzenia:

Funkcje urządzenia

Aby umożliwić zarządzanie dostępnością aplikacji na podstawie funkcji urządzenia, Android definiuje identyfikatory funkcji dla funkcji sprzętowych i programowych, które mogą być niedostępne na niektórych urządzeniach. Na przykład identyfikator funkcji dla czujnika kompasu to FEATURE_SENSOR_COMPASS, a identyfikator funkcji dla widżetów aplikacji to FEATURE_APP_WIDGETS.

W razie potrzeby możesz uniemożliwić użytkownikom instalowanie aplikacji, gdy ich urządzenia nie obsługują niezbędnej funkcji. Aby to zrobić, ogłoś tę funkcję za pomocą elementu <uses-feature>pliku manifestu aplikacji.

Jeśli na przykład aplikacja nie ma sensu na urządzeniu, które nie ma czujnika kompasu, możesz zadeklarować ten czujnik jako wymagany za pomocą tego tagu manifestu:

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

Sklep Google Play porównuje funkcje wymagane przez Twoją aplikację z funkcjami dostępnymi na urządzeniu każdego użytkownika, aby określić, czy aplikacja jest zgodna z każdym urządzeniem. Jeśli urządzenie nie ma wszystkich funkcji wymaganych przez aplikację, użytkownik nie będzie mógł jej zainstalować.

Jeśli jednak główna funkcja aplikacji nie wymaga funkcji urządzenia, ustaw atrybut required na "false" i sprawdź, czy funkcja urządzenia jest dostępna w czasie działania. Jeśli funkcja aplikacji jest niedostępna na bieżącym urządzeniu, przeprowadź łagodną degradację odpowiedniej funkcji aplikacji. Możesz na przykład sprawdzić, czy dana funkcja jest dostępna, wywołując funkcję hasSystemFeature()w ten sposób:

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();
}

Informacje o wszystkich filtrach, których możesz używać do kontrolowania dostępności aplikacji w Sklepie Google Play, znajdziesz w dokumentacji Filtry w Google Play.

Wersja platformy

Na różnych urządzeniach mogą działać różne wersje platformy Android, np. Android 12 lub Android 13. Każda kolejna wersja platformy często zawiera interfejsy API niedostępne w poprzedniej wersji. Aby wskazać, które interfejsy API są dostępne, każda wersja platformy określa poziom interfejsu API. Na przykład Android 12 jest na poziomie API 31, a Android 13 to API 33.

W pliku build.gradle musisz podać wartości minSdkVersiontargetSdkVersion:

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
        ...
    }
}

Więcej informacji o pliku build.gradle znajdziesz w artykule Konfigurowanie kompilacji.

Każda kolejna wersja Androida zapewnia zgodność z aplikacjami utworzonymi przy użyciu interfejsów API z poprzednich wersji platformy, dzięki czemu Twoja aplikacja jest zgodna z przyszłościowymi wersjami Androida, a jednocześnie korzysta z udokumentowanych interfejsów API Androida.

Jeśli jednak Twoja aplikacja korzysta z interfejsów API dodanych w późniejszej wersji platformy, ale nie są one wymagane do jej podstawowej funkcjonalności, sprawdź poziom interfejsu API w czasie wykonywania i łagodnie zdegraduj odpowiednie funkcje, gdy poziom interfejsu API jest zbyt niski. W tym przypadku ustaw minSdkVersion na najniższą możliwą wartość dla głównej funkcji aplikacji, a potem porównaj bieżącą wersję systemu SDK_INT z wartością stałej nazwy kodu Build.VERSION_CODES, która odpowiada poziomowi interfejsu API, który chcesz sprawdzić. Oto przykład:

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();
}

Konfiguracja ekranu

Android działa na urządzeniach różnych rozmiarów, takich jak telefony, tablety i telewizory. Aby pogrupować urządzenia według typu ekranu, Android definiuje dla każdego z nich 2 cechy: rozmiar ekranu (fizyczny rozmiar ekranu) i gęstość ekranu (fizyczna gęstość pikseli na ekranie, czyli DPI). Aby uprościć różne konfiguracje, Android ogólnie łączy te warianty w grupy, które ułatwiają ich kierowanie:

  • 4 ogólne rozmiary: mały, normalny, duży i bardzo duży.
  • kilka ogólnych wartości gęstości: mdpi (średnia), hdpi (wysoka), xhdpi (bardzo wysoka), xxhdpi (bardzo wysoka) i inne;

Domyślnie aplikacja jest zgodna ze wszystkimi rozmiarami i gęstościami ekranu, ponieważ system dostosowuje układ interfejsu użytkownika i zasoby obrazów do potrzeb poszczególnych ekranów. Prześlij zoptymalizowane obrazy mapy bitowej dla typowych gęstości ekranu.

Zoptymalizuj wrażenia użytkowników, stosując elastyczne układy. Jeśli istnieją układy przeznaczone do wprowadzania dużych zmian w konfiguracji, np. układy pionowy i położny lub układy z dużą i małą wielkością okna, rozważ udostępnienie alternatywnych układów, które można elastycznie dostosować do mniejszych zmian w konfiguracji. Dzięki temu użytkownicy będą mogli lepiej korzystać z urządzeń takich jak tablety, telefony i urządzenia składane. Pomaga to również, gdy okna zmieniają rozmiar w trybie wielu okien.

Informacje o tworzeniu zasobów alternatywnych na potrzeby różnych ekranów oraz o ograniczaniu dostępności aplikacji do określonych rozmiarów ekranu znajdziesz w artykule Omówienie zgodności z ekranem i w wytycznych dotyczących jakości aplikacji na duże ekrany.

Kontrolowanie dostępności aplikacji z powodów biznesowych

Oprócz ograniczenia dostępności aplikacji na podstawie cech urządzenia możesz też ograniczyć dostępność aplikacji ze względów biznesowych lub prawnych. W takich przypadkach w Konsoli Play dostępne są opcje filtrowania, które umożliwiają kontrolowanie dostępności aplikacji z nietechnicznych powodów, takich jak lokalizacja użytkownika lub operator sieci bezprzewodowej.

Filtrowanie pod kątem zgodności technicznej (np. wymaganych komponentów sprzętowych) zawsze odbywa się na podstawie informacji zawartych w pliku APK lub AAB. Filtrowanie z powodów nietechnicznych, np. ze względu na język, zawsze odbywa się w Konsoli Google Play.

Dodatkowe zasoby:

Omówienie zasobów dotyczących aplikacji
Informacje o strukturze aplikacji na Androida, która umożliwia oddzielenie zasobów aplikacji od kodu aplikacji, w tym o tym, jak udostępniać alternatywne zasoby w przypadku określonych konfiguracji urządzenia.
Filtry w Google Play
Informacje o różnych sposobach blokowania instalacji aplikacji przez Sklep Google Play na różnych urządzeniach.
Uprawnienia w Androidzie
Jak Android ogranicza dostęp aplikacji do określonych interfejsów API za pomocą systemu uprawnień, który wymaga zgody użytkownika na korzystanie z tych interfejsów przez aplikację.