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 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 anpassen, damit diese Änderungen ordnungsgemäß unterstützt werden.

Wenn die „targetSdkVersion“ Ihrer App 29 oder höher ist, müssen Sie auch zusätzliche Änderungen unterstützen. Weitere Informationen finden Sie unter Verhaltensänderungen bei Apps, die auf API-Level 29 ausgerichtet sind.

Hinweis : Zusätzlich zu den auf dieser Seite aufgeführten Änderungen werden mit Android 10 zahlreiche datenschutzbezogene Änderungen und Einschränkungen eingeführt, darunter:

  • Hintergrundzugriff auf den Gerätestandort
  • Starts von Hintergrundaktivitäten
  • Informationen zur Affinität von Kontakten
  • MAC-Adressen-Randomisierung
  • Kamerametadaten
  • Berechtigungsmodell

Diese Änderungen betreffen alle Apps und verbessern den Datenschutz für Nutzer. Weitere Informationen dazu, wie Sie diese Änderungen unterstützen können, finden Sie auf der Seite Datenschutzänderungen.

Einschränkungen für Nicht-SDK-Schnittstellen

Um die Stabilität und Kompatibilität von Apps zu gewährleisten, wurde mit Android 9 (API-Level 28) damit begonnen, die Verwendung von Nicht-SDK-Schnittstellen durch Apps einzuschränken. 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 du nicht auf Android 10 (API-Level 29) abzielst, betreffen dich einige dieser Änderungen möglicherweise nicht sofort. Derzeit können Sie zwar einige Nicht-SDK-Schnittstellen verwenden (abhängig vom Ziel-API-Level Ihrer App), die Verwendung von Nicht-SDK-Methoden oder ‑Feldern birgt jedoch immer ein hohes Risiko, dass Ihre App nicht mehr funktioniert.

Wenn Sie sich nicht sicher sind, ob Ihre App Nicht-SDK-Schnittstellen verwendet, können Sie Ihre App testen, um dies herauszufinden. Wenn Ihre App auf Nicht-SDK-Schnittstellen basiert, sollten Sie mit der Planung einer Migration zu SDK-Alternativen beginnen. Wir wissen jedoch, dass es für einige Apps gültige Anwendungsfälle für die Verwendung von Nicht-SDK-Schnittstellen gibt. Wenn Sie keine Alternative zur Verwendung einer Nicht-SDK-Schnittstelle für eine Funktion in Ihrer App finden, sollten Sie eine neue öffentliche API anfordern.

Weitere Informationen finden Sie unter Updates to non-SDK interface restrictions in Android 10 und Restrictions on non-SDK interfaces.

Bedienung über Gesten

Ab Android 10 können Nutzer die Bedienung über Gesten auf dem gesamten 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 Bildschirmrand nach innen wischt, interpretiert das System diese Geste als Rückwärtsnavigation, es sei denn, eine App überschreibt diese Geste ausdrücklich für Teile des Bildschirms.

Damit Ihre App mit der Bedienung über Gesten kompatibel ist, müssen Sie den App-Inhalt von Rand zu Rand erweitern und widersprüchliche Gesten entsprechend verarbeiten. Weitere Informationen findest du in der Dokumentation zur Bedienung über Gesten.

NDK

Android 10 enthält die folgenden NDK-Änderungen.

Freigegebene Objekte dürfen keine Textverschiebungen enthalten

In Android 6.0 (API-Level 23) wurde die Verwendung von Textverschiebungen in freigegebenen Objekten untersagt. Der Code muss unverändert geladen werden und darf nicht geändert werden. Diese Änderung verbessert die Ladezeiten und die Sicherheit von Apps.

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

Änderungen an Bionic-Bibliotheken und dynamischen Linker-Pfaden

Ab Android 10 sind mehrere Pfade symbolische Links anstelle von regulären Dateien. Anwendungen, die davon ausgehen, dass die Pfade reguläre 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 symbolischen Links unter den alten Pfaden bereitgestellt. Beispiel: /system/lib/libc.so ist ein symbolischer Link zu /apex/com.android.runtime/lib/bionic/libc.so. dlopen(“/system/lib/libc.so”) funktioniert also weiterhin, aber Apps erkennen den Unterschied, wenn sie versuchen, die geladenen Bibliotheken zu prüfen, indem sie /proc/self/maps oder Ähnliches lesen. Das ist zwar nicht üblich, aber wir haben 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ärdateien/-bibliotheken, die dem Nur-Ausführungs-Speicher zugeordnet sind

