Zmiany w działaniu: wszystkie aplikacje

Android 10 wprowadza zmiany w zachowaniu, które mogą mieć wpływ na Twoją aplikację. Zmiany wymienione na tej stronie będą miały wpływ na Twoją aplikację działającą na Androidzie 10 niezależnie od jej targetSdkVersion. Przetestuj aplikację i w razie potrzeby zmodyfikuj ją, aby prawidłowo obsługiwała te zmiany.

Jeśli targetSdkVersion Twojej aplikacji to 29 lub wyższa, musisz też wprowadzić dodatkowe zmiany. Więcej informacji znajdziesz w artykule Zmiany w działaniu aplikacji kierowanych na Androida 10 (API 29).

Uwaga: oprócz zmian wymienionych na tej stronie Android 10 wprowadza wiele zmian i ograniczeń związanych z ochroną prywatności, w tym:

  • Dostęp do lokalizacji urządzenia w tle
  • Uruchamianie aktywności w tle
  • Informacje o koligacji kontaktów
  • Randomizacja adresu MAC
  • Metadane kamery
  • Model uprawnień

Zmiany te dotyczą wszystkich aplikacji i zwiększają ochronę prywatności użytkowników. Więcej informacji o tym, jak dostosować się do tych zmian, znajdziesz na stronie Zmiany dotyczące prywatności.

Ograniczenia interfejsu innego niż SDK

Aby zapewnić stabilność i kompatybilność aplikacji, platforma zaczęła ograniczać, których interfejsów spoza SDK może używać aplikacja w Androidzie 9 (poziom API 28). Android 10 zawiera zaktualizowane listy ograniczonych interfejsów spoza SDK, które powstały na podstawie współpracy z programistami Androida i najnowszych testów wewnętrznych. Chcemy mieć pewność, że zanim ograniczymy interfejsy inne niż SDK, dostępne będą publiczne alternatywy.

Jeśli nie kierujesz aplikacji na Androida 10 (poziom interfejsu API 29), niektóre z tych zmian mogą nie mieć na Ciebie natychmiastowego wpływu. Obecnie możesz używać niektórych interfejsów spoza SDK (w zależności od docelowego poziomu interfejsu API aplikacji), ale korzystanie z dowolnej metody lub pola spoza SDK zawsze wiąże się z wysokim ryzykiem awarii aplikacji.

Jeśli nie masz pewności, czy Twoja aplikacja używa interfejsów innych niż SDK, możesz to sprawdzić, testując aplikację. Jeśli Twoja aplikacja korzysta z interfejsów spoza SDK, zacznij planować przejście na alternatywne rozwiązania SDK. Rozumiemy jednak, że w przypadku niektórych aplikacji używanie interfejsów innych niż SDK jest uzasadnione. Jeśli nie możesz znaleźć alternatywy dla używania interfejsu innego niż SDK w przypadku funkcji w aplikacji, poproś o nowy publiczny interfejs API.

Więcej informacji znajdziesz w artykule Zmiany w ograniczeniach dotyczących interfejsów innych niż SDK w Androidzie 10 oraz w sekcji Ograniczenia dotyczące interfejsów innych niż SDK.

Nawigacja przy użyciu gestów

Od Androida 10 użytkownicy mogą włączyć nawigację przy użyciu gestów na całym urządzeniu. Jeśli użytkownik włączy nawigację gestami, wpłynie to na wszystkie aplikacje na urządzeniu, niezależnie od tego, czy są one kierowane na interfejs API na poziomie 29. Jeśli na przykład użytkownik przesunie palcem od krawędzi ekranu, system zinterpretuje ten gest jako nawigację Wstecz, chyba że aplikacja specjalnie zastąpi ten gest w przypadku części ekranu.

Aby aplikacja była zgodna z nawigacją gestami, musisz rozszerzyć jej zawartość od krawędzi do krawędzi i odpowiednio obsługiwać sprzeczne gesty. Więcej informacji znajdziesz w dokumentacji nawigacji gestami.

NDK

Android 10 wprowadza te zmiany w NDK:

