Omówienie zgodności urządzeń

Android jest przeznaczony do działania na wielu różnych urządzeniach, takich jak telefony, tablety i telewizory. Szeroka gama urządzeń zapewnia aplikacji ogromny potencjał. Aby odnieść sukces na wszystkich urządzeniach, aplikacja musi tolerować zmienność funkcji i zapewniać elastyczny interfejs użytkownika, który dostosowuje się do różnych konfiguracji ekranu.

Aby ułatwić zachowanie zgodności z urządzeniami, Android udostępnia dynamiczną strukturę aplikacji, w której możesz podać zasoby aplikacji specyficzne dla konfiguracji w plikach statycznych, np. różne układy XML dla różnych rozmiarów ekranu. Android wczytuje 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 wygodę użytkowników na różnych urządzeniach.

W razie potrzeby możesz jednak określić wymagania dotyczące funkcji aplikacji i kontrolować, na jakich typach urządzeń można ją instalować 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 odpowiednich odbiorców.

Co oznacza „kompatybilność”?

W przypadku tworzenia aplikacji na Androida istnieją 2 rodzaje zgodności: zgodność z urządzeniem i zgodność z aplikacją.

Android to projekt open source, więc każdy producent sprzętu może stworzyć urządzenie z tym systemem operacyjnym. Urządzenie jest jednak „kompatybilne z Androidem” tylko wtedy, gdy może prawidłowo uruchamiać aplikacje napisane dla środowiska wykonawczego Androida. Szczegółowe informacje o środowisku wykonawczym Androida są określone w programie zgodności z Androidem. Aby urządzenie było uznawane za zgodne, musi przejść pakiet testów zgodności (CTS).

Jako deweloper aplikacji nie musisz się martwić, czy urządzenie jest zgodne z Androidem, ponieważ tylko urządzenia zgodne z Androidem mają Sklep 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 sprawdzić, czy aplikacja jest zgodna z każdą potencjalną konfiguracją urządzenia. Android jest używany na wielu urządzeniach o różnych konfiguracjach, dlatego niektóre funkcje nie są dostępne na wszystkich urządzeniach. Na przykład niektóre urządzenia nie mają czujnika kompasu. Jeśli jedna z kluczowych funkcji aplikacji wymaga kompasu, wtedy aplikacja jest zgodna tylko z urządzeniami, które mają tę funkcję.

Kontrolowanie dostępności aplikacji na urządzeniach

Android obsługuje różne funkcje, które aplikacja może wykorzystywać 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 ograniczenie dostępności aplikacji na urządzeniach na podstawie wymaganych przez nią funkcji.

Aby dotrzeć do jak największej liczby użytkowników, obsługuj jak najwięcej konfiguracji urządzeń za pomocą jednego pliku APK lub AAB. W większości przypadków możesz to zrobić, wyłączając opcjonalne funkcje w czasie działania i udostępniając zasoby aplikacji z alternatywnymi rozwiązaniami dla różnych konfiguracji, np. różne układy dla różnych rozmiarów ekranu. W razie potrzeby możesz ograniczyć dostępność aplikacji w Google Play do określonych urządzeń na podstawie tych cech:

• Funkcje urządzenia
• Wersja platformy
• Konfiguracja ekranu

Funkcje urządzenia

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

W razie potrzeby możesz uniemożliwić użytkownikom instalowanie aplikacji, gdy ich urządzenia nie mają niezbędnej funkcji. W tym celu zadeklaruj tę funkcję za pomocą elementu <uses-feature> w pliku manifestu aplikacji.

Jeśli na przykład aplikacja nie ma sensu na urządzeniu bez czujnika kompasu, możesz zadeklarować czujnik kompasu jako wymaganie 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 aplikację z funkcjami dostępnymi na urządzeniu każdego użytkownika, aby określić, czy aplikacja jest zgodna z danym 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ź funkcję urządzenia w czasie działania aplikacji. Jeśli funkcja aplikacji nie jest dostępna na bieżącym urządzeniu, przeprowadź łagodną degradację odpowiedniej funkcji aplikacji. Możesz na przykład sprawdzić, czy funkcja jest dostępna, wywołując hasSystemFeature() w ten sposób:

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

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 Filtrów w Google Play.

Wersja platformy

