Zmiany w działaniu: wszystkie aplikacje

Android 9 (poziom interfejsu API 28) wprowadza wiele zmian w systemie Android. Podane niżej zmiany zachowania dotyczą wszystkich aplikacji, które działają na platformie Androida 9, niezależnie od poziomu interfejsu API, na który są kierowane. Wszyscy deweloperzy powinni zapoznać się z tymi zmianami i w odpowiednich przypadkach odpowiednio zmodyfikować swoje aplikacje.

Zmiany, które dotyczą tylko aplikacji kierowanych na interfejs API na poziomie 28 lub wyższym, znajdziesz w sekcji Zmiany w zachowaniu: aplikacje kierowane na interfejs API na poziomie 28 lub wyższym.

Zarządzanie zasilaniem

Android 9 wprowadza nowe funkcje, które poprawiają zarządzanie energią urządzenia. Te zmiany, wraz z funkcjami, które były dostępne już przed Androidem 9, pomagają zapewnić dostęp do zasobów systemowych aplikacjom, które ich najbardziej potrzebują.

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

Zmiany dotyczące prywatności

Aby zwiększyć prywatność użytkowników, Android 9 wprowadza kilka zmian w zachowaniu, takich jak ograniczenie dostępu aplikacji działających w tle do czujników urządzenia, ograniczenie informacji pobieranych z skanowania sieci Wi-Fi oraz nowe reguły i grupy uprawnień związane z połączeniami telefonicznymi, stanem telefonu oraz skanowaniem sieci Wi-Fi.

Te zmiany mają wpływ na wszystkie aplikacje działające na Androidzie 9, niezależnie od wersji docelowego pakietu SDK.

Ograniczony dostęp do czujników w tle

Android 9 ogranicza dostęp aplikacji działających w tle do danych o wprowadzanych przez użytkownika treściach i danych z czujników. Jeśli aplikacja działa w tle na urządzeniu z Androidem 9, system nakłada na nią te ograniczenia:

  • Aplikacja nie ma dostępu do mikrofonu ani kamery.
  • Czujniki, które używają ciągłego trybu raportowania, takie jak akcelerometry i żyroskopy, nie otrzymują zdarzeń.
  • Czujniki, które używają trybów raportowania on-change lub one-shot, nie otrzymują zdarzeń.

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

Ograniczony dostęp do dzienników połączeń

Android 9 wprowadza CALL_LOG grupę uprawnień i przenosi do niej uprawnienia READ_CALL_LOG, WRITE_CALL_LOG i PROCESS_OUTGOING_CALLS. We wcześniejszych wersjach Androida te uprawnienia znajdowały się w grupie uprawnień PHONE.

Ta grupa uprawnień CALL_LOG zapewnia użytkownikom większą kontrolę i widoczność w przypadku aplikacji, które potrzebują dostępu do poufnych informacji o połączeniach telefonicznych, takich jak odczytywanie zapisów połączeń i identyfikowanie numerów telefonów.

Jeśli aplikacja wymaga dostępu do rejestru połączeń lub musi przetwarzać wychodzące połączenia, musisz wyraźnie poprosić o te uprawnienia z grupy uprawnień CALL_LOG. W przeciwnym razie wystąpi błąd SecurityException.

Uwaga: ponieważ te uprawnienia zostały przeniesione do innych grup i są przyznawane w czasie wykonywania aplikacji, użytkownik może zablokować dostęp aplikacji do informacji z rejestrów połączeń. W takim przypadku aplikacja powinna być w stanie poradzić sobie z brakiem dostępu do informacji.

Jeśli Twoja aplikacja już stosuje sprawdzone metody dotyczące uprawnień w czasie wykonywania, może obsłużyć zmianę grupy uprawnień.

Ograniczony dostęp do numerów telefonów

Aplikacje działające na Androidzie 9 nie mogą odczytywać numerów telefonów ani stanu telefonu bez wcześniejszego uzyskania uprawnienia READ_CALL_LOG, oprócz innych uprawnień wymaganych przez przypadki użycia aplikacji.

