Verhaltensänderungen: alle Apps

Android 10 enthält Verhaltensänderungen, die sich auf Ihre App auswirken können. Die auf dieser Seite aufgeführten Änderungen gelten für Ihre App, wenn sie auf Android 10 ausgeführt wird, unabhängig von der targetSdkVersion der App. Sie sollten Ihre App testen und nach Bedarf anpassen, um diese Änderungen richtig zu unterstützen.

Wenn die targetSdkVersion Ihrer App 29 oder höher ist, müssen Sie auch zusätzliche Änderungen unterstützen. Weitere Informationen finden Sie unter Änderungen am Verhalten von Apps, die auf Nutzer unter 29 Jahren ausgerichtet sind.

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

  • Hintergrundzugriff auf den Gerätestandort
  • Start der Hintergrundaktivität
  • Informationen zur Kundenaffinität
  • Zufallsgenerierung von MAC-Adressen
  • 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 Ä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, 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 Sie Ihre App nicht auf Android 10 (API-Level 29) ausrichten, wirken sich einige dieser Änderungen möglicherweise nicht sofort auf Sie aus. Derzeit können Sie jedoch einige Nicht-SDK-Schnittstellen verwenden (je nach 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 das herauszufinden. Wenn Ihre App Nicht-SDK-Schnittstellen verwendet, sollten Sie mit der Planung einer Migration zu SDK-Alternativen beginnen. Uns ist jedoch bewusst, 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-Benutzeroberfläche für eine Funktion in Ihrer App finden, sollten Sie eine 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 gesamten Gerät aktivieren. Wenn ein Nutzer die Gestennavigation aktiviert, wirkt sich das auf alle Apps auf dem Gerät aus, unabhängig davon, ob die App auf API-Level 29 ausgerichtet ist oder nicht. Wenn der Nutzer beispielsweise vom Rand des Displays nach innen wischt, interpretiert das System diese Geste als Zurück-Navigation, es sei denn, eine App überschreibt diese Geste ausdrücklich für Teile des Displays.

Damit Ihre App mit der Gestennavigation kompatibel ist, sollten Sie die App-Inhalte von Rand zu Rand ausdehnen und sich überschneidende Touch-Gesten entsprechend behandeln. Weitere Informationen finden Sie in der Dokumentation zur Gestennavigation.

NDK

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

Freigegebene Objekte dürfen keine Textumplatzierungen enthalten.

Unter Android 6.0 (API-Ebene 23) ist die Verwendung von Textumsetzungen in freigegebenen Objekten nicht mehr zulässig. Der Code muss unverändert geladen 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 Textumstellungen enthalten, besteht ein hohes Risiko, dass sie nicht mehr funktionieren.

Änderungen an Bionic-Bibliotheken und Pfaden für dynamischen Linker

Ab Android 10 sind mehrere Pfade symbolische Links anstelle von regulären Dateien. Bei Apps, die davon ausgegangen sind, dass die Pfade reguläre Dateien sind, kann es zu Fehlern kommen:

  • /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. Dabei wird lib/ durch lib64/ ersetzt.

Aus Kompatibilitätsgründen werden die Symlinks an den alten Pfaden bereitgestellt. Beispielsweise ist /system/lib/libc.so ein Symlink 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.

System-Binärdateien/-Bibliotheken, die dem Nur-Ausführungsspeicher zugeordnet sind

Ab Android 10 werden ausführbare Segmente von Systembinärdateien und ‑Bibliotheken als Härtungstechnik gegen Code-Reuse-Angriffe nur zum Ausführen (nicht lesbar) in den Arbeitsspeicher zugeordnet. 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.

Ob dieses Verhalten zu einem Absturz geführt hat, können Sie anhand der zugehörigen Tombstone-Datei in /data/tombstones/ feststellen. Ein Absturz im Zusammenhang mit dem Nur-Ausführungsmodus 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, die Einstellung danach wieder auf „Nur ausführen“ zurückzusetzen, da diese Zugriffsberechtigungseinstellung einen besseren Schutz für Ihre App und Ihre 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-Chiffrenfolgen können nicht angepasst werden. Die unterstützten TLS 1.3-Chiffrengruppen sind immer aktiviert, wenn TLS 1.3 aktiviert ist. Versuche, sie durch Aufrufen von setEnabledCipherSuites() zu deaktivieren, werden 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 Fällen, in denen SSLEngine-Instanzen in früheren Android-Versionen eine SSLHandshakeException auswerfen, wird unter Android 10 und höher stattdessen eine SSLProtocolException ausgegeben.
  • Der 0-RTT-Modus wird nicht unterstützt.

Wenn Sie möchten, können Sie eine 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() auf ein entsprechendes Objekt anwenden.

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

In Android 10 werden Zertifikate, die den SHA-1-Hash-Algorithmus verwenden, in TLS-Verbindungen nicht als vertrauenswürdig eingestuft. Root-CAs haben seit 2016 keine solchen Zertifikate 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 besteht, die ein SHA-1-Zertifikat vorlegt.

Änderungen und Verbesserungen am Verhalten von KeyChain

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 enthält dieser Prompt keine Optionen, die nicht den Serverspezifikationen entsprechen.

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

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

Weitere Änderungen bei TLS und Kryptografie

Es gab mehrere kleinere Änderungen an den TLS- und Kryptografiebibliotheken, die unter Android 10 wirksam werden:

  • Die Chiffren AES/GCM/NoPadding und ChaCha20/Poly1305/NoPadding geben ab getOutputSize() genauere Puffergrößen zurück.
  • Die Chiffrensammlung TLS_FALLBACK_SCSV wird bei Verbindungsversuchen mit einem maximalen Protokoll von TLS 1.2 oder höher nicht berücksichtigt. Aufgrund von Verbesserungen bei der TLS-Serverimplementierung empfehlen wir, keinen externen TLS-Fallback zu versuchen. Stattdessen empfehlen wir die TLS-Versionenverhandlung.
  • ChaCha20-Poly1305 ist ein Alias für ChaCha20/Poly1305/NoPadding.
  • Hostnamen mit Endpunkten gelten nicht als gültige SNI-Hostnamen.
  • Die Erweiterung „supported_signature_algorithms“ in CertificateRequest wird bei der Auswahl eines Signaturschlüssels für Zertifikatantworten berücksichtigt.
  • Opaque-Signaturschlüssel, z. B. aus dem Android Keystore, können mit RSA-PSS-Signaturen in TLS verwendet werden.

Wi‑Fi Direct-Broadcasts

Unter Android 10 sind die folgenden Wi‑Fi Direct-Anzeigen nicht fixiert:

Wenn Ihre App bei der Registrierung auf den Empfang dieser Übertragungen angewiesen war, weil sie „sticky“ waren, verwenden Sie stattdessen die entsprechende get()-Methode bei der Initialisierung, um die Informationen abzurufen.

Wi‑Fi Aware-Funktionen

Android 10 unterstützt das Erstellen von TCP/UDP-Sockets mithilfe von Wi‑Fi Aware-Datenpaden. Um einen TCP/UDP-Socket zu erstellen, der eine Verbindung zu einem ServerSocket herstellt, muss das Clientgerät die IPv6-Adresse und den Port des Servers kennen. Bisher musste dies außerhalb des Bandes kommuniziert werden, z. B. über BT- oder Wi‑Fi Aware-Layer-2-Messaging oder innerhalb des Bandes mit anderen Protokollen wie mDNS. Unter Android 10 können die Informationen im Rahmen der Netzwerkeinrichtung übermittelt werden.

Der Server kann Folgendes tun:

  • Initialisieren Sie eine 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 Geräten mit Android 10 (Go-Edition) ausgeführt werden, können die Berechtigung SYSTEM_ALERT_WINDOW nicht erhalten. Das liegt daran, dass das Zeichnen von Overlay-Fenstern viel Arbeitsspeicher beansprucht, was sich besonders negativ auf die Leistung von Android-Geräten mit wenig Arbeitsspeicher auswirkt.

Wenn eine App auf einem Gerät mit der Go-Version und Android 9 oder niedriger die Berechtigung SYSTEM_ALERT_WINDOW erhält, behält sie diese auch dann, wenn das Gerät auf Android 10 aktualisiert wird. Apps, die diese Berechtigung nicht bereits haben, können sie nach dem Upgrade jedoch nicht mehr erhalten.

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 Bildschirm mit den Einstellungen weiter, auf dem steht, dass die Berechtigung nicht zulässig ist, da 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 vor dem Upgrade des Geräts auf Android 10 erhalten haben.

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-Ebene 22) oder niedriger ausgerichtet ist, gewarnt. 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 Anforderungen an die Ziel-API von Google Play sehen Nutzer diese Warnungen nur, wenn sie eine App ausführen, die seit einiger Zeit nicht aktualisiert wurde. 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 Anforderungen finden Sie unter Erweiterung der Anforderungen an das Ziel-API-Level im Jahr 2019.

