Zmiany w działaniu: wszystkie aplikacje

Android 9 (poziom interfejsu API 28) wprowadza szereg zmian w systemie Android. Podane niżej zmiany w działaniu dotyczą wszystkich aplikacji działających na platformie Androida 9, niezależnie od poziomu interfejsu API, na który są kierowane. Wszyscy deweloperzy powinni przejrzeć te zmiany i w razie potrzeby odpowiednio dostosować swoje aplikacje.

Informacje o zmianach, które mają wpływ tylko na aplikacje kierowane na interfejs API na poziomie 28 lub wyższym, znajdziesz w artykule Zmiany w działaniu: aplikacje kierowane na interfejs API na poziomie 28 lub wyższym.

Zarządzanie zasilaniem

W Androidzie 9 wprowadzamy nowe funkcje, które usprawniają zarządzanie energią urządzenia. Te zmiany, wraz z funkcjami, które były dostępne w wersji sprzed Androida 9, pomagają zapewnić, że zasoby systemowe będą dostępne dla aplikacji, które najbardziej ich potrzebują.

Więcej informacji znajdziesz w artykule Zarządzanie zasilaniem.

Zmiany w ochronie prywatności

Aby zwiększyć prywatność użytkowników, Android 9 wprowadza kilka zmian w działaniu, np. ogranicza dostęp aplikacji w tle do czujników urządzenia, ogranicza dostęp do informacji pobieranych ze skanowania Wi-Fi, a także nowe reguły uprawnień i grupy uprawnień związane z połączeniami telefonicznymi, stanem telefonu i skanowaniami Wi-Fi.

Te zmiany dotyczą wszystkich aplikacji działających w Androidzie 9 niezależnie od docelowej wersji pakietu SDK.

Ograniczony dostęp do czujników w tle

Android 9 ogranicza aplikacjom w tle możliwość dostępu do danych wejściowych użytkownika i danych z czujników. Jeśli na urządzeniu z Androidem 9 Twoja aplikacja działa w tle, system stosuje do niej te ograniczenia:

  • Aplikacja nie ma dostępu do mikrofonu lub aparatu.
  • Czujniki korzystające z trybu raportowania ciągłego, np. akcelerometry i żyroskopy, nie otrzymują zdarzeń.
  • Czujniki, które korzystają z trybów raportowania on-change lub one-shot, nie otrzymują zdarzeń.

Jeśli aplikacja musi wykrywać zdarzenia z czujników na urządzeniach z Androidem 9, użyj usługi na pierwszym planie.

Ograniczono dostęp do rejestrów połączeń

Android 9 wprowadza grupę uprawnień CALL_LOG oraz przenosi uprawnienia READ_CALL_LOG, WRITE_CALL_LOG oraz PROCESS_OUTGOING_CALLS do tej grupy. W poprzednich wersjach Androida te uprawnienia znajdowały się w grupie uprawnień PHONE.

Ta grupa uprawnień CALL_LOG zapewnia użytkownikom większą kontrolę i wgląd w aplikacje, które potrzebują dostępu do poufnych informacji o połączeniach telefonicznych, np. do odczytywania zarejestrowanych połączeń i identyfikowania numerów telefonów.

Jeśli Twoja aplikacja wymaga dostępu do rejestrów połączeń lub przetwarza połączenia wychodzące, musisz wyraźnie poprosić o te uprawnienia grupę uprawnień CALL_LOG. W przeciwnym razie wystąpi SecurityException.

Uwaga: ponieważ te uprawnienia zmieniły grupy i są przyznawane w czasie działania, użytkownik może zablokować aplikacji dostęp do informacji z dzienników połączeń telefonicznych. W takim przypadku aplikacja powinna być w stanie dobrze poradzić sobie z brakiem dostępu do informacji.

Jeśli Twoja aplikacja jest już zgodna ze sprawdzonymi metodami dotyczącymi uprawnień czasu działania, może obsłużyć zmianę w grupie uprawnień.

Ograniczony dostęp do numerów telefonów

