Omówienie zgodności urządzeń

Android działa na wielu różnych urządzeniach, np. na telefonach, tabletach i telewizorach. Różnorodność urządzeń może zapewnić Twojej aplikacji szerokie grono odbiorców. Aby aplikacja z powodzeniem działała na wszystkich urządzeniach, musi tolerować zmienność funkcji i mieć elastyczny interfejs, który dostosowuje się do różnych konfiguracji ekranu.

Aby zapewnić zgodność z urządzeniami, Android udostępnia dynamiczną platformę aplikacji, w której możesz udostępniać zasoby aplikacji związane z konfiguracją w plikach statycznych (np. różne układy XML w zależności od rozmiaru ekranu). Android wczyta wtedy odpowiednie zasoby na podstawie bieżącej konfiguracji urządzenia. Przemyślając projekt aplikacji i dodatkowe zasoby, możesz opublikować pakiet z jednym pakietem aplikacji (APK), który optymalizuje 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 ją zainstalować 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 dotarły do właściwych odbiorców.

Co oznacza „zgodność”?

W przypadku tworzenia aplikacji na Androida wyróżniamy 2 rodzaje zgodności: zgodność urządzenia i zgodność aplikacji.

Android to projekt open source, więc każdy producent sprzętu może stworzyć urządzenie z tym systemem. Jednak urządzenie jest „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ślane w programie zgodności z Androidem. Aby urządzenie zostało uznane za zgodne, musi spełniać wymagania zgodności z pakietem CTS (Compatibility Test Suite).

Deweloper aplikacji nie musi się martwić o to, czy urządzenie jest zgodne z Androidem. Sklep Google Play obejmuje tylko urządzenia z tym systemem. Jeśli więc użytkownik zainstaluje Twoją aplikację ze Sklepu Google Play, 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 urządzeniach o różnych konfiguracjach, więc niektóre funkcje nie są dostępne na wszystkich urządzeniach. Na przykład niektóre urządzenia mogą nie zawierać czujnika kompasu. Jeśli główna funkcjonalność aplikacji wymaga czujnika kompasu, jest ona zgodna tylko z urządzeniami, które obsługują tę funkcję.

Kontrolowanie dostępności aplikacji na urządzeniach

Android obsługuje wiele funkcji, z których może korzystać Twoja aplikacja za pomocą interfejsów API platformy. Niektóre funkcje są oparte na sprzęcie, np. czujnikach kompasu, inne z zastosowaniem oprogramowania, np. widżetów aplikacji, a inne 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 w zależności od wymagań aplikacji.

Aby 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 AAB. Zwykle można to zrobić, wyłączając funkcje opcjonalne w czasie działania i udostępniając zasoby aplikacji alternatywne dla różnych konfiguracji, takich jak różne układy dla ekranów o różnych rozmiarach. W razie potrzeby możesz ograniczyć dostępność aplikacji w Sklepie Google Play do określonych urządzeń na podstawie tych parametrów urządzenia:

Funkcje urządzenia

Aby zarządzać dostępnością aplikacji na podstawie funkcji urządzenia, Android określa identyfikatory funkcji wszystkich funkcji sprzętu lub oprogramowania, które mogą być niedostępne na niektórych 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 Twojej aplikacji, gdy ich urządzenia nie udostępniają wymaganej funkcji. W tym celu deklaruj funkcję za pomocą elementu <uses-feature> w pliku manifestu aplikacji.

Jeśli np. aplikacja nie działa na urządzeniu bez czujnika kompasu, możesz zadeklarować, że czujnik kompasu jest wymagany, korzystając z tego tagu w pliku manifestu:

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

Aby określić, czy aplikacja jest zgodna z danym urządzeniem, Sklep Google Play porównuje funkcje wymagane przez Twoją aplikację z funkcjami dostępnymi na urządzeniu każdego użytkownika. 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 korzystania z funkcji urządzenia, ustaw wartość atrybutu required na "false" i sprawdzaj działanie funkcji urządzenia w czasie działania. Jeśli funkcja aplikacji nie jest dostępna na obecnym urządzeniu, wyłącz w łatwy sposób jej działanie. Aby na przykład sprawdzić, czy dana funkcja jest dostępna, wywołaj 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, za pomocą których możesz kontrolować dostępność aplikacji w Sklepie Google Play, znajdziesz w dokumentacji filtrów w Google Play.