SHA-2-CBC-Chiffrensammlungen entfernt

Die folgenden SHA-2-CBC-Chiffrensammlungen 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 Chiffrensuites sind weniger sicher als ähnliche Chiffrensuites, die GCM verwenden. Die meisten Server unterstützen entweder sowohl die GCM- als auch die CBC-Varianten dieser Chiffrensuites oder keine von beiden.

App-Nutzung

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

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

  • Mit

Änderungen an HTTPS-Verbindungen

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

Die Bibliothek „android.preference“ wird eingestellt

Die android.preference-Bibliothek wird ab Android 10 nicht mehr unterstützt. Entwickler sollten stattdessen die AndroidX-Einstellungenbibliothek verwenden, die Teil von Android Jetpack ist. Weitere Ressourcen zur Migration und Entwicklung finden Sie im aktualisierten Leitfaden zu Einstellungen, in unserer öffentlichen Beispiel-App und in der Referenzdokumentation.

Änderungen an der ZIP-Datei-Dienstprogrammbibliothek

In Android 10 wurden die folgenden Änderungen an Klassen im java.util.zip-Paket vorgenommen, das ZIP-Dateien verarbeitet. Durch diese Änderungen ist das Verhalten der Bibliothek auf Android-Geräten und anderen Plattformen, auf denen java.util.zip verwendet wird, einheitlicher.