Aplikacje działające na Androidzie 9 nie mogą odczytywać numerów ani stanu telefonu bez wcześniejszego uzyskania uprawnień READ_CALL_LOG, a także innych uprawnień wymaganych w przypadku danej aplikacji.

Numery telefonów powiązane z połączeniami przychodzącymi i wychodzącymi są widoczne w stanie transmisji (np. w przypadku połączeń przychodzących i wychodzących) i są dostępne w klasie PhoneStateListener. Bez uprawnienia READ_CALL_LOG pole numeru telefonu dostępne w transmisjach PHONE_STATE_CHANGED i za pośrednictwem PhoneStateListener jest puste.

Aby odczytywać numery telefonów ze stanu telefonu, zaktualizuj aplikację tak, aby prosiła o przyznanie niezbędnych uprawnień w zależności od przypadku użycia:

Ograniczony dostęp do lokalizacji Wi-Fi i informacji o połączeniu

W Androidzie 9 wymagania dotyczące uprawnień aplikacji do przeprowadzania skanowania Wi-Fi są bardziej rygorystyczne niż w poprzednich wersjach. Więcej informacji znajdziesz w artykule Ograniczenia skanowania Wi-Fi.

Podobne ograniczenia mają też zastosowanie do metody getConnectionInfo(), która zwraca obiekt WifiInfo opisujący bieżące połączenie Wi-Fi. Metody tego obiektu mogą służyć do pobierania wartości identyfikatorów SSID i BSSID tylko wtedy, gdy aplikacja wywołująca ma te uprawnienia:

  • ACCESS_FINE_LOCATION lub ACCESS_COARSE_LOCATION
  • ACCESS_WIFI_STATE

Pobieranie identyfikatora SSID lub BSSID wymaga też, aby na urządzeniu były włączone usługi lokalizacyjne (w sekcji Ustawienia > Lokalizacja).

Informacje zostały usunięte z metod usługi Wi-Fi

W Androidzie 9 te zdarzenia i transmisje nie otrzymują informacji o lokalizacji użytkownika ani danych umożliwiających identyfikację:

Transmisja systemu NETWORK_STATE_CHANGED_ACTION z Wi-Fi nie zawiera już identyfikatora SSID (poprzednio EXTRA_SSID), BSSID (wcześniej EXTRA_BSSID) ani informacji o połączeniu (wcześniej Extra_NETWORK_INFO). Jeśli aplikacja potrzebuje tych informacji, wywołaj metodę getConnectionInfo().

Informacje telefoniczne zależą teraz od ustawień lokalizacji urządzenia

Jeśli użytkownik wyłączył lokalizację urządzenia na urządzeniu z Androidem 9, te metody nie dają oczekiwanych wyników:

Ograniczenia w zakresie korzystania z interfejsów innych niż SDK

Aby zapewnić stabilność i zgodność aplikacji, platforma ogranicza możliwość korzystania z niektórych metod i pól spoza SDK. Te ograniczenia mają zastosowanie niezależnie od tego, czy próbujesz uzyskać bezpośredni dostęp do tych metod i pól, za pomocą analizy czy za pomocą interfejsu JNI. Na Androidzie 9 aplikacja nadal ma dostęp do tych interfejsów z ograniczeniami. Platforma wykorzystuje powiadomienia i wpisy logu, aby zwrócić na nie uwagę. Jeśli w aplikacji wyświetla się taki komunikat, pamiętaj, aby zastosować inną strategię implementacji niż interfejs z ograniczonym dostępem. Jeśli uważasz, że żadna alternatywna strategia nie jest możliwa, możesz zgłosić błąd z prośbą o ponowne rozpatrzenie ograniczenia.

Sekcja Ograniczenia interfejsów innych niż SDK zawiera dodatkowe ważne informacje. Sprawdź go, aby mieć pewność, że aplikacja nadal działa prawidłowo.

Zmiany w działaniu zabezpieczeń

Zmiany w zabezpieczeniach urządzenia

