Zmiany w działaniu Androida 5.0

Poziom API: 21

Oprócz nowych funkcji i możliwości Android 5.0 zawiera szereg zmian w systemie oraz w działaniu interfejsów API. W tym dokumencie opisujemy najważniejsze zmiany, które musisz wziąć pod uwagę i uwzględnić w swoich aplikacjach.

Jeśli masz już opublikowaną aplikację na Androida, pamiętaj, że te zmiany mogą mieć wpływ na tę aplikację w wersji 5.0.

Aby dowiedzieć się więcej o nowych funkcjach platformy, obejrzyj najważniejsze informacje na temat Androida Lollipop.

Filmy

Bajty deweloperskie: co nowego w Androidzie 5.0

Bajty deweloperskie: powiadomienia

Środowisko uruchomieniowe Androida (ART)

W Androidzie 5.0 środowisko wykonawcze ART zastępuje Dalvik jako domyślną platformę. Środowisko wykonawcze ART zostało wprowadzone w Androidzie 4.4 w ramach eksperymentu.

Więcej informacji o nowych funkcjach ART: Przedstawiamy ART. Oto niektóre z najważniejszych nowych funkcji:

• Kompilacja z wyprzedzeniem (AOT)
• Ulepszone czyszczenie pamięci
• Ulepszona obsługa debugowania

Większość aplikacji na Androida powinna działać bez zmian w ART. Niektóre techniki, które sprawdzają się w przypadku Dalvika, nie sprawdzają się w przypadku ART. Informacje o najważniejszych problemach znajdziesz w sekcji Weryfikowanie działania aplikacji w środowisku wykonawczym Androida (ART). Zwróć szczególną uwagę, jeśli:

• Twoja aplikacja używa natywnego interfejsu Java (JNI) do uruchamiania kodu w języku C/C++.
• Używasz narzędzi dla programistów, które generują niestandardowy kod (np. niektórych zaciemniających kodu).
• Używasz technik, które są niezgodne z kompaktowym zarządzaniem śmieciami.

Powiadomienia

Upewnij się, że powiadomienia uwzględniają te zmiany w Androidzie 5.0. Więcej informacji o projektowaniu powiadomień na Androida 5.0 i nowsze znajdziesz w przewodniku po projektowaniu powiadomień.

Styl Material Design

Powiadomienia są rysowane ciemnym tekstem na białym (lub bardzo jasnym) tle, aby dopasować je do nowych widżetów Material Design. Upewnij się, że wszystkie powiadomienia wyglądają poprawnie w nowym schemacie kolorów. Jeśli powiadomienia wyglądają nieprawidłowo, popraw je:

• Użyj setColor(), aby ustawić kolor uzupełniający w okręgu za obrazem ikony.
• Zaktualizuj lub usuń komponenty, które zawierają kolor. System ignoruje wszystkie kanały inne niż alfa widoczne w ikonach czynności i głównej ikonie powiadomień. Należy zakładać, że te ikony są dostępne tylko w wersji alfa. System rysuje ikony powiadomień na biało, a ikony działań – na ciemnoszare.

Dźwięk i wibracje

Jeśli obecnie dodajesz do powiadomień dźwięki i wibracje za pomocą klas Ringtone, MediaPlayer lub Vibrator, usuń ten kod, aby system mógł prawidłowo wyświetlać powiadomienia w trybie priorytetowym. Aby dodać dźwięki i wibracje, użyj metody Notification.Builder.

Ustawienie urządzenia na RINGER_MODE_SILENT powoduje przejście w nowy tryb priorytetu. Urządzenie opuści tryb priorytetu, jeśli ustawisz go na wartość RINGER_MODE_NORMAL lub RINGER_MODE_VIBRATE.

Wcześniej Android używany był jako główny strumień do regulacji głośności na tabletach STREAM_MUSIC. W Androidzie 5.0 główny strumień głośności telefonów i tabletów jest teraz ujednolicony i steruje nim STREAM_RING lub STREAM_NOTIFICATION.

Widoczność ekranu blokady

