Zmiany w działaniu w Androidzie 5.0

Poziom interfejsu API: 21

Oprócz nowych funkcji i możliwości Android 5.0 zawiera też wiele zmian w systemie i zachowaniu interfejsu API. W tym dokumencie omawiamy niektóre z najważniejszych zmian, które należy wziąć pod uwagę w przypadku aplikacji.

Jeśli masz już opublikowaną aplikację na Androida, pamiętaj, że zmiany w Androidzie 5.0 mogą na nią wpłynąć.

Ogólne informacje o nowych funkcjach platformy znajdziesz w artykule o Androidzie Lollipop.

Filmy

Informacje dla programistów: nowości w Androidzie 5.0

Dev Byte: powiadomienia

Środowisko uruchomieniowe Androida (ART)

W Androidzie 5.0 środowisko wykonawcze ART zastępuje środowisko Dalvik jako domyślne środowisko na platformie. Środowisko wykonawcze ART zostało wprowadzone w Androidzie 4.4 w ramach eksperymentu.

Omówienie nowych funkcji ART znajdziesz w artykule Przedstawiamy ART. Oto kilka najważniejszych nowych funkcji:

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

Większość aplikacji na Androida powinna działać bez żadnych zmian w ramach ART. Jednak niektóre techniki, które działają w przypadku Dalvik, nie działają w przypadku ART. Informacje o najważniejszych problemach znajdziesz w artykule Weryfikowanie działania aplikacji w czasie działania Android Runtime (ART). Zwróć szczególną uwagę, jeśli:

  • Twoja aplikacja używa interfejsu natywnego Javy (JNI) do uruchamiania kodu C/C++.
  • Używasz narzędzi programistycznych, które generują niestandardowy kod (np. niektóre narzędzia do zaciemniania).
  • Używasz technik niezgodnych z zbiorem skompresowanych danych.

Powiadomienia

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

Styl Material Design

Powiadomienia są wyświetlane przy użyciu ciemnego tekstu na białym (lub bardzo jasnym) tle, aby pasowały do nowych widżetów w ramach projektu Material Design. Upewnij się, że wszystkie powiadomienia wyglądają prawidłowo w nowej palecie kolorów. Jeśli powiadomienia wyglądają nieprawidłowo, popraw je:

  • Użyj setColor(), aby ustawić kolor akcentu w kółku za ikoną.
  • Zaktualizuj lub usuń zasoby, które zawierają kolor. System ignoruje wszystkie kanały inne niż alfa w przypadku ikon czynności i głównej ikony powiadomienia. Zakładaj, że te ikony będą widoczne tylko w wersji alfa. System wyświetla ikony powiadomień na biało, a ikony czynności na ciemnoszarym tle.

Dźwięk i wibracje

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

Ustawienie urządzenia na RINGER_MODE_SILENT powoduje przejście urządzenia w nowy tryb priorytetowy. Urządzenie opuszcza tryb priorytetowy, jeśli ustawisz go na RINGER_MODE_NORMAL lub RINGER_MODE_VIBRATE.

Wcześniej Android używał STREAM_MUSIC jako głównego strumienia do sterowania głośnością na tabletach. W Androidzie 5.0 strumień głośności głównej zarówno na telefonach, jak i na tabletach jest teraz ujednolicony i sterowany przez STREAM_RING lub STREAM_NOTIFICATION.

Widoczność ekranu blokady

W Androidzie 5.0 powiadomienia są domyślnie wyświetlane na ekranie blokady użytkownika. Użytkownicy mogą zdecydować, czy chcą chronić poufne informacje przed udostępnieniem. W takim przypadku system automatycznie zasłoni tekst wyświetlany w powiadomieniu. Aby dostosować to powiadomienie, użyj setPublicVersion().

Jeśli powiadomienie nie zawiera danych osobowych lub jeśli 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 kontrolki transportu, rozważ użycie nowego szablonu Notification.MediaStyle zamiast niestandardowego obiektu RemoteViews.RemoteView. W obu przypadkach ustaw widoczność powiadomienia na VISIBILITY_PUBLIC, aby ustawienia były dostępne na ekranie blokady. Pamiętaj, że od Androida 5.0 system nie wyświetla już obiektów RemoteControlClient na ekranie blokady. Więcej informacji znajdziesz w artykule Jeśli Twoja aplikacja używa RemoteControlClient.

