Zmiany w działaniu: wszystkie aplikacje

Android 10 zawiera zmiany zachowania, które mogą mieć wpływ na Twoją aplikację. Zmiany wymienione na tej stronie mają zastosowanie do aplikacji, gdy jest ona uruchamiana na Androidzie 10, niezależnie od jej targetSdkVersion. Należy przetestować aplikację i w razie potrzeby odpowiednio ją zmodyfikować, aby uwzględnić te zmiany.

Jeśli wartość targetSdkVersion Twojej aplikacji wynosi 29 lub jest wyższa, musisz też uwzględnić dodatkowe zmiany. Szczegółowe informacje znajdziesz w zmianach zachowania aplikacji kierowanych na 29 lat.

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

  • Dostęp do lokalizacji urządzenia w tle
  • Rozpoczęcie aktywności w tle
  • informacje o związkach kontaktów,
  • losowanie adresów MAC.
  • Metadane aparatu
  • Model uprawnień

Te zmiany dotyczą wszystkich aplikacji i zwiększają prywatność użytkowników. Więcej informacji o tym, jak wspierać te zmiany, znajdziesz na stronie Zmiany dotyczące prywatności.

Ograniczenia interfejsu innego niż SDK

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

Jeśli nie będziesz kierować 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 pakietu SDK (w zależności od docelowego poziomu interfejsu API aplikacji), ale korzystanie z metod lub pól spoza pakietu 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 ją przetestować, aby się tego dowiedzieć. Jeśli Twoja aplikacja korzysta z interfejsów spoza pakietu SDK, zaplanuj migrację na alternatywy dla pakietu SDK. Zdajemy sobie jednak sprawę, że w niektórych przypadkach interfejsy inne niż SDK mogą być przydatne. Jeśli nie możesz znaleźć alternatywy dla interfejsu spoza pakietu SDK, który jest używany w funkcji Twojej aplikacji, poproś o nowy publiczny interfejs API.

Więcej informacji znajdziesz w artykule Aktualizacje ograniczeń interfejsów innych niż SDK w Androidzie 10 oraz Ograniczenia interfejsów innych niż SDK.

Nawigacja przy użyciu gestów

Począwszy od Androida 10 użytkownicy mogą włączyć nawigację za pomocą gestów na całym urządzeniu. Jeśli użytkownik włączy nawigację za pomocą gestów, wpłynie to na wszystkie aplikacje na urządzeniu, niezależnie od tego, czy aplikacja jest kierowana 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 wyraźnie zastąpi ten gest na niektórych częściach ekranu.

Aby aplikacja była zgodna z nawigacją za pomocą gestów, rozciągnij zawartość aplikacji od krawędzi do krawędzi i odpowiednio obsłuż sprzeczne gesty. Więcej informacji znajdziesz w dokumentacji dotyczącej nawigacji za pomocą gestów.

NDK

Android 10 zawiera te zmiany w NDK:

Udostępnione obiekty nie mogą zawierać przemieszczeń tekstu.

W Androidzie 6.0 (poziom interfejsu API 23) niedozwolone jest przenoszenie tekstu w wspólnych obiektach. Kod musi być wczytywany w postaci oryginalnej i nie może być modyfikowany. Ta zmiana poprawia czas wczytywania aplikacji i jej bezpieczeństwo.

SELinux egzekwuje to ograniczenie w przypadku aplikacji kierowanych na Androida 10 lub nowszego. Jeśli te aplikacje nadal będą używać udostępnionych obiektów zawierających przeniesienia tekstu, istnieje duże ryzyko, że ulegną one uszkodzeniu.

Zmiany w bibliotekach Bionic i ścieżkach dynamicznego linkera

Począwszy od Androida 10 kilka ścieżek to linki symboliczne zamiast zwykłych plików. 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ą również wersji 64-bitowych pliku, w których lib/ zostało zastąpione przez lib64/.

