Omówienie zgodności urządzeń

Android jest przeznaczony do działania na wielu różnych urządzeniach, takich jak telefony, tablety i telewizory. Dzięki temu Twoja aplikacja może dotrzeć do ogromnej liczby użytkowników. Aby odnieść sukces na wszystkich urządzeniach, musi tolerować zmienność funkcji i zapewniać elastyczny interfejs użytkownika, który dostosowuje się do różnych konfiguracji ekranu.

Aby ułatwić zapewnienie zgodności z urządzeniami, Android udostępnia dynamiczny framework aplikacji w którym możesz udostępniać 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 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ć, które typy urządzeń mogą instalować Twoją 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 dotrzeć do odpowiednich odbiorców.

Co oznacza „zgodność”?

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

Ponieważ Android jest projektem open source, każdy producent sprzętu może stworzyć urządzenie, które będzie działać pod kontrolą tego systemu operacyjnego. 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ślone w programie zgodności z Androidem. 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, będzie korzystać z urządzenia zgodnego z Androidem.

Musisz jednak sprawdzić, czy Twoja aplikacja jest zgodna z każdą potencjalną konfiguracją urządzenia. Ponieważ Android działa na wielu różnych konfiguracjach urządzeń, niektóre funkcje nie są dostępne na wszystkich urządzeniach. Na przykład niektóre urządzenia mogą nie mieć czujnika kompasu. Jeśli główna funkcjonalność aplikacji wymaga czujnika kompasu, wtedy aplikacja jest zgodna tylko z urządzeniami, które mają tę funkcjonalność.

Kontrolowanie dostępności aplikacji na urządzeniach

Android obsługuje różne funkcje, które Twoja 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, dlatego może być konieczne kontrolowanie dostępności aplikacji na urządzeniach na podstawie wymaganych funkcji.

Aby aplikacja docierała 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 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

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, gdy ich urządzenia nie mają wymaganej funkcji. Aby to zrobić, zadeklaruj funkcję za pomocą <uses-feature> elementu w pliku manifestu aplikacji.

Jeśli na przykład Twoja aplikacja nie ma sensu na urządzeniu bez 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 danym urządzeniem. Jeśli urządzenie nie ma wszystkich funkcji wymaganych przez Twoją aplikację, użytkownik nie może jej zainstalować.

Jeśli jednak podstawowa funkcjonalność aplikacji nie wymaga funkcji urządzenia, ustaw required atrybut na "false" i sprawdź, czy funkcja urządzenia jest dostępna 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 metodę 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();
}

Więcej informacji o wszystkich filtrach, których możesz użyć 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 dodaje interfejsy API, które nie są dostę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 ma poziom interfejsu API 31, a Android 13 – 33.

Musisz określić wartości minSdkVersion i targetSdkVersion w pliku build.gradle:

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

Dynamiczny

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 za pomocą interfejsów API z poprzednich wersji platformy, dzięki czemu Twoja aplikacja jest zgodna z przyszłymi wersjami Androida, gdy 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 podstawowej funkcjonalności, sprawdź poziom interfejsu API w czasie działania i przeprowadź łagodną degradację odpowiednich funkcji, gdy poziom interfejsu API jest zbyt niski. W takim przypadku ustaw atrybut 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łą kryptonimu w Build.VERSION_CODES, która odpowiada poziomowi interfejsu API, który chcesz sprawdzić, jak pokazano 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 urządzeniach o różnych rozmiarach, takich jak telefony, tablety i telewizory. Aby podzielić urządzenia na kategorie według typu ekranu, Android definiuje 2 cechy każdego urządzenia: rozmiar ekranu (fizyczny rozmiar ekranu) i gęstość ekranu (fizyczna gęstość pikseli na ekranie, czyli DPI). Aby uprościć różne konfiguracje, Android uogólnia te warianty w 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 (bardzo, bardzo wysoka) i inne.

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

Zoptymalizuj wrażenia użytkowników, używając w miarę możliwości elastycznych układów. Jeśli masz układy dla 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 rozmiar okien zmienia się w trybie wielu okien.

Więcej informacji o tworzeniu alternatywnych zasobów dla różnych ekranów i o tym, jak w razie potrzeby ograniczyć aplikację do określonych rozmiarów ekranu, znajdziesz w omówieniu zgodności z ekranem i w wytycznych dotyczących jakości aplikacji na dużych ekranach.

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

Oprócz ograniczenia dostępności aplikacji na podstawie cech urządzenia może być konieczne ograniczenie jej dostępności 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, takich jak ustawienia regionalne użytkownika lub operator sieci komórkowej.

Filtrowanie pod kątem zgodności technicznej, np. wymaganych komponentów sprzętowych, zawsze opiera się na informacjach zawartych w pliku APK lub AAB. Filtrowanie z powodów nietechnicznych, np. ustawień geograficznych , jest zawsze obsługiwane w Konsoli Google Play.

Dodatkowe zasoby:

Omówienie zasobów aplikacji
Informacje o tym, jak są zbudowane aplikacje na Androida, aby oddzielić zasoby aplikacji od kodu aplikacji, 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żliwić zainstalowanie aplikacji na różnych urządzeniach.
Uprawnienia w 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ę.