Różne urządzenia mogą działać na różnych wersjach platformy Android, np. Androidzie 12 lub Androidzie 13. Każda kolejna wersja platformy często zawiera interfejsy API niedostępne w poprzedniej wersji. Aby wskazać, który zestaw interfejsów API jest dostępny, 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:

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

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, więc Twoja aplikacja jest zgodna z przyszłymi wersjami Androida, a jednocześnie korzysta z udokumentowanych interfejsów API Androida.

Jeśli jednak Twoja aplikacja korzysta z interfejsów API dodanych w nowszej wersji platformy, ale nie są one wymagane do jej podstawowego działania, sprawdzaj poziom interfejsu API w czasie działania i łagodnie wyłączaj odpowiednie funkcje, gdy poziom interfejsu API jest zbyt niski. W takim przypadku ustaw wartość minSdkVersion na najniższą możliwą wartość dla podstawowej funkcjonalności aplikacji, a następnie porównaj bieżącą wersję systemu SDK_INT ze stałą nazwą kodową w Build.VERSION_CODES, która odpowiada poziomowi interfejsu API, który chcesz sprawdzić, jak pokazano w poniższym przykładzie:

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

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 jest używany na urządzeniach o różnych rozmiarach, takich jak telefony, tablety i telewizory. Aby podzielić urządzenia na kategorie według typu ekranu, Android określa dla każdego urządzenia 2 cechy: rozmiar ekranu (fizyczny rozmiar ekranu) i gęstość ekranu (fizyczna gęstość pikseli na ekranie, znana jako DPI). Aby uprościć różne konfiguracje, Android uogólnia te warianty w grupy, które ułatwiają kierowanie:

• 4 ogólne rozmiary: mały, normalny, duży i bardzo duży.
• Kilka uogólnionych gęstości: mdpi (średnia), hdpi (wysoka), xhdpi (bardzo wysoka), xxhdpi (bardzo-bardzo wysoka) i inne

Domyślnie aplikacja jest zgodna ze wszystkimi rozmiarami i gęstościami ekranu, ponieważ system dostosowuje układ interfejsu i zasoby obrazów do każdego ekranu. Dostarczaj zoptymalizowane obrazy bitmapowe dla typowych gęstości ekranu.

Optymalizuj wrażenia użytkowników, stosując w jak największym stopniu elastyczne układy. W przypadku układów przeznaczonych do dużych zmian konfiguracji, takich jak orientacja pionowa i pozioma czy duże i małe rozmiary okien, rozważ udostępnienie alternatywnych układów, które są elastyczne w przypadku mniejszych zmian konfiguracji. Poprawia to wrażenia użytkowników na urządzeniach takich jak tablety, telefony i urządzenia składane. Jest to też przydatne, gdy rozmiar okien zmienia się w trybie wielu okien.

Informacje o tym, jak tworzyć alternatywne zasoby dla różnych ekranów i w razie potrzeby ograniczać dostępność aplikacji do określonych rozmiarów ekranu, znajdziesz w omówieniu zgodności z ekranami oraz w wytycznych dotyczących jakości aplikacji na duże ekrany.

Kontrolowanie dostępności aplikacji z przyczyn biznesowych

Oprócz ograniczenia dostępności aplikacji na podstawie cech urządzenia możesz też ograniczyć ją z przyczyn biznesowych lub prawnych. W takiej sytuacji Sklep Google Play udostępnia w Konsoli Play opcje filtrowania, które pozwalają kontrolować dostępność aplikacji z przyczyn nietechnicznych, 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 przyczyn nietechnicznych, takich jak lokalizacja geograficzna, jest zawsze obsługiwane w Konsoli Google Play.

Dodatkowe zasoby:

Omówienie zasobów aplikacji

Informacje o tym, jak aplikacje na Androida są skonstruowane, aby oddzielić zasoby aplikacji od kodu, w tym o tym, jak udostępniać alternatywne zasoby dla określonych konfiguracji urządzeń.

Filtry w Google Play

Informacje o różnych sposobach, w jakie Sklep Google Play może uniemożliwiać instalowanie aplikacji na różnych urządzeniach.

Uprawnienia na Androidzie

Jak Android ogranicza dostęp aplikacji do niektórych interfejsów API za pomocą systemu uprawnień, który wymaga zgody użytkownika na korzystanie z tych interfejsów API przez aplikację.