Verhaltensänderungen: alle Apps

Unter Android 10 gibt es Verhaltensänderungen, die sich auf deine App auswirken können. Die auf dieser Seite aufgeführten Änderungen gelten für deine App, wenn sie unter Android 10 ausgeführt wird, unabhängig von der targetSdkVersion der App. Sie sollten Ihre App testen und bei Bedarf ändern, um diese Änderungen korrekt zu unterstützen.

Wenn die targetSdkVersion Ihrer App 29 oder höher ist, müssen auch zusätzliche Änderungen unterstützt werden. Weitere Informationen finden Sie unter Änderungen des Verhaltens bei Apps mit Ausrichtung auf 29.

Hinweis : Zusätzlich zu den auf dieser Seite aufgeführten Änderungen bringt Android 10 zahlreiche datenschutzkonforme Änderungen und Einschränkungen mit sich, darunter:

• Hintergrundzugriff auf den Gerätestandort
• Beginn der Hintergrundaktivität
• Informationen zu gemeinsamen Interessen von Kontakten
• Zufällige Anordnung der MAC-Adresse
• Kamerametadaten
• Berechtigungsmodell

Diese Änderungen wirken sich auf alle Apps aus und verbessern den Datenschutz für Nutzer. Weitere Informationen dazu, wie du diese Änderungen unterstützen kannst, findest du auf der Seite Datenschutzänderungen.

Einschränkungen für Nicht-SDK-Schnittstellen

Um die Stabilität und Kompatibilität der App zu gewährleisten, hat die Plattform damit begonnen, festzulegen, welche Nicht-SDK-Schnittstellen deine App unter Android 9 (API-Level 28) verwenden kann. Android 10 enthält aktualisierte Listen eingeschränkter Nicht-SDK-Schnittstellen, die auf der Zusammenarbeit mit Android-Entwicklern und den neuesten internen Tests basieren. Unser Ziel ist es, dafür zu sorgen, dass öffentliche Alternativen verfügbar sind, bevor wir Nicht-SDK-Schnittstellen einschränken.

Wenn deine App nicht auf Android 10 (API-Level 29) ausgerichtet ist, betreffen dich einige dieser Änderungen möglicherweise nicht sofort. Sie können derzeit zwar einige Nicht-SDK-Schnittstellen verwenden (abhängig vom Ziel-API-Level Ihrer App), aber die Verwendung von Nicht-SDK-Methoden oder -Feldern birgt immer ein hohes Risiko für Probleme mit Ihrer App.

Wenn Sie sich nicht sicher sind, ob Ihre Anwendung Nicht-SDK-Schnittstellen verwendet, können Sie Ihre Anwendung testen, um das herauszufinden. Wenn Ihre App Nicht-SDK-Schnittstellen verwendet, sollten Sie mit der Planung einer Migration zu SDK-Alternativen beginnen. Trotzdem können einige Apps für die Verwendung von Nicht-SDK-Schnittstellen infrage kommen. Wenn Sie für eine Funktion in Ihrer App keine Alternative zur Verwendung einer Nicht-SDK-Schnittstelle finden, sollten Sie eine neue öffentliche API anfordern.

Weitere Informationen finden Sie unter Aktualisierungen der 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 Gerät aktivieren. Wenn ein Nutzer die Bedienung über Gesten aktiviert, wirkt sich dies auf alle Apps auf dem Gerät aus, unabhängig davon, ob die App auf API-Level 29 ausgerichtet ist. Wenn der Nutzer beispielsweise vom Rand des Bildschirms nach unten wischt, interpretiert das System diese Geste als Zurück-Navigation, es sei denn, eine App überschreibt diese Geste speziell für Teile des Bildschirms.

Damit Ihre App mit der Gestensteuerung kompatibel ist, sollten Sie den App-Inhalt von Rand bis Rand erweitern und in Konflikt stehende Touch-Gesten entsprechend handhaben. Weitere Informationen finden Sie in der Dokumentation zu Gestensteuerung.