Powiadomienie z ostrzeżeniem

Powiadomienia mogą teraz pojawiać się w małym oknie (zwanym też powiadomieniem z poprzednim wyświetleniem) wtedy, gdy urządzenie jest aktywne (czyli jest odblokowane i ma włączony ekran). Te powiadomienia wyglądają podobnie do ich kompaktowej formy, z tym że powiadomienie z ostrzeżeniem zawiera też przyciski czynności. Użytkownicy mogą reagować na powiadomienie lub je odrzucać, nie wychodząc z obecnej aplikacji.

Oto przykłady warunków, które mogą powodować wyświetlanie powiadomień z ostrzeżeniem:

  • Aktywność użytkownika w trybie pełnoekranowym (aplikacja używafullScreenIntent)
  • Powiadomienie ma wysoki priorytet i wykorzystuje dzwonek lub wibracje.

Jeśli Twoja aplikacja implementuje powiadomienia w którymś z tych scenariuszy, upewnij się, że powiadomienia z ostrzeżeniem są wyświetlane prawidłowo.

Sterowanie multimediami i RemoteControlClient

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

Na ekranie blokady w Androidzie 5.0 nie wyświetlają się elementy sterujące transportem w przypadku MediaSession ani RemoteControlClient. Zamiast tego aplikacja może umożliwić sterowanie odtwarzaniem multimediów z poziomu ekranu blokady za pomocą powiadomienia. Dzięki temu aplikacja ma większą kontrolę nad prezentacją przycisków multimediów, a jednocześnie zapewnia użytkownikom spójne działanie na urządzeniach zablokowanych i odblokowanych.

W Androidzie 5.0 wprowadzono nowy szablon Notification.MediaStyle do tego celu. Notification.MediaStyle zamienia polecenia w powiadomieniach dodane za pomocą Notification.Builder.addAction() w kompaktowe przyciski wbudowane w powiadomienia o odtwarzaniu multimediów w aplikacji. Przekaż token sesji metodzie setSession(), aby powiadomić system, że to powiadomienie kontroluje trwającą sesję multimedialną.

Upewnij się, że widoczność powiadomienia jest ustawiona na VISIBILITY_PUBLIC aby oznaczyć powiadomienie jako bezpieczne do wyświetlania na dowolnym ekranie blokady (bezpiecznym lub innym). Więcej informacji znajdziesz w artykule Powiadomienia na ekranie blokady.

Aby wyświetlić elementy sterujące odtwarzaniem multimediów, jeśli aplikacja działa na platformie Android TV lub Wear, zaimplementuj klasę MediaSession. Musisz też zaimplementować MediaSession, jeśli aplikacja ma otrzymywać zdarzenia przycisków multimediów na urządzeniach z Androidem.

getRecentTasks()

