Zmiany w działaniu: wszystkie aplikacje

Android 10 obejmuje zmiany w działaniu, które mogą mieć wpływ na Twoją aplikację. Zmiany wymienione na tej stronie dotyczą Twojej aplikacji, gdy jest ona uruchomiona na Androidzie 10, niezależnie od uprawnienia targetSdkVersion aplikacji. Przetestuj w aplikacji i w razie potrzeby zmodyfikuje ją, aby obsługiwać te zmiany.

Jeśli wartość targetSdkVersion aplikacji to 29 lub nowsza, musisz też wykonać pozwalają na wprowadzanie dodatkowych zmian. Szczegółowe informacje znajdziesz w zmianach zachowania aplikacji kierowanych na 29.

Ograniczenia interfejsu spoza SDK

Aby zapewnić stabilność i zgodność aplikacji, platforma zaczęła ograniczać które interfejsy inne niż SDK aplikacja może być używana w Androidzie 9 (poziom API 28). Android 10 zawiera zaktualizowane listy ograniczonych interfejsów spoza SDK na podstawie współpracy z deweloperami aplikacji na Androida oraz najnowsze testy wewnętrzne. Zależy nam na tym, przed ograniczeniem korzystania z interfejsów innych niż SDK.

Jeśli nie będziesz kierować swoich aplikacji na Androida 10 (poziom interfejsu API 29), niektóre z tych zmian mogą nie być od razu widoczne. Mimo że obecnie możesz korzystać z wybranych interfejsy inne niż SDK (w zależności od docelowego poziomu interfejsu API aplikacji), Korzystanie z dowolnej metody lub pola niezwiązanego z pakietem SDK zawsze wiąże się z dużym ryzykiem naruszenia .

Jeśli nie wiesz, czy Twoja aplikacja korzysta z interfejsów innych niż SDK, przetestuj swoją aplikację, dowiedzieć się więcej. Jeśli Twoja aplikacja korzysta z interfejsów innych niż SDK, należy zaplanować migracji do alternatywnych pakietów SDK. Rozumiemy jednak, że niektóre aplikacje z prawidłowych zastosowań interfejsów innych niż SDK. Jeśli nie możesz znaleźć innej do korzystania z interfejsu poza pakietem SDK, musisz żądanie nowego publicznego interfejsu API.

Więcej informacji znajdziesz w artykule Aktualizacje ograniczeń interfejsu spoza SDK w Androidzie 10. oraz zapoznaj się z ograniczeniami dotyczącymi interfejsów innych niż SDK.

Nawigacja przy użyciu gestów

Począwszy od Androida 10 użytkownicy mogą włączać nawigację przy użyciu gestów urządzenia. Jeśli użytkownik włączy nawigację przy użyciu gestów, będzie to miało wpływ na wszystkie aplikacje na bez względu na to, czy aplikacja jest kierowana na interfejs API na poziomie 29. Jeśli na przykład użytkownik przesunie palcem po ekranie od krawędzi ekranu, system zinterpretuje ten gest jako Wstecz nawigacji, chyba że aplikacja zastępuje ten gest w przypadku fragmentów na ekranie.

Aby zapewnić zgodność aplikacji z nawigacją przy użyciu gestów, aplikacji, od krawędzi do krawędzi, a także odpowiednio reaguj na sprzeczne gesty. Więcej informacji znajdziesz w dokumentacji dotyczącej nawigacji za pomocą gestów.

NDK

Android 10 zawiera następujące zmiany NDK.

Obiekty udostępnione nie mogą zawierać relokacji tekstu

Android 6.0 (poziom interfejsu API 23) nie zezwala na przenoszenie tekstu w wspólnych obiektach. Kod musi być ładowany w takiej postaci, w jakiej jest, i nie może zostać zmodyfikowane. Ta zmiana wydłuży czas wczytywania aplikacji i zwiększy bezpieczeństwo.

SELinux wymusza to ograniczenie w aplikacjach kierowanych na Androida 10. lub wyższą. Jeśli te aplikacje nadal będą używać udostępnionych obiektów zawierających tekst przeniesione, są bardzo narażone na zniszczenie.

Zmiany w bibliotekach Bionic i ścieżkach dynamicznego łączącego