Obiekty udostępnione nie mogą zawierać przeniesień tekstu

Android 6.0 (poziom interfejsu API 23) uniemożliwia korzystanie z relokacji tekstu w obiektach współdzielonych. Kod musi być wczytany w takiej formie, w jakiej został podany, i nie może być modyfikowany. Ta zmiana poprawia czas wczytywania aplikacji i zwiększa bezpieczeństwo.

SELinux wymusza to ograniczenie w przypadku aplikacji kierowanych na Androida 10 lub nowszego. Jeśli te aplikacje nadal będą używać obiektów współdzielonych zawierających relokacje tekstu, będą narażone na wysokie ryzyko awarii.

Zmiany w bibliotekach Bionic i ścieżkach dynamicznego linkera

Od Androida 10 kilka ścieżek to linki symboliczne, a nie zwykłe pliki. Aplikacje, które korzystały ze ścieżek jako zwykłych plików, mogą przestać działać:

  • /system/lib/libc.so -> /apex/com.android.runtime/lib/bionic/libc.so
  • /system/lib/libm.so -> /apex/com.android.runtime/lib/bionic/libm.so
  • /system/lib/libdl.so -> /apex/com.android.runtime/lib/bionic/libdl.so
  • /system/bin/linker -> /apex/com.android.runtime/bin/linker

Zmiany te dotyczą też 64-bitowych wariantów pliku, w których znak lib/ zastąpiono znakiem lib64/.

Aby zapewnić zgodność, linki symboliczne są dostępne w starych ścieżkach. Na przykład /system/lib/libc.so to link symboliczny do /apex/com.android.runtime/lib/bionic/libc.so. Dlatego dlopen(“/system/lib/libc.so”) nadal działa, ale aplikacje zauważą różnicę, gdy spróbują sprawdzić załadowane biblioteki, odczytując /proc/self/maps lub podobne dane. Nie jest to typowe, ale zauważyliśmy, że niektóre aplikacje robią to w ramach procesu przeciwdziałania hakowaniu. W takim przypadku ścieżki /apex/… należy dodać jako prawidłowe ścieżki do plików Bionic.

Pliki binarne i biblioteki systemowe mapowane na pamięć tylko do wykonywania

Od Androida 10 segmenty wykonywalne binarnych plików systemowych i bibliotek są mapowane w pamięci tylko do wykonywania (nie do odczytu) jako technika wzmacniająca ochronę przed atakami polegającymi na ponownym wykorzystaniu kodu. Jeśli aplikacja wykonuje operacje odczytu w segmentach pamięci oznaczonych jako tylko do wykonania (z powodu błędu, luki w zabezpieczeniach lub celowego sprawdzania pamięci), system wysyła do niej sygnał SIGSEGV.

Aby sprawdzić, czy to zachowanie spowodowało awarię, przejrzyj powiązany plik zrzutu w /data/tombstones/. Awaria związana z wykonywaniem kodu zawiera ten komunikat o przerwaniu:

Cause: execute-only (no-read) memory access error; likely due to data in .text.

Aby obejść ten problem i wykonywać operacje takie jak sprawdzanie pamięci, można oznaczyć segmenty tylko do wykonania jako odczyt+wykonanie, wywołując funkcję mprotect(). Zdecydowanie zalecamy jednak przywrócenie ustawienia „Tylko wykonywanie”, ponieważ to uprawnienie dostępu zapewnia lepszą ochronę aplikacji i użytkowników.

Bezpieczeństwo

Android 10 zawiera te zmiany dotyczące bezpieczeństwa:

Protokół TLS 1.3 jest domyślnie włączony.