Ab Android 10 werden ausführbare Segmente von Systembinärdateien und ‑bibliotheken als Härtungstechnik gegen Angriffe zur Wiederverwendung von Code nur ausführbar (nicht lesbar) im Speicher zugeordnet. Wenn Ihre App Lesevorgänge in Speichersegmenten ausführt, die als „Nur ausführen“ gekennzeichnet sind – sei es aufgrund eines Fehlers, einer Sicherheitslücke oder einer absichtlichen Speicherprüfung –, sendet das System ein SIGSEGV-Signal an Ihre App.

Du kannst feststellen, ob dieses Verhalten einen Absturz verursacht hat, indem du die zugehörige Tombstone-Datei in /data/tombstones/ untersuchst. Ein Absturz im Zusammenhang mit „Nur ausführen“ enthält die folgende Abbruchmeldung:

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

Um dieses Problem zu umgehen und Vorgänge wie den Memory Inspector auszuführen, können Sie Segmente, die nur ausgeführt werden dürfen, als „Lesen und Ausführen“ markieren, indem Sie mprotect() aufrufen. Wir empfehlen jedoch dringend, die Einstellung danach wieder auf „Nur ausführen“ zurückzusetzen, da diese Zugriffsberechtigungseinstellung einen besseren Schutz für Ihre App und Nutzer bietet.

Sicherheit

Android 10 enthält 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 sind einige wichtige Details zu unserer TLS 1.3-Implementierung:

  • Die TLS 1.3-Cipher-Suites können nicht angepasst werden. Die unterstützten TLS 1.3-Cipher-Suites sind immer aktiviert, wenn TLS 1.3 aktiviert ist. Jeder Versuch, sie durch Aufrufen von setEnabledCipherSuites() zu deaktivieren, wird ignoriert.
  • Wenn TLS 1.3 ausgehandelt wird, 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.)
  • In einigen Situationen, in denen SSLEngine-Instanzen in früheren Android-Versionen eine SSLHandshakeException auslösen, lösen diese Instanzen unter Android 10 und höher stattdessen eine SSLProtocolException aus.
  • Der 0-RTT-Modus wird nicht unterstützt.

Bei Bedarf können Sie einen SSLContext mit deaktiviertem TLS 1.3 abrufen, indem Sie SSLContext.getInstance("TLSv1.2") aufrufen. Sie können Protokollversionen auch pro Verbindung aktivieren oder deaktivieren, indem Sie setEnabledProtocols() für ein entsprechendes Objekt aufrufen.

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

In Android 10 wird Zertifikaten, die den SHA-1-Hash-Algorithmus verwenden, in TLS-Verbindungen nicht vertraut. Root-CAs haben solche Zertifikate seit 2016 nicht mehr ausgestellt und sie werden in Chrome oder anderen gängigen Browsern nicht mehr als vertrauenswürdig eingestuft.

Jeder Verbindungsversuch schlägt fehl, wenn die Verbindung zu einer Website hergestellt wird, die ein Zertifikat mit SHA-1 verwendet.

Änderungen und Verbesserungen am Verhalten von KeyChain

In einigen Browsern, z. B. Google Chrome, können Nutzer ein Zertifikat auswählen, wenn ein TLS-Server im Rahmen eines TLS-Handshakes eine Zertifikatsanfrage 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. Insbesondere enthält dieser Prompt keine Auswahlmöglichkeiten, die nicht den Serverspezifikationen entsprechen.

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

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

Weitere Änderungen an TLS und Kryptografie

In den TLS- und Kryptografiebibliotheken wurden mehrere kleinere Änderungen vorgenommen, die in Android 10 wirksam werden:

  • Die Chiffren AES/GCM/NoPadding und ChaCha20/Poly1305/NoPadding geben genauere Puffergrößen von getOutputSize() zurück.
  • Die Cipher Suite TLS_FALLBACK_SCSV wird bei Verbindungsversuchen mit einem maximalen Protokoll von TLS 1.2 oder höher weggelassen. Aufgrund von Verbesserungen bei TLS-Serverimplementierungen empfehlen wir nicht, einen externen TLS-Fallback zu versuchen. Stattdessen empfehlen wir, die TLS-Versionsverhandlung zu verwenden.
  • 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.
  • Undurchsichtige Signaturschlüssel, z. B. aus dem Android-Keystore, 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 dauerhaft:

Wenn deine App diese Broadcasts bei der Registrierung erhalten hat, weil sie „sticky“ waren, verwende stattdessen die entsprechende get()-Methode bei der Initialisierung, um die Informationen zu erhalten.

Wi-Fi Aware-Funktionen