Numery telefonów powiązane z połączeniami przychodzącymi i wychodzącymi są widoczne w transmisji stanu telefonu, na przykład w przypadku połączeń przychodzących i wychodzących. Można je wyświetlić w klasie PhoneStateListener. Bez tegoREAD_CALL_LOGuprawnienia pole numeru telefonu, które jest dostępne w transmisjach PHONE_STATE_CHANGED i poprzez PhoneStateListener, jest puste.

Aby odczytać numery telefonów z stanu telefonu, zaktualizuj aplikację, aby poprosić o wymagane uprawnienia na podstawie przypadku użycia:

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

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

Podobne ograniczenia dotyczą również metody getConnectionInfo(), która zwraca obiekt WifiInfoopisujący bieżące połączenie Wi-Fi. Metody tego obiektu można używać do pobierania wartości SSID i BSSID tylko wtedy, gdy aplikacja wywołująca ma te uprawnienia:

  • ACCESS_FINE_LOCATION lub ACCESS_COARSE_LOCATION
  • ACCESS_WIFI_STATE

Aby pobrać identyfikator SSID lub BSSID, musisz też włączyć na urządzeniu usługi lokalizacyjne (w sekcji Ustawienia > Lokalizacja).

Informacje usunięte z metod obsługi Wi-Fi

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

Systemowy pakiet danych NETWORK_STATE_CHANGED_ACTION z sieci Wi-Fi nie zawiera już identyfikatora SSID (wcześniej EXTRA_SSID), identyfikatora BSSID (wcześniej EXTRA_BSSID) ani informacji o połączeniu (wcześniej EXTRA_NETWORK_INFO). Jeśli aplikacja potrzebuje tych informacji, wywołaj funkcję getConnectionInfo().

Informacje o telefonii są teraz powiązane z ustawieniem lokalizacji urządzenia

Jeśli użytkownik wyłączył lokalizowanie urządzenia na urządzeniu z Androidem 9, te metody nie przynoszą rezultatów:

Ograniczenia dotyczące korzystania z interfejsów innych niż SDK

Aby zapewnić stabilność i zgodność aplikacji, platforma ogranicza użycie niektórych metod i pól, które nie należą do platformy SKAdowe. Ograniczenia te obowiązują niezależnie od tego, czy próbujesz uzyskać dostęp do tych metod i pól bezpośrednio, za pomocą funkcji odbicia lustrzanego czy za pomocą JNI. W Androidzie 9 aplikacja może nadal uzyskiwać dostęp do tych ograniczonych interfejsów. Platforma używa komunikatów i wpisów w dzienniku, aby zwrócić na nie uwagę. Jeśli w Twojej aplikacji pojawia się taka informacja, musisz zastosować inną strategię implementacji niż interfejs z ograniczeniami. Jeśli uważasz, że nie ma żadnej alternatywnej strategii, możesz zgłosić błąd, aby poprosić o ponowne rozpatrzenie ograniczenia.

Więcej ważnych informacji znajdziesz w artykule Ograniczenia dotyczące interfejsów innych niż SDK. Przejrzyj je, aby mieć pewność, że aplikacja będzie nadal działać prawidłowo.

Zmiany w działaniu zabezpieczeń

Zmiany zabezpieczeń urządzenia

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

Zmiany w implementacji TLS

W Androidzie 9 wdrożenie TLS przeszło kilka zmian:

  • Jeśli podczas tworzenia instancji SSLSocket nie uda się nawiązać połączenia, system zwróci błąd IOException zamiast błędu NullPointerException.
  • Klasa SSLEngine sprawnie obsługuje wszystkie alerty close_notify, które się pojawiają.

Więcej informacji o wysyłaniu bezpiecznych żądań sieciowych w aplikacji na Androida znajdziesz w artykule Przykład HTTPS.

Surowsze filtrowanie SECCOMP

Android 9 jeszcze bardziej ogranicza wywołania systemowe dostępne dla aplikacji. To działanie jest rozszerzeniem filtra SECCOMP, który jest zawarty w Androidzie 8.0 (poziom interfejsu API 26).

Zmiany dotyczące kryptografii

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

Implementacje parametrów i algorytmów w Conscrypt

Android 9 udostępnia dodatkowe implementacje parametrów algorytmu w Conscrypt. Te parametry to: AES, DESEDE, OAEP i EC. W wersji 9 Androida wycofane zostały wersje tych parametrów i wielu algorytmów z usług Bouncy Castle.