Android 9 dodaje kilka funkcji, które zwiększają bezpieczeństwo aplikacji niezależnie od tego, na którą wersję jest ona kierowana.

Zmiany implementacji TLS

W Androidzie 9 w implementacji TLS w systemie wprowadzono kilka zmian:

Więcej informacji o tworzeniu bezpiecznych żądań sieciowych w aplikacji na Androida znajdziesz w tym artykule.

Ściślejszy filtr SECCOMP

Android 9 jeszcze bardziej ogranicza połączenia systemowe dostępne dla aplikacji. To działanie jest rozszerzeniem filtra SECCOMP dostępnego w Androidzie 8.0 (poziom interfejsu API 26).

Zmiany kryptograficzne

Android 9 wprowadza kilka zmian w implementacji i obsłudze algorytmów kryptograficznych.

szyfrowanie implementacji parametrów i algorytmów;

Android 9 udostępnia dodatkowe implementacje parametrów algorytmu w Conscrypt. Są to: AES, DESEDE, OAEP i EC. W Androidzie 9 wersje tych parametrów oraz wiele algorytmów zostały wycofane z wersji Bouncy Castle.

Jeśli Twoja aplikacja jest kierowana na Androida 8.1 (poziom interfejsu API 27) lub starszego, otrzymasz ostrzeżenie, gdy poprosisz o implementację jednego z wycofanych algorytmów Bouncy Castle. Jeśli jednak kierujesz aplikację na Androida 9, każde z tych żądań powoduje wywołanie NoSuchAlgorithmException.

Inne zmiany

W Androidzie 9 wprowadziliśmy kilka innych zmian związanych z kryptografią:

  • Jeśli używasz kluczy PBE, jeśli Bouncy Castle oczekuje na wektor inicjujący (IV), a Twoja aplikacja go nie udostępnia, otrzymasz ostrzeżenie.
  • Implementacja szyfrowania ARC4 w Conscrypt pozwala określić ARC4/ECB/NoPadding lub ARC4/NONE/NoPadding.
  • Dostawca technologii Crypto Java Cryptography Architecture (JCA) został usunięty. W efekcie, jeśli aplikacja wywoła metodę SecureRandom.getInstance("SHA1PRNG", "Crypto"), wystąpi NoSuchProviderException.
  • Jeśli Twoja aplikacja analizuje klucze RSA z buforów, które są większe niż struktura klucza, wyjątek się nie pojawi.

Więcej informacji o korzystaniu z możliwości kryptograficznych Androida znajdziesz w artykule Kryptografia.

Bezpieczne zaszyfrowane pliki Androida nie są już obsługiwane

Android 9 całkowicie wyłącza obsługę bezpiecznych plików zaszyfrowanych na Androidzie (ASEC).

W Androidzie 2.2 (poziom interfejsu API 8) na Androidzie wprowadzono ASEC, aby obsługiwać funkcje aplikacji na karcie SD. W Androidzie 6.0 (poziom interfejsu API 23) platforma wprowadziła technologię adaptacyjnych urządzeń do przechowywania danych, której deweloperzy mogą używać zamiast ASEC.

Aktualizacje bibliotek ICU

Android 9 używa biblioteki ICU w wersji 60. Android 8.0 (poziom interfejsu API 26) i Android 8.1 (poziom API 27) korzystają z ICU 58.

ICU służy do udostępniania publicznych interfejsów API w obrębie android.icu package i jest używany wewnętrznie na platformie Androida do obsługi internacjonalizacji. Używa się go na przykład do implementacji klas Androida w java.util, java.text i android.text.format.

Aktualizacja ICU 60 wprowadza wiele drobnych, ale przydatnych zmian, w tym obsługę danych Emotikon 5.0 oraz ulepszone formaty daty i godziny, co zostało opisane w informacjach o wersji ICU 59 i ICU60.

