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 vom targetSdkVersion der App. Sie sollten Ihre Anwendung testen und nach Bedarf anpassen, damit diese Änderungen korrekt unterstützt werden.

Wenn die targetSdkVersion Ihrer Anwendung 29 oder höher ist, müssen auch zusätzliche Änderungen unterstützt werden. Weitere Informationen hierzu finden Sie im Artikel Verhaltensänderungen für Apps mit dem Ziel 29.

Einschränkungen für Nicht-SDK-Schnittstellen

Um die Stabilität und Kompatibilität der Apps zu gewährleisten, wurde eingeschränkt, welche Nicht-SDK-Schnittstellen deine App unter Android 9 (API-Level 28) verwenden kann. Android 10 enthält aktualisierte Listen der eingeschränkten Nicht-SDK-Schnittstellen, die auf der Zusammenarbeit mit Android-Entwicklern und den neuesten internen Tests basieren. Wir möchten dafür 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 zwar derzeit einige Nicht-SDK-Schnittstellen verwenden (je nach Ziel-API-Level Ihrer App), aber die Verwendung von Nicht-SDK-Methoden und -Feldern birgt immer ein hohes Risiko für Probleme mit Ihrer App.

Wenn Sie sich nicht sicher sind, ob Ihre App Nicht-SDK-Schnittstellen verwendet, können Sie Ihre App testen, um es herauszufinden. Wenn Ihre App Nicht-SDK-Schnittstellen benötigt, sollten Sie mit der Migration zu SDK-Alternativen beginnen. Uns ist aber bewusst, dass es bei einigen Apps gültige Anwendungsfälle für die Verwendung von Nicht-SDK-Schnittstellen gibt. Wenn Sie für ein Feature in Ihrer App keine Alternative zur Verwendung einer Nicht-SDK-Schnittstelle finden, sollten Sie eine neue öffentliche API anfordern.

Weitere Informationen findest du unter Updates zu 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 Bedienung über Gesten aktiviert, wirkt sich das 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 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 Bedienung über Gesten kompatibel ist, sollten Sie den App-Inhalt von Edge zu Edge erweitern und in Konflikt stehende Gesten entsprechend handhaben. Weitere Informationen finden Sie in der Dokumentation zur Bedienung über Gesten.

Logo: NDK

Android 10 umfasst die folgenden NDK-Änderungen.

Gemeinsam genutzte Objekte dürfen keine Textverschiebungen enthalten

Android 6.0 (API-Level 23): die Verwendung von Textverschiebungen in gemeinsam genutzten Objekten ist nicht zulässig. Der Code muss unverändert geladen werden und darf nicht geändert werden. Durch diese Änderung werden die Ladezeiten und die Sicherheit der App 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 ein hohes Risiko, Probleme zu beheben.

Änderungen an Bionic-Bibliotheken und dynamischen Verknüpfungspfaden

Ab Android 10 sind mehrere Pfade symbolische Links anstelle von regulären Dateien. Anwendungen, die bisher reguläre Dateien waren, funktionieren möglicherweise nicht mehr richtig:

• /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 unter den alten Pfaden bereitgestellt. Beispiel: /system/lib/libc.so ist ein Symlink zu /apex/com.android.runtime/lib/bionic/libc.so. dlopen(“/system/lib/libc.so”) funktioniert zwar weiterhin, aber Apps können einen Unterschied feststellen, wenn sie versuchen, die geladenen Bibliotheken durch Lesen von /proc/self/maps oder ähnlich zu untersuchen. Dies ist 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 Ausführungsspeicher zugeordnet sind

Ab Android 10 werden ausführbare Segmente von Binärdateien und Bibliotheken des Systems zur Härtung von Code-Wiederverwendungsangriffen schreibgeschützten (nicht lesbaren) Arbeitsspeicher-Segmenten zugeordnet. Wenn Ihre App Leseoperationen in Arbeitsspeichersegmente ausführt, die als Nur-Ausführung gekennzeichnet sind – sei es aufgrund eines Programmfehlers, einer Sicherheitslücke oder einer beabsichtigten Speicherprüfung –, sendet das System ein SIGSEGV-Signal an Ihre App.

Sie können herausfinden, ob dieses Verhalten zu einem Absturz geführt hat, indem Sie die zugehörige Tombstone-Datei in /data/tombstones/ untersuchen. Ein Absturz, der nur eine Ausführung erfordern, enthält die folgende Abbruchnachricht:

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