Jeśli Twoja aplikacja jest kierowana na Androida 8.1 (poziom interfejsu API 27) lub niższą wersję, otrzymasz ostrzeżenie, gdy zażądasz implementacji Bouncy Castle jednego z tych wycofanych algorytmów. Jeśli jednak kierujesz reklamy na Androida 9, te żądania będą wywoływać błąd NoSuchAlgorithmException.

Inne zmiany

Android 9 wprowadza kilka innych zmian związanych z kryptografia:

  • Jeśli podczas używania kluczy PBE biblioteka Bouncy Castle oczekuje wektora inicjalizacji (IV), a aplikacja go nie podaje, pojawi się ostrzeżenie.
  • Implementacja szyfru ARC4 w Conscrypt umożliwia ustawienie opcji ARC4/ECB/NoPadding lub ARC4/NONE/NoPadding.
  • Usunięto dostawcę Crypto Java Cryptography Architecture (JCA). W efekcie, jeśli Twoja aplikacja wywoła funkcję SecureRandom.getInstance("SHA1PRNG", "Crypto"), nastąpi błąd NoSuchProviderException.
  • Jeśli aplikacja parsuje klucze RSA z buforów większych niż struktura klucza, wyjątek nie wystąpi.

Więcej informacji o funkcjach kryptograficznych Androida znajdziesz w artykule Kryptograficzne.

Zaszyfrowane pliki Androida nie są już obsługiwane

Android 9 całkowicie usuwa obsługę zaszyfrowanych plików Androida (ASEC).

W Androidzie 2.2 (poziom interfejsu API 8) wprowadzono ASEC, aby obsługiwać aplikacje na karcie SD. W Androidzie 6.0 (poziom interfejsu API 23) wprowadzono technologię adoptable storage, której deweloperzy mogą używać zamiast ASEC.

Aktualizacje bibliotek ICU

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

ICU służy do udostępniania publicznych interfejsów API w ramach interfejsu android.icu package. Jest też używany wewnętrznie na platformie Android do obsługi międzynarodowej. Jest on na przykład używany do implementowania klas Androida w plikach java.util, java.text i android.text.format.

Aktualizacja do ICU 60 zawiera wiele drobnych, ale przydatnych zmian, w tym obsługę danych Emoji 5.0 i ulepszone formaty daty i czasu, opisane w notatkach o wersjach ICU 59 i ICU 60.

Ważne zmiany w tej aktualizacji:

  • Zmieniliśmy sposób obsługi stref czasowych przez platformę.
    • Platforma lepiej obsługuje czas GMT i UTC. Czas UTC nie jest już synonimem czasu GMT.

      ICU udostępnia teraz przetłumaczone nazwy stref GMT i UTC. Ta zmiana wpływa na formatowanie i parsowanie android.icu w przypadku stref czasowych takich jak „GMT”, „Etc/GMT”, „UTC”, „Etc/UTC” i „Zulu”.

    • java.text.SimpleDateFormat teraz używa ICU do wyświetlania nazw strefy UTC /GMT:
      • Formatowanie zzzz generuje długi ciąg znaków zlokalizowany na potrzeby wielu ustawień regionalnych. Wcześniej w przypadku czasu UTC zwracał on wartość „UTC”, a w przypadku czasu GMT – ciągi znaków takie jak „GMT+00:00”.
      • Analizowanie zzzz rozpoznaje ciągi znaków takie jak „Uniwersalny czas koordynowany” i „Czas Greenwich”.
      • Aplikacje mogą napotkać problemy ze zgodnością, jeśli zakładają, że „UTC” lub „GMT+00:00” są wyjściem dla zzzz we wszystkich językach.
    • Zmieniło się działanie funkcji java.text.DateFormatSymbols.getZoneStrings():
      • Podobnie jak w przypadku SimpleDateFormat, strefy czasowe UTC i GMT mają teraz długie nazwy. Zmienne nazwy stref czasowych z czasem letnim dla strefy UTC, takie jak „UTC”, „Etc/UTC” i „Zulu”, stają się GMT+00:00, co jest standardowym rozwiązaniem zastępczym, gdy nie ma dostępnych nazw, zamiast zakodowanego na stałe ciągu UTC.
      • Niektóre identyfikatory stref są prawidłowo rozpoznawane jako synonimy innych stref, dzięki czemu Android znajduje ciągi znaków dla przestarzałych identyfikatorów stref, takich jak Eire, które wcześniej nie mogły zostać rozwiązane.
    • Strefa Asia/Hanoi nie jest już rozpoznawana. Z tego powodu funkcja java.util.TimeZones.getAvailableIds() nie zwraca tej wartości, a funkcja java.util.TimeZone.getTimeZone() jej nie rozpoznaje. Jest to zgodne z dotychczasowym działaniem android.icu.
  • Metoda android.icu.text.NumberFormat.getInstance(ULocale, PLURALCURRENCYSTYLE).parse(String) może zwrócić wartość ParseException nawet podczas analizowania prawidłowego tekstu waluty. Aby uniknąć tego problemu, użyj wartości NumberFormat.parseCurrency, która jest dostępna od Androida 7.0 (poziom interfejsu API 24) w przypadku tekstu waluty w formacie PLURALCURRENCYSTYLE.