Wersja platformy

Na różnych urządzeniach mogą być zainstalowane 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:

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

Odlotowy

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 za pomocą interfejsów API z poprzednich wersji platformy. Dzięki temu aplikacja jest zgodna z przyszłymi wersjami Androida podczas korzystania z wymienionych w dokumentacji interfejsów API.

Jeśli jednak Twoja aplikacja korzysta z interfejsów API dodanych w nowszej wersji platformy, ale nie wymaga ich ze względu na swoją główną funkcjonalność, sprawdź poziom interfejsu API w czasie działania i delikatnie obniż odpowiednie funkcje, gdy poziom interfejsu API będzie zbyt niski. W takim przypadku ustaw minSdkVersion na najniższą wartość możliwą dla głównej funkcji aplikacji, a następnie porównaj bieżącą wersję systemu (SDK_INT) ze stałą kryptonimem Build.VERSION_CODES odpowiadającą poziomowi interfejsu API, który chcesz sprawdzić, jak pokazujemy w tym przykładzie:

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 różnych urządzeniach, takich jak telefony, tablety i telewizory. Aby kategoryzować urządzenia według typu ekranu, Android określa 2 cechy: rozmiar ekranu (fizyczny rozmiar ekranu) i gęstość ekranu (fizyczną gęstość pikseli na ekranie, czyli DPI). Aby uprościć różne konfiguracje, Android uogólnia te warianty w grupy, co ułatwia kierowanie na nie reklam:

  • Cztery 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 wysoka) i inne

Domyślnie aplikacja jest zgodna ze wszystkimi rozmiarami i gęstościami ekranu, ponieważ system w razie potrzeby dostosowuje układ interfejsu użytkownika i zasoby obrazu w zależności od potrzeb. Dostarczaj zoptymalizowane obrazy bitmapowe pod kątem typowych gęstości ekranu.

Zoptymalizuj wrażenia użytkowników, stosując w miarę możliwości elastyczne układy. Jeśli obowiązują układy na potrzeby dużych zmian w konfiguracji, np. pionowe i poziome lub duże i małe okna, rozważ zastosowanie alternatywnych układów, które są elastyczne w połączeniu z mniejszymi zmianami w konfiguracji. Zwiększa to wygodę użytkowników korzystających z różnych formatów, takich jak tablety, telefony i urządzenia składane. Jest to też przydatne, gdy okno zmienia rozmiar w trybie wielu okien.

Informacje o tworzeniu alternatywnych zasobów dla różnych ekranów i ograniczaniu aplikacji do określonych rozmiarów ekranu znajdziesz w omówieniu zgodności z ekranami oraz ze wskazówkami dotyczącymi jakości aplikacji na duże ekrany.

Kontrolowanie dostępności aplikacji do celów biznesowych

Oprócz ograniczenia dostępności na podstawie cech urządzenia może być konieczne ograniczenie dostępności aplikacji z powodów biznesowych lub prawnych. W takiej sytuacji Sklep Google Play udostępnia w Konsoli Play opcje filtrowania, które pozwalają kontrolować dostępność aplikacji z powodów nietechnicznych, np. dotyczących regionu użytkownika lub operatora 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 pliku pakietu AAB. Jednak filtrowanie z powodów nietechnicznych, np. dotyczących regionu geograficznego, zawsze odbywa się w Konsoli Google Play.

Dodatkowe zasoby:

Omówienie zasobów aplikacji
Informacje o strukturze aplikacji na Androida w celu oddzielenia zasobów aplikacji od jej kodu, w tym o sposobie udostępniania zasobów alternatywnych na potrzeby konkretnych konfiguracji urządzeń.
Filtry w Google Play
Informacje o różnych sposobach, w jakie Sklep Google Play może uniemożliwiać instalowanie Twojej aplikacji na różnych urządzeniach.
Uprawnienia na 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 przez aplikację z tych interfejsów.