Ważne zmiany w tej aktualizacji:

  • Zmienił się sposób, w jaki platforma obsługuje strefy czasowe.
    • Platforma lepiej obsługuje czas GMT i UTC; UTC nie jest już synonimem czasu GMT.

      ICU udostępnia teraz przetłumaczone nazwy stref dla czasu GMT i UTC. Ta zmiana wpływa na formatowanie i analizowanie działania funkcji android.icu w strefach takich jak „GMT”, „Etc/GMT”, „UTC”, „Etc/UTC” i „Zulu”.

    • java.text.SimpleDateFormat używa teraz ICU do podawania wyświetlanych nazw dla strefy UTC /GMT, co oznacza:
      • Formatowanie zzzz generuje długi zlokalizowany ciąg znaków dla wielu języków. Wcześniej był to czas UTC, a czas GMT+ to „GMT+00:00”.
      • Analiza zzzz rozpoznaje ciągi takie jak „uniwersalny czas koordynowany” i „czas uniwersalny”.
      • Aplikacje mogą napotkać problemy ze zgodnością, jeśli przyjmą, że czas UTC lub GMT+00:00 w przypadku zzzz we wszystkich językach jest zwracany.
    • Sposób działania instancji java.text.DateFormatSymbols.getZoneStrings() zmienił się:
      • Podobnie jak SimpleDateFormat, strefy UTC i GMT mają teraz długie nazwy. Odmiany czasu letniego (czasu UTC) strefy czasowej UTC, takie jak „UTC”, „ETC/UTC” czy „Zulu”, zostają zamienione na czas GMT+00:00. Stanowi on standardową opcję zastępczą w sytuacji, gdy nazwy nie są dostępne, a nie ciąg tekstowy UTC zakodowany na stałe w kodzie.
      • Niektóre identyfikatory stref są prawidłowo rozpoznawane jako synonimy innych stref, dzięki czemu Android znajduje ciągi znaków dotyczące archiwalnych identyfikatorów stref, takich jak Eire, których wcześniej nie można było rozpoznać.
    • Azja/Hanoi nie jest już uznawana. Z tego powodu java.util.TimeZones.getAvailableIds() nie zwraca tej wartości, a java.util.TimeZone.getTimeZone() jej nie rozpoznaje. To zachowanie jest zgodne z obecnym działaniem android.icu.
  • Metoda android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String) może zwrócić błąd ParseException nawet podczas analizowania prawidłowego tekstu waluty. Unikaj tego problemu, używając w tekście waluty w stylu PLURALCURRENCYSTYLE parametru NumberFormat.parseCurrency, który jest dostępny od Androida 7.0 (poziom interfejsu API 24).

Zmiany w programie Android Test

Android 9 wprowadza kilka zmian w bibliotece i strukturze klas platformy Android Test. Te zmiany ułatwią deweloperom korzystanie z publicznych interfejsów API obsługiwanych przez platformę, ale umożliwią też większą elastyczność w tworzeniu i przeprowadzaniu testów za pomocą bibliotek innych firm lub niestandardowych algorytmów.

Biblioteki zostały usunięte z platformy

Android 9 dzieli klasy oparte na JUnit w 3 biblioteki: android.test.base, android.test.runner i android.test.mock. Ta zmiana umożliwia przeprowadzanie testów na wersji JUnit, która najlepiej współpracuje z zależnościami projektu. Ta wersja JUnit może się różnić od wersji dostępnej w android.jar.

Więcej informacji o pogrupowaniu klas opartych na JUnit w te biblioteki oraz o tym, jak przygotować projekt aplikacji pod kątem pisania i przeprowadzania testów, znajdziesz w artykule Konfigurowanie projektu na potrzeby Android Test.

Zmiany w kompilacji pakietu testowego

Metoda addRequirements() w klasie TestSuiteBuilder została usunięta, a sama klasa TestSuiteBuilder została wycofana. Metoda addRequirements() wymagała od programistów podania argumentów, których typy to interfejsy API, dlatego interfejs API był nieprawidłowy.

Dekoder UTF w Javie