Zmiany w Android Test

Android 9 wprowadza kilka zmian w bibliotece i strukturze klas Android Test framework. Te zmiany pomagają deweloperom korzystać z publicznych interfejsów API obsługiwanych przez framework, ale zapewniają też większą elastyczność w tworzeniu i uruchamianiu testów za pomocą bibliotek innych firm lub logiki niestandardowej.

Biblioteki usunięte z ramy

Android 9.0 reorganizuje klasy oparte na JUnit w 3 biblioteki: android.test.base, android.test.runner i android.test.mock. Ta zmiana umożliwia uruchamianie testów w wersji JUnit, która najlepiej współpracuje z zależnościami projektu. Ta wersja JUnit może być inna niż ta, którą udostępnia android.jar.

Więcej informacji o tym, jak klasy oparte na JUnit są zorganizowane w tych bibliotekach, oraz jak przygotować projekt aplikacji do pisania i uruchamiania testów, znajdziesz w artykule Konfigurowanie projektu na potrzeby testów Android Test.

Zmiany w kompilacji zestawu testów

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 są ukrytymi interfejsami API, co powodowało nieprawidłowość interfejsu API.

Dekoder UTF w Javie

UTF-8 to domyślny zestaw znaków na Androidzie. Sekwencja bajtów UTF-8 może zostać zdekodowana przez konstruktor String, np. String(byte[] bytes).

Dekoder UTF-8 w Androidzie 9 stosuje standardy Unicode w bardziej rygorystyczny sposób niż w poprzednich wersjach. Zmiany obejmują:

  • Nienajkrótsza forma UTF-8, np. <C0, AF>, jest traktowana jako nieprawidłowa.
  • Postać zastępcza UTF-8, np. U+D800..U+DFFF, jest traktowana jako źle sformułowana.
  • Maksymalna podczęść jest zastępowana pojedynczym U+FFFD. Na przykład w sekwencji bajtów „41 C0 AF 41 F4 80 80 41” maksymalne podciągi to „C0”, „AF” i „F4 80 80”. „F4 80 80” może być początkowym podciągiem ciągu „F4 80 80 80”, ale „C0” nie może być początkowym podciągiem żadnej poprawnej sekwencji jednostek kodu. 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 metody JNI NewStringUTF().

Weryfikacja nazwy hosta za pomocą certyfikatu

RFC 2818 opisuje 2 metody dopasowywania nazwy domeny do certyfikatu: za pomocą dostępnych nazw w rozszerzeniu subjectAltName (SAN) lub, w przypadku braku rozszerzenia SAN, z użyciem rozszerzenia commonName (CN).

Jednak w standardzie RFC 2818 wycofano obsługę CN. Z tego powodu Android nie używa już CN. Aby zweryfikować nazwę hosta, serwer musi przedstawić certyfikat z odpowiednim SAN. Certyfikaty, które nie zawierają SAN pasującego do nazwy hosta, nie są już zaufane.

Wyszukiwanie adresów sieciowych może powodować naruszenia zasad sieciowych

Wyszukiwania adresów sieciowych, które wymagają rozpoznawania nazw, mogą wiązać się z wejściem/wyjściem sieciowym i zatem są uważane za operacje blokujące. Blokowanie operacji w wątku głównym może powodować przerwy lub zakłócenia.