Um dieses Problem zu umgehen und Vorgänge wie die Speicherinspektion auszuführen, können Sie Segmente, für die nur Ausführungen gelten, als „Lesen + Ausführen“ markieren. Rufen Sie dazu mprotect() auf. Wir empfehlen jedoch dringend, sie anschließend wieder auf „Nur Ausführung“ zurückzusetzen, da diese Einstellung für die Zugriffsberechtigung einen besseren Schutz für Ihre App und Ihre Nutzer bietet.

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 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 unter früheren Android-Versionen ein SSLHandshakeException ausgeben, lösen diese Instanzen unter Android 10 und höher stattdessen SSLProtocolException aus.
• 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 SSLContext.getInstance("TLSv1.2") aufrufen. Sie können Protokollversionen auch für jede Verbindung aktivieren oder deaktivieren, indem Sie setEnabledProtocols() in einem entsprechenden Objekt aufrufen.

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

In Android 10 werden Zertifikate, die den SHA-1-Hash-Algorithmus verwenden, in TLS-Verbindungen nicht als vertrauenswürdig eingestuft. Stamm-CAs haben seit 2016 kein solches Zertifikat ausgestellt und sie gelten in Chrome oder anderen wichtigen Browsern nicht mehr als vertrauenswürdig.

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

Änderungen und Verbesserungen des KeyChain-Verhaltens

Bei einigen Browsern wie Google Chrome können Nutzer ein Zertifikat auswählen, wenn ein TLS-Server im Rahmen eines TLS-Handshakes eine Zertifikatsanfragenachricht 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 diese Eingabeaufforderung keine Auswahlmöglichkeiten, 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 nicht angezeigt.

Außerdem ist auf Geräten mit 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 in Android 10 vorgenommen:

• Die Chiffren AES/GCM/NoPadding und ChaCha20/Poly1305/NoPadding geben genauere Zwischenspeichergröß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 ausgelassen. Aufgrund von Verbesserungen bei den TLS-Serverimplementierungen raten wir davon ab, ein TLS-externes Fallback zu verwenden. Stattdessen empfehlen wir die TLS-Versionsverhandlung.
• 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 wird berücksichtigt, wenn ein Signaturschlüssel für Zertifikatsantworten ausgewählt wird.
• Intransparente Signaturschlüssel wie diejenigen 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 fixiert:

• WIFI_P2P_CONNECTION_CHANGED_ACTION
• WIFI_P2P_THIS_DEVICE_CHANGED_ACTION

Wenn Ihre App diese Broadcasts bei der Registrierung empfangen hat, weil sie fixiert waren, verwenden Sie bei der Initialisierung stattdessen die entsprechende get()-Methode, um die Informationen abzurufen.

Wi-Fi Aware-Funktionen

Android 10 unterstützt das Erstellen 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 IPv6-Port des Servers kennen. Dies musste bisher Out-of-Band kommuniziert werden, z. B. über BT oder Wi-Fi Aware Layer 2, oder über andere Protokolle wie mDNS im Band erkannt. Mit 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 in der Netzwerkanfrage Portinformationen angeben:

val ss = ServerSocket()
val ns = WifiAwareNetworkSpecifier.Builder(discoverySession, peerHandle)
  .setPskPassphrase("some-password")
  .setPort(ss.localPort)
  .build()

val myNetworkRequest = NetworkRequest.Builder()
  .addTransportType(NetworkCapabilities.TRANSPORT_WIFI_AWARE)
  .setNetworkSpecifier(ns)
  .build()

ServerSocket ss = new ServerSocket();
WifiAwareNetworkSpecifier ns = new WifiAwareNetworkSpecifier
  .Builder(discoverySession, peerHandle)
  .setPskPassphrase(“some-password”)
  .setPort(ss.getLocalPort())
  .build();

NetworkRequest myNetworkRequest = new NetworkRequest.Builder()
  .addTransportType(NetworkCapabilities.TRANSPORT_WIFI_AWARE)
  .setNetworkSpecifier(ns)
  .build();

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