Wraz z wprowadzeniem nowej funkcji jednoczesnych dokumentów i działań w Androidzie 5.0 (patrz Jednoczesne dokumenty i działania na ekranie Ostatnie 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 niewielką podgrupę danych, w tym zadania wywołującej aplikacji i ewentualnie inne zadania niekrytyczne (np. Dom). Jeśli aplikacja używa tej metody do pobierania własnych zadań, do pobierania tych informacji użyj zamiast tego metody getAppTasks().

Obsługa 64-bitowa w NDK Androida

Android 5.0 wprowadza obsługę systemów 64-bitowych. Ulepszenie dotyczące 64-bitów zwiększa przestrzeń adresową i poprawia wydajność, a jednocześnie w pełni obsługuje dotychczasowe aplikacje 32-bitowe. Obsługa 64-bitowa poprawia też wydajność OpenSSL do zastosowań kryptograficznych. W tej wersji wprowadzamy też nowe natywne interfejsy NDK do obsługi multimediów oraz obsługę natywnej wersji OpenGL ES 3.1 (GLES).

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

Powiązanie z usługą

Metoda Context.bindService() wymaga teraz jawnej wartości Intent i zwraca wyjątek, jeśli zostanie wywołana z użyciem domyślnej intencji. Aby zapewnić bezpieczeństwo aplikacji, podczas uruchamiania lub wiązania Service użyj jawnego zamiaru. Nie deklaruj filtrów zamiaru dla tej usługi.

WebView | komponent WebView

Android 5.0 zmienia domyślne działanie aplikacji.

  • Jeśli aplikacja jest kierowana na poziom interfejsu API 21 lub nowszy:
    • Domyślnie system blokuje mieszane treści i pliki cookie innych firm. Aby zezwolić na treści mieszane i pliki cookie innych firm, użyj odpowiednio metod setMixedContentMode() i setAcceptThirdPartyCookies().
    • System wybiera teraz inteligentnie fragmenty dokumentu HTML do narysowania. To nowe domyślne zachowanie pomaga zmniejszyć obciążenie pamięci i zwiększyć wydajność. Jeśli chcesz wyrenderować cały dokument naraz, wyłącz tę optymalizację, wywołując funkcję enableSlowWholeDocumentDraw().
  • Jeśli Twoja aplikacja jest kierowana na poziomy interfejsu API niższe niż 21: system zezwala na treści mieszane i pliki cookie innych firm oraz zawsze renderuje cały dokument naraz.

Wymagania dotyczące unikalności uprawnień niestandardowych

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

W niewielkiej liczbie scenariuszy określenie niestandardowych uprawnień jest uzasadnionym i bezpiecznym podejściem. Utworzenie niestandardowych uprawnień może być jednak niepotrzebne, a nawet stanowić potencjalne zagrożenie dla aplikacji, w zależności od poziomu ochrony przypisanej do uprawnień.

Android 5.0 zawiera zmianę zachowania, która zapewnia, że tylko 1 aplikacja może definiować dane niestandardowe uprawnienie, chyba że jest podpisana tym samym kluczem co inne aplikacje definiujące to uprawnienie.

Aplikacje korzystające z podwójnych niestandardowych uprawnień

Każda aplikacja może zdefiniować dowolne uprawnienia niestandardowe, więc może się zdarzyć, że wiele aplikacji zdefiniuje to samo uprawnienie niestandardowe. Jeśli na przykład 2 aplikacje oferują podobne funkcje, mogą mieć tę samą nazwę logiczną dla swoich niestandardowych uprawnień. Aplikacje mogą też zawierać wspólne publiczne biblioteki lub przykłady kodu, które zawierają te same niestandardowe definicje uprawnień.

W Androidzie 4.4 i starszych użytkownicy mogli instalować na danym urządzeniu wiele takich aplikacji, ale system przypisywał poziom ochrony określony przez pierwszą zainstalowaną aplikację.

Od Androida 5.0 system narzuca nowe ograniczenie dotyczące unikalności uprawnień niestandardowych w przypadku aplikacji podpisanych różnymi kluczami. Teraz tylko 1 aplikacja na urządzeniu może definiować określone niestandardowe uprawnienie (na podstawie nazwy), chyba że inna aplikacja definiująca to uprawnienie jest podpisana tym samym kluczem. Jeśli użytkownik spróbuje zainstalować aplikację z duplikatem uprawnień niestandardowych i nie będzie ona podpisana tym samym kluczem co aplikacja zdefiniowana przez uprawnienia, 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 inne aplikacje za pomocą mechanizmu <uses-permission>. Jednak ze względu na nowe wymagania wprowadzone w Androidzie 5.0 należy dokładnie ocenić możliwe skutki dla aplikacji.

Oto kilka kwestii do rozważenia:

  • Czy w pliku manifestu Twojej aplikacji występują elementy <permission>? Jeśli tak, to czy są one rzeczywiście niezbędne do prawidłowego działania aplikacji lub usługi? A może zamiast tego użyjesz domyślnego uprawnienia systemowego?
  • Czy wiesz, skąd pochodzą elementy <permission> w Twojej aplikacji?
  • Czy chcesz, aby inne aplikacje mogły prosić o uprawnienia niestandardowe za pomocą <uses-permission>?
  • Czy w aplikacji używasz szablonów lub przykładowego kodu, który zawiera elementy <permission>? Czy te elementy uprawnień są rzeczywiście potrzebne?
  • Czy Twoje niestandardowe uprawnienia mają proste nazwy lub nazwy oparte na wspólnych terminach, które mogą być używane przez inne aplikacje?

Nowe instalacje i aktualizacje

Jak już wspomnieliśmy, nowe instalacje i aktualizacje aplikacji na urządzeniach z Androidem 4.4 lub starszym nie są objęte tą zmianą i nie ulegną zmianie. W przypadku nowych instalacji i aktualizacji na urządzeniach z Androidem 5.0 lub nowszym system nie zezwala na instalację aplikacji, jeśli definiuje ona uprawnienie niestandardowe, które jest już zdefiniowane przez istniejącą aplikację rezydencką.

Dotychczasowe instalacje z aktualizacją systemu Android 5.0

Jeśli Twoja aplikacja korzysta z uprawnień niestandardowych i jest szeroko rozpowszechniona, istnieje ryzyko, że będzie ona miała problemy po aktualizacji urządzeń użytkowników do Androida 5.0. Po zainstalowaniu aktualizacji systemu system ponownie sprawdza zainstalowane aplikacje, w tym ich niestandardowe uprawnienia. Jeśli Twoja aplikacja definiuje uprawnienie niestandardowe, które jest już zdefiniowane przez inną aplikację, która została już zweryfikowana, a Twoja aplikacja nie jest podpisana tym samym kluczem, co ta inna aplikacja, system nie instaluje ponownie aplikacji.

Rekomendacje

Na urządzeniach 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 aplikacji używasz niestandardowych uprawnień, zastanów się, skąd pochodzą i czy rzeczywiście ich potrzebujesz. Usuń z aplikacji wszystkie elementy <permission>, chyba że masz pewność, że są one niezbędne do prawidłowego działania aplikacji.
  • W miarę możliwości zastąp uprawnienia niestandardowe domyślnymi uprawnieniami systemu.
  • Jeśli Twoja aplikacja wymaga uprawnień niestandardowych, nadaj im unikalne nazwy, na przykład dodając je do pełnej nazwy pakietu aplikacji.
  • Jeśli masz pakiet aplikacji podpisany różnymi kluczami, a aplikacje te uzyskują dostęp do udostępnionego komponentu za pomocą niestandardowego uprawnienia, upewnij się, że to niestandardowe uprawnienie jest zdefiniowane tylko raz w umieszczonym komponencie. Aplikacje, które korzystają z wspólnego komponentu, nie powinny definiować niestandardowych uprawnień samodzielnie, lecz prosić o dostęp za pomocą mechanizmu <uses-permission>.
  • Jeśli masz pakiet aplikacji podpisanych tym samym kluczem, każda aplikacja może definiować te same niestandardowe uprawnienia, które są potrzebne. System umożliwia instalowanie aplikacji w zwykły sposób.

Zmiany domyślnej konfiguracji TLS/SSL

Android 5.0 wprowadza zmiany domyślnej konfiguracji TLS/SSL używanej przez aplikacje w przypadku ruchu 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 stałego ECDH są teraz wyłączone.
  • Preferowane są zestawy szyfrów ECDHE i DHE.

Te zmiany mogą spowodować przerwy w połączeniach HTTPS lub TLS/SSL w niewielkiej liczbie przypadków wymienionych poniżej.

Pamiętaj, że aplikacja ProviderInstaller z Usług Google Play zawiera już te zmiany w przypadku wersji Androida od 2.3 w górę.

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

Serwer może na przykład obsługiwać tylko zestawy szyfrowania 3DES lub MD5. Preferowanym rozwiązaniem jest ulepszenie konfiguracji serwera, aby umożliwić stosowanie silniejszych i bardziej nowoczesnych mechanizmów szyfrowania oraz protokołów. W idealnej sytuacji należy włączyć TLS 1.2 i AES-GCM oraz włączyć i preferować zestawy szyfrowania z zabezpieczeniami Forward Secrecy (ECDHE, DHE).

Możesz też zmodyfikować aplikację, aby używała niestandardowego obiektu SSLSocketFactory do komunikacji z serwerem. Fabryka powinna być zaprojektowana tak, aby tworzyć instancje SSLSocket, które mają włączone niektóre z zestawów szyfrów wymaganych przez serwer oprócz domyślnych zestawów szyfrów.

Aplikacja tworzy nieprawidłowe założenia dotyczące zestawów szyfrów używanych do łączenia się z serwerem

Na przykład niektóre aplikacje zawierają niestandardowy interfejs X509TrustManager, który ulega awarii, ponieważ oczekuje, że parametr authType będzie miał wartość RSA, ale napotyka wartość ECDHE_RSA lub DHE_RSA.

Serwer nie obsługuje TLS 1.1, TLS 1.2 ani nowych rozszerzeń TLS

Na przykład uzgodnienie TLS/SSL z serwerem jest błędnie odrzucane lub zawiesza się. Najlepszym rozwiązaniem jest uaktualnienie serwera, aby był zgodny z protokołem TLS/SSL. Dzięki temu serwer będzie mógł negocjować nowsze protokoły lub negocjować protokoły TLSv1 lub starsze i ignorować rozszerzenia TLS, których nie rozumie. W niektórych przypadkach wyłączenie TLSv1.1 i TLSv1.2 na serwerze może być tymczasowym rozwiązaniem do czasu uaktualnienia oprogramowania serwera.

Możesz też zmodyfikować aplikację, aby używała niestandardowego obiektu SSLSocketFactory do komunikacji z serwerem. Fabryka powinna być zaprojektowana tak, aby tworzyć instancje SSLSocket z włączonymi tylko tymi protokołami, które są prawidłowo obsługiwane przez serwer.

Obsługa profili zarządzanych

Administratorzy urządzeń mogą dodać do urządzenia profil zarządzany. Jest on własnością administratora, który ma nad nim kontrolę, a profil osobisty użytkownika i powiązana z nim przestrzeń dyskowa pozostają pod kontrolą użytkownika. Ta zmiana może wpływać na działanie dotychczasowej aplikacji w następujący sposób.

Obsługa intencji

Administratorzy urządzenia mogą ograniczyć dostęp do aplikacji systemowych z profilu zarządzanego. W takim przypadku, jeśli aplikacja wywoła intencję z profilu zarządzanego, która normalnie byłaby obsługiwana przez tę aplikację, a na profilu zarządzanym nie ma odpowiedniego modułu obsługi tej intencji, intencja powoduje wyjątek. Na przykład administrator urządzenia może ograniczyć dostęp aplikacji na profilu zarządzanym do aplikacji aparatu systemowego. Jeśli aplikacja działa na profilu zarządzanym i wywołuje funkcję startActivityForResult() dla MediaStore.ACTION_IMAGE_CAPTURE, a na profilu zarządzanym nie ma aplikacji, która mogłaby obsłużyć tę intencję, nastąpi ActivityNotFoundException.

Możesz temu zapobiec, sprawdzając, czy przed wywołaniem intencji istnieje co najmniej 1 obsługa. Aby sprawdzić prawidłowy moduł obsługi, zadzwoń pod numer Intent.resolveActivity(). Przykład takiego działania znajdziesz w artykule Robienie zdjęć: proste: robienie zdjęć za pomocą aplikacji Aparat.

Udostępnianie plików w różnych profilach

Każdy profil ma własne miejsce na pliki. Identyfikator URI pliku odnosi się do konkretnej lokalizacji w magazynie plików, co oznacza, że identyfikator URI pliku, który jest prawidłowy w jednym profilu, nie jest prawidłowy w drugim. Zwykle nie stanowi to problemu dla aplikacji, która zwykle tylko odczytuje utworzone przez siebie pliki. Jeśli jednak aplikacja dołącza plik do intencji, nie należy dołączać identyfikatora URI pliku, ponieważ w niektórych okolicznościach intencja może zostać obsłużona na innym profilu. Na przykład administrator urządzenia może określić, że zdarzenia związane z przechwytywaniem obrazu powinny być obsługiwane przez aplikację aparatu na profilu osobistym. Jeśli zamiar jest wywoływany przez aplikację na profilu zarządzanym, aparat musi mieć możliwość zapisania obrazu w miejscu, w którym aplikacje na profilu zarządzanym mogą go odczytać.

Aby zachować bezpieczeństwo, gdy musisz dołączyć plik do intencjonalnego działania, które może przechodzić z jednego profilu na inny, utwórz URI treści dla tego pliku i używaj go. Więcej informacji o udostępnianiu plików za pomocą identyfikatorów URI treści znajdziesz w artykule Udostępnianie plików. Na przykład administrator urządzenia może zezwolić aplikacji ACTION_IMAGE_CAPTURE na obsługę aparatu w profilu osobistym. Intent EXTRA_OUTPUT, który powoduje wykonanie działania, powinien zawierać URI treści określający, gdzie ma być zapisane zdjęcie. Aplikacja aparatu może zapisać obraz w lokalizacji określonej przez identyfikator URI, a aplikacja, która wywołała intencję, będzie mogła odczytać ten plik, nawet jeśli jest na innym profilu.

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

Android 5.0 nie obsługuje już widżetów na ekranie blokady, ale nadal obsługuje widżety na ekranie głównym.