W Androidzie 10 i nowszych wersjach protokół TLS 1.3 jest domyślnie włączony we wszystkich połączeniach TLS. Oto kilka ważnych informacji o naszej implementacji protokołu TLS 1.3:

  • Zestawów szyfrów TLS 1.3 nie można dostosowywać. Obsługiwane zestawy szyfrów TLS 1.3 są zawsze włączone, gdy włączony jest protokół TLS 1.3. Każda próba wyłączenia ich przez wywołanie funkcji setEnabledCipherSuites() zostanie zignorowana.
  • Gdy negocjowany jest protokół TLS 1.3, obiekty HandshakeCompletedListener są wywoływane przed dodaniem sesji do pamięci podręcznej sesji. (W protokole TLS 1.2 i innych poprzednich wersjach te obiekty są nazywane po dodaniu sesji do pamięci podręcznej sesji).
  • W niektórych sytuacjach, w których instancje SSLEngine zgłaszają błąd SSLHandshakeException w starszych wersjach Androida, w Androidzie 10 i nowszych zgłaszają błąd SSLProtocolException.
  • Tryb 0-RTT nie jest obsługiwany.

Jeśli chcesz uzyskać SSLContext z wyłączonym protokołem TLS 1.3, zadzwoń pod numer SSLContext.getInstance("TLSv1.2"). Możesz też włączać i wyłączać wersje protokołu dla poszczególnych połączeń, wywołując setEnabledProtocols() na odpowiednim obiekcie.

Certyfikaty podpisane za pomocą SHA-1 nie są zaufane w TLS

W Androidzie 10 certyfikaty, które używają algorytmu szyfrowania SHA-1, nie są zaufane w połączeniach TLS. Główne urzędy certyfikacji nie wystawiają takich certyfikatów od 2016 r. Nie są one już zaufane w Chrome ani w innych głównych przeglądarkach.

Każda próba połączenia z witryną, która przedstawia certyfikat korzystający z SHA-1, zakończy się niepowodzeniem.

Zmiany i ulepszenia dotyczące działania pęku kluczy

Niektóre przeglądarki, np. Google Chrome, umożliwiają użytkownikom wybór certyfikatu, gdy serwer TLS wysyła komunikat z prośbą o certyfikat w ramach uzgadniania połączenia TLS. Od Androida 10 obiekty KeyChain uwzględniają parametry specyfikacji wystawców i kluczy podczas wywoływania funkcji KeyChain.choosePrivateKeyAlias(), aby wyświetlać użytkownikom prośbę o wybranie certyfikatu. W szczególności ten prompt nie zawiera wyborów, które nie są zgodne ze specyfikacjami serwera.

Jeśli nie ma dostępnych certyfikatów, które użytkownik może wybrać (np. gdy żaden certyfikat nie pasuje do specyfikacji serwera lub na urządzeniu nie ma zainstalowanych certyfikatów), w ogóle nie pojawia się prośba o wybranie certyfikatu.

Dodatkowo w przypadku Androida 10 lub nowszego nie trzeba mieć blokady ekranu urządzenia, aby importować klucze lub certyfikaty urzędu certyfikacji do obiektu KeyChain.

Inne zmiany dotyczące TLS i kryptografii

W bibliotekach TLS i kryptograficznych wprowadziliśmy kilka drobnych zmian, które zaczną obowiązywać w Androidzie 10:

  • Szyfry AES/GCM/NoPadding i ChaCha20/Poly1305/NoPadding zwracają bardziej dokładne rozmiary bufora z getOutputSize().
  • Mechanizm szyfrowania TLS_FALLBACK_SCSV jest pomijany w przypadku prób połączenia z maksymalnym protokołem TLS 1.2 lub nowszym. Ze względu na ulepszenia w implementacjach serwera TLS nie zalecamy próby powrotu do TLS zewnętrznego. Zamiast tego zalecamy korzystanie z negocjacji wersji TLS.
  • ChaCha20-Poly1305 to alias dla ChaCha20/Poly1305/NoPadding.
  • Nazwy hostów z kropkami na końcu nie są uznawane za prawidłowe nazwy hostów SNI.
  • Rozszerzenie supported_signature_algorithms w CertificateRequest jest uwzględniane podczas wybierania klucza podpisywania odpowiedzi certyfikatu.
  • Nieprzezroczyste klucze podpisywania, takie jak klucze z Android Keystore, mogą być używane z podpisami RSA-PSS w TLS.

Transmisje Wi-Fi Direct

W Androidzie 10 te transmisje związane z Wi-Fi Direct nie są trwałe:

