Android został zaprojektowany z myślą o działaniu 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, oraz jak przygotować aplikacje, aby docierały do właściwych odbiorców.
Co oznacza „zgodność”?
Jeśli chodzi o programowanie na Androida, dostępne są 2 typy zgodności: zgodność urządzeń i aplikacji.
Ponieważ Android jest projektem typu open source, każdy producent sprzętu może zbudować urządzenie z systemem operacyjnym Android. Urządzenie jest jednak „zgodne z Androidem” tylko wtedy, gdy może prawidłowo uruchamiać aplikacje napisane pod kątem środowiska wykonawczego Androida. Szczegółowe informacje o środowisku wykonywania aplikacji na Androida są określone w programie zgodności z Androidem. Aby zostało uznane za zgodne, każde urządzenie musi przejść testy 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ą niedostępne na niektórych urządzeniach. Na przykład niektóre urządzenia mogą nie mieć 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 (np. widżety) aplikacji, a 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żna to zrobić, wyłączając funkcje opcjonalne w czasie działania i udostępniając zasoby aplikacji z alternatywami dla różnych konfiguracji, np. różnymi układami na różne rozmiary ekranów. 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 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, gdy 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 działa na urządzeniu bez czujnika kompasu, możesz zadeklarować czujnik kompasu jako wymóg, używając 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, 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ą 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 jest na poziomie API 31, a Android 13 to API 33.
W pliku build.gradle
musisz określić 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.
Jeśli jednak Twoja aplikacja korzysta z interfejsów API dodanych w nowszej wersji platformy, ale nie wymaga ich ze względu na główną funkcjonalność, sprawdź ich poziom w środowisku wykonawczym i płynnie dostosuj odpowiednie funkcje, gdy poziom interfejsu API będzie za niski. W tym przypadku ustaw minSdkVersion
na najniższą możliwą wartość dla głównej funkcji aplikacji, a potem porównaj obecną wersję systemu (SDK_INT
) ze stałą kryptonimem w Build.VERSION_CODES
, która odpowiada poziomowi interfejsu API, który chcesz sprawdzić, jak 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 pogrupować 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:
- Cztery uogólnione 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 wprowadzania dużych zmian w konfiguracji, np. układy pionowy i położny 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 wygodniej 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 ze względó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 lub 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. Jednak filtrowanie z powodów nietechnicznych, takich jak region geograficzny, jest zawsze obsługiwane 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ę.