val callback = object : ConnectivityManager.NetworkCallback() {
  override fun onAvailable(network: Network) {
    ...
  }
  
  override fun onLinkPropertiesChanged(network: Network,
      linkProperties: LinkProperties) {
    ...
  }

  override fun onCapabilitiesChanged(network: Network,
      networkCapabilities: NetworkCapabilities) {
    ...
    val ti = networkCapabilities.transportInfo
    if (ti is WifiAwareNetworkInfo) {
       val peerAddress = ti.peerIpv6Addr
       val peerPort = ti.port
    }
  }
  override fun onLost(network: Network) {
    ...
  }
};

connMgr.requestNetwork(networkRequest, callback)

callback = new ConnectivityManager.NetworkCallback() {
  @Override
  public void onAvailable(Network network) {
    ...
  }
  @Override
  public void onLinkPropertiesChanged(Network network,
      LinkProperties linkProperties) {
    ...
  }
  @Override
  public void onCapabilitiesChanged(Network network,
      NetworkCapabilities networkCapabilities) {
    ...
    TransportInfo ti = networkCapabilities.getTransportInfo();
    if (ti instanceof WifiAwareNetworkInfo) {
       WifiAwareNetworkInfo info = (WifiAwareNetworkInfo) ti;
       Inet6Address peerAddress = info.getPeerIpv6Addr();
       int peerPort = info.getPort();
    }
  }
  @Override
  public void onLost(Network network) {
    ...
  }
};

connMgr.requestNetwork(networkRequest, callback);

SYSTEM_ALERT_WINDOW 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. Dies liegt daran, dass das Zeichnen von Overlay-Fenstern zu viel Arbeitsspeicher erfordert, was sich besonders negativ auf die Leistung von Android-Geräten mit wenig Arbeitsspeicher auswirkt.

Wenn eine App, die auf einem Gerät der Go-Edition mit Android 9 oder niedriger ausgeführt wird, die Berechtigung SYSTEM_ALERT_WINDOW erhält, behält die App diese Berechtigung auch dann bei, 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 erteilt 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 steht, dass die Berechtigung nicht erlaubt ist, da das Gerät dadurch verlangsamt wird. Wenn eine App auf einem Go-Gerät Settings.canDrawOverlays() aufruft, gibt die Methode immer „false“ zurück. Diese Einschränkungen gelten wieder nicht für Apps, die die Berechtigung SYSTEM_ALERT_WINDOW vor dem Upgrade 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 gewarnt, wenn sie zum ersten Mal eine App ausführen, die auf Android 5.1 (API-Level 22) oder niedriger ausgerichtet ist. Wenn der Nutzer Berechtigungen erteilen muss, hat er außerdem 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 einem Nutzer diese Warnungen nur angezeigt, wenn er eine App ausführt, die in letzter Zeit nicht aktualisiert wurde. Für Anwendungen, die über andere Stores vertrieben werden, gelten 2019 ähnliche Ziel-API-Anforderungen. Weitere Informationen zu diesen Anforderungen finden Sie unter 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 ähnliche Chiffresammlungen, die GCM verwenden. Außerdem unterstützen die meisten Server entweder die GCM- und die CBC-Variante dieser Cipher Suites oder keine von ihnen.

App-Nutzung

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

• Verbesserung der Nutzung von Statistiken zur App-Nutzung Bild-in-App-Nutzung Außerdem wird die Nutzung von Instant-Apps unter Android 10 korrekt erfasst.

• Graustufen pro App –

• Ablenkungsstatus pro App – Apps werden nicht als Benachrichtigungen angezeigt.

• Sperrung und Wiedergabe – Android können nicht gesperrt werden.

Änderungen der HTTPS-Verbindung

Wenn eine App mit Android 10 null an setSSLSocketFactory() übergibt, tritt ein IllegalArgumentException auf. 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 mit Android 10 eingestellt. Entwickler sollten stattdessen die AndroidX-Einstellungsbibliothek verwenden, die Teil von Android Jetpack ist. Weitere Ressourcen für Migration und Entwicklung finden Sie im aktualisierten Einstellungsleitfaden, in unserer öffentlichen Beispiel-App und in der Referenzdokumentation.

Änderungen an der Dienstprogrammbibliothek für ZIP-Dateien

Mit Android 10 werden die folgenden Änderungen an den 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, einheitlicher.

Aufblasgerät

