Ta strona została przetłumaczona przez Cloud Translation API.

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. Dzięki przemyślanemu projektowi aplikacji i dodatkowym zasobom możesz opublikować jeden pakiet aplikacji (APK), który zoptymalizuje wrażenia użytkowników na różnych urządzeniach.

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, i 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ądzeniem i zgodność 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 „kompatybilne z Androidem” tylko wtedy, gdy może prawidłowo uruchamiać aplikacje napisane dla środowiska wykonawczego Androida. Szczegóły dotyczące środowiska 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 wziąć pod uwagę, czy Twoja aplikacja jest zgodna z każdą możliwą konfiguracją urządzenia. Android działa na wielu urządzeniach z różnymi konfiguracjami, dlatego niektóre funkcje są dostępne tylko 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 różne funkcje, których aplikacja może używać za pomocą interfejsów API platformy. Niektóre funkcje są oparte na sprzęcie, np. czujnik kompasu, inne na oprogramowaniu, np. widżety aplikacji, a jeszcze 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 uzyskać jak największą liczbę użytkowników aplikacji, uwzględnij w niej jak najwięcej konfiguracji urządzeń, używając jednego pliku APK lub AAB. 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. W razie potrzeby możesz ograniczyć dostępność aplikacji na określonych urządzeniach w Sklepie Google Play na podstawie tych cech urządzenia:

Funkcje urządzenia
Wersja platformy
Konfiguracja ekranu

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, jeśli ich urządzenia nie obsługują niezbędnej funkcji. Aby to zrobić, ogłoś tę funkcję za pomocą elementu <uses-feature> w pliku manifestu aplikacji.

Jeśli na przykład aplikacja nie ma sensu na urządzeniu, które nie ma czujnika kompasu, możesz zadeklarować czujnik kompasu 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 funkcjonalność aplikacji nie wymaga funkcji urządzenia, ustaw atrybut required na "false" i sprawdź, czy funkcja urządzenia jest dostępna w czasie wykonywania. 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.

Uwaga: niektóre uprawnienia systemowe wymagają domyślnie dostępu do funkcji urządzenia. Jeśli na przykład aplikacja prosi o dostęp do funkcji BLUETOOTH, to oznacza, że pośrednio wymaga funkcji urządzenia FEATURE_BLUETOOTH. Możesz wyłączyć filtrowanie na podstawie tej funkcji i uzyskać dostęp do aplikacji na urządzeniach bez Bluetooth, ustawiając atrybut required na "false" w tagu <uses-feature>. Więcej informacji o funkcjach urządzenia wymaganych pośrednio znajdziesz w artykule Uprawnienia, które zakładają wymagania dotyczące funkcji.

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 to poziom API 31, a Android 13 to poziom API 33.

W pliku build.gradle musisz podać wartości minSdkVersion i targetSdkVersion:

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.

Uwaga: atrybut targetSdkVersion nie uniemożliwia zainstalowania aplikacji na wersjach platformy wyższych niż określona wartość, ale jest ważny, ponieważ wskazuje systemowi, czy aplikacja dziedziczy zmiany zachowania w nowszych wersjach. Jeśli nie zaktualizujesz targetSdkVersion do najnowszej wersji, system uzna, że Twoja aplikacja wymaga zgodności wstecznej podczas działania w najnowszej wersji.

Jeśli jednak Twoja aplikacja korzysta z interfejsów API dodanych w później wersji platformy, ale nie wymaga ich do obsługi głównej 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 parametr 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 o różnych rozmiarach, takich jak telefony, tablety i telewizory. Aby kategoryzować 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 dużych zmian konfiguracji, np. układy pionowy i poziomy 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.

Zarządzanie dostępnością aplikacji ze względów biznesowych

Oprócz ograniczenia dostępności aplikacji na podstawie cech urządzenia możesz też ograniczyć dostępność aplikacji z powodó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 czy 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, odbywa się zawsze w Konsoli Google Play.

Dodatkowe zasoby:

Przegląd zasobów 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, w jakie Sklep Google Play może uniemożliwić zainstalowanie aplikacji 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ę.

Dalej

Informacje o zgodności ekranu