UTF-8 to domyślny zestaw znaków w Androidzie. Sekwencję bajtową UTF-8 można dekodować za pomocą konstruktora String, takiego jak String(byte[] bytes).

Dekoder UTF-8 w Androidzie 9 spełnia standardy Unicode bardziej rygorystycznie niż w poprzednich wersjach. Zmiany obejmują:

  • Najkrótszy format UTF-8, na przykład <C0, AF>, jest traktowany jako nieprawidłowy.
  • Format zastępcza kodowania UTF-8, taki jak U+D800..U+DFFF, jest traktowany jako nieprawidłowy format.
  • Wartość maksymalna jest zastępowana pojedynczym elementem U+FFFD. Na przykład w sekwencji bajtów „41 C0 AF 41 F4 80 80 41” maksymalne podczęści to „C0”, „AF” i „F4 80 80”. „F4 80 80” może być początkową sekwencją ciągu „F4 80 80 80”, ale „C0” nie może być początkowym podrzędem żadnej prawidłowej sekwencji jednostek kodu. W związku z tym dane wyjściowe powinny wyglądać tak: „A\ufffd\ufffdA\ufffdA”.
  • Aby zdekodować zmodyfikowaną sekwencję UTF-8 / CESU-8 w Androidzie 9 lub nowszym, użyj metody DataInputStream.readUTF() lub NewStringUTF() JNI.

Weryfikacja nazwy hosta przy użyciu certyfikatu

RFC 2818 opisuje 2 metody dopasowywania nazwy domeny do certyfikatu – przy użyciu dostępnych nazw w rozszerzeniu subjectAltName (SAN) lub w przypadku braku rozszerzenia SAN, które są stosowane do commonName (CN).

Jednak wartość zastępcza obiektu CN została wycofana w RFC 2818. Dlatego Android nie korzysta już z interfejsu CN. Aby można było zweryfikować nazwę hosta, serwer musi przedstawić certyfikat z pasującym identyfikatorem SAN. Certyfikaty, które nie zawierają elementu SAN pasującego do nazwy hosta, nie są już zaufane.

Wyszukiwanie adresu sieciowego może powodować naruszenia zasad sieci

Wyszukiwanie adresów sieciowych, które wymagają rozpoznawania nazw, może obejmować operacje wejścia-wyjścia sieci i dlatego są uznawane za operacje blokujące. Blokowanie operacji w wątku głównym może powodować przerwy lub zacinanie.

Klasa StrictMode jest narzędziem dla programistów, które pomaga programistom wykrywać problemy w kodzie.

W Androidzie 9 i nowszych StrictMode wykrywa naruszenia sieci spowodowane wyszukiwaniem adresu sieciowego, który wymaga rozpoznania nazwy.

Nie wysyłaj aplikacji z włączoną opcją StrictMode. Jeśli to zrobisz, w aplikacjach mogą występować wyjątki, takie jak NetworkOnMainThreadException, gdy używasz metody detectNetwork() lub detectAll() do pobierania zasad, które wykrywają naruszenia sieci.

Rozwiązanie liczbowego adresu IP nie jest uznawane za operację blokującą. Rozpoznawanie liczbowych adresów IP działa tak samo jak w wersjach starszych niż 9.

Tagowanie gniazd

W wersjach platformy starszych niż Android 9, jeśli gniazdo zostało oznaczone tagiem za pomocą metody setThreadStatsTag(), podczas wysyłania do innego procesu przy użyciu powiązań IPC z kontenerem ParcelFileDescriptor jest ono usuwane.

W Androidzie 9 i nowszych tag gniazda jest zachowywany, gdy jest wysyłany do innego procesu za pomocą wiąza IPC. Ta zmiana może wpłynąć na statystyki ruchu w sieci, np. przy korzystaniu z metody queryDetailsForUidTag().

Jeśli chcesz zachować zachowanie poprzednich wersji, co spowoduje usunięcie tagów z boksa wysyłanego do innego procesu, możesz przed wysłaniem go wywołać funkcję untagSocket().

