Android 9 (poziom API 28) wprowadza nowe funkcje i interfejsy API, z których możesz czerpać korzyści w swoich aplikacjach, jak również na zmiany w zachowaniu użytkowników. Ten dokument zawiera omówienie etapów migracji aplikacje na Androida 9 można podzielić na 2 główne fazy:
- Zapewnianie podstawowej zgodności z Androidem 9
Sprawdź, czy Twoja dotychczasowa aplikacja jest w pełni funkcjonalna w nowej wersji platformy. Na tym etapie nie używasz nowych interfejsów API ani nie zmieniasz w swojej aplikacji:
targetSdkVersion
, ale konieczne mogą być drobne zmiany. - Kieruj reklamy na nową platformę, skompiluj z pakietem SDK Androida 9.
z funkcjami Androida 9
Gdy będziesz gotowy do korzystania z nowych funkcji platformy, zaktualizuj wartość
targetSdkVersion
na28
, sprawdź, czy aplikacja nadal działa zgodnie z oczekiwaniami, a potem zacznij używać nowych interfejsów API.
Przygotowanie urządzenia z Androidem 9
Jeśli masz zgodne urządzenie, pobierz obraz systemu Android 9 od producenta. Obrazy fabryczne dla urządzeń Pixel Ogólne instrukcje dotyczące obrazu systemu znajdziesz tutaj.
Możesz też pobrać obraz systemu Androida 9 na potrzeby emulatora Androida. Jest on dostępny w Menedżerze pakietu SDK w sekcji Android API 28 jako Google APIs Intel x86 Atom System Image.
Uwaga: obraz systemu emulatora Androida 9 można pobrać na Android Studio 3.1 lub nowszy, Android Studio 3.2 zapewnia maksymalną zgodność. Więcej informacji znajdziesz w artykule Pobieranie pakietu SDK Androida 9.
Zapewnianie zgodności z Androidem 9
Celem jest sprawdzenie, czy obecna aplikacja działa prawidłowo na Androidzie 9. Niektóre zmiany w platformie mogą wpływać na działanie aplikacji, dlatego konieczne może być wprowadzenie pewnych poprawek, ale nie musisz używać nowych interfejsów API ani zmieniać targetSdkVersion
.
Testy zgodności
Najczęściej testujemy zgodność z Androidem 9 obejmuje ten sam typ testów, które wykonujesz podczas przygotowań do opublikowania aplikacji To dobry moment na zapoznanie się ze podstawowymi wskazówkami dotyczącymi jakości aplikacji i sprawdzonymi metodami testowania.
Testowanie ma też inny aspekt: Android 9 wprowadza zmiany w
które mogą oddziaływać na działanie aplikacji lub całkowicie zepsuć jej działanie, nawet jeśli nie zmienisz
targetSdkVersion
. Dlatego ważne jest, aby zapoznać się z głównymi zmianami w tabeli 1 i przetestować wszelkie poprawki, które wdrożysz, aby uwzględnić te zmiany.
Tabela 1. Kluczowe zmiany, które mają wpływ na wszystkie aplikacje działające na urządzeniach z Androidem 9.
Zmień | Podsumowanie |
---|---|
Ograniczenia dotyczące interfejsów innych niż SDK |
Dostęp do określonych interfejsów innych niż SDK jest teraz zablokowany, niezależnie od tego, czy jest bezpośredni, przez JNI czy przez odbicie. Próby uzyskania dostępu do interfejsów z ograniczonym dostępem powodują błędy takie jak NoSuchFieldException i NoSuchMethodException .
Więcej informacji znajdziesz w artykule Ograniczenia dotyczące interfejsów innych niż SDK.
|
Usunięcie dostawcy kryptowalut |
Od Androida 9 dostawca Crypto JCA został usunięty. Połączenia do SecureRandom.getInstance("SHA1PRNG", "Crypto") będą rzucać błąd NoSuchProviderException .
|
bardziej rygorystyczny dekoder UTF-8, | W Androidzie 9 dekoder UTF-8 dla języka Java jest bardziej rygorystyczny i zgodny ze standardem Unicode. |
Dostęp do aparatu, mikrofonu i czujników jest zablokowany w przypadku aplikacji działających w tle | Gdy aplikacje są nieaktywne, nie mają już dostępu do aparatu, mikrofonu ani czujników SensorManager. |
Pełną listę zmian zachowania we wszystkich aplikacjach działających na Androidzie 9 znajdziesz w dokumentacji Zmiany zachowania.
Aktualizowanie wersji docelowej i korzystanie z funkcji Androida P
W tej sekcji wyjaśniamy, jak włączyć pełną obsługę Androida 9. Aby to zrobić, zaktualizuj targetSdkVersion
do wersji 28 i dodaj nowe funkcje dostępne w Androidzie 9.
Oprócz nowych interfejsów API Android 9 wprowadza pewne zmiany w zachowaniu, gdy zaktualizujesz targetSdkVersion
do wersji 28. Ponieważ niektóre zachowania zmieniają się
może wymagać zmian w kodzie, aby uniknąć awarii,
gdy zmienisz targetSdkVersion
, zapoznając się ze wszystkimi zmianami w działaniu aplikacji kierowanych na Androida 9.
Uwaga: czynności opisane powyżej, które zapewniają zgodność z platformą, są wymagane do kierowania aplikacji na Androida 9. Najpierw wykonaj te czynności.
Pobierz pakiet SDK Androida 9
Pakiety SDK do kompilowania aplikacji na Androida 9 możesz pobrać za pomocą Android Studio 3.1 lub nowszej wersji. Jeśli nie potrzebujesz jeszcze nowych funkcji w Androidzie 9 i chcesz skompilować aplikację tylko na tę wersję platformy, możesz użyć Android Studio 3.1. Android Studio 3.2 zapewnia pełną obsługę: Funkcje Androida 9.
Testowanie aplikacji na Androida 9
Po wykonaniu powyższych czynności możesz skompilować aplikację, a następnie przetestować ją, aby mieć pewność, że działa prawidłowo w przypadku kierowania na Androida 9 (poziom API 28). To dobry moment, aby przejrzeć Aplikacja podstawowa Wskazówki dotyczące jakości i najlepsza Praktyki testowania.
Gdy tworzysz aplikację z targetSdkVersion
ustawionym na P,
musisz pamiętać o konkretnych zmianach dotyczących platformy. Niektóre z
te zmiany mogą w znacznym stopniu wpłynąć na działanie aplikacji,
całkowicie zepsuć aplikację, nawet jeśli nie wdrożysz nowych,
funkcji w Androidzie 9.
W tabeli 2. znajdziesz listę tych zmian wraz z linkami do dodatkowych informacji.
Tabela 2. Najważniejsze zmiany wpływające na aplikacje
gdy targetSdkVersion
ma wartość 28.
Zmień | Podsumowanie |
---|---|
Uprawnienia usługi na pierwszym planie | Aplikacje, które chcą korzystać z usług na pierwszym planie, muszą teraz najpierw poprosić o uprawnienie FOREGROUND_SERVICE. Jest to normalne uprawnienie, więc system automatycznie przyznaje je stronie, która wysłała żądanie . Uruchomienie usługi na pierwszym planie bez uprawnień powoduje zgłoszenie wyjątku SecurityException. |
Wycofanie szyfrów Bouncy Castle |
Android 9 wycofuje kilka szyfrów od dostawcy Bouncy Castle na rzecz szyfrów od dostawcy Conscrypt. Połączenia z numerem getInstance()
poproś o Bouncy
Dostawca zamku wygenerował błędy (NoSuchAlgorithmException ). Aby naprawić błąd,
określ dostawcę w metodzie getInstance() (czyli zażądać domyślnej implementacji).
|
Usunięcie bezpośredniego dostępu do aplikacji Build.serial
|
Aplikacje, które potrzebują identyfikatora Build.serial, muszą teraz prosić o uprawnienia READ_PHONE_STATE , a następnie używać nowej metody Build.getSerial() dodanej w Androidzie 9.
|
Zabronione udostępnianie katalogu danych WebView | Aplikacje nie mogą już udostępniać jednego katalogu danych WebView w różnych procesach. Jeśli Twoja aplikacja ma więcej niż 1 proces korzystający z WebView, CookieManagera lub innego interfejsu API w pakiecie android.webkit, ulegnie ona awarii, gdy drugi proces wywoła metodę WebView. |
Dostęp do katalogu danych aplikacji zablokowany przez SELinux | System stosuje piaskownice SELinux dla poszczególnych aplikacji z ograniczeniami SELinux dla każdego katalogu danych prywatnych aplikacji. Bezpośrednie uzyskiwanie dostępu do katalogu danych innej aplikacji za pomocą ścieżki jest teraz niedozwolone. Aplikacje mogą nadal udostępniać dane, korzystając z mechanizmów IPC, w tym FD. |
Pełną listę zmian zachowania w przypadku aplikacji kierowanych na Androida 9 znajdziesz w dokumentzie Zmiany zachowania.
Aby poznać nowe funkcje i interfejsy API dostępne w Androidzie 9, zobacz Funkcje i interfejsy API Androida 9