Jeśli Twoja aplikacja polegała na otrzymywaniu tych transmisji podczas rejestracji, ponieważ były one trwałe, użyj odpowiedniej metody get() podczas inicjowania, aby zamiast tego uzyskać informacje.

Funkcje Wi-Fi Aware

Android 10 ułatwia tworzenie gniazd TCP/UDP za pomocą ścieżek danych Wi-Fi Aware. Aby utworzyć gniazdo TCP/UDP łączące się z ServerSocket, urządzenie klienckie musi znać adres IPv6 i port serwera. Wcześniej trzeba było przekazywać te informacje poza pasmem, np. za pomocą wiadomości warstwy 2 protokołu BT lub Wi-Fi Aware, albo wykrywać je w paśmie za pomocą innych protokołów, takich jak mDNS. W Androidzie 10 informacje te mogą być przekazywane w ramach konfiguracji sieci.

Serwer może wykonać jedną z tych czynności:

  • Zainicjuj ServerSocket i ustaw lub uzyskaj port, który ma być używany.
  • Podaj informacje o porcie w ramach żądania sieci Wi-Fi Aware.

Poniższy przykładowy kod pokazuje, jak określić informacje o porcie w ramach żądania sieciowego:

Kotlin

val ss = ServerSocket()
val ns = WifiAwareNetworkSpecifier.Builder(discoverySession, peerHandle)
  .setPskPassphrase("some-password")
  .setPort(ss.localPort)
  .build()

val myNetworkRequest = NetworkRequest.Builder()
  .addTransportType(NetworkCapabilities.TRANSPORT_WIFI_AWARE)
  .setNetworkSpecifier(ns)
  .build()

Java

ServerSocket ss = new ServerSocket();
WifiAwareNetworkSpecifier ns = new WifiAwareNetworkSpecifier
  .Builder(discoverySession, peerHandle)
  .setPskPassphrase(“some-password”)
  .setPort(ss.getLocalPort())
  .build();

NetworkRequest myNetworkRequest = new NetworkRequest.Builder()
  .addTransportType(NetworkCapabilities.TRANSPORT_WIFI_AWARE)
  .setNetworkSpecifier(ns)
  .build();

Klient wysyła następnie żądanie sieci Wi-Fi Aware, aby uzyskać adres IPv6 i port dostarczony przez serwer:

Kotlin

val callback = object : ConnectivityManager.NetworkCallback() {
  override fun onAvailable(network: Network) {
    ...
  }
  
  override fun onLinkPropertiesChanged(network: Network,
      linkProperties: LinkProperties) {
    ...
  }

  override fun onCapabilitiesChanged(network: Network,
      networkCapabilities: NetworkCapabilities) {
    ...
    val ti = networkCapabilities.transportInfo
    if (ti is WifiAwareNetworkInfo) {
       val peerAddress = ti.peerIpv6Addr
       val peerPort = ti.port
    }
  }
  override fun onLost(network: Network) {
    ...
  }
};

connMgr.requestNetwork(networkRequest, callback)

Java

callback = new ConnectivityManager.NetworkCallback() {
  @Override
  public void onAvailable(Network network) {
    ...
  }
  @Override
  public void onLinkPropertiesChanged(Network network,
      LinkProperties linkProperties) {
    ...
  }
  @Override
  public void onCapabilitiesChanged(Network network,
      NetworkCapabilities networkCapabilities) {
    ...
    TransportInfo ti = networkCapabilities.getTransportInfo();
    if (ti instanceof WifiAwareNetworkInfo) {
       WifiAwareNetworkInfo info = (WifiAwareNetworkInfo) ti;
       Inet6Address peerAddress = info.getPeerIpv6Addr();
       int peerPort = info.getPort();
    }
  }
  @Override
  public void onLost(Network network) {
    ...
  }
};

connMgr.requestNetwork(networkRequest, callback);

SYSTEM_ALERT_WINDOW na urządzeniach Go