W Androidzie 5.0 powiadomienia są teraz domyślnie wyświetlane na ekranie blokady użytkownika. Użytkownicy mogą zdecydować, aby nie ujawnić informacji poufnych. W takim przypadku system automatycznie usunie tekst wyświetlany w powiadomieniu. Aby dostosować usunięte powiadomienie, użyj setPublicVersion().

Jeśli powiadomienie nie zawiera danych osobowych lub chcesz zezwolić na sterowanie odtwarzaniem multimediów w powiadomieniu, wywołaj metodę setVisibility() i ustaw poziom widoczności powiadomienia na VISIBILITY_PUBLIC.

Odtwarzanie multimediów

Jeśli wdrażasz powiadomienia, które przedstawiają stan odtwarzania multimediów lub elementy sterujące przesyłaniem, rozważ użycie nowego szablonu Notification.MediaStyle zamiast niestandardowego obiektu RemoteViews.RemoteView. Niezależnie od wybranej metody pamiętaj, aby ustawić widoczność powiadomienia na VISIBILITY_PUBLIC, aby elementy sterujące były dostępne na ekranie blokady. Pamiętaj, że od Androida 5.0 system nie pokazuje już obiektów RemoteControlClient na ekranie blokady. Więcej informacji znajdziesz w sekcji Jeśli Twoja aplikacja używa RemoteControlClient.

Ostrzeżenie

Powiadomienia mogą się teraz wyświetlać w małym pływającym oknie (nazywanym też powiadomieniem HUD), gdy urządzenie jest aktywne (czyli gdy urządzenie jest odblokowane, a jego ekran jest włączony). Wyglądają one podobnie do kompaktowego powiadomienia, z tym że zawiera ono też przyciski poleceń. Użytkownicy mogą reagować na powiadomienia z ostrzeżeniem lub je odrzucać bez opuszczania bieżącej aplikacji.

Przykłady sytuacji, które mogą powodować wyświetlanie powiadomień z ostrzeżeniem:

• Aktywność użytkownika jest w trybie pełnoekranowym (aplikacja korzysta z funkcji fullScreenIntent)
• Powiadomienie ma wysoki priorytet i jest sygnalizowane dzwonkiem lub wibracjami.

Jeśli Twoja aplikacja stosuje powiadomienia w którymkolwiek z tych scenariuszy, upewnij się, że powiadomienia HUD są wyświetlane prawidłowo.

Sterowanie multimediami i RemoteControlClient

Klasa RemoteControlClient została wycofana. Jak najszybciej przejdź na nowy interfejs MediaSession API.

Ekrany blokady w Androidzie 5.0 nie pokazują elementów sterujących przesyłaniem w aplikacjach MediaSession i RemoteControlClient. Zamiast tego aplikacja może sterować odtwarzaniem multimediów z poziomu ekranu blokady. Dzięki temu aplikacja ma większą kontrolę nad wyświetlaniem przycisków multimedialnych, a jednocześnie umożliwia spójne korzystanie z zablokowanych i odblokowanych urządzeń.

W Androidzie 5.0 wprowadzono nowy szablon Notification.MediaStyle, który służy do tego celu. Notification.MediaStyle konwertuje działania powiadomień dodane za pomocą Notification.Builder.addAction() w kompaktowe przyciski umieszczone w powiadomieniach o odtwarzaniu multimediów w aplikacji. Przekaż token sesji do metody setSession(), aby poinformować system, że to powiadomienie steruje trwającą sesją multimediów.

Pamiętaj, aby ustawić widoczność powiadomienia na VISIBILITY_PUBLIC, aby oznaczyć je jako bezpieczne do wyświetlenia na dowolnym ekranie blokady (zabezpieczonym lub innym). Więcej informacji znajdziesz w artykule Powiadomienia na ekranie blokady.

Aby wyświetlić elementy sterujące odtwarzaniem multimediów, jeśli Twoja aplikacja działa na platformie Android TV lub na platformie Wear, zaimplementuj klasę MediaSession. Zalecamy też wdrożenie MediaSession, jeśli aplikacja ma odbierać zdarzenia przycisku multimediów na urządzeniach z Androidem.

