Android jest przeznaczony do działania 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, i jak przygotować aplikacje, aby docierały do właściwych odbiorców.
Co oznacza „zgodność”?
W przypadku tworzenia aplikacji na Androida występują 2 rodzaje zgodności: zgodność z urządzeniem i zgodność z aplikacją.
Ponieważ Android jest projektem typu open source, każdy producent sprzętu może zbudować urządzenie z systemem operacyjnym Android. Urządzenie jest „kompatybilne z Androidem” tylko wtedy, gdy może prawidłowo uruchamiać aplikacje napisane dla środowiska wykonawczego Androida. Szczegóły dotyczące środowiska wykonywania aplikacji na Androida są określone w programie zgodności z Androidem. Aby urządzenie zostało uznane za zgodne, musi przejść test 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ą dostępne tylko na niektórych urządzeniach. Na przykład niektóre urządzenia nie mają 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 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 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 pojedynczego pliku APK lub AAB. W większości przypadków możesz to zrobić, wyłączając opcjonalne funkcje w czasie wykonywania 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 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, jeśli 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 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 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, 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 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 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)
...
}
}
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 późniejszej wersji platformy, ale nie są one wymagane do jej podstawowej funkcjonalności, sprawdź poziom interfejsu API w czasie wykonywania i łagodnie zdegraduj odpowiednie funkcje, gdy poziom interfejsu API jest zbyt niski. W tym przypadku ustaw parametr minSdkVersion na najniższą możliwą wartość dla głównej funkcji aplikacji, a potem porównaj bieżącą wersję systemu SDK_INT z wartością stałej nazwy kodu w Build.VERSION_CODES, która odpowiada poziomowi interfejsu API, który chcesz sprawdzić. Oto przykład:
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 kategoryzować 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:
- 4 ogólne 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 dużych zmian 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 lepiej korzystać z urządzeń takich jak tablety, telefony i urządzenia składane. Pomaga też, 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. Filtrowanie z nietechnicznych powodów, np. ze względu na język, zawsze odbywa się 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ą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 określonych interfejsów API za pomocą systemu uprawnień, który wymaga zgody użytkownika na korzystanie z tych interfejsów przez aplikację.