Ze względu na zgodność symboliczne linki są udostępniane na starych ścieżkach. Na przykład: /system/lib/libc.so to skrót do pliku /apex/com.android.runtime/lib/bionic/libc.so. Biblioteka dlopen(“/system/lib/libc.so”) nadal działa, ale aplikacje zauważą różnicę, gdy spróbują zbadać załadowane biblioteki, odczytując /proc/self/maps lub coś podobnego. Nie jest to typowe, ale okazało się, że niektóre aplikacje robią to w ramach procesu zapobiegania włamaniom. Jeśli tak, ścieżki /apex/… należy dodać jako prawidłowe ścieżki dla plików Bionic.

pliki binarne/biblioteki systemowe zmapowane na pamięć tylko do wykonywania,

Od Androida 10 wykonalne segmenty binarnych plików systemowych i bibliotek są mapowane w pamięci tylko do wykonania (nie do odczytu) jako technika wzmacniania zabezpieczeń przed atakami polegającymi na ponownym użyciu kodu. Jeśli Twoja aplikacja wykonuje operacje odczytu w segmentach pamięci oznaczonych jako „tylko do wykonania” (z powodu błędu, luki w zabezpieczeniach lub celowego sprawdzenia pamięci), system wysyła do niej sygnał SIGSEGV.

Aby sprawdzić, czy to zachowanie spowodowało awarię, możesz przejrzeć powiązany plik tombstone w katalogu /data/tombstones/. Awaria związana z tylko wykonywaniem zawiera następujący komunikat o przerwaniu:

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

Aby obejść ten problem i wykonać operacje, takie jak inspekcja pamięci, możesz oznaczyć segmenty tylko do wykonania jako odczyt + wykonanie, wywołując funkcję mprotect(). Zalecamy jednak, aby później zmienić to ustawienie z powrotem na „Tylko wykonywanie”, ponieważ to ustawienie uprawnień dostępu zapewnia lepszą ochronę aplikacji i użytkowników.

Bezpieczeństwo

Android 10 zawiera te zmiany dotyczące zabezpieczeń:

TLS 1.3 jest domyślnie włączony

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

  • Zestawy szyfrów TLS 1.3 nie mogą być dostosowywane. Obsługiwane zestawy szyfrów TLS 1.3 są zawsze włączone, gdy włączony jest TLS 1.3. Wszelkie próby wyłączenia ich przez wywołanie funkcji setEnabledCipherSuites() zostaną zignorowane.
  • Podczas negocjowania TLS 1.3 obiekty HandshakeCompletedListener są wywoływane przed dodaniem sesji do pamięci podręcznej sesji. (w TLS 1.2 i w innych poprzednich wersjach te obiekty są wywoływane po dodaniu sesji do pamięci podręcznej sesji).
  • W niektórych przypadkach, gdy instancje SSLEngine w poprzednich wersjach Androida wywołują błąd SSLHandshakeException, w Androidzie 10 i nowszych wywołują one błąd SSLProtocolException.
  • Tryb 0-RTT nie jest obsługiwany.

Jeśli chcesz, możesz uzyskać SSLContext z wyłączonym protokołem TLS 1.3, wykonując wywołanie SSLContext.getInstance("TLSv1.2"). Wersje protokołów możesz też włączać i wyłączać w poszczególnych połączeniach, wywołując setEnabledProtocols() w odpowiednim obiekcie.

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

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

Każda próba połączenia kończy się niepowodzeniem, jeśli połączenie jest z witryną, która przedstawia certyfikat z wykorzystaniem SHA-1.

Zmiany i ulepszenia dotyczące działania KeyChain

Niektóre przeglądarki, takie jak Google Chrome, umożliwiają użytkownikom wybranie certyfikatu, gdy serwer TLS wysyła wiadomość z prośbą o certyfikat w ramach uzgadniania połączenia TLS. Od Androida 10 obiekty KeyChain uwzględniają parametry specyfikacji wydawców i kluczy podczas wywoływania KeyChain.choosePrivateKeyAlias(), aby wyświetlić użytkownikom prośbę o wybranie certyfikatu. W szczególności nie zawiera on opcji, które nie są zgodne ze specyfikacją serwera.