Logo: NDK

Android 10 umfasst die folgenden NDK-Änderungen.

Freigegebene Objekte dürfen keine Textverschiebungen enthalten

Unter Android 6.0 (API-Level 23) ist die Verwendung von Textverschiebungen in gemeinsam genutzten Objekten nicht zulässig. 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 Anwendungen weiterhin gemeinsam genutzte Objekte mit Textverschiebungen verwenden, besteht die Gefahr, dass Fehler auftreten.

Änderungen an Bionic-Bibliotheken und dynamischen Verknüpfungspfaden

Ab Android 10 sind mehrere Pfade symbolische Links anstelle von regulären Dateien. Anwendungen, die darauf angewiesen sind, dass die Pfade normale Dateien sind, funktionieren möglicherweise nicht mehr:

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

Aus Kompatibilitätsgründen werden die Symlinks unter den alten Pfaden bereitgestellt. /system/lib/libc.so ist z. B. ein Symlink für /apex/com.android.runtime/lib/bionic/libc.so. dlopen(“/system/lib/libc.so”) funktioniert also weiterhin, Apps werden jedoch einen Unterschied feststellen, wenn sie versuchen, die geladenen Bibliotheken tatsächlich durch Lesen von /proc/self/maps oder ähnlich zu untersuchen. Dies ist nicht üblich. Wir haben jedoch festgestellt, dass einige Apps dies im Rahmen ihres Anti-Hacking-Prozesses tun. In diesem Fall sollten die /apex/…-Pfade als gültige Pfade für die Bionic-Dateien hinzugefügt werden.

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

Ab Android 10 werden ausführbare Segmente der Binärdateien und Bibliotheken des Systems dem Arbeitsspeicher zugeordnet, der nur ausgeführt werden kann (nicht lesbar), um eine Härtungstechnik gegen Code-Wiederverwendungsangriffe zu gewährleisten. Wenn Ihre App Lesevorgänge in Speichersegmenten ausführt, die als „Nur Ausführung“ gekennzeichnet sind – sei es aufgrund von Programmfehlern, Sicherheitslücken oder beabsichtigter Speicherprüfung –, sendet das System ein SIGSEGV-Signal an Ihre App.

Sie können feststellen, ob dieses Verhalten einen Absturz verursacht hat, indem Sie die zugehörige Tombstone-Datei in /data/tombstones/ untersuchen. Ein Absturz, der nur die Ausführung ermöglicht, enthält die folgende Abbruchmeldung:

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

Zur Umgehung dieses Problems bei der Durchführung von Vorgängen wie einer Speicherprüfung können Sie Segmente, die nur zum Ausführen ausgeführt werden, als Lesen + Ausführen markieren, indem Sie mprotect() aufrufen. Wir empfehlen jedoch dringend, sie im Anschluss wieder auf „Nur ausführen“ zurückzusetzen, da diese Einstellung für die Zugriffsberechtigung einen besseren Schutz für Ihre Anwendung und Nutzer bietet.

Hinweis :Aufrufe von ptrace sind von diesem Verhalten nicht betroffen, sodass Sie Fehler in ptrace beheben können.

Sicherheit

Android 10 umfasst die folgenden Sicherheitsänderungen.

TLS 1.3 ist standardmäßig aktiviert

Ab Android 10 ist TLS 1.3 standardmäßig für alle TLS-Verbindungen aktiviert. Hier sind einige wichtige Details zu unserer TLS 1.3-Implementierung:

• Die Cipher Suites von TLS 1.3 können nicht angepasst werden. Die unterstützten Cipher Suites von TLS 1.3 sind immer aktiviert, wenn TLS 1.3 aktiviert ist. Versuche, sie durch Aufrufen von setEnabledCipherSuites() zu deaktivieren, werden ignoriert.
• Bei der Aushandlung von TLS 1.3 werden HandshakeCompletedListener-Objekte aufgerufen, bevor Sitzungen dem Sitzungscache hinzugefügt werden. In TLS 1.2 und anderen früheren Versionen werden diese Objekte aufgerufen, nachdem Sitzungen dem Sitzungscache hinzugefügt wurden.
• Wenn SSLEngine-Instanzen unter älteren Android-Versionen ein SSLHandshakeException ausgeben, geben diese Instanzen unter Android 10 und höher stattdessen ein SSLProtocolException aus.
• Der 0-RTT-Modus wird nicht unterstützt.