getLastTasks();

Wraz z wprowadzeniem w Androidzie 5.0 nowej funkcji jednoczesnych dokumentów i zadań (patrz Równoczesne dokumenty i działania na ekranie ostatnich poniżej) metoda ActivityManager.getRecentTasks() została wycofana, aby zwiększyć prywatność użytkowników. Ze względu na zgodność wsteczną ta metoda nadal zwraca mały podzbiór swoich danych, w tym własne zadania aplikacji wywołującej i prawdopodobnie niektóre inne zadania, które nie są poufne (np. strona główna). Jeśli aplikacja wykorzystuje tę metodę do pobierania własnych zadań, zamiast tego użyj metody getAppTasks().

Obsługa 64-bitowego pakietu Android NDK

Android 5.0 wprowadza obsługę systemów 64-bitowych. Ulepszenie wersji 64-bitowej zwiększa przestrzeń adresową i poprawia wydajność, a jednocześnie nadal w pełni obsługuje istniejące aplikacje 32-bitowe. Obsługa wersji 64-bitowej poprawia również wydajność OpenSSL na potrzeby kryptografii. Ponadto w tej wersji wprowadziliśmy nowe interfejsy API dla natywnych multimediów NDK oraz natywną obsługę OpenGL ES (GLES) 3.1.

Aby korzystać z obsługi 64-bitowej w Androidzie 5.0, pobierz i zainstaluj pakiet NDK w wersji 10c ze strony pakietu Android NDK. Więcej informacji o ważnych zmianach i poprawkach w pakiecie NDK znajdziesz w informacjach o wersji 10c.

Powiązanie z usługą

Metoda Context.bindService() wymaga teraz jawnego Intent i zgłasza wyjątek w przypadku niejawnej intencji. Aby zapewnić bezpieczeństwo aplikacji, podczas uruchamiania lub powiązania Service używaj wyraźnej intencji i nie deklaruj filtrów intencji dla usługi.

WebView | komponent WebView

Android 5.0 zmienia domyślne działanie aplikacji.

• Jeśli Twoja aplikacja jest kierowana na interfejs API na poziomie 21 lub wyższym:
  • System domyślnie blokuje treści mieszane i pliki cookie innych firm. Aby zezwolić na zawartość mieszaną i pliki cookie innych firm, użyj odpowiednio metod setMixedContentMode() i setAcceptThirdPartyCookies().
  • System inteligentnie wybiera teraz fragmenty dokumentu HTML do rysowania. To nowe domyślne zachowanie pomaga zmniejszyć ilość pamięci i zwiększyć wydajność. Jeśli chcesz wyrenderować cały dokument od razu, wyłącz tę optymalizację, wywołując enableSlowWholeDocumentDraw().
• Jeśli Twoja aplikacja jest kierowana na poziom interfejsu API niższy niż 21: system zezwala na zawartość mieszaną i pliki cookie innych firm, a zawsze renderuje cały dokument od razu.

Wymagania dotyczące unikalności uprawnień niestandardowych

Zgodnie z opisem w sekcji Uprawnienia aplikacje na Androida mogą definiować uprawnienia niestandardowe jako sposób zarządzania dostępem do komponentów w zastrzeżony sposób, bez korzystania ze wstępnie zdefiniowanych uprawnień systemowych platformy. Aplikacje definiują uprawnienia niestandardowe w elementach <permission> zadeklarowanych w plikach manifestu.

W niektórych sytuacjach definiowanie uprawnień niestandardowych jest legalne i bezpieczne. Jednak tworzenie uprawnień niestandardowych jest czasami niepotrzebne i może nawet stanowić potencjalne zagrożenie dla aplikacji w zależności od poziomu ochrony przypisanego do uprawnień.

W Androidzie 5.0 wprowadzono zmianę działania, dzięki której tylko jedna aplikacja może definiować dane niestandardowe, chyba że podpisze je tym samym kluczem co inne aplikacje definiujące uprawnienia.

Aplikacje używające zduplikowanych uprawnień niestandardowych