Android 10 bietet Unterstützung für die einfachere Erstellung von TCP/UDP-Sockets mithilfe von Wi-Fi Aware-Datenpfaden. Zum Erstellen eines TCP/UDP-Sockets, der eine Verbindung zu einem ServerSocket herstellt, muss das Clientgerät die IPv6-Adresse und den Port des Servers kennen. Dies musste bisher Out-of-Band kommuniziert werden, z. B. über BT- oder Wi-Fi Aware-Layer-2-Messaging, oder In-Band über andere Protokolle wie mDNS erkannt werden. Unter Android 10 können die 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 fest oder rufen 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 Android 10-Geräten (Go-Edition) ausgeführt werden, können die Berechtigung SYSTEM_ALERT_WINDOW nicht erhalten. Das Zeichnen von Overlay-Fenstern verbraucht nämlich sehr viel Arbeitsspeicher, was sich besonders negativ auf die Leistung von Android-Geräten mit wenig Arbeitsspeicher auswirkt.

Wenn eine App, die auf einem Go-Edition-Gerät mit Android 9 oder niedriger ausgeführt wird, die Berechtigung SYSTEM_ALERT_WINDOW erhält, behält die App die Berechtigung auch dann, wenn das Gerät auf Android 10 aktualisiert wird. Apps, die diese Berechtigung noch nicht haben, kann sie nach dem Upgrade des Geräts jedoch 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 zu einem Einstellungsbildschirm weiter, auf dem angegeben ist, dass die Berechtigung nicht zulässig ist, weil sie das Gerät verlangsamt. 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

Auf Geräten mit Android 10 oder höher werden Nutzer beim ersten Ausführen einer App, die auf Android 5.1 (API-Level 22) oder niedriger ausgerichtet ist, gewarnt. Wenn die App Berechtigungen vom Nutzer benötigt, kann der Nutzer die Berechtigungen der App anpassen, bevor die App zum ersten Mal ausgeführt werden darf.

Aufgrund der Anforderungen an das Ziel-API-Level von Google Play werden diese Warnungen nur angezeigt, wenn eine App ausgeführt wird, die nicht vor Kurzem aktualisiert wurde. Für Apps, die über andere Stores vertrieben werden, gelten im Laufe des Jahres 2019 ähnliche Anforderungen an das Ziel-API-Level. 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-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 die ähnlichen Cipher Suites, die GCM verwenden. Die meisten Server unterstützen entweder sowohl die GCM- als auch die CBC-Varianten dieser Cipher Suites oder keine von beiden.

App-Nutzung

In Android 10 werden die folgenden Verhaltensänderungen in Bezug auf die App-Nutzung eingeführt:

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

  • Graustufen pro App: In Android 10 kann der Graustufenmodus für jede App einzeln festgelegt werden.

  • Ablenkungsstatus pro App: Android 10 kann Apps selektiv in einen „Ablenkungsstatus“ versetzen, in dem ihre Benachrichtigungen unterdrückt werden und sie nicht als vorgeschlagene Apps angezeigt werden.

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

Änderungen an HTTPS-Verbindungen

Wenn eine App unter Android 10 null an setSSLSocketFactory() übergibt, tritt ein IllegalArgumentException auf. In früheren Versionen hatte die Übergabe von null an setSSLSocketFactory() denselben Effekt wie die Übergabe der aktuellen Standard-Factory.

Die Bibliothek „android.preference“ wird nicht mehr unterstützt

Die Bibliothek android.preference wird ab Android 10 nicht mehr unterstützt. 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 zu den Einstellungen, in unserer öffentlichen Beispiel-App und in der Referenzdokumentation.

Änderungen an der ZIP-Datei-Dienstprogrammbibliothek

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 zwischen Android und anderen Plattformen, die java.util.zip verwenden, konsistenter.

Inflater

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 lösen diese Methoden stattdessen eine NullPointerException aus.

ZipFile

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

ZipOutputStream

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

Kameraänderungen

Viele Apps, die die Kamera verwenden, gehen davon aus, dass sich das physische Gerät im Hochformat befindet, wenn das Gerät im Hochformat konfiguriert ist, wie unter Kameraausrichtung beschrieben. In der Vergangenheit war das eine sichere Annahme, aber das hat sich mit der Erweiterung der verfügbaren Formfaktoren wie Foldables geändert. Diese Annahme kann bei diesen Geräten dazu führen, dass der Kamerasucher falsch gedreht oder skaliert (oder beides) angezeigt wird.

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

Tracking der Akkunutzung

Ab Android 10 setzt SystemHealthManager die Nutzungsstatistik zur Akkunutzung zurück, wenn das Gerät nach einem wichtigen Ladevorgang vom Stromnetz getrennt wird. Im Allgemeinen ist ein wichtiger Ladevorgang entweder: Das Gerät wurde vollständig aufgeladen oder das Gerät wurde von fast leer auf fast voll aufgeladen.

Vor Android 10 wurden die Statistiken zur Akkunutzung immer zurückgesetzt, wenn das Gerät vom Stromnetz getrennt wurde, unabhängig davon, wie gering die Änderung des Akkustands war.