Bei Bedarf können Sie durch Aufrufen von SSLContext.getInstance("TLSv1.2") eine SSLContext abrufen, bei der TLS 1.3 deaktiviert ist. Sie können Protokollversionen auch für einzelne Verbindungen aktivieren oder deaktivieren. Dazu rufen Sie setEnabledProtocols() für ein entsprechendes Objekt auf.

Mit SHA-1 signierte Zertifikate sind in TLS nicht vertrauenswürdig

In Android 10 sind Zertifikate, die den SHA-1-Hash-Algorithmus verwenden, in TLS-Verbindungen nicht vertrauenswürdig. Root-Zertifizierungsstellen haben seit 2016 kein solches Zertifikat mehr ausgestellt und sie sind in Chrome und anderen wichtigen Browsern nicht mehr vertrauenswürdig.

Jeder Verbindungsversuch schlägt fehl, wenn die Verbindung zu einer Website führt, die ein SHA-1-Zertifikat bereitstellt.

Ä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 Zertifikatanfragenachricht sendet. Ab Android 10 berücksichtigen KeyChain-Objekte die Aussteller und Schlüsselspezifikationsparameter, wenn KeyChain.choosePrivateKeyAlias() aufgerufen wird, um Nutzern eine Aufforderung zur Zertifikatsauswahl anzuzeigen. Diese Eingabeaufforderung enthält insbesondere keine Auswahlmöglichkeiten, die nicht den Serverspezifikationen entsprechen.

Wenn keine vom Nutzer auswählbaren Zertifikate verfügbar sind, z. B. wenn keine Zertifikate mit der Serverspezifikation übereinstimmen oder auf einem Gerät keine Zertifikate installiert sind, wird keine Aufforderung zur Zertifikatsauswahl angezeigt.

Außerdem ist unter Android 10 oder höher keine Displaysperre erforderlich, um Schlüssel oder CA-Zertifikate in ein KeyChain-Objekt zu importieren.

Weitere Änderungen bei TLS und Kryptografie

Es wurden mehrere kleinere Änderungen an den TLS- und Kryptografiebibliotheken unter Android 10 vorgenommen:

• Die Verschlüsselungen AES/GCM/NoPadding und ChaCha20/Poly1305/NoPadding geben genauere Puffergrößen aus getOutputSize() zurück.
• Die Cipher Suite TLS_FALLBACK_SCSV wird bei Verbindungversuchen mit einem Max-Protokoll von TLS 1.2 oder höher weggelassen. Aufgrund von Verbesserungen bei den Implementierungen von TLS-Servern raten wir von einem TLS-externen Fallback ab. Stattdessen empfehlen wir, sich auf die Aushandlung der TLS-Version zu verlassen.
• ChaCha20-Poly1305 ist ein Alias für ChaCha20/Poly1305/NoPadding.
• Hostnamen mit nachgestellten Punkten gelten nicht als gültige SNI-Hostnamen.
• Die Erweiterung „supported_signature_algorithms“ in CertificateRequest wird bei der Auswahl eines Signaturschlüssels für Zertifikatsantworten berücksichtigt.
• Intransparente Signaturschlüssel, z. B. aus dem Android-Schlüsselspeicher, können mit RSA-PSS-Signaturen in TLS verwendet werden.

Wi-Fi Direct-Übertragungen

Unter Android 10 sind die folgenden Broadcasts im Zusammenhang mit Wi-Fi Direct nicht fixiert:

• WIFI_P2P_CONNECTION_CHANGED_ACTION
• WIFI_P2P_THIS_DEVICE_CHANGED_ACTION