Zgłoszona liczba dostępnych bajtów w gnieździe

Metoda available() zwraca 0, gdy zostanie wywołana po wywołaniu metody shutdownInput().

bardziej szczegółowe raportowanie możliwości sieci w przypadku sieci VPN.

W Androidzie 8.1 (poziom interfejsu API 27) i starszych klasa NetworkCapabilities zgłaszała tylko ograniczony zestaw informacji dotyczących sieci VPN, np. TRANSPORT_VPN, ale pomijała informacje NET_CAPABILITY_NOT_VPN. Z tych ograniczonych informacji trudno było określić, czy korzystanie z sieci VPN wiąże się z obciążeniem użytkownika aplikacji. Na przykład sprawdzenie NET_CAPABILITY_NOT_METERED nie określiłoby, czy używane sieci są objęte pomiarem.

W Androidzie 9 i nowszych, gdy VPN wywołuje metodę setUnderlyingNetworks(), system Android scala dane i możliwości pozostałych sieci i zwraca wynik jako efektywne funkcje sieciowe sieci VPN.

Na Androidzie 9 i nowszych aplikacje, które już sprawdzają NET_CAPABILITY_NOT_METERED, korzystają z możliwości sieciowych VPN i sieci.

Pliki w folderze xt_qtaguid nie są już dostępne dla aplikacji

Począwszy od Androida 9, aplikacje nie mogą mieć bezpośredniego dostępu do plików w folderze /proc/net/xt_qtaguid. Chodzi o to, aby zachować spójność z urządzeniami, na których w ogóle ich nie ma.

Publiczne interfejsy API, które korzystają z tych plików, TrafficStats i NetworkStatsManager, nadal działają zgodnie z oczekiwaniami. Jednak nieobsługiwane funkcje cutils, takie jak qtaguid_tagSocket(), mogą nie działać zgodnie z oczekiwaniami lub w ogóle nie działać na różnych urządzeniach.

Wymaganie FLAG_ACTIVITY_NEW_TASK jest teraz egzekwowane

W Androidzie 9 nie można rozpoczynać działań z kontekstu niezwiązanego z aktywnością, chyba że przekażesz flagę intencji FLAG_ACTIVITY_NEW_TASK. Jeśli spróbujesz rozpocząć działanie bez przekazania tej flagi, działanie się nie rozpocznie, a system zapisze komunikat w dzienniku.

Zmiany obrotu ekranu

Począwszy od Androida 9 zaszły istotne zmiany w trybie rotacji pionowej. Na Androidzie 8.0 (poziom interfejsu API 26) użytkownicy mogą przełączać się między trybami autoobracania i pionowego za pomocą kafelka Szybkie ustawienia lub ustawień wyświetlacza. Tryb portretowy to teraz blokada obracania. Jest on aktywny po wyłączeniu autoobracania. Tryb autoobracania się nie zmieni.

Gdy urządzenie jest w trybie blokady obrotu, użytkownik może zablokować ekran i wybrać dowolny obrót obsługiwany przez górną, widoczną aktywność. Aktywność nie powinna zakładać, że będzie zawsze renderowana w orientacji pionowej. Jeśli aktywność o największej liczbie wyświetleń można renderować w kilku rotacjach w trybie autoobracania, w trybie blokady rotacji powinny być dostępne te same opcje, z pewnymi wyjątkami wynikającymi z ustawienia screenOrientation aktywności (patrz tabela poniżej).

Aktywności, które wymagają określonej orientacji (np. screenOrientation=landscape), ignorują ustawienie blokady użytkownika i działają tak samo jak na Androidzie 8.0.

Preferencje dotyczące orientacji ekranu możesz ustawić na poziomie aktywności w pliku manifestu Androida lub automatycznie za pomocą funkcji setRequestedOrientation().

