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 ogromną potencjalną grupę odbiorców aplikacji. Aby aplikacja działała prawidłowo na wszystkich urządzeniach, musi tolerować zmienność funkcji i zapewniać elastyczny interfejs, który dostosowuje się do różnych konfiguracji ekranu.

Aby ułatwić zapewnienie zgodności z urządzeniami, Android udostępnia dynamiczną platformę aplikacji, w której możesz podawać zasoby aplikacji zależne od 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. Jeśli przemyślisz projekt aplikacji i dodatkowe zasoby, 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 kontrolować, na jakich typach urządzeń można zainstalować 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 odpowiednich odbiorców.

Co oznacza „zgodność”?

W przypadku programowania na Androida istnieją 2 rodzaje zgodności: zgodność urządzenia i zgodność aplikacji.

Ponieważ Android jest projektem open source, każdy producent sprzętu może stworzyć urządzenie z systemem operacyjnym Android. Urządzenie jest jednak „zgodne 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 systemem Android. Aby urządzenie zostało uznane za zgodne, musi przejść testy Compatibility Test Suite (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 więc użytkownik zainstaluje Twoją aplikację ze Sklepu Google Play, oznacza to, że korzysta z urządzenia zgodnego z Androidem.

Musisz jednak rozważyć, czy aplikacja jest zgodna z każdą potencjalną konfiguracją urządzenia. Android działa na wielu różnych konfiguracjach urządzeń, 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 główna funkcjonalność aplikacji wymaga 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ó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 każde urządzenie obsługuje wszystkie funkcje, więc może być konieczne kontrolowanie dostępności aplikacji na urządzeniach na podstawie wymaganych funkcji aplikacji.

Aby aplikacja miała jak największą bazę 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óżnymi układami 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 zarządzać dostępnością aplikacji na podstawie funkcji urządzenia, Android definiuje identyfikatory funkcji dla każdej funkcji sprzętowej lub programowej, która może nie być dostępna 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, jeśli ich urządzenia nie obsługują wymaganej funkcji. Aby to zrobić, zadeklaruj 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 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 może 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. 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 Filtry w Google Play.

Wersja platformy

Na różnych urządzeniach mogą działać różne wersje platformy Androida, np. Android 12 lub Android 13. Każda kolejna wersja platformy często dodaje 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(36)
        ...
    }
}

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

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, gdy korzysta z udokumentowanych interfejsów API Androida.

Jeśli jednak aplikacja używa interfejsów API dodanych w nowszej wersji platformy, ale nie wymaga ich do działania podstawowych funkcji, sprawdź poziom interfejsu API w czasie działania i przeprowadź łagodną degradację odpowiednich funkcji, gdy poziom interfejsu API będzie zbyt niski. W takim przypadku ustaw minSdkVersion na najniższą możliwą wartość dla podstawowej funkcji aplikacji, a następnie porównaj bieżącą wersję systemu SDK_INT ze stałą nazwy kodowej w Build.VERSION_CODES, która odpowiada poziomowi interfejsu API, który chcesz sprawdzić, jak w tym 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 działa na urządzeniach o różnych rozmiarach, takich jak telefony, tablety i telewizory. To categorize devices by their screen type, Android defines two characteristics for each device: screen size (the physical size of the screen) and screen density (the physical density of the pixels on the screen, known as DPI). Aby uprościć różne konfiguracje, Android uogólnia te warianty na grupy, które ułatwiają kierowanie:

• 4 uogólnione rozmiary: mały, normalny, duży i bardzo duży;
• Kilka uogólnionych gęstości: mdpi (średnia), hdpi (wysoka), xhdpi (bardzo wysoka), xxhdpi (wyjątkowo 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. Udostępniaj zoptymalizowane obrazy bitmapowe dla typowych gęstości ekranu.

Zoptymalizuj wrażenia użytkowników, stosując w jak największym stopniu elastyczne układy. Jeśli masz układy przeznaczone do dużych zmian konfiguracji, np. orientacji pionowej i poziomej lub dużych i małych rozmiarów 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. Pomaga też, gdy okna zmieniają rozmiar w trybie wielu okien.

Informacje o tym, jak tworzyć zasoby alternatywne dla różnych ekranów i jak w razie potrzeby ograniczyć działanie aplikacji do określonych rozmiarów ekranu, znajdziesz w omówieniu zgodności ekranów i wskazówkach 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że być konieczne ograniczenie jej dostępności ze względów biznesowych lub prawnych. W takich sytuacjach Sklep Google Play udostępnia w Konsoli Play opcje filtrowania, które pozwalają kontrolować dostępność aplikacji z powodów nietechnicznych, takich jak lokalizacja użytkownika czy operator sieci komórkowej.

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. Jednak filtrowanie z powodów nietechnicznych, takich jak lokalizacja geograficzna, zawsze odbywa się 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 jej kodu, w tym o tym, jak można udostępniać zasoby alternatywne dla określonych konfiguracji urządzeń.

Filtry w Google Play

Informacje o różnych sposobach, w jakie Sklep Google Play może uniemożliwić instalację 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 przez aplikację.