Aplikacje działające na urządzeniach z Androidem 10 (wersja Go) nie mogą otrzymywać uprawnień SYSTEM_ALERT_WINDOW. Wynika to z faktu, że rysowanie okien nakładki zużywa zbyt dużo pamięci, co jest szczególnie szkodliwe dla wydajności urządzeń z Androidem o małej ilości pamięci.

Jeśli aplikacja działająca na urządzeniu z Androidem 9 lub starszym w wersji Go otrzyma uprawnienie SYSTEM_ALERT_WINDOW, zachowa je nawet po uaktualnieniu urządzenia do Androida 10. Jednak aplikacje, które nie mają tego uprawnienia, nie mogą go uzyskać po uaktualnieniu urządzenia.

Jeśli aplikacja na urządzeniu Go wyśle intencję z działaniem ACTION_MANAGE_OVERLAY_PERMISSION, system automatycznie odrzuci żądanie i przekieruje użytkownika na ekran Ustawienia, na którym pojawi się komunikat, że uprawnienie nie jest dozwolone, ponieważ spowalnia urządzenie. Jeśli aplikacja na urządzeniu Go wywołuje Settings.canDrawOverlays(), metoda zawsze zwraca wartość „fałsz”. Te ograniczenia nie dotyczą aplikacji, które otrzymały uprawnienie SYSTEM_ALERT_WINDOW przed uaktualnieniem urządzenia do Androida 10.

Ostrzeżenia dotyczące aplikacji przeznaczonych na starsze wersje Androida

Urządzenia z Androidem 10 lub nowszym wyświetlają ostrzeżenie, gdy użytkownik po raz pierwszy uruchamia aplikację kierowaną na Androida 5.1 (API na poziomie 22) lub starszego. Jeśli aplikacja wymaga przyznania uprawnień przez użytkownika, ma on również możliwość dostosowania uprawnień aplikacji, zanim będzie mógł ją uruchomić po raz pierwszy.

Ze względu na wymagania Google Play dotyczące docelowego interfejsu API użytkownik widzi te ostrzeżenia tylko wtedy, gdy uruchamia aplikację, która nie była ostatnio aktualizowana. W przypadku aplikacji rozpowszechnianych w innych sklepach podobne wymagania dotyczące docelowego poziomu interfejsu API wejdą w życie w 2019 r. Więcej informacji o tych wymaganiach znajdziesz w artykule Rozszerzenie wymagań dotyczących docelowego poziomu interfejsu API w 2019 r..

Usunięcie zestawów szyfrów SHA-2 CBC

Z platformy zostały usunięte te zestawy szyfrów SHA-2 CBC:

  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

Te zestawy szyfrów są mniej bezpieczne niż podobne zestawy szyfrów, które używają GCM, a większość serwerów obsługuje zarówno warianty GCM, jak i CBC tych zestawów szyfrów lub nie obsługuje żadnego z nich.

Transmisja danych w aplikacjach

Android 10 wprowadza te zmiany w zachowaniu związane z korzystaniem z aplikacji:

  • Ulepszenia dotyczące korzystania z aplikacji UsageStats – <0x0 Dodatkowo Android 10 prawidłowo śledzi korzystanie z aplikacji błyskawicznych.

  • Skala szarości dla poszczególnych aplikacji – <

  • Stan rozproszenia uwagi w przypadku poszczególnych aplikacji – <x0A> <

  • Zawieszenie i odtwarzanie – w Androidzie 10 zawieszone aplikacje nie mogą odtwarzać dźwięku.

Zmiany w połączeniu HTTPS

Jeśli aplikacja działająca na Androidzie 10 przekazuje wartość null do setSSLSocketFactory(), występuje błąd IllegalArgumentException. W poprzednich wersjach przekazanie wartości null do funkcji setSSLSocketFactory() dawało taki sam efekt jak przekazanie bieżącej domyślnej wartości fabrycznej.

Biblioteka android.preference została wycofana

Biblioteka android.preference została wycofana w Androidzie 10. Deweloperzy powinni zamiast tego używać biblioteki preferencji AndroidX, która jest częścią Androida Jetpack. Dodatkowe materiały, które pomogą Ci w migracji i tworzeniu aplikacji, znajdziesz w zaktualizowanym przewodniku po ustawieniach, a także w naszej publicznej aplikacji przykładowej i dokumentacji referencyjnej.