Jeśli nie ma certyfikatów, które użytkownik może wybrać (np. gdy żaden z nich nie pasuje do specyfikacji serwera lub na urządzeniu nie ma zainstalowanych żadnych certyfikatów), prośba o wybór certyfikatu w ogóle się nie wyświetli.

Ponadto w Androidzie 10 lub nowszym nie trzeba blokować ekranu urządzenia, aby zaimportować klucze lub certyfikaty urzędu certyfikacji do obiektu KeyChain.

Inne zmiany dotyczące TLS i kryptografii

W bibliotekach TLS i kryptograficznych wprowadzono kilka drobnych zmian, które mają zastosowanie w Androidzie 10:

  • Szyfry AES/GCM/NoPadding i ChaCha20/Poly1305/NoPadding zwracają dokładniejsze rozmiary buforów z getOutputSize().
  • Zestaw szyfrowania TLS_FALLBACK_SCSV jest pomijany w przypadku prób połączenia z maksymalnie obsługiwanym protokołem TLS 1.2 lub nowszym. Ze względu na ulepszenia w implementacjach serwerów TLS nie zalecamy korzystania z zewnętrznego mechanizmu zastępczego TLS. Zamiast tego zalecamy korzystanie z negocjacji wersji TLS.
  • ChaCha20-Poly1305 to alias ChaCha20/Poly1305/NoPadding.
  • Nazwy hostów z kropkami na końcu nie są uznawane za prawidłowe nazwy hostów SNI.
  • Podczas wybierania klucza podpisywania odpowiedzi certyfikatu uwzględniane jest rozszerzenie supported_signature_algorithms w sekcji CertificateRequest.
  • Nieprzezroczyste klucze podpisywania, takie jak te z Keystore na Androida, można używać z podpisami RSA-PSS w TLS.

Transmisje Wi-Fi Direct

Na Androidzie 10 te transmisje dotyczące Wi-Fi Direct nie są trwałe:

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

Funkcje Wi-Fi Aware

Android 10 umożliwia tworzenie gniazda TCP/UDP za pomocą ścieżek danych Wi-Fi Aware. Aby utworzyć gniazdo TCP/UDP łączące się z ServerSocket, urządzenie klienta musi znać adres IPv6 i port serwera. Wcześniej informacje te musiały być przesyłane poza pasmem, na przykład za pomocą wiadomości warstwy 2 w technologii BT lub Wi-Fi Aware, albo wykrywane w pasmie 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:

  • Inicjuj ServerSocket i ustaw lub pobierz port do użycia.
  • Określ informacje o porcie w ramach żądania sieci Wi-Fi Aware.

Poniższy przykładowy kod pokazuje, jak podać informacje o porcie w żądaniu sieci:

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();

Następnie klient wysyła żądanie do sieci Wi-Fi Aware, aby uzyskać adres IPv6 i numer portu podane 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ą uzyskać uprawnień SYSTEM_ALERT_WINDOW. Dzieje się tak, ponieważ rysowanie okien nakładek wykorzystuje 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 Go w wersji 9 lub starszej otrzyma uprawnienie SYSTEM_ALERT_WINDOW, to uprawnienie pozostanie przypisane do aplikacji nawet po uaktualnieniu urządzenia do Androida 10. Jednak aplikacji, które nie mają tego uprawnienia, nie można go przyznać po uaktualnieniu urządzenia.

Jeśli aplikacja na urządzeniu Go wysyła intencję z działaniem ACTION_MANAGE_OVERLAY_PERMISSION, system automatycznie odrzuca żądanie i przenosi użytkownika na ekran Ustawienia, na którym informuje, że uprawnienie nie jest dozwolone, ponieważ spowalnia urządzenie. Jeśli aplikacja na urządzeniu Go wywołuje funkcję Settings.canDrawOverlays(), metoda zawsze zwraca wartość „fałsz”. Ponownie przypominamy, że 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 kierowanych na starsze wersje Androida