Każda aplikacja może zdefiniować dowolne niestandardowe uprawnienia, dlatego wiele aplikacji może zdefiniować te same uprawnienia niestandardowe. Jeśli na przykład 2 aplikacje oferują podobną możliwość, mogą otrzymać tę samą nazwę logiczną dla swoich niestandardowych uprawnień. Aplikacje mogą też zawierać wspólne biblioteki publiczne lub przykłady kodu, które same mają te same niestandardowe definicje uprawnień.

W Androidzie 4.4 i starszych użytkownicy mogli zainstalować wiele takich aplikacji na jednym urządzeniu, jednak system przypisał poziom ochrony określony przez aplikację zainstalowaną jako pierwszą.

Począwszy od Androida 5.0 system wymusza nowe ograniczenie unikalności uprawnień niestandardowych w przypadku aplikacji podpisanych innymi kluczami. Teraz tylko jedna aplikacja na urządzeniu może zdefiniować dane niestandardowe (określoną na podstawie nazwy), chyba że druga aplikacja, która je określa, została podpisana tym samym kluczem. Jeśli użytkownik spróbuje zainstalować aplikację ze zduplikowanym niestandardowymi uprawnieniami i nie zostanie podpisany tym samym kluczem co aplikacja rezydentna, która określa to uprawnienie, system zablokuje instalację.

Uwagi dotyczące aplikacji

W Androidzie 5.0 i nowszych aplikacje mogą nadal definiować własne uprawnienia niestandardowe i prosić o nie z innych aplikacji za pomocą mechanizmu <uses-permission>. Jednak w związku z nowym wymaganiem wprowadzonym w Androidzie 5.0 musisz dokładnie ocenić potencjalny wpływ tej zmiany na swoją aplikację.

Oto kilka kwestii, które warto wziąć pod uwagę:

• Czy w pliku manifestu aplikacji są deklarowane elementy <permission>? Jeśli tak, czy są one niezbędne do prawidłowego działania aplikacji lub usługi? A może zamiast tego możesz użyć domyślnego uprawnienia systemowego?
• Jeśli masz w aplikacji elementy <permission>, czy wiesz, skąd pochodzą?
• Czy rzeczywiście chcesz, aby inne aplikacje prosiły o uprawnienia niestandardowe za pomocą <uses-permission>?
• Czy w swojej aplikacji używasz stałego kodu lub przykładowego kodu, który zawiera elementy <permission>? Czy te elementy uprawnień są rzeczywiście niezbędne?
• Czy uprawnienia niestandardowe używają prostych nazw lub opiera się na wspólnych hasłach, które mogą być używane przez inne aplikacje?

Nowe instalacje i aktualizacje

Jak wspomnieliśmy wyżej, nie ma to wpływu na nowe instalacje i aktualizacje aplikacji na urządzeniach z Androidem 4.4 lub starszym i nie ma to wpływu na działanie aplikacji. W przypadku nowych instalacji i aktualizacji na urządzeniach z Androidem 5.0 lub nowszym system uniemożliwia instalację aplikacji, jeśli definiuje niestandardowe uprawnienie, które jest już zdefiniowane przez istniejącą aplikację rezydentną.

Dotychczasowe instalacje z aktualizacją systemową Androida 5.0

Jeśli Twoja aplikacja korzysta z niestandardowych uprawnień oraz jest powszechnie rozpowszechniana i instalowana, może to wpłynąć na użytkowników urządzeń, gdy otrzymają aktualizację do Androida 5.0. Po zainstalowaniu aktualizacji system ponownie weryfikuje zainstalowane aplikacje, w tym sprawdza ich uprawnienia niestandardowe. Jeśli Twoja aplikacja określa uprawnienie niestandardowe zdefiniowane przez inną aplikację, która została już zweryfikowana, a aplikacja nie jest podpisana tym samym kluczem co inna aplikacja, system nie zainstaluje jej ponownie.

Rekomendacje

W przypadku urządzeń z Androidem 5.0 lub nowszym zalecamy natychmiastowe sprawdzenie aplikacji, wprowadzenie niezbędnych poprawek i jak najszybsze opublikowanie zaktualizowanej wersji dla użytkowników.