Zmiany w bibliotece narzędzi do obsługi plików ZIP

Android 10 wprowadza te zmiany w klasach w pakiecie java.util.zip, który obsługuje pliki ZIP. Dzięki tym zmianom biblioteka będzie działać bardziej spójnie na Androidzie i innych platformach, które korzystają z java.util.zip.

Pompka

W poprzednich wersjach niektóre metody w klasie Inflater zgłaszały wyjątek IllegalStateException, jeśli były wywoływane po wywołaniu metody end(). W Androidzie 10 te metody zamiast tego zgłaszają wyjątek NullPointerException.

ZipFile

W Androidzie 10 i nowszych wersjach konstruktor ZipFile przyjmujący argumenty typu File, int i Charset nie zgłasza wyjątku ZipException, jeśli podany plik ZIP nie zawiera żadnych plików.

ZipOutputStream

W Androidzie 10 i nowszych wersjach metoda finish() w ZipOutputStream nie zgłasza wyjątku ZipException, jeśli próbuje zapisać strumień wyjściowy dla pliku ZIP, który nie zawiera żadnych plików.

Zmiany w aparacie

Wiele aplikacji korzystających z aparatu zakłada, że jeśli urządzenie jest w konfiguracji pionowej, to fizycznie też jest w orientacji pionowej, jak opisano w sekcji Orientacja aparatu. W przeszłości było to bezpieczne założenie, ale zmieniło się ono wraz z rozwojem dostępnych formatów, takich jak urządzenia składane. To założenie w przypadku tych urządzeń może prowadzić do nieprawidłowego obracania lub skalowania (albo obu tych czynności) obrazu w wizjerze aparatu.

Aplikacje kierowane na interfejs API na poziomie 24 lub wyższym powinny jawnie ustawiać wartość android:resizeableActivity i zapewniać niezbędne funkcje do obsługi działania w wielu oknach.

Śledzenie wykorzystania baterii

Od Androida 10SystemHealthManager resetuje statystyki zużycia baterii za każdym razem, gdy urządzenie zostanie odłączone od zasilania po ważnym zdarzeniu ładowania. Ogólnie rzecz biorąc, główne zdarzenie ładowania to: urządzenie zostało w pełni naładowane lub urządzenie zostało naładowane od stanu prawie rozładowanego do stanu prawie naładowanego.

Przed Androidem 10 statystyki zużycia baterii były resetowane za każdym razem, gdy urządzenie było odłączane od zasilania, niezależnie od tego, jak niewielka była zmiana poziomu baterii.

Wycofanie Androida Beam

W Androidzie 10 oficjalnie wycofujemy Android Beam, starszą funkcję inicjowania udostępniania danych między urządzeniami za pomocą komunikacji NFC. Wycofujemy też kilka powiązanych interfejsów API NFC. Android Beam pozostaje opcjonalnie dostępny dla partnerów produkujących urządzenia, którzy chcą z niego korzystać, ale nie jest już aktywnie rozwijany. Android nadal będzie obsługiwać inne funkcje i interfejsy API NFC, a przypadki użycia, takie jak odczytywanie tagów i płatności, będą działać zgodnie z oczekiwaniami.

Zmiana działania metody java.math.BigDecimal.stripTrailingZeros()

BigDecimal.stripTrailingZeros() nie zachowuje już zer na końcu jako specjalnego przypadku, jeśli wartość wejściowa wynosi zero.

Zmiany w działaniu klas java.util.regex.Matcher i Pattern