Użytkownicy urządzeń z Androidem 10 lub nowszym otrzymują ostrzeżenie przy pierwszym uruchomieniu aplikacji kierowanej na Androida 5.1 (poziom interfejsu API 22) lub starszego. Jeśli aplikacja wymaga od użytkownika przyznania uprawnień, użytkownik ma też możliwość dostosowania uprawnień aplikacji przed jej pierwszym uruchomieniem.

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

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

Z platformy zostały usunięte te zestawy szyfrowania CBC SHA-2:

  • 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 albo oba warianty GCM i CBC tych zestawów szyfrów, albo żaden z nich.

Transmisja danych w aplikacjach

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

  • Ulepszenia dotyczące korzystania z aplikacji UsageStats – Android 10 dokładnie śledzi korzystanie z aplikacji za pomocą UsageStats, gdy aplikacje są używane w trybie podzielonego ekranu lub obrazu w obrazie. Dodatkowo Android 10 poprawnie śledzi korzystanie z aplikacji błyskawicznych.

  • Tryb szarości dla poszczególnych aplikacji – Android 10 może ustawiać tryb wyświetlania w szarościach dla poszczególnych aplikacji.

  • Stan „rozpraszania uwagi” dla poszczególnych aplikacji – w Androidzie 10 można wybrać aplikacje, które mają mieć stan „rozpraszania uwagi”, w którym ich powiadomienia są tłumione i nie pojawiają się jako sugerowane aplikacje.

  • Zawieszenie i odtwarzanie –

Zmiany w połączeniu HTTPS

Jeśli aplikacja na Androidzie 10 przekaże null do setSSLSocketFactory(), nastąpi IllegalArgumentException. W poprzednich wersjach przekazanie argumentu null do funkcji setSSLSocketFactory() miało taki sam efekt jak przekazanie bieżącej fabrykacji domyślnej.

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ą Jetpacka Androida. Aby uzyskać dodatkowe materiały pomocne w migracji i rozwijaniu aplikacji, zapoznaj się z aktualizowanym przewodnikiem po ustawieniach, publiczną aplikacją przykładową oraz dokumentacją referencyjną.

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

Android 10 wprowadza następujące zmiany w klasach w pakiecie java.util.zip, który obsługuje pliki ZIP. Dzięki tym zmianom działanie biblioteki jest bardziej spójne na Androidzie i innych platformach, które korzystają z java.util.zip.

Inflater

We wcześniejszych wersjach niektóre metody klasy Inflater wywoływały błąd IllegalStateException, jeśli były wywoływane po wywołaniu metody end(). W Androidzie 10 te metody zwracają zamiast tego kod błędu NullPointerException.

ZipFile

W Androidzie 10 i nowszych konstruktor klasy ZipFile, który przyjmuje 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 metoda finish() w ZipOutputStream nie powoduje błęduZipException, jeśli próbuje zapisać strumień wyjściowy do 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 orientacji poziomej, to fizyczne urządzenie ma też orientację poziomą, zgodnie z opisem w sekcji Orientacja aparatu. W przeszłości było to bezpieczne założenie, ale zmieniło się to wraz z rozszerzeniem dostępnych formatów, takich jak składane urządzenia. Takie założenie może prowadzić do nieprawidłowego obracania lub skalowania (lub obu tych czynności) okna aparatu na tych urządzeniach.

Aplikacje kierowane na interfejs API na poziomie 24 lub wyższym powinny wyraźnie ustawić android:resizeableActivity i zapewnić niezbędne funkcje do obsługi działania w wielu oknach.

Śledzenie wykorzystania baterii

Począwszy od Androida 10, SystemHealthManager statystyki dotyczące zużycia baterii są resetowane, gdy urządzenie zostanie odłączone od źródła zasilania po większym zdarzeniu ładowania. Ogólnie rzecz biorąc, główne zdarzenie ładowania to: urządzenie zostało w pełni naładowane lub urządzenie przeszło z stanu prawie wyczerpanego do stanu prawie naładowanego.

Przed Androidem 10 statystyki dotyczące zużycia baterii były resetowane po odłączeniu urządzenia, niezależnie od tego, jak niewielka była zmiana poziomu naładowania baterii.