Einstellung von Android Beam

In Android 10 wird Android Beam offiziell eingestellt. Dabei handelt es sich um eine ältere Funktion, mit der die Datenweitergabe zwischen Geräten über Nahfeldkommunikation (NFC) initiiert wird. Außerdem werden mehrere der zugehörigen NFC-APIs eingestellt. Android Beam ist weiterhin optional für Gerätehersteller verfügbar, die es verwenden möchten, wird aber nicht mehr aktiv weiterentwickelt. Android unterstützt jedoch weiterhin andere NFC-Funktionen und ‑APIs. Anwendungsfälle wie das Lesen von Tags und Zahlungen funktionieren weiterhin wie erwartet.

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

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

Änderungen am Verhalten von java.util.regex.Matcher und Pattern

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 wirkt sich auch auf String.split() aus. Beispiel: "x".split("") gibt jetzt {"x"} zurück, während in älteren Android-Versionen {"", "x"} zurückgegeben wurde. "aardvark".split("(?=a)" gibt jetzt {"a", "ardv", "ark"} anstelle von {"", "a", "ardv", "ark"} zurück.

Das Verhalten bei Ausnahmen für ungültige Argumente wurde ebenfalls verbessert:

  • appendReplacement(StringBuffer, String) löst jetzt einen IllegalArgumentException anstelle von IndexOutOfBoundsException aus, wenn der Ersatz-String mit einem einzelnen Backslash endet, was unzulässig ist. Dieselbe Ausnahme wird jetzt ausgelöst, wenn der Ersatz-String mit einem $ endet. Bisher wurde in diesem Szenario keine Ausnahme ausgelöst.
  • replaceFirst(null) ruft reset() nicht mehr für Matcher auf, wenn ein NullPointerException ausgelöst wird. NullPointerException wird jetzt auch ausgelöst, wenn es keine Übereinstimmung gibt. Bisher wurde er nur ausgelöst, wenn eine Übereinstimmung gefunden wurde.
  • start(int group), end(int group) und group(int group) lösen jetzt eine allgemeinere IndexOutOfBoundsException aus, wenn der Gruppenindex außerhalb des zulässigen Bereichs liegt. Bisher haben diese Methoden ArrayIndexOutOfBoundsException ausgegeben.

Der Standardwinkel für GradientDrawable ist jetzt TOP_BOTTOM

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

Wenn Sie auf die neueste Version von AAPT2 aktualisieren, legt das Tool für ältere Apps eine Winkelmessung von 0 fest, wenn keine Winkelmessung angegeben ist.

Logging für serialisierte Objekte mit Standard-SUID

Ab Android 7.0 (API-Level 24) wurde die Plattform um eine Korrektur der standardmäßigen serialVersionUID für serialisierbare Objekte erweitert. Diese Korrektur hatte keine Auswirkungen auf Apps, die auf API-Level 23 oder niedriger ausgerichtet waren.

Wenn eine App ab Android 10 auf API-Level 23 oder niedriger ausgerichtet ist und auf dem alten, falschen Standard-serialVersionUID basiert, protokolliert das System eine Warnung und schlägt eine Codekorrektur vor.

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

  • Die App ist auf API-Level 23 oder niedriger ausgerichtet.
  • Eine Klasse wird serialisiert.
  • Die serialisierte Klasse verwendet die Standard-serialVersionUID, anstatt explizit eine serialVersionUID festzulegen.
  • Der Standard-serialVersionUID unterscheidet sich von dem serialVersionUID, der verwendet würde, wenn die App auf Ziel-API-Level 24 oder höher ausgerichtet wäre.

Diese Warnung wird für jede betroffene Klasse einmal protokolliert. Die Warnmeldung enthält einen Lösungsvorschlag, nämlich serialVersionUID explizit auf den Standardwert festzulegen, der berechnet werden würde, wenn die App auf Ziel-API-Level 24 oder höher ausgerichtet wäre. Mit dieser Korrektur können Sie dafür sorgen, dass ein Objekt aus dieser Klasse, das in einer App mit Ziel-API-Level 23 oder niedriger serialisiert wird, von Apps mit Ziel-API-Level 24 oder höher korrekt gelesen wird und umgekehrt.

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

Ab Android 10 wird FileChannel.map() für nicht standardmäßige Dateien wie /dev/zero nicht unterstützt, deren Größe nicht mit truncate() geändert werden kann. In früheren Android-Versionen wurde die von truncate() zurückgegebene Fehlernummer ignoriert, aber Android 10 löst eine IOException aus. Wenn Sie das alte Verhalten benötigen, müssen Sie nativen Code verwenden.