Wenn deine App diese Broadcasts bei der Registrierung nur empfangen konnte, weil sie fixiert waren, verwende stattdessen bei der Initialisierung die entsprechende get()-Methode, um die Informationen abzurufen.

Wi-Fi-Aware-Funktionen

Android 10 unterstützt jetzt die Erstellung von TCP/UDP-Sockets mit Wi-Fi-sensitiven Datenpfaden. Damit ein TCP/UDP-Socket mit einer ServerSocket verbunden wird, muss das Clientgerät die IPv6-Adresse und den Port des Servers kennen. Dies musste bisher Out-of-Band übertragen werden, z. B. über BT oder Wi-Fi Aware Layer 2-Messaging oder mithilfe anderer Protokolle wie mDNS in Band erkannt werden. Unter Android 10 können diese Informationen im Rahmen der Netzwerkeinrichtung übermittelt werden.

Der Server kann eine der folgenden Aktionen ausführen:

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

Das folgende Codebeispiel zeigt, wie Sie Portinformationen als Teil der Netzwerkanfrage angeben:

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 IPv6-Adresse und den vom Server bereitgestellten Port zu erhalten:

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 die Berechtigung SYSTEM_ALERT_WINDOW nicht erhalten. Das liegt daran, dass beim Zeichnen von Overlay-Fenstern übermäßig viel Arbeitsspeicher verbraucht wird, was die Leistung von Android-Geräten mit wenig Arbeitsspeicher besonders schadet.

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

Wenn eine App auf einem Go-Gerät einen Intent mit der Aktion ACTION_MANAGE_OVERLAY_PERMISSION sendet, lehnt das System die Anfrage automatisch ab und leitet den Nutzer zum Bildschirm Einstellungen weiter, auf dem er angezeigt wird, dass die Berechtigung aufgrund der Verlangsamung des Geräts nicht zulässig ist. Wenn eine App auf einem Go-Gerät Settings.canDrawOverlays() aufruft, gibt die Methode immer „false“ zurück. Diese Einschränkungen gelten nicht für Apps, die die Berechtigung SYSTEM_ALERT_WINDOW erhalten haben, bevor das Gerät auf Android 10 aktualisiert wurde.

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

Geräte mit Android 10 oder höher warnen Nutzer, wenn sie zum ersten Mal eine App ausführen, die auf Android 5.1 (API-Level 22) oder niedriger ausgerichtet ist. Wenn für die App der Nutzer Berechtigungen erteilen muss, hat er auch die Möglichkeit, die Berechtigungen der App anzupassen, bevor die App zum ersten Mal ausgeführt werden darf.

Aufgrund der Anforderungen an die Ziel-API von Google Play werden Nutzern diese Warnungen nur angezeigt, wenn sie eine App ausführen, die in letzter Zeit nicht aktualisiert wurde. Für Anwendungen, die über andere Stores vertrieben werden, gelten im Laufe des Jahres 2019 ähnliche Ziel-API-Anforderungen. Weitere Informationen zu diesen Anforderungen finden Sie unter Erweiterung der Anforderungen an das Ziel-API-Level im Jahr 2019.

SHA-2-CBC-Cipher Suites entfernt

Die folgenden SHA-2-CBC-Chiffresammlungen 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. Die meisten Server unterstützen entweder die GCM- und die CBC-Varianten dieser Chiffresammlungen oder keine.

Hinweis: Anwendungen und Bibliotheken sollten die gewünschten Cipher Suites mit dem Rückgabewert von getSupportedCipherSuites() schneiden, um eine zukunftssichere Auswahl der Cipher Suite gegen zukünftige Entfernungen zu verhindern.

App-Nutzung

In Android 10 wurden folgende Änderungen am Verhalten der App-Nutzung vorgenommen:

• UsageStats App-Nutzungsnutzung wird in - - wird in App-Nutzung in App -1 n-1 verwendet - Außerdem wird die Instant-App-Nutzung von Android 10 korrekt erfasst.