Począwszy od Androida 10 kilka ścieżek to linki symboliczne zamiast zwykłych plików. Aplikacje, które używały ścieżek jako zwykłych plików mogą nie działać prawidłowo:

• /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

Te zmiany dotyczą również 64-bitowych wersji pliku, przy czym Element lib/ został zastąpiony elementem lib64/.

Aby zapewnić zgodność, dowiązania symboliczne są podane w starych ścieżkach. Przykład: /system/lib/libc.so jest linkiem symbolicznym do: /apex/com.android.runtime/lib/bionic/libc.so No więc Aplikacja dlopen(“/system/lib/libc.so”) nadal działa, ale aplikacje gdy trzeba sprawdzić wczytane biblioteki, czytając /proc/self/maps lub podobną, co nie jest normalne, ale wygląda na to, że niektóre aplikacje robią to w ramach procesu ochrony przed hakerami. Jeśli tak, parametr /apex/… ścieżki należy dodać jako prawidłowe ścieżki do plików Bionic.

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

Począwszy od Androida 10: segmenty wykonywalnych plików binarnych systemowych a biblioteki są mapowane w pamięci tylko do wykonania (niedostępne do odczytu), co stanowi przed atakami polegającymi na ponownym wykorzystaniu kodu. Jeśli aplikacja wykonuje operacje odczytu w segmenty pamięci oznaczone jako tylko do wykonania – ze względu na błędy, luki w zabezpieczeniach celową kontrolę pamięci – system wysyła do Twojej aplikacji sygnał SIGSEGV.

Możesz określić, czy to zachowanie spowodowało wypadek, analizując powiązane tombstone w folderze /data/tombstones/. Awaria związana tylko z wykonaniem zawiera następujący komunikat o przerwie:

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

Aby obejść ten problem i przeprowadzić takie operacje jak kontrola pamięci, należy segmenty tylko do wykonania jako do odczytu i wykonywania za pomocą mprotect() Zdecydowanie zalecamy jednak powrót do a potem tylko do wykonywania, ponieważ to ustawienie uprawnień dostępu aby chronić aplikację i użytkowników.

Bezpieczeństwo

Android 10 wprowadza opisane poniżej zmiany w zabezpieczeniach.

Domyślnie włączony protokół TLS 1.3

W Androidzie 10 i nowszych protokół TLS 1.3 jest domyślnie włączony dla wszystkich Połączenia TLS. Oto kilka ważnych informacji na temat protokołu TLS 1.3 implementacja:

• Nie można dostosować zestawów szyfrów TLS 1.3. Obsługiwany mechanizm szyfrowania TLS 1.3 pakiety są zawsze włączone, gdy włączony jest protokół TLS 1.3. Każda próba wyłączenia im, dzwoniąc do nich setEnabledCipherSuites() jest ignorowany.
• Podczas negocjowania protokołu TLS 1.3 HandshakeCompletedListener są wywoływane przed dodaniem sesji do pamięci podręcznej sesji. (W TLS 1.2 i inne poprzednie wersje, obiekty te są wywoływane po dodaniu sesji do pamięci podręcznej sesji).
• W niektórych sytuacjach, gdy SSLEngine instancje zgłaszają żądanie SSLHandshakeException w dniu starszych wersji Androida, instancje te generują SSLProtocolException na urządzeniach z Androidem 10 lub nowszym.
• Tryb 0-RTT nie jest obsługiwany.

W razie potrzeby możesz uzyskać numer SSLContext z wyłączonym TLS 1.3, dzwoniąc pod numer SSLContext.getInstance("TLSv1.2") Możesz też włączać i wyłączać wersje protokołu dla poszczególnych połączeń przez dzwonię pod numer setEnabledProtocols() na odpowiednim obiekcie.

Certyfikaty podpisane przy użyciu SHA-1 nie są zaufane w TLS

Na Androidzie 10 certyfikaty korzystające z algorytmu szyfrowania SHA-1 nie są zaufane w połączeniach TLS. Główne urzędy certyfikacji nie wystawiono takiego certyfikatu od 2016 r. i nie są już zaufane w Chrome ani w innych popularnych przeglądarkach.

Próba nawiązania połączenia kończy się niepowodzeniem, jeśli nawiązano połączenie z witryną, która wyświetla za pomocą SHA-1.

Zmiany i ulepszenia dotyczące KeyChain

Niektóre przeglądarki, takie jak Google Chrome, pozwalają użytkownikom wybrać certyfikat, gdy Serwer TLS wysyła komunikat z żądaniem certyfikatu w ramach uzgadniania połączenia TLS. Stan na Android 10 Obiekty KeyChain honorują wystawców i parametry specyfikacji klucza podczas wywoływania funkcji KeyChain.choosePrivateKeyAlias() do wyświetlać użytkownikom prośbę o wybór certyfikatu. W szczególności ten prompt nie zawiera zawierają opcje, które nie są zgodne ze specyfikacją serwera.

Jeśli nie są dostępne żadne certyfikaty do wyboru przez użytkownika, tak jak w przypadku braku certyfikaty są zgodne ze specyfikacją serwera lub urządzenie nie ma żadnych certyfikatów zainstalowanych, prośba o wybór certyfikatu w ogóle się nie wyświetli.

Na Androidzie 10 ani nowszym nie musisz też blokady ekranu urządzenia na potrzeby importowania kluczy lub certyfikatów CA do obiektu KeyChain.

Inne zmiany dotyczące TLS i kryptografii

Wprowadzono kilka drobnych zmian w bibliotekach TLS i kryptografii, będą obowiązywać na urządzeniach z Androidem 10:

• Szyfry AES/GCM/NoPadding i ChaCha20/Poly1305/NoPadding zwracają dokładniejsze rozmiary buforów z getOutputSize().
• Zestaw szyfrów TLS_FALLBACK_SCSV jest pomijany przy próbach połączenia z z protokołem maksymalnego TLS w wersji 1.2 lub nowszej. Ze względu na ulepszenia serwera TLS nie zalecamy korzystania z zewnętrznej kreacji zastępczej TLS. Zamiast tego: zalecamy negocjowanie 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.
• Rozszerzenie obsługiwane_signature_algorithms w języku: CertificateRequest to respektowane przy wyborze klucza podpisywania na potrzeby odpowiedzi certyfikatu.
• 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 urządzeniu z Androidem 10 następujące komunikaty związane z Wi-Fi Bezpośrednie nie są trwałe:

• WIFI_P2P_CONNECTION_CHANGED_ACTION
• WIFI_P2P_THIS_DEVICE_CHANGED_ACTION

Jeśli aplikacja polegała na odbieraniu tych komunikatów podczas rejestracji, ponieważ: były przyklejone, użyj odpowiedniej metody get() przy inicjowaniu, aby uzyskać takie informacje.

Funkcje Wi-Fi Aware

Android 10 dodaje obsługę, aby ułatwić tworzenie gniazd TCP/UDP dzięki Wi-Fi Aware ścieżek danych. Aby utworzyć gniazdo TCP/UDP łączące się z ServerSocket, klient urządzenie 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. Na Androida 10, informacje 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.
• Podaj informacje o porcie jako część żądania sieciowego Wi-Fi Aware.

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

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

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 sieci Wi-Fi Aware, aby uzyskać adresy IPv6 port udostępniony przez serwer:

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)

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ć SYSTEM_ALERT_WINDOW uprawnienia. Dzieje się tak, ponieważ nakładane okna rysowania wykorzystują nadmierną ilość pamięci, co jest szczególnie szkodliwe dla Androida z małą ilością pamięci. urządzenia.

Jeśli aplikacja działająca na urządzeniu w wersji Go z Androidem 9 lub starszym otrzymuje SYSTEM_ALERT_WINDOW, aplikacja zachowa je, nawet jeśli urządzenie zostało zaktualizowane 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 przekierowuje użytkownika Ekran Ustawienia z informacją, że uprawnienia są niedozwolone, spowolni działanie urządzenia. Jeśli aplikacja na urządzeniu Go zadzwoni 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

Urządzenia z Androidem 10 lub nowszym ostrzegają użytkowników po raz pierwszy używają wszystkich aplikacji kierowanych 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 docelowy interfejs API Google Play , użytkownik widzi te ostrzeżenia tylko podczas uruchamiania aplikacji, która nie została zaktualizowana w ostatnim czasie. W przypadku aplikacji rozpowszechnianych w innych sklepach, podobny docelowy interfejs API które będą obowiązywać w 2019 r. Więcej informacji na ten temat zapoznaj się z artykułem Wymagania dotyczące docelowego poziomu interfejsu API 2019 r.

Usunięto zestawy szyfrów SHA-2 CBC

Usunęliśmy z platformy 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 korzystają z GCM, a większość serwerów obsługuje zarówno warianty GCM, jak i CBC i nie obsługują żadnego z nich.

Transmisja danych w aplikacjach

Android 10 wprowadza te zmiany w działaniu związane z korzystaniem z aplikacji:

• Ulepszenia korzystania z aplikacji UsageStats - Android 10 dokładnie śledzi korzystanie z aplikacji dzięki Stats o korzystaniu, gdy aplikacje są używane w trybie podzielonego ekranu lub obrazu w obrazie. Dodatkowo: Android 10 prawidłowo śledzi korzystanie z aplikacji błyskawicznych.

• Odcienie szarości dla poszczególnych aplikacji - Android 10 może ustawić tryb wyświetlania w skali szarości w przypadku poszczególnych aplikacji.

• Stan rozpraszania uwagi według aplikacji - Android 10 może wybiórczo ustawiać aplikacje w „stan rozpraszania uwagi” gdzie są one ukryte i nie wyświetlają się jako sugerowane aplikacje.

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

Zmiany w połączeniu HTTPS

Jeśli aplikacja na Androidzie 10 przekazuje null do setSSLSocketFactory() IllegalArgumentException ma miejsce. 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

W Androidzie 10 biblioteka android.preference jest wycofana. Deweloperzy powinni zamiast tego korzystać z biblioteki preferencji AndroidaX, dostępnej w ramach funkcji Jetpack. Dodatkowe materiały pomocne w migracji i zapoznaj się ze zaktualizowanymi ustawieniami, Przewodnik wraz z naszą publiczną próbką i dokumentację referencyjną.

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

Android 10 wprowadza te zmiany w klasach w java.util.zip pakiet, który obsługuje pliki ZIP. Te zmiany sprawią, że biblioteka będzie lepiej działać takie same między Androidem a innymi platformami korzystającymi z java.util.zip.

Sztuczne

W poprzednich wersjach niektóre metody klasy Inflater zwróciły błąd IllegalStateException, jeśli: zostały wywołane po wywołaniu funkcji end(). W Androidzie 10 te metody zwracają zamiast tego błąd NullPointerException.

Plik ZIP

W Androidzie 10 i nowszych konstruktor ZipFile który przyjmuje argumenty typu File, int i Charset nie zwraca ZipException, jeśli dostarczony plik ZIP nie zawiera żadnych plików.

Strumień danych wyjściowych Zip

W Androidzie 10 i nowszych parametr finish() w ZipOutputStream nie rzuca ZipException, jeśli próbuje zapisać strumienia wyjściowego dla pliku ZIP, który nie zawiera żadnych plików.

Zmiany w kamerze

Wiele aplikacji używających aparatu zakłada, że urządzenie jest w orientacji pionowej, to urządzenie jest też w orientacji pionowej, jak opisano w Orientacja aparatu. W przeszłości było to bezpieczne założenie, ale wraz z rozwojem dostępnych formatów, na przykład urządzeń składanych. Ten przy założeniu, że te urządzenia mogą prowadzić do nieprawidłowego obrócenia lub przeskalowania i wyświetlacz w wizjerze aparatu.

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

Śledzenie wykorzystania baterii

Począwszy od Androida 10: SystemHealthManager zresetowania statystyki użytkowania baterii za każdym razem, gdy urządzenie zostanie odłączone od zasilania po znacznym stopniu zdarzenia ładowania. Ogólnie rzecz biorąc, ważną kwestią związaną z ładowaniem urządzenia jest: zostało w pełni naładowane lub urządzenie stało się w większości rozładowane Naładowany.

Przed Androidem 10 statystyki użytkowania baterii są resetowane za każdym razem, gdy urządzenie bez zasilania, bez względu na to, jak mała zmiana nastąpiła w poziomie baterii.

Wycofanie Android Beam

W Androidzie 10 oficjalnie wycofujemy starszą funkcję Android Beam, inicjowanie udostępniania danych między urządzeniami za pomocą komunikacji Near Field Communication (NFC). Wycofujemy też kilka powiązanych z nimi interfejsów API NFC. Android Beam pozostaje opcjonalnie dla producentów, którzy chcą z niej korzystać, nie jest to jednak możliwe. w fazie aktywnego rozwoju. Android nadal będzie obsługiwać inne komunikację NFC funkcji i interfejsów API, a także przypadki użycia, takie jak odczyt z tagów płatności będą nadal działać zgodnie z oczekiwaniami.

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

Funkcja BigDecimal.stripTrailingZeros() nie zachowuje już zera końcowych jako specjalnego przypadku, jeśli wartość wejściowa wynosi 0.

Zmiany w działaniu java.util.regex.Matcher i wzorca

Zmieniono wynik funkcji split() tak, aby nie zaczynał się już pustym elementem String („”), jeśli na początku danych wejściowych występuje dopasowanie o zerowej szerokości. To także dotyczy String.split(). Na przykład "x".split("") zwraca teraz {"x"} a w starszych wersjach Androida zwracało ono {"", "x"}. "aardvark".split("(?=a)" zwraca teraz {"a", "ardv", "ark"} zamiast {"", "a", "ardv", "ark"}

Ulepszyliśmy też sposób działania wyjątków w przypadku nieprawidłowych argumentów:

• appendReplacement(StringBuffer, String) trafia teraz: IllegalArgumentException zamiast IndexOutOfBoundsException, jeśli zamiennik String kończy się pojedynczym ukośnikiem lewym, co jest niedozwolone. jeśli zamiennik String kończy się znakiem $, zgłaszany jest ten sam wyjątek. Wcześniej w tym scenariuszu nie było zgłaszanych wyjątków.
• replaceFirst(null) nie wywołuje już funkcji reset() na urządzeniu Matcher, jeśli wyrzuci błąd NullPointerException Wyjątek NullPointerException jest teraz również zgłaszany, gdy nie ma dopasowania. Wcześniej był on odrzucany tylko wtedy, gdy udało się dopasować grę.
• start(int group), end(int group) i group(int group) rzucają teraz więcej ogólny IndexOutOfBoundsException, jeśli indeks grupy jest poza zakresem. Wcześniej te metody zwracały żądanie ArrayIndexOutOfBoundsException.

Domyślny kąt elementu GradientDrawable to teraz TOP_BOTTOM

Jeśli w Androidzie 10 zdefiniujesz GradientDrawable w kodzie XML i nie podają pomiaru kąta, orientacji gradientu przyjmuje domyślnie wartość TOP_BOTTOM Jest to zmiana w porównaniu z poprzednimi wersjami Androida, w których domyślnie była ustawiana wartość LEFT_RIGHT.

Aby obejść ten problem, po zaktualizowaniu pakietu AAPT2 do najnowszej wersji Jeśli nie ma kąta, narzędzie ustawia 0 nastawy kąta w starszych aplikacjach. pomiar skuteczności.

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ę do domyślnej wartości serialVersionUID dla serializowalności . Ta poprawka nie dotyczyło aplikacji kierowanych na interfejs API na poziomie 23 lub niższym.

Od Androida 10 w przypadku aplikacji kierowanych na interfejs API na poziomie 23 lub niższym i korzysta ze starej, nieprawidłowej, domyślnej wersji serialVersionUID, dzienników systemowych pojawi się ostrzeżenie i zaproponuje 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 zserializowana.
• Klasa zserializowana używa domyślnego elementu serialVersionUID zamiast bezpośrednio ustawiając serialVersionUID.
• Domyślna wartość serialVersionUID jest inna niż serialVersionUID by aplikacja była kierowana na interfejs API na poziomie 24 lub wyższym.

To ostrzeżenie jest logowane raz dla każdej klasy, której dotyczy problem. Komunikat z ostrzeżeniem zawiera sugerowaną poprawkę, którą należy ustawić, serialVersionUID na wartość domyślną, która zostanie obliczona, kierowana aplikacja na interfejs API na poziomie 24 lub wyższym. Dzięki temu rozwiązaniu jeśli obiekt tej klasy jest zserializowany w aplikacji kierowanej na poziom interfejsu API; 23 lub niższy, obiekt będzie poprawnie odczytywany przez aplikacje kierowane na wersję 24 lub nowszą, i na odwrót.

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(). Poprzedni wersji Androida połknął błąd zwrócony przez truncate(), ale Android 10 zgłasza wyjątek IOException. Jeśli chcesz korzystać ze starego sposobu, musisz użyć kodu natywnego.