Verhaltensänderungen: alle Apps

Android 10 enthält Verhaltensänderungen, die sich auf deine App auswirken können. Die auf dieser Seite aufgeführten Änderungen gelten für Ihre App, wenn sie ausgeführt wird unter Android 10, unabhängig vom targetSdkVersion der App. Sie sollten und passen Sie sie bei Bedarf an, damit diese Änderungen korrekt unterstützt werden.

Wenn die targetSdkVersion deiner App 29 oder höher ist, musst du außerdem Folgendes tun: zusätzliche Änderungen unterstützen. Lesen Sie unbedingt den Artikel Verhaltensänderungen bei Apps Targeting 29 finden Sie weitere Informationen.

Hinweis : Zusätzlich zu den auf dieser Seite aufgeführten Änderungen kann Android 10 führt eine große Anzahl datenschutzbasierter Änderungen und Einschränkungen ein, darunter Folgendes:

  • Hintergrundzugriff auf Gerätestandort
  • Start der Hintergrundaktivität
  • Affinitätsinformationen zu Kontakten
  • Randomisierung der MAC-Adresse
  • Kamerametadaten
  • Berechtigungsmodell

Diese Änderungen betreffen alle Apps und verbessern den Datenschutz für Nutzer. Weitere Informationen über wie diese Änderungen umgesetzt werden können, Seite Änderungen beim Datenschutz.

Einschränkungen für Nicht-SDK-Schnittstellen

Um die Stabilität und Kompatibilität von Apps zu verbessern, hat die Plattform damit begonnen, einzuschränken, welche nicht zu SDKs gehörenden Schnittstellen Ihre App unter Android 9 (API-Level 28) verwenden kann. Android 10 enthält aktualisierte Listen eingeschränkter Nicht-SDK-Schnittstellen basierend auf der Zusammenarbeit mit Android-Entwicklern und die neuesten internen Tests. Unser Ziel ist es, Alternativen sind verfügbar, bevor wir Nicht-SDK-Schnittstellen einschränken.

Wenn deine App nicht auf Android 10 (API-Level 29) ausgerichtet ist, gibt es einige dieser Änderungen nicht sofort betreffen. Obwohl Sie derzeit einige Nicht-SDK-Schnittstellen (abhängig vom Ziel-API-Level Ihrer App) die Verwendung einer Nicht-SDK-Methode oder eines Nicht-SDK-Felds birgt immer ein hohes Risiko, dass Ihre

Wenn Sie nicht sicher sind, ob Ihre App Nicht-SDK-Schnittstellen verwendet, können Sie Ihre App testen, finden Sie es heraus. Wenn Ihre App Nicht-SDK-Schnittstellen benötigt, sollten Sie mit der Planung auf SDK-Alternativen umstellen. Dennoch ist uns bewusst, dass einige Apps Anwendungsfälle für die Verwendung von Nicht-SDK-Schnittstellen. Wenn Sie keine Alternative finden eine Nicht-SDK-Schnittstelle für eine Funktion in Ihrer App nutzen, Neue öffentliche API anfordern

Weitere Informationen finden Sie unter Änderungen an den Einschränkungen für Nicht-SDK-Schnittstellen in Android 10 und Einschränkungen für Nicht-SDK-Schnittstellen.

Bedienung über Gesten

Ab Android 10 können Nutzer die Bedienung über Gesten auf dem . Wenn ein Nutzer die Bedienung über Gesten aktiviert, wirkt sich dies auf alle Apps auf dem Gerät unabhängig davon, ob die App auf API-Level 29 ausgerichtet ist. Wischt die nutzende Person beispielsweise vom Bildschirmrand erfasst, interpretiert das System diese Geste als „Zurück“- Navigation, es sei denn, eine App überschreibt diese Geste ausdrücklich für Teile des auf dem Bildschirm.

Damit Ihre App mit der Bedienung über Gesten kompatibel ist, sollten Sie die und mit in Konflikt stehenden Gesten konsequent umgehen zu können. Weitere Informationen finden Sie in der Dokumentation zur Gestennavigation.

Logo: NDK

Android 10 umfasst die folgenden NDK-Änderungen.

Gemeinsam genutzte Objekte dürfen keine Textverschiebungen enthalten