• Graustufen pro App – eine Graustufen pro App.

• Ablenkungsstatus pro App:

• Sperrung und Wiedergabe – Android kann nicht wiedergegeben werden.

Änderungen der HTTPS-Verbindung

Wenn eine App mit Android 10 null an setSSLSocketFactory() übergibt, wird ein IllegalArgumentException ausgelöst. In früheren Versionen hatte die Übergabe von null an setSSLSocketFactory() denselben Effekt wie das Übergeben der aktuellen Standard-Factory.

Die Bibliothek „android.preference“ wurde eingestellt

Die android.preference-Bibliothek wird ab Android 10 eingestellt. Entwickler sollten stattdessen die AndroidX-Präferenzbibliothek verwenden, die Teil von Android Jetpack ist. Weitere Ressourcen zur Unterstützung bei der Migration und Entwicklung finden Sie im aktualisierten Leitfaden für Einstellungen sowie in unserer öffentlichen Beispiel-App und in unserer Referenzdokumentation.

Änderungen an der Dienstprogrammbibliothek für ZIP-Dateien

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

Luftpumpe

In früheren Versionen haben einige Methoden in der Klasse Inflater eine IllegalStateException ausgelöst, wenn sie nach einem Aufruf von end() aufgerufen wurden. In Android 10 geben diese Methoden stattdessen ein NullPointerException aus.

ZIP-Datei

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

ZipOutputStream

Unter Android 10 und höher gibt die Methode finish() in ZipOutputStream keinen ZipException aus, wenn sie versucht, einen Ausgabestream für eine ZIP-Datei zu schreiben, die keine Dateien enthält.

Kameraänderungen

Bei vielen kamerabasierten Apps wird davon ausgegangen, dass sich das physische Gerät auch im Hochformat befindet, wenn sich das Gerät im Hochformat befindet, wie unter Kameraausrichtung beschrieben. Das war in der Vergangenheit eine sichere Annahme, hat sich aber mit der Erweiterung der verfügbaren Formfaktoren, wie z. B. faltbarer Smartphones, geändert. Diese Annahme kann auf diesen Geräten dazu führen, dass der Kamerasucher entweder falsch gedreht oder skaliert (oder beides) angezeigt wird.

Bei Anwendungen, die auf API-Level 24 oder höher ausgerichtet sind, sollten Sie explizit android:resizeableActivity festlegen und die erforderlichen Funktionen für den Mehrfensterbetrieb bereitstellen.

Tracking der Akkunutzung

Ab Android 10 setzt SystemHealthManager die Statistiken zur Akkunutzung zurück, sobald das Gerät nach einem wichtigen Ladeereignis vom Stromnetz getrennt wurde. Im Großen und Ganzen besteht ein wichtiges Ladeereignis entweder: Das Gerät ist vollständig aufgeladen oder es ist nicht mehr ausreichend entleert, sondern fast vollständig aufgeladen.

Vor Android 10 wurden die Statistiken zur Akkunutzung immer zurückgesetzt, wenn das Gerät vom Stromnetz getrennt wurde, unabhängig davon, wie wenig sich der Akkustand verändert hatte.

Einstellung von Android Beam

In Android 10 wird die ältere Funktion Android Beam zur Initiierung der geräteübergreifenden Datenfreigabe über die Nahfeldkommunikation (NFC) offiziell eingestellt. Außerdem stellen wir einige der zugehörigen NFC APIs ein. Android Beam bleibt optional für Gerätehersteller verfügbar, die es verwenden möchten, befindet sich jedoch nicht mehr in der aktiven Entwicklung. Android wird jedoch weiterhin andere NFC-Funktionen und APIs unterstützen und Anwendungsfälle wie das Lesen aus Tags und Zahlungen funktionieren weiterhin wie erwartet.

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

BigDecimal.stripTrailingZeros() behält nachgestellte Nullen nicht mehr als Sonderfall bei, wenn der Eingabewert Null ist.