Kompressor

In früheren Versionen warf eine Methode der Klasse Inflater die Ausnahme IllegalStateException, wenn sie nach einem Aufruf von end() aufgerufen wurde. Unter Android 10 werfen diese Methoden stattdessen eine NullPointerException.

ZipFile

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

ZipOutputStream

Unter Android 10 und höher wird bei der Methode finish() in ZipOutputStream kein ZipException geworfen, 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 das Gerät im Hochformat gehalten wird, wenn die Kamera im Hochformat ist, wie unter Kameraausrichtung beschrieben. Das war in der Vergangenheit eine sichere Annahme, aber das hat sich mit der Erweiterung der verfügbaren Formfaktoren wie faltbaren Geräten 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, muss android:resizeableActivity explizit festgelegt werden und die erforderlichen Funktionen für die Multifenster-Bedienung müssen vorhanden sein.

Tracking der Akkunutzung

Ab Android 10 werden die Statistiken zur Akkunutzung von SystemHealthManager zurückgesetzt, wenn das Gerät nach einem großen Ladevorgang vom Netz getrennt wird. Grob gesagt ist ein wichtiges Ladeereignis entweder: Das Gerät wurde vollständig aufgeladen oder es hat sich von einem fast leeren Akku zu einem fast voll aufgeladenen Akku entwickelt.

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

Mit Android 10 wird Android Beam offiziell eingestellt. Das ist eine ältere Funktion, mit der die Datenfreigabe zwischen Geräten über Nahfeldkommunikation (NFC) gestartet werden kann. Außerdem werden einige der zugehörigen NFC-APIs eingestellt. Android Beam ist weiterhin optional für Gerätehersteller verfügbar, die die Funktion verwenden möchten. Die Funktion wird jedoch 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.

Änderung am Verhalten von java.math.BigDecimal.stripTrailingZeros()

Bei BigDecimal.stripTrailingZeros() werden nachgestellte Nullen nicht mehr als Sonderfall behandelt, wenn der Eingabewert null ist.

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

Das Ergebnis von split() beginnt jetzt nicht mehr mit einer leeren String („""), wenn sich am Anfang der Eingabe ein Zeichen mit Nullbreite befindet. Das gilt auch für String.split(). 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"} statt {"", "a", "ardv", "ark"} zurück.

Außerdem wurde das Verhalten bei Ausnahmen für ungültige Argumente 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 gleiche Ausnahme wird jetzt ausgelöst, wenn das Ersatz-String auf ein $ endet. Bisher wurde in diesem Szenario keine Ausnahme ausgelöst.
  • replaceFirst(null) ruft reset() nicht mehr auf der Matcher auf, wenn eine NullPointerException geworfen wird. NullPointerException wird jetzt auch ausgegeben, wenn keine Übereinstimmung gefunden wird. Bisher wurde die Ausnahme nur geworfen, wenn eine Übereinstimmung gefunden wurde.
  • start(int group), end(int group) und group(int group) geben jetzt eine allgemeinere IndexOutOfBoundsException zurück, wenn der Gruppenindex außerhalb des zulässigen Bereichs liegt. Bisher wurde bei diesen Methoden ArrayIndexOutOfBoundsException geworfen.

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 Standardausrichtung des Farbverlaufs TOP_BOTTOM. Dies ist eine Änderung gegenüber früheren Android-Versionen, in denen LEFT_RIGHT standardmäßig festgelegt war.

Als Problemumgehung können Sie auf die neueste Version von AAPT2 aktualisieren. In diesem Fall wird für ältere Apps ein Winkel von 0 festgelegt, wenn keine Winkelmessung angegeben ist.

Logging für serialisierte Objekte mit der Standard-SUID

Ab Android 7.0 (API-Level 24) wurde auf der Plattform ein Fehler bei der Standardeinstellung serialVersionUID für serialisierbare Objekte behoben. Diese Korrektur wirkt sich nicht auf Apps aus, die auf API-Level 23 oder niedriger ausgerichtet sind.

Ab Android 10 wird bei einer App, die auf API-Ebene 23 oder niedriger ausgerichtet ist und die alte, falsche Standard-serialVersionUID verwendet, eine Warnung protokolliert und eine Codekorrektur vorgeschlagen.

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

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

Diese Warnung wird einmal für jede betroffene Klasse protokolliert. Die Warnmeldung enthält eine vorgeschlagene Lösung: Legen Sie serialVersionUID explizit auf den Standardwert fest, der berechnet würde, wenn die App auf API-Level 24 oder höher ausgerichtet wäre. Wenn Sie diese Korrektur anwenden, wird ein Objekt aus dieser Klasse, das in einer App serialisiert wird, die auf API-Level 23 oder niedriger ausgerichtet ist, von Apps, die auf API-Level 24 oder höher ausgerichtet sind, korrekt gelesen.

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

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