Klasa StrictMode to narzędzie programistyczne, które pomaga deweloperom wykrywać problemy w kodzie.

W Androidzie 9 i nowszych StrictMode wykrywa naruszenia sieci spowodowane wyszukiwaniem adresów sieci, które wymagają rozpoznawania nazw.

Nie należy udostępniać aplikacji z włączoną funkcją StrictMode. Jeśli tak, Twoje aplikacje mogą napotkać wyjątki, takie jak NetworkOnMainThreadException, gdy używasz metod detectNetwork() lub detectAll(), aby uzyskać zasady, które wykrywają naruszenia zasad sieci.

Rozwiązywanie numerycznego adresu IP nie jest uważane za blokowanie. Rozpoznawanie adresów IP w postaci liczbowej działa tak samo jak w wersjach Androida wcześniejszych niż 9.

Tagowanie gniazd

W wersjach platformy starszych niż Android 9, jeśli gniazdo jest otagowane za pomocą metody setThreadStatsTag(), gniazdo jest odtagowane, gdy jest wysyłane do innego procesu za pomocą bindera IPC z kontenerem ParcelFileDescriptor.

W Androidzie 9 i nowszych tag gniazda jest zachowany, gdy jest wysyłany do innego procesu za pomocą binder IPC. Ta zmiana może mieć wpływ na statystyki ruchu sieciowego, na przykład w przypadku korzystania z metody queryDetailsForUidTag().

Jeśli chcesz zachować działanie poprzednich wersji, które odznacza gniazdo wysłane do innego procesu, możesz wywołać funkcję untagSocket() przed wysłaniem gniazda.

Zgłaszana liczba dostępnych bajtów w gniezdziu

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

bardziej szczegółowe raporty o możliwościach sieciowych VPN,

W Androidzie 8.1 (poziom interfejsu API 27) i starszych klasa NetworkCapabilities przekazywała tylko ograniczony zestaw informacji o sieciach VPN, takich jak TRANSPORT_VPN, ale pomijając NET_CAPABILITY_NOT_VPN. Z powodu tych ograniczonych informacji trudno było ustalić, czy korzystanie z VPN spowoduje obciążenie użytkownika aplikacji. Na przykład sprawdzenie parametru NET_CAPABILITY_NOT_METERED nie pozwoli określić, czy sieci podstawowe były objęte naliczaniem.

W Androidzie 9 i nowszych, gdy VPN wywołuje metodę setUnderlyingNetworks(), system Android łączy transporty i możliwości wszystkich sieci podrzędnych, a następnie zwraca wynik jako skuteczne możliwości sieci VPN.

W Androidzie 9 i nowszych aplikacje, które już sprawdzają dostępność NET_CAPABILITY_NOT_METERED, otrzymują możliwości sieci VPN i sieci podrzędnych.

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 odczytu plików w folderze /proc/net/xt_qtaguid. Dzieje się tak, aby zapewnić spójność z niektórymi urządzeniami, na których te pliki wcale nie występują.

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

Wymagany jest teraz flaga FLAG_ACTIVITY_NEW_TASK

W Androidzie 9 nie możesz uruchomić aktywności z kontekstu poza aktywnością, chyba że przekażesz flagę intencji FLAG_ACTIVITY_NEW_TASK. Jeśli spróbujesz uruchomić aktywność bez przekazania tej flagi, aktywność nie rozpocznie się, a system wypisze komunikat do dziennika.

Zmiany w obrocie ekranu

Począwszy od Androida 9 wprowadzono istotne zmiany w trybie portretowym. W Androidzie 8.0 (poziom interfejsu API 26) użytkownicy mogli przełączać się między trybami automatycznego obracania i portretowego za pomocą kafelka Szybkie ustawienia lub ustawień wyświetlacza. Tryb pionowy został przemianowany na blokadę orientacji i jest aktywny, gdy autoobracanie jest wyłączone. Nie wprowadziliśmy żadnych zmian w trybie autoobracania.