In früheren Versionen haben einige Methoden in der Klasse Inflater ein IllegalStateException ausgelöst, wenn sie nach einem Aufruf von end() aufgerufen wurden. In Android 10 lösen diese Methoden stattdessen 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 wird von der Methode finish() in ZipOutputStream kein ZipException ausgelöst, wenn versucht wird, einen Ausgabestream für eine ZIP-Datei zu schreiben, die keine Dateien enthält.

Kameraänderungen

Bei vielen Kamera-Apps wird davon ausgegangen, dass bei einem Gerät im Hochformat auch das physische Gerät im Hochformat gezeigt wird. Dies wird unter Kameraausrichtung beschrieben. Dies war in der Vergangenheit eine sichere Annahme, aber das hat sich durch die Erweiterung der verfügbaren Formfaktoren wie faltbare Smartphones geändert. Diese Annahme kann auf diesen Geräten dazu führen, dass der Kamerasucher falsch gedreht oder skaliert wird (oder beides).

Für Anwendungen, die auf API-Level 24 oder höher ausgerichtet sind, muss android:resizeableActivity explizit festgelegt werden und sie müssen die erforderlichen Funktionen für den Mehrfenstermodus bieten.

Tracking der Akkunutzung

Ab Android 10 werden die Statistiken zur Akkunutzung von SystemHealthManager zurückgesetzt, wenn das Gerät nach einem großen Ladeereignis vom Stromnetz getrennt wird. Im Grunde ist ein wichtiges Ladeereignis entweder: Das Gerät wurde vollständig aufgeladen oder das Gerät ist von einem Großteil erschöpft zu einem vollständig aufgeladenen Gerät geworden.

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

Einstellung von Android Beam

In Android 10 stellen wir Android Beam offiziell ein, eine ältere Funktion zur Initiierung der Datenfreigabe zwischen Geräten über Nahfeldkommunikation (NFC). Außerdem werden mehrere zugehörige NFC APIs eingestellt. Android Beam ist weiterhin 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 von Tags und Zahlungen funktionieren weiterhin wie erwartet.

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

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

Verhaltensänderungen bei 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 Null Breite vorliegt. Dies betrifft auch String.split(). Beispielsweise gibt "x".split("") jetzt {"x"} zurück, während früher {"", "x"} unter älteren Android-Versionen zurückgegeben wurde. "aardvark".split("(?=a)" gibt jetzt {"a", "ardv", "ark"} statt {"", "a", "ardv", "ark"} zurück.

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

• appendReplacement(StringBuffer, String) gibt jetzt einen IllegalArgumentException statt IndexOutOfBoundsException aus, wenn der Ersatz-String mit einem einzigen umgekehrten Schrägstrich endet. Dies ist nicht zulässig. 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 eine NullPointerException ausgegeben wird. NullPointerException wird jetzt auch ausgelöst, wenn keine Übereinstimmung vorliegt. Zuvor wurde er nur bei einem Spiel geworfen.
• start(int group), end(int group) und group(int group) geben jetzt eine allgemeinere IndexOutOfBoundsException aus, 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 einen GradientDrawable in XML definieren und keine Winkelmessung angeben, wird die Farbverlaufsausrichtung standardmäßig auf TOP_BOTTOM festgelegt. Dies ist eine Änderung im Vergleich zu früheren Android-Versionen, in denen der Standardwert LEFT_RIGHT war.

Zur Umgehung dieses Problems legt das Tool nach einem Update auf die neueste Version von AAPT2 für Legacy-Anwendungen 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 Standardeinstellung serialVersionUID für serialisierbare Objekte korrigiert. Diese Korrektur hatte keine Auswirkungen auf Apps, die auf API-Level 23 oder niedriger ausgerichtet waren.

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

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, anstatt explizit einen serialVersionUID festzulegen.
• Der Standardwert für serialVersionUID unterscheidet sich von dem für 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 darin besteht, serialVersionUID explizit auf den Standardwert zu setzen, 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 Anwendung, die auf API-Level 23 oder niedriger ausgerichtet ist, 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 standardmäßige Dateien wie /dev/zero nicht mehr unterstützt, da deren Größe nicht mit truncate() geändert werden kann. Frühere Versionen von Android haben den von truncate() zurückgegebenen Fehler verschluckt, Android 10 löst jedoch eine IOException aus. Wenn Sie das alte Verhalten benötigen, müssen Sie nativen Code verwenden.