Tryb blokady rotacji działa dzięki ustawieniu preferencji rotacji użytkowników, których WindowManager używa do obsługi rotacji aktywności. Preferencje rotacji użytkowników możesz zmienić w tych przypadkach. Pamiętaj, że występuje odchylenie od naturalnego obrotu urządzenia, które zwykle jest ustawione pionowo na urządzeniach o różnych formatach:

  • Gdy użytkownik zaakceptuje sugestię rotacji, ustawienie rotacji zmieni się na tę sugestię.
  • Gdy użytkownik przełączy się na aplikację z wymuszonym wyświetlaniem pionowym (w tym na ekranie blokady lub w programie uruchamiającym), ustawienie obrotu zmieni się na pionową.

W tabeli poniżej znajdziesz podsumowanie działania rotacji w przypadku typowych orientacji ekranu:

Orientacja ekranu Działanie
nie określono, użytkownik Przy blokadzie autoobracania i obrotu aktywność może być renderowana w orientacji pionowej lub poziomej (i odwrotnie). Prawdopodobnie będzie obsługiwany zarówno układ pionowy, jak i poziomy.
krajobraz użytkownika W przypadku blokady autoobracania i obrotu aktywność może być renderowana zarówno w orientacji poziomej, jak i odwrotnej. Obsługuje tylko układy poziome.
użytkownikPortret W przypadku blokady autoobracania i obrotu aktywność może być renderowana w orientacji pionowej lub odwróconej. Prawdopodobnie obsługiwane są tylko układy pionowe.
Użytkownik z pełnymi uprawnieniami Przy blokadzie autoobracania i obrotu aktywność może być renderowana w orientacji pionowej lub poziomej (i odwrotnie). Prawdopodobnie będzie obsługiwany zarówno układ pionowy, jak i poziomy.

Użytkownicy z blokadą obracania będą mogli skorzystać z możliwości zablokowania ustawienia w celu odwrócenia orientacji pionowej (często o 180°).
czujnik, pełny matryca, czujnikPortret, czujniki orientacji poziomej Ustawienie blokady obrotu jest ignorowane i jest traktowane tak, jakby autoobracanie było aktywne. Tej opcji należy używać tylko w wyjątkowych sytuacjach, z dużą rozwagą, by zadbać o wrażenia użytkowników.

Wycofanie klienta HTTP Apache wpływa na aplikacje z niestandardowym elementem ClassLoader

W Androidzie 6.0 usunęliśmy obsługę klienta HTTP Apache. Ta zmiana nie wpływa na większość aplikacji, które nie są kierowane na Androida 9 lub nowszego. Ta zmiana może jednak mieć wpływ na niektóre aplikacje o niestandardowej strukturze ClassLoader, nawet jeśli nie są one kierowane na Androida 9 lub nowszego.

Może to mieć wpływ na aplikację, która używa niestandardowego elementu ClassLoader, który jednoznacznie przekazuje dostęp do systemu ClassLoader. Te aplikacje muszą przekazać dostęp do aplikacji ClassLoader zamiast tego, gdy szukają zajęć w org.apache.http.*. Jeśli klient przekaże dostęp do systemu ClassLoader, aplikacje przestaną działać w Androidzie 9 lub nowszym z klasą NoClassDefFoundError, ponieważ te klasy nie są już znane systemowi ClassLoader. Aby zapobiec podobnym problemom w przyszłości, aplikacje powinny w ogólnych klasach wczytywania używać aplikacji ClassLoader, zamiast uzyskiwać bezpośredni dostęp do systemu ClassLoader.

Wyliczam kamery

Aplikacje działające na urządzeniach z Androidem 9 mogą wykryć każdą dostępną kamerę, wywołując metodę getCameraIdList(). Aplikacja nie powinna zakładać, że urządzenie ma tylko jeden tylny aparat czy tylko jeden przedni.

Jeśli na przykład aplikacja ma przycisk do przełączania się między przednim a tylnym aparatem, może być dostępnych więcej niż jeden przedni i tylny aparat. Zapoznaj się z listą kamer, przyjrzyj się właściwościom poszczególnych kamer i zdecyduj, które z nich będzie można pokazać użytkownikowi.