• Jeśli w swojej aplikacji używasz uprawnień niestandardowych, zastanów się, skąd pochodzą, i zastanów się, czy naprawdę ich potrzebujesz. Usuń z aplikacji wszystkie elementy <permission>, chyba że masz pewność, że są one wymagane do prawidłowego działania aplikacji.
• Rozważ zastąpienie uprawnień niestandardowych domyślnymi uprawnieniami systemu.
• Jeśli Twoja aplikacja wymaga niestandardowych uprawnień, zmień ich nazwę, aby były unikalne dla aplikacji, na przykład dołączając je do pełnej nazwy pakietu aplikacji.
• Jeśli masz zestaw aplikacji podpisanych innymi kluczami i uzyskują one dostęp do współdzielonego komponentu za pomocą uprawnień niestandardowych, upewnij się, że niestandardowe uprawnienie zostało zdefiniowane tylko raz w komponencie współdzielonym. Aplikacje, które używają współdzielonego komponentu, nie powinny same definiować uprawnień niestandardowych. Zamiast tego powinny prosić o dostęp za pomocą mechanizmu <uses-permission>.
• Jeśli masz zestaw aplikacji podpisany tym samym kluczem, każda z nich może zdefiniować te same uprawnienia niestandardowe, których jest potrzebne – system umożliwia ich instalowanie w zwykły sposób.

Zmiany domyślnej konfiguracji TLS/SSL

Android 5.0 wprowadza zmiany w domyślnej konfiguracji TLS/SSL używanej przez aplikacje do obsługi protokołu HTTPS i innego ruchu TLS/SSL:

• Protokoły TLSv1.2 i TLSv1.1 są teraz włączone
• Zestawy szyfrów AES-GCM (AEAD) są teraz włączone.
• Zestawy szyfrów MD5, 3DES, eksportu i klucza statycznego ECDH są teraz wyłączone.
• Preferowane są zestawy szyfrów Forward Secrecy (ECDHE i DHE).

Te zmiany mogą w nielicznych przypadkach wymienionych poniżej spowodować awarie w połączeniach HTTPS lub TLS/SSL.

Pamiętaj, że dostawca zabezpieczeń ProviderInstaller z Usług Google Play oferuje już te zmiany na platformach Androida od wersji 2.3.

Serwer nie obsługuje żadnego z włączonych zestawów szyfrów

Na przykład serwer może obsługiwać tylko zestawy szyfrów 3DES lub MD5. Zalecaną poprawką jest poprawa konfiguracji serwera, aby można było włączyć mocniejsze i bardziej nowoczesne zestawy szyfrów oraz protokoły. Najlepiej włączyć protokoły TLSv1.2 i AES-GCM oraz włączyć i preferowane mechanizmy szyfrowania Forward Secrecy (ECDHE, DHE).

Zamiast tego możesz zmodyfikować aplikację tak, aby do komunikacji z serwerem używała niestandardowego protokołu SSLSocketFactory. Fabryka powinna tworzyć instancje SSLSocket, które oprócz domyślnych zestawów szyfrów mają część zestawów szyfrów wymaganych przez serwer.

Aplikacja przyjmuje błędne założenia dotyczące zestawów szyfrów używanych do łączenia się z serwerem

Na przykład niektóre aplikacje zawierają niestandardowy menedżer zaufania X509, który ulega awarii, ponieważ oczekuje, że parametr authType powinien mieć wartość RSA, ale napotka ECDHE_RSA lub DHE_RSA.

Serwer nie toleruje rozszerzeń TLS 1.1 i TLSv1.2 ani nowych

Na przykład uzgadnianie połączenia TLS/SSL z serwerem jest błędnie odrzucane lub zostaje zatrzymane. Preferowaną metodą jest uaktualnienie serwera tak, aby był zgodny z protokołem TLS/SSL. Dzięki temu serwer będzie negocjował nowsze protokoły lub TLSv1 lub starsze, ignorując rozszerzenia TLS, których nie rozpoznaje. W niektórych przypadkach wyłączenie TLSv1.1 i TLSv1.2 na serwerze może działać w celu zatrzymania do czasu uaktualnienia oprogramowania serwera.