Wynik funkcji split() został zmieniony tak, aby nie zaczynał się już od pustego ciągu String (""), gdy na początku danych wejściowych występuje dopasowanie o zerowej szerokości. Ma to też wpływ na String.split(). Na przykład "x".split("") zwraca teraz {"x"}, a w starszych wersjach Androida zwracało {"", "x"}. "aardvark".split("(?=a)" zwraca teraz wartość {"a", "ardv", "ark"} zamiast {"", "a", "ardv", "ark"}.

Ulepszyliśmy też działanie w przypadku nieprawidłowych argumentów:

  • appendReplacement(StringBuffer, String) zgłasza teraz wyjątek IllegalArgumentException zamiast IndexOutOfBoundsException, jeśli zamiennik String kończy się pojedynczym ukośnikiem odwrotnym, co jest niedozwolone. Ten sam wyjątek jest teraz zgłaszany, jeśli zamiennik String kończy się znakiem $. Wcześniej w takim przypadku nie zgłaszaliśmy wyjątku.
  • replaceFirst(null) nie wywołuje już funkcji reset() w Matcher, jeśli zwraca ona błąd NullPointerException. Wyjątek NullPointerException jest teraz zgłaszany również wtedy, gdy nie ma dopasowania. Wcześniej był on zgłaszany tylko w przypadku dopasowania.
  • start(int group), end(int group) i group(int group) zgłaszają teraz bardziej ogólny błąd IndexOutOfBoundsException, jeśli indeks grupy jest poza zakresem. Wcześniej te metody zgłaszały wyjątek ArrayIndexOutOfBoundsException.

Domyślny kąt w przypadku GradientDrawable to teraz TOP_BOTTOM

W Androidzie 10, jeśli zdefiniujesz GradientDrawable w XML-u i nie podasz pomiaru kąta, orientacja gradientu domyślnie przyjmie wartość TOP_BOTTOM. To zmiana w porównaniu z poprzednimi wersjami Androida, w których domyślnym ustawieniem było LEFT_RIGHT.

Jeśli zaktualizujesz AAPT2 do najnowszej wersji, narzędzie ustawi pomiar kąta na 0 w przypadku starszych aplikacji, jeśli nie określono pomiaru kąta.

Logowanie serializowanych obiektów przy użyciu domyślnego identyfikatora SUID

Począwszy od Androida 7.0 (poziom interfejsu API 24), platforma wprowadziła poprawkę domyślnego serialVersionUID dla obiektów serializowalnych. Ta poprawka nie miała wpływu na aplikacje kierowane na poziom API 23 lub niższy.

Począwszy od Androida 10, jeśli aplikacja jest kierowana na interfejs API na poziomie 23 lub niższym i korzysta ze starego, nieprawidłowego domyślnego ustawienia serialVersionUID, system rejestruje ostrzeżenie i sugeruje poprawkę kodu.

System rejestruje ostrzeżenie, jeśli są spełnione wszystkie te warunki:

  • Aplikacja jest kierowana na interfejs API na poziomie 23 lub niższym.
  • Klasa jest serializowana.
  • Klasa serializowana używa domyślnego typu serialVersionUID zamiast jawnie ustawiać typ serialVersionUID.
  • Domyślna wartość serialVersionUID różni się od wartości serialVersionUID w przypadku aplikacji kierowanych na interfejs API na poziomie 24 lub wyższym.

To ostrzeżenie jest rejestrowane raz dla każdej klasy, której dotyczy. Wiadomość ostrzegawcza zawiera sugerowaną poprawkę, która polega na wyraźnym ustawieniu serialVersionUID na wartość domyślną, która zostałaby obliczona, gdyby aplikacja była kierowana na poziom API 24 lub wyższy. Dzięki temu rozwiązaniu możesz mieć pewność, że jeśli obiekt z tej klasy zostanie zserializowany w aplikacji kierowanej na interfejs API na poziomie 23 lub niższym, będzie prawidłowo odczytywany przez aplikacje kierowane na interfejs API na poziomie 24 lub wyższym i odwrotnie.

Zmiany w metodzie java.io.FileChannel.map()

Od Androida 10 funkcja FileChannel.map() nie jest obsługiwana w przypadku niestandardowych plików, takich jak /dev/zero, których rozmiaru nie można zmienić za pomocą truncate(). W poprzednich wersjach Androida wartość errno zwracana przez truncate() była ignorowana, ale w Androidzie 10 zgłaszany jest wyjątek IOException. Jeśli potrzebujesz starego sposobu działania, musisz użyć kodu natywnego.