Gdy urządzenie jest w trybie blokady orientacji, użytkownicy mogą zablokować ekran na dowolną orientację obsługiwaną przez widoczną na górze aktywność. Aktywność nie powinna zakładać, że zawsze będzie renderowana w orientacji pionowej. Jeśli główna aktywność może być renderowana w różnych orientacjach w trybie automatycznego obracania, te same opcje powinny być dostępne w trybie zablokowanego obracania, z niektórymi wyjątkami związanymi z ustawieniem 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 w Androidzie 8.0.

Ustawienie orientacji ekranu można określić na poziomie aktywności w pliku AndroidManifest lub programowo za pomocą metody setRequestedOrientation().

Tryb blokady orientacji działa poprzez ustawienie preferencji użytkownika, których WindowManager używa do obsługi orientacji aktywności. Ustawienie rotacji użytkowników może zostać zmienione w tych przypadkach: Pamiętaj, że istnieje tendencja do powrotu do naturalnego ustawienia orientacji urządzenia, która jest zwykle pionowa w przypadku urządzeń o formacie telefonu:

  • Gdy użytkownik zaakceptuje propozycję rotacji, ustawienie rotacji zmieni się na tę propozycję.
  • Gdy użytkownik przełączy się na aplikację w orientacji pionowej (w tym na ekranie blokady lub w wyszukiwarce), ustawienie orientacji zmieni się na pionową.

W tabeli poniżej omówiono zachowanie funkcji obracania w przypadku typowych orientacji ekranu:

Orientacja ekranu Działanie
nieokreślony, użytkownik W trybie automatycznego obracania i blokady obracania Aktywność może być wyświetlana w orientacji pionowej lub poziomej (i na odwrót). Obsługują one układy w orientacji pionowej i poziomej.
userLandscape W trybie automatycznego obracania i blokady obracania aktywność może być renderowana w układzie poziomym lub odwróconym poziomym. Obsługa tylko układów poziomych.
userPortrait W trybie automatycznego obracania i blokady obracania aktywność może być renderowana w układach pionowym i odwróconym pionowym. Obsługa tylko układów pionowych.
fullUser W trybie automatycznego obracania i blokady obracania Aktywność może być wyświetlana w orientacji pionowej lub poziomej (i na odwrót). Obsługuj formaty pionowy i poziomy.

Użytkownicy będą mogli zablokować obrót w orientacji pionowej, często o 180°.
sensor, fullSensor, sensorPortrait, sensorLandscape Ustawienie trybu blokady orientacji jest ignorowane i traktowane tak, jakby było aktywne automatyczne obracanie. Używaj tej funkcji tylko w wyjątkowych okolicznościach i z dużą dbałością o UX.

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

W Androidzie 6.0 wyłączyliśmy obsługę klienta HTTP Apache. Ta zmiana nie ma wpływu na większość aplikacji, które nie są kierowane na Androida w wersji 9 lub nowszej. Zmiana może jednak wpłynąć na niektóre aplikacje, które korzystają z niestandardowej struktury ClassLoader, nawet jeśli nie są kierowane na Androida 9 lub nowszego.

Aplikacja może być dotknięta, jeśli używa niestandardowego ClassLoader, który wyraźnie deleguje systemowi ClassLoader. Aby znaleźć zajęcia w org.apache.http.*, te aplikacje muszą zamiast tego przekazać uprawnienia aplikacji ClassLoader. Jeśli delegują je do systemu ClassLoader, aplikacje nie będą działać na Androidzie 9 lub nowszym z błędem NoClassDefFoundError, ponieważ te klasy nie są już znane systemowi ClassLoader. Aby uniknąć podobnych problemów w przyszłości, aplikacje powinny ogólnie wczytywać klasy za pomocą aplikacji ClassLoader, a nie uzyskiwać dostępu do systemu ClassLoaderbezpośrednio.

Wyliczanie kamer

Aplikacje działające na urządzeniach z Androidem 9 mogą wykrywać wszystkie dostępne kamery, wywołując funkcję getCameraIdList(). Aplikacja nie powinna zakładać, że urządzenie ma tylko 1 tylny aparat lub tylko 1 przedni aparat.

Jeśli np. Twoja aplikacja ma przycisk do przełączania się między przednim a tylnym aparatem, może mieć więcej niż 1 przedni lub tylny aparat do wyboru. Przejrzyj listę kamer, sprawdź ich właściwości i zdecyduj, które z nich mają być widoczne dla użytkownika.