Zamiast tego możesz zmodyfikować aplikację tak, aby do komunikacji z serwerem używała niestandardowego protokołu SSLSocketFactory. Fabryka powinna tworzyć instancje SSLSocket tylko z włączonymi protokołami, które są poprawnie obsługiwane przez serwer.

Obsługa profili zarządzanych

Administratorzy urządzenia mogą dodać profil zarządzany do urządzenia. Ten profil należy do administratora, który daje mu kontrolę nad profilem zarządzanym przy opuszczaniu profilu osobistego użytkownika i jego przestrzeni dyskowej pod kontrolą użytkownika. Ta zmiana może wpłynąć na działanie istniejącej aplikacji w następujący sposób.

Obsługa intencji

Administratorzy urządzeń mogą ograniczyć dostęp do aplikacji systemowych z profilu zarządzanego. W takim przypadku, jeśli aplikacja uruchamia intencję z profilu zarządzanego, która była zwykle obsługiwana przez tę aplikację, i nie ma odpowiedniego modułu obsługi dla intencji w profilu zarządzanym, intencja powoduje wyjątek. Administrator urządzenia może na przykład ograniczyć dostęp aplikacji z profilu zarządzanego systemu do aplikacji aparatu. Jeśli Twoja aplikacja działa w profilu zarządzanym i wywołuje metodę startActivityForResult() na potrzeby MediaStore.ACTION_IMAGE_CAPTURE, a w profilu zarządzanym nie ma aplikacji, która może obsłużyć intencję, jest to wywołane przez ActivityNotFoundException.

Aby temu zapobiec, sprawdź przed uruchomieniem intencji, czy istnieje co najmniej jeden moduł obsługi dla danej intencji. Aby sprawdzić prawidłowy moduł obsługi, wywołaj funkcję Intent.resolveActivity(). Przykład znajdziesz w sekcji Zrób zdjęcia: Zrób zdjęcie przy użyciu aplikacji Aparat.

Udostępnianie plików między profilami

Każdy profil ma własne miejsce na pliki. Ponieważ identyfikator URI pliku odnosi się do określonej lokalizacji w pamięci masowej, oznacza to, że prawidłowy identyfikator URI pliku w jednym profilu jest nieprawidłowy w drugim. Zwykle nie jest to problem dla aplikacji, która zwykle korzysta tylko z utworzonych przez siebie plików. Jeśli jednak aplikacja dołączy plik do intencji, nie można bezpiecznie dołączyć identyfikatora URI pliku, ponieważ w niektórych sytuacjach intencja może być obsługiwana w innym profilu. Administrator urządzenia może na przykład określić, że zdarzenia przechwytywania obrazu powinny być obsługiwane przez aplikację aparatu na profilu osobistym. Jeśli intencja jest wywoływana przez aplikację w profilu zarządzanym, kamera musi mieć możliwość zapisania obrazu w lokalizacji, z której mogą go odczytać aplikacje profilu zarządzanego.

Gdy musisz dołączyć plik do intencji, która może przechodzić między profilami, utwórz i użyj identyfikatora URI treści dla tego pliku. Więcej informacji o udostępnianiu plików przy użyciu identyfikatorów URI treści znajdziesz w artykule Udostępnianie plików. Na przykład administrator urządzenia może zezwolić na obsługę programu ACTION_IMAGE_CAPTURE przez kamerę w profilu osobistym. Obiekt EXTRA_OUTPUT intencji uruchamiającej powinien zawierać identyfikator URI treści określający miejsce przechowywania zdjęcia. Aplikacja aparatu może zapisać obraz w lokalizacji określonej przez ten identyfikator URI, a aplikacja, która uruchomiła intencję, będzie mogła odczytać ten plik, nawet jeśli znajduje się w innym profilu.

Usunięto obsługę widżetów ekranu blokady

Android 5.0 wyłącza obsługę widżetów ekranu blokady, ale nadal obsługuje je na ekranie głównym.