Wycofanie funkcji Android Beam

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

Zmiana zachowania metody java.math.BigDecimal.stripTrailingZeros()

Funkcja BigDecimal.stripTrailingZeros() nie zachowuje już końcowych zer jako szczególnego przypadku, jeśli podana wartość jest równa 0.

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

Zmieniliśmy wynik funkcji split() tak, aby nie zaczynała się ona pustym ciągiem znaków String („””), gdy na początku danych wejściowych występuje dopasowanie o zerowej szerokości. Dotyczy to również String.split(). Na przykład funkcja "x".split("") zwraca teraz wartość {"x"}, podczas gdy w starszych wersjach Androida zwracała wartość {"", "x"}. Funkcja "aardvark".split("(?=a)" zwraca teraz wartość {"a", "ardv", "ark"}, a nie {"", "a", "ardv", "ark"}.

Poprawiono też działanie wyjątków w przypadku nieprawidłowych argumentów:

  • Funkcja appendReplacement(StringBuffer, String) zwraca teraz błąd IllegalArgumentException zamiast IndexOutOfBoundsException, jeśli zastąpienie String kończy się pojedynczą ukośnicą wsteczną, co jest nieprawidłowe. Ten sam wyjątek jest teraz zgłaszany, jeśli zastępowana wartość String kończy się na $. Wcześniej w tym scenariuszu nie było zgłaszanych wyjątków.
  • replaceFirst(null) nie wywołuje już funkcji reset() w komponencie Matcher, jeśli rzuca wyjątek NullPointerException. NullPointerException jest teraz również zgłaszany, gdy nie ma dopasowania. Wcześniej wyjątek był zgłaszany tylko w przypadku dopasowania.
  • Funkcje 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 wywoływały błąd ArrayIndexOutOfBoundsException.

Domyślnym kątem dla GradientDrawable jest teraz TOP_BOTTOM

W Androidzie 10, jeśli zdefiniujesz element GradientDrawable w pliku XML i nie podasz pomiaru kąta, orientacja gradientu zostanie domyślnie ustawiona na TOP_BOTTOM. Jest to zmiana w porównaniu z poprzednimi wersjami Androida, w których domyślnie była ustawiana wartość LEFT_RIGHT.

Jeśli zaktualizujesz narzędzie do najnowszej wersji AAPT2, w przypadku starszych aplikacji, w których nie określono pomiaru kąta, narzędzie ustawia wartość 0.

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

Począwszy od Androida 7.0 (poziom interfejsu API 24) platforma wprowadziła poprawkę do domyślnego serialVersionUID dla obiektów możliwych do serializacji. Ta poprawka nie dotyczyła aplikacji kierowanych na poziom interfejsu API 23 lub niższego.

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

W szczególności 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.
  • Serializowana klasa używa domyślnej wartości serialVersionUID zamiast jawnie ustawiać wartość serialVersionUID.
  • Domyślna wartość serialVersionUID jest inna niż serialVersionUID, gdyby aplikacja była kierowana na poziom interfejsu API 24 lub wyższy.

To ostrzeżenie jest rejestrowane raz w przypadku każdej klasy, której dotyczy. Wiadomość ostrzegawcza zawiera sugerowane rozwiązanie, które polega na jawnym ustawieniu parametru serialVersionUID na wartość domyślną, która zostałaby obliczona, gdyby aplikacja była kierowana na poziom API 24 lub wyższy. Dzięki tej poprawce 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 on prawidłowo odczytywany przez aplikacje kierowane na interfejs API na poziomie 24 lub wyższym i odwrotnie.

Zmiany w java.io.FileChannel.map()

Od Androida 10 FileChannel.map() nie jest obsługiwany w przypadku plików niestandardowych, takich jak /dev/zero, których rozmiaru nie można zmienić za pomocą truncate(). W poprzednich wersjach Androida errno zwracany przez funkcję truncate() był ignorowany, ale Android 10 zgłasza wyjątek IOException. Jeśli potrzebujesz starszego zachowania, musisz użyć kodu natywnego.