Verhaltensänderungen für „java.util.regex.Matcher“ und „Muster“

Das Ergebnis von split() wurde so geändert, dass es nicht mehr mit einem leeren String("") beginnt, wenn am Anfang der Eingabe eine Übereinstimmung mit der Breite Null vorliegt. Dies betrifft auch String.split(). Beispielsweise gibt "x".split("") jetzt {"x"} zurück, während früher in älteren Android-Versionen {"", "x"} zurückgegeben wurde. "aardvark".split("(?=a)" gibt jetzt {"a", "ardv", "ark"} anstelle von {"", "a", "ardv", "ark"} zurück.

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

• appendReplacement(StringBuffer, String) gibt jetzt einen IllegalArgumentException anstelle von IndexOutOfBoundsException aus, wenn der Ersatz-String mit einem einzigen umgekehrten Schrägstrich endet, was nicht zulässig ist. Dieselbe Ausnahme wird jetzt ausgelöst, wenn der Ersatz-String mit einem $ endet. Zuvor wurde in diesem Szenario keine Ausnahme ausgegeben.
• replaceFirst(null) ruft nicht mehr reset() für die Matcher auf, wenn ein NullPointerException ausgegeben wird. NullPointerException wird jetzt auch ausgelöst, wenn es keine Übereinstimmung gibt. Bisher wurde sie nur bei einem Match geworfen.
• start(int group), end(int group) und group(int group) geben jetzt einen allgemeineren IndexOutOfBoundsException aus, wenn der Gruppenindex außerhalb des Bereichs liegt. Zuvor haben diese Methoden ArrayIndexOutOfBoundsException ausgelöst.

Der Standardwinkel für GradientDrawable ist jetzt TOP_BOTTOM

Wenn Sie in Android 10 eine GradientDrawable in XML definieren und keine Winkelmessung angeben, wird die Ausrichtung des Gradienten standardmäßig auf TOP_BOTTOM festgelegt. Dies ist eine Änderung gegenüber früheren Android-Versionen, bei denen standardmäßig LEFT_RIGHT verwendet wurde.

Wenn Sie auf die neueste Version von AAPT2 aktualisieren, legt das Tool als Behelfslösung für Legacy-Apps einen Winkelmesswert von 0 fest, wenn keine Winkelmessung angegeben ist.

Logging für serielle Objekte mit Standard-SUID

Ab Android 7.0 (API-Level 24) wurde auf der Plattform die Standard-serialVersionUID für serielle Objekte korrigiert. Diese Fehlerkorrektur hatte keine Auswirkungen auf Apps, die auf API-Level 23 oder niedriger ausgerichtet waren.

Ab Android 10 gilt: Wenn eine App auf API-Level 23 oder niedriger ausgerichtet ist und auf dem alten, falschen, standardmäßigen serialVersionUID basiert, protokolliert das System eine Warnung und schlägt eine Code-Korrektur vor.

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

• Die App ist auf API-Level 23 oder niedriger ausgerichtet.
• Eine Klasse ist seriell.
• Die serielle Klasse verwendet den Standard-serialVersionUID, anstatt explizit einen serialVersionUID festzulegen.
• Die standardmäßige serialVersionUID unterscheidet sich von der serialVersionUID, wenn die App auf API-Level 24 oder höher ausgerichtet ist.

Diese Warnung wird für jede betroffene Klasse einmal protokolliert. Die Warnmeldung enthält eine vorgeschlagene Korrektur, bei der serialVersionUID explizit auf den Standardwert gesetzt wird, der berechnet wird, wenn die App auf API-Level 24 oder höher ausgerichtet ist. Mit dieser Korrektur können Sie dafür sorgen, dass ein Objekt aus dieser Klasse in einer App, die auf API-Level 23 oder niedriger ausgerichtet ist, das Objekt korrekt von Apps gelesen wird, die auf Version 24 oder höher ausgerichtet sind, und umgekehrt.

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

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