Android 6.0 (API-Level 23) Unzulässige Verwendung von Textverschiebungen in gemeinsamen Objekten. Der Code muss unverändert geladen werden und darf nicht geändert werden. Durch diese Änderung werden die Ladezeiten und die Sicherheit von Apps verbessert.

SELinux erzwingt diese Einschränkung für Apps, die auf Android 10 oder höher ausgerichtet sind. Wenn diese Apps weiterhin freigegebene Objekte verwenden, die Textumordnungen enthalten, besteht ein hohes Risiko, dass sie nicht mehr funktionieren.

Änderungen an Bionic-Bibliotheken und dynamischen Verknüpfungspfaden

Ab Android 10 sind mehrere Pfade symbolische Links statt normalen Dateien. Apps, die bisher reguläre Dateien als Pfade verwendet haben könnte fehlerhaft sein:

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

Diese Änderungen gelten auch für die 64-Bit-Varianten der Datei, wobei lib/ durch lib64/ ersetzt.

Aus Kompatibilitätsgründen werden die Symlinks unter den alten Pfaden bereitgestellt. Beispielsweise ist /system/lib/libc.so ein Symlink zu /apex/com.android.runtime/lib/bionic/libc.so. Also dlopen(“/system/lib/libc.so”) funktioniert weiterhin, aber Apps finden wenn sie tatsächlich versuchen, die geladenen Bibliotheken zu untersuchen, /proc/self/maps oder ähnlich, was nicht üblich ist, aber wir haben festgestellt, einige Apps tun dies als Teil ihres Anti-Hacking-Prozesses. Wenn ja, wird der /apex/…-Pfade sollten als gültige Pfade für die Bionic-Dateien hinzugefügt werden.

Systembinärdateien/-bibliotheken, die dem Ausführungsspeicher zugeordnet sind

Ab Android 10 werden ausführbare Segmente von System-Binärdateien und die Bibliotheken werden zur Härtung in einen schreibgeschützten Methode zum Schutz vor Angriffen aus der Code-Wiederverwendung. Wenn Ihre App Lesevorgänge in Speichersegmente ausführt, die als „Nur ausführen“ gekennzeichnet sind, sendet das System ein SIGSEGV-Signal an Ihre App. Dies kann aufgrund eines Bugs, einer Sicherheitslücke oder einer beabsichtigten Speicherprüfung geschehen.

Sie können herausfinden, ob dieses Verhalten zu einem Absturz geführt hat, indem Sie die zugehörigen Tombstone-Datei in /data/tombstones/. Ein Absturz im Zusammenhang mit der Ausführung enthält die folgende Abbruchsmeldung:

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

Um dieses Problem zu umgehen und Vorgänge wie die Speicherprüfung auszuführen, können Sie Lese-/Ausführungssegmente durch Aufrufen von mprotect() als Lese-/Ausführungssegmente kennzeichnen. Wir empfehlen jedoch dringend, nur nach der Ausführung ausführen, da diese Einstellung Schutz für Ihre App und Ihre Nutzer.

Sicherheit

Android 10 umfasst die folgenden Sicherheitsänderungen.

TLS 1.3 standardmäßig aktiviert

Unter Android 10 und höher ist TLS 1.3 standardmäßig für alle TLS-Verbindungen aktiviert. Hier ein paar wichtige Details zu TLS 1.3 Implementierung:

  • Die TLS 1.3-Cipher Suites können nicht angepasst werden. Die unterstützten TLS 1.3-Chiffrengruppen sind immer aktiviert, wenn TLS 1.3 aktiviert ist. Jeder Versuch einer Deaktivierung aufrufen, indem Sie setEnabledCipherSuites() wird ignoriert.
  • Wenn TLS 1.3 verhandelt wird, werden HandshakeCompletedListener-Objekte vor dem Hinzufügen von Sitzungen zum Sitzungscache aufgerufen. In TLS 1.2 und anderen früheren Versionen werden diese Objekte nach dem Hinzufügen von Sitzungen zum Sitzungscache aufgerufen.
  • In einigen Situationen, in denen SSLEngine-Instanzen SSLHandshakeException aktiviert früheren Android-Versionen lösen diese Instanzen eine Stattdessen SSLProtocolException Android 10 und höher.
  • Der 0-RTT-Modus wird nicht unterstützt.

Bei Bedarf können Sie eine SSLContext abrufen, für die TLS 1.3 deaktiviert ist, indem Sie Folgendes aufrufen: SSLContext.getInstance("TLSv1.2") Sie können Protokollversionen auch für jede Verbindung aktivieren oder deaktivieren. setEnabledProtocols() wird angerufen auf ein geeignetes Objekt.

Mit SHA-1 signierte Zertifikate werden in TLS nicht als vertrauenswürdig eingestuft

Zertifikate unter Android 10, die den SHA-1-Hash-Algorithmus verwenden bei TLS-Verbindungen nicht vertrauenswürdig sind. Root-Zertifizierungsstellen haben kein solches Zertifikat ausgestellt und werden in Chrome und anderen gängigen Browsern nicht mehr vertraut.

Ein Verbindungsversuch schlägt fehl, wenn die Verbindung zu einer Website erfolgt, die ein mit SHA-1.

Änderungen und Verbesserungen des KeyChain-Verhaltens

In einigen Browsern wie Google Chrome können Nutzer ein Zertifikat auswählen, wenn ein TLS-Server im Rahmen eines TLS-Handshakes eine Zertifikatsanfrage sendet. Ab Android 10 werden bei KeyChain-Objekten die Aussteller und Schlüsselspezifikationsparameter berücksichtigt, wenn KeyChain.choosePrivateKeyAlias() aufgerufen wird, um Nutzern eine Aufforderung zur Zertifikatsauswahl anzuzeigen. Insbesondere geht es bei dieser Aufforderung nicht Auswahlmöglichkeiten enthalten, die nicht den Serverspezifikationen entsprechen.

Wenn keine Zertifikate verfügbar sind, die vom Nutzer ausgewählt werden können, z. B. mit der Serverspezifikation übereinstimmen oder auf einem Gerät keine Zertifikate installiert haben, wird die Aufforderung zur Zertifikatsauswahl nicht angezeigt.

Außerdem ist es auf Geräten mit Android 10 oder höher nicht erforderlich, Displaysperre, um Schlüssel oder CA-Zertifikate in ein KeyChain-Objekt zu importieren.

Weitere Änderungen bei TLS und Kryptografie

An den TLS- und Kryptografiebibliotheken wurden einige kleinere Änderungen vorgenommen, ab Android 10 wirksam werden:

  • Die Chiffren AES/GCM/NoPadding und ChaCha20/Poly1305/NoPadding geben mehr zurück korrekte Puffergrößen von getOutputSize().
  • Die TLS_FALLBACK_SCSV-Chiffrensammlung wird bei Verbindungsversuchen mit einem maximalen Protokoll von TLS 1.2 oder höher nicht berücksichtigt. Aufgrund von Verbesserungen am TLS-Server -Implementierungen, raten wir von einem externen TLS-Fallback ab. Stattdessen empfehlen wir die TLS-Versionenverhandlung.
  • ChaCha20-Poly1305 ist ein Alias für ChaCha20/Poly1305/NoPadding.
  • Hostnamen mit abschließenden Punkten werden nicht als gültige SNI-Hostnamen betrachtet.
  • Die Erweiterung „supported_signature_algorithms“ in CertificateRequest ist bei der Auswahl eines Signaturschlüssels für Zertifikatantworten berücksichtigt.
  • Undurchsichtige Signaturschlüssel wie diejenigen aus dem Android Keystore können mit RSA-PSS-Signaturen in TLS.

Wi-Fi Direct-Übertragungen

Unter Android 10: die folgenden Broadcasts in Zusammenhang mit WLAN Direkt sind nicht fixiert:

Wenn deine App diese Broadcasts bei der Registrierung bisher erhalten hat, sie fixiert waren, verwenden Sie bei der Initialisierung die entsprechende get()-Methode, stattdessen die Informationen zu erhalten.

Wi-Fi Aware-Funktionen

Android 10 unterstützt das Erstellen von TCP/UDP-Sockets mithilfe von Wi‑Fi Aware-Datenpaden. Zum Erstellen eines TCP/UDP-Sockets, der eine Verbindung zu einem ServerSocket herstellt, muss der Client muss das Gerät die IPv6-Adresse und den Port des Servers kennen. Dies hatte zuvor eine Out-of-Band-Kommunikation, z. B. BT oder Wi-Fi Aware. 2-Messaging oder In-Band-Erkennung mithilfe anderer Protokolle, wie z. B. mDNS. Mit Android 10 können diese Informationen im Rahmen der Netzwerkeinrichtung übermittelt werden.

Der Server kann eine der folgenden Aktionen ausführen:

  • Initialisieren Sie eine ServerSocket und legen Sie den zu verwendenden Port fest oder holen Sie ihn ab.
  • Geben Sie die Portinformationen als Teil der Wi-Fi Aware-Netzwerkanfrage an.

Im folgenden Codebeispiel wird gezeigt, wie Portinformationen als Teil der Netzwerkanfrage angegeben werden:

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

Der Client führt dann eine Wi‑Fi Aware-Netzwerkanfrage aus, um die vom Server bereitgestellte IPv6-Adresse und den Port abzurufen:

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 auf Go-Geräten

Apps, die auf Geräten mit Android 10 (Go-Edition) ausgeführt werden, können den SYSTEM_ALERT_WINDOW Berechtigung. Das liegt daran, dass das Zeichnen von Overlay-Fenstern zu viel Arbeitsspeicher verbraucht. was die Leistung von Android-Geräten mit wenig Arbeitsspeicher Geräte.

Wenn eine App auf einem Gerät der Go-Edition mit Android 9 oder niedriger den SYSTEM_ALERT_WINDOW hat, behält die App die Berechtigung auch dann bei, wenn das auf Android 10 aktualisiert wird. Apps, die das noch nicht Berechtigung kann nach dem Upgrade des Geräts nicht mehr gewährt werden.

Wenn eine App auf einem Go-Gerät einen Intent mit der Aktion sendet ACTION_MANAGE_OVERLAY_PERMISSION, lehnt das System die Anfrage automatisch ab und leitet den Nutzer zu einer Auf dem Bildschirm Einstellungen wird angezeigt, dass die Berechtigung nicht erlaubt ist, verlangsamt das Gerät. Wenn eine App auf einem Go-Gerät einen Anruf durchführt Settings.canDrawOverlays(), gibt die Methode immer "false" zurück. Auch diese Einschränkungen gelten nicht für Apps. die die Berechtigung SYSTEM_ALERT_WINDOW erhalten hat, bevor das Gerät auf Android 10 aktualisiert.

Warnungen für Apps, die auf ältere Android-Versionen ausgerichtet sind

Auf Geräten mit Android 10 oder höher werden Nutzer beim ersten Mal gewarnt werden alle Apps ausgeführt, die auf Android 5.1 (API-Level 22) oder niedriger ausgerichtet sind. Wenn die App vom Nutzer die Gewährung von Berechtigungen erfordert, hat er auch die Möglichkeit, die Berechtigungen der App anzupassen, bevor die App zum ersten Mal ausgeführt werden darf.

Aufgrund der Ziel-API von Google Play Anforderungen, Nutzer sehen diese Warnungen nur, wenn sie eine App ausführen, die nicht aktualisiert wurde vor Kurzem. Für Apps, die über andere App-Shops vertrieben werden, treten im Laufe des Jahres 2019 ähnliche Anforderungen an das Ziel-API-Level in Kraft. Weitere Informationen zu diesen siehe Anforderungen an die Erweiterung des Ziel-API-Levels in 2019

SHA-2-CBC-Cipher Suites entfernt

Die folgenden SHA-2-CBC-Cipher Suites wurden von der Plattform entfernt:

  • 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

Diese Cipher Suites sind weniger sicher als ähnliche Cipher Suites, die GCM verwenden. und die meisten Server unterstützen entweder die GCM- und die CBC-Variante dieser Chiffre oder keines davon unterstützen.

App-Nutzung

Mit Android 10 werden die folgenden Verhaltensänderungen im Zusammenhang mit der App-Nutzung eingeführt:

  • Verbesserungen bei der Nutzung von UsageStats App: Android 10 erfasst die App-Nutzung UsageStats, wenn Apps die im Splitscreen- oder Bild-im-Bild-Modus verwendet werden. Außerdem Unter Android 10 wird die Nutzung von Instant-Apps korrekt erfasst.

  • Graustufen pro App: Unter Android 10 kann für einzelne Apps ein Graustufenanzeigemodus festgelegt werden.

  • Ablenkungsstatus pro App: Android 10 kann Apps selektiv auf einen „Ablenkungsstatus“ setzen Wo? werden ihre Benachrichtigungen unterdrückt und nicht als vorgeschlagene Apps angezeigt.

  • Sperrung und Wiedergabe In Android 10 können gesperrte Apps keine Audioinhalte wiedergeben.

Änderungen der HTTPS-Verbindung

Wenn eine App mit Android 10 null an setSSLSocketFactory(), ein IllegalArgumentException erfolgt. In früheren Versionen hatte das Übergeben von null an setSSLSocketFactory() denselben Effekt wie das Übergeben der aktuellen Standard-Fabrik.

Die Bibliothek „android.preference“ wurde eingestellt

Die android.preference-Bibliothek wird mit Android 10 eingestellt. Entwickler sollten stattdessen die AndroidX-Einstellungsbibliothek verwenden, die Teil der Android- Jetpack Weitere Ressourcen zur Unterstützung bei der Migration und finden Sie in den aktualisierten Einstellungen Leitfaden mit unserem öffentlichen Beispiel App und die Referenzdokumentation.

Änderungen an der Dienstprogrammbibliothek für ZIP-Dateien

Mit Android 10 werden die folgenden Änderungen an Klassen im java.util.zip eingeführt -Paket, das ZIP-Dateien verarbeitet. Durch diese Änderungen wird das Verhalten der Bibliothek zwischen Android und anderen Plattformen, die java.util.zip verwenden, einheitlich sind.

Aufblasgerät

In früheren Versionen haben einige Methoden in der Klasse Inflater den Fehler ausgelöst. IllegalStateException, wenn wurden nach einem Aufruf von end() aufgerufen. In Android 10 lösen diese Methoden eine NullPointerException.

ZIP-Datei

Unter Android 10 und höher hat der Konstruktor für ZipFile nimmt Argumente vom Typ File, int und Charset an. ZipException, wenn die bereitgestellte ZIP-Datei enthält keine Dateien.

ZipOutputStream

Unter Android 10 und höher Methode finish() in ZipOutputStream wirft kein ZipException, wenn versucht wird, Ausgabestream für eine ZIP-Datei, die keine Dateien enthält.

Kameraänderungen

Viele Kamera-Apps gehen davon aus, dass bei Geräten im Hochformat befindet sich das physische Gerät ebenfalls im Hochformat, wie in den Kameraausrichtung. Früher war das eine sichere Annahme, durch die Erweiterung verfügbarer Formfaktoren wie faltbare Smartphones verändert. Das auf diesen Geräten zu einer falschen Drehung oder Skalierung führen (oder Kamerasucher angezeigt wird.

Für Apps, die auf API-Level 24 oder höher ausgerichtet sind, muss Folgendes explizit festgelegt werden: android:resizeableActivity und stellen die erforderlichen Funktionen bereit, mit dem Mehrfenstermodus.

Tracking der Akkunutzung

Ab Android 10 SystemHealthManager wurde zurückgesetzt seine Akkunutzungsstatistiken, wenn das Gerät nach einer größeren Ladeereignis. Im Großen und Ganzen ist ein wichtiges Ladeereignis entweder: Das Gerät vollständig aufgeladen ist oder das Gerät vollständig erschöpft ist, geladen wurde.

Vor Android 10 wurden die Statistiken zur Akkunutzung jedes Mal zurückgesetzt, wenn das Gerät egal wie wenig sich der Batteriestand verändert hatte.

Einstellung von Android Beam

In Android 10 stellen wir Android Beam offiziell ein, eine ältere Funktion für Initiieren der geräteübergreifenden Datenfreigabe über Nahfeldkommunikation (NFC) Außerdem werden mehrere zugehörige NFC APIs eingestellt. Android Beam bleibt Geräteherstellern-Partnern zur Verfügung, die die App nutzen möchten. in der Entwicklung aktiv ist. Android unterstützt jedoch weiterhin andere NFC-Funktionen und ‑APIs. Anwendungsfälle wie das Lesen von Tags und Zahlungen funktionieren weiterhin wie erwartet.

java.math.BigDecimal.stripTrailingZeros() Verhaltensänderung

In BigDecimal.stripTrailingZeros() werden nachgestellte Nullen nicht mehr als Sonderfall, wenn der Eingabewert Null ist.

Verhaltensänderungen bei java.util.regex.Matcher und Muster

Das Ergebnis von split() wurde geändert, sodass es nicht mehr mit einem leeren String beginnt („“), wenn am Anfang der Eingabe eine Übereinstimmung mit Null Breite vorliegt. Dies gilt auch für betrifft String.split(). Beispiel: "x".split("") gibt jetzt {"x"} zurück. Bei älteren Android-Versionen wurde hingegen {"", "x"} zurückgegeben. "aardvark".split("(?=a)" gibt jetzt {"a", "ardv", "ark"} statt {"", "a", "ardv", "ark"}

Das Ausnahmeverhalten für ungültige Argumente wurde ebenfalls verbessert:

  • appendReplacement(StringBuffer, String) gibt jetzt IllegalArgumentException anstelle von IndexOutOfBoundsException zurück, wenn der Ersatz String mit einem einzelnen umgekehrten Schrägstrich endet, was unzulässig ist. Die dieselbe Ausnahme wird jetzt ausgelöst, wenn der Ersatz-String mit einem $ endet. Zuvor wurde in diesem Szenario keine Ausnahme ausgelöst.
  • replaceFirst(null) ruft reset() nicht mehr für Matcher auf, wenn der Fehler NullPointerException. NullPointerException wird jetzt auch ausgelöst, wenn es ist keine Übereinstimmung. Zuvor wurde er nur bei einem Spiel geworfen.
  • start(int group), end(int group) und group(int group) werfen jetzt eine weitere Benachrichtigung aus IndexOutOfBoundsException allgemein, wenn der Gruppenindex außerhalb des gültigen Bereichs liegt. Bisher haben diese Methoden ArrayIndexOutOfBoundsException ausgelöst.

Der Standardwinkel für GradientDrawable ist jetzt TOP_BOTTOM.

Wenn Sie in Android 10 eine GradientDrawable in XML und stellen keine Winkelmessung, die Farbverlaufsausrichtung standardmäßig auf TOP_BOTTOM Dies ist eine Änderung im Vergleich zu früheren Android-Versionen, in denen die Standardversion LEFT_RIGHT

Du kannst das Problem umgehen, indem du ein Update auf die neueste Version von AAPT2 durchführst: Das Tool legt für ältere Apps eine Winkelmessung von 0 fest, wenn kein Winkel vorhanden ist. Messung angegeben.

Logging für serialisierte Objekte mit der Standard-SUID

Ab Android 7.0 (API-Level 24) hat die Plattform eine Fehlerbehebung auf die Standardeinstellung serialVersionUID für serialisierbare -Objekt. Diese Korrektur Apps, die auf API-Level 23 oder niedriger ausgerichtet sind, waren davon nicht betroffen.

Ab Android 10, wenn eine App auf API-Level 23 oder niedriger ausgerichtet ist und stützt sich auf die alten, falschen Standard-serialVersionUID, die Systemprotokolle und schlägt eine Korrektur des Codes vor.

Insbesondere protokolliert das System eine Warnung, wenn alle der folgenden Bedingungen erfüllt sind:

  • Die App ist auf API-Level 23 oder niedriger ausgerichtet.
  • Eine Klasse ist serialisiert.
  • Die serialisierte Klasse verwendet die Standard-serialVersionUID anstelle von explizit ein serialVersionUID festgelegt wird.
  • Der Standardwert für serialVersionUID unterscheidet sich vom serialVersionUID wenn die App auf API-Level 24 oder höher ausgerichtet ist.

Diese Warnung wird für jeden betroffenen Kurs einmal protokolliert. Die Warnmeldung enthält eine vorgeschlagene Korrektur, die explizit festgelegt wird, den serialVersionUID auf den Standardwert, der berechnet wird, wenn App-Level 24 oder höher, auf das die App ausgerichtet ist. Mit dieser Korrektur können Sie sicherstellen, Ein Objekt aus dieser Klasse wird in einer App serialisiert, die auf das API-Level ausgerichtet ist. 23 oder niedriger wird das Objekt von Apps, die auf Version 24 oder höher ausgerichtet sind, korrekt gelesen. und umgekehrt.

Änderungen an java.io.FileChannel.map()

Ab Android 10 wird FileChannel.map() nicht mehr unterstützt für Nicht-Standarddateien wie /dev/zero, deren Größe nicht mit truncate() Zurück von Android-Versionen verschluckt den Fehler, der von truncate(), aber Android 10 löst eine IOException aus. Wenn Sie das alte Verhalten benötigen, müssen Sie nativen Code verwenden.