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 unter Android 10 ausgeführt wird, unabhängig vom targetSdkVersion der App. Sie sollten Ihre App testen und sie bei Bedarf anpassen, damit sie diese Änderungen richtig unterstützt.

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 für Apps, die auf Android 29 ausgerichtet sind.

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

  • Hintergrundzugriff auf den Gerätestandort
  • Starts von Hintergrundaktivitäten
  • Informationen zur Affinität von Kontakten
  • MAC‑Adress‑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, hat die Plattform in Android 9 (API-Level 28) begonnen, die Verwendung von Nicht-SDK-Schnittstellen durch Ihre App 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 Sie nicht auf Android 10 (API-Level 29) ausgerichtet sind, wirken sich einige dieser Änderungen möglicherweise nicht sofort auf Sie aus. Derzeit können Sie jedoch einige Nicht-SDK-Schnittstellen verwenden (abhängig vom Ziel-API-Level Ihrer App). Die Verwendung einer Nicht-SDK-Methode oder eines Nicht-SDK-Felds 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 auf Nicht-SDK-Schnittstellen basiert, sollten Sie mit der Planung einer Migration zu SDK-Alternativen beginnen. Wir verstehen jedoch, dass einige Apps gültige Anwendungsfälle für die Verwendung von Nicht-SDK-Schnittstellen haben. 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 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 Gestensteuerung 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 Bildschirmrand nach innen wischt, interpretiert das System diese Geste als „Zurück“, es sei denn, eine App überschreibt diese Geste speziell für bestimmte Bereiche des Bildschirms.

Damit Ihre App mit der Gestennavigation kompatibel ist, müssen Sie den App-Inhalt von Rand zu Rand ausdehnen und widersprüchliche Gesten entsprechend verarbeiten. Weitere Informationen finden Sie in der Dokumentation zur Gestensteuerung.

NDK

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

Freigegebene Objekte dürfen keine Textverlagerungen enthalten

In Android 6.0 (API-Level 23) ist die Verwendung von Textumsetzungen in gemeinsam genutzten Objekten nicht zulässig. Der Code muss unverändert geladen werden und darf nicht geändert werden. Diese Änderung verbessert die Ladezeiten von Apps und die Sicherheit.

SELinux erzwingt diese Einschränkung für Apps, die auf Android 10 oder höher ausgerichtet sind. Wenn diese Apps weiterhin freigegebene Objekte mit Textverlagerungen 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. Apps, die darauf angewiesen sind, 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 sind die Symlinks unter den alten Pfaden verfügbar. /system/lib/libc.so ist beispielsweise ein symbolischer Link zu /apex/com.android.runtime/lib/bionic/libc.so. dlopen(“/system/lib/libc.so”) funktioniert also weiterhin, aber Apps stellen den Unterschied fest, wenn sie versuchen, die geladenen Bibliotheken zu untersuchen, 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. Wenn ja, sollten die /apex/…-Pfade als gültige Pfade für die Bionic-Dateien hinzugefügt werden.

Systembinärdateien/-bibliotheken, die dem Nur-Ausführen-Speicher zugeordnet sind

Ab Android 10 werden ausführbare Segmente von Systembinärdateien und ‑bibliotheken als Härtungstechnik gegen Code-Wiederverwendungsangriffe nur in den Arbeitsspeicher gemappt (nicht lesbar). Wenn Ihre App Leseoperationen in Speichersegmente ausführt, die als „Nur ausführen“ markiert sind – sei es aufgrund eines Fehlers, einer Sicherheitslücke oder einer beabsichtigten Speicherprüfung –, sendet das System ein SIGSEGV-Signal an Ihre App.

Ob dieses Verhalten einen Absturz verursacht hat, können Sie anhand der zugehörigen Tombstone-Datei in /data/tombstones/ feststellen. Ein Absturz, der sich nur auf die Ausführung bezieht, 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 die Speicherprüfung auszuführen, können Sie Segmente, die nur ausgeführt werden können, mit dem Aufruf von mprotect() als „Lesen + Ausführen“ markieren. Wir empfehlen jedoch dringend, sie danach wieder auf „Nur ausführen“ zurückzusetzen, da diese Zugriffsberechtigung Ihre App und Ihre Nutzer besser schützt.

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 zur Implementierung von TLS 1.3:

  • Die TLS 1.3-Cipher Suites können nicht angepasst werden. Die unterstützten TLS 1.3-Chiffrierverfahren werden 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 bevor Sitzungen dem Sitzungscache hinzugefügt werden aufgerufen. In TLS 1.2 und anderen früheren Versionen werden diese Objekte nach dem Hinzufügen von Sitzungen zum Sitzungscache aufgerufen.
  • In einigen Situationen, in denen SSLEngine-Instanzen in früheren Android-Versionen eine SSLHandshakeException auslösen, lösen diese Instanzen in Android 10 und höher stattdessen eine SSLProtocolException aus.
  • Der 0-RTT-Modus wird nicht unterstützt.

Bei Bedarf können Sie ein 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 geeignetes Objekt aufrufen.

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 erfolgt, die ein Zertifikat mit SHA‑1 präsentiert.

Änderungen und Verbesserungen bei 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 Zertifikatanfrage sendet. Ab Android 10 werden bei KeyChain-Objekten die Parameter für Aussteller und Schlüsselspezifikation berücksichtigt, wenn KeyChain.choosePrivateKeyAlias() aufgerufen wird, um Nutzern eine Aufforderung zur Zertifikatauswahl anzuzeigen. Dieser Prompt enthält insbesondere keine Optionen, 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 nicht 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 an TLS und Kryptografie

In den TLS- und Kryptografiebibliotheken wurden mehrere kleinere Änderungen vorgenommen, die sich auf Android 10 auswirken:

  • Die Chiffren AES/GCM/NoPadding und ChaCha20/Poly1305/NoPadding geben genauere Puffergrößen von getOutputSize() zurück.
  • Die Chiffrensammlung TLS_FALLBACK_SCSV wird bei Verbindungsversuchen mit einem maximalen Protokoll von TLS 1.2 oder höher ausgelassen. Aufgrund von Verbesserungen bei TLS-Serverimplementierungen empfehlen wir, keinen externen TLS-Fallback zu versuchen. Stattdessen empfehlen wir, sich auf die TLS-Versionsaushandlung 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.
  • Opake 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 Broadcasts im Zusammenhang mit Wi‑Fi Direct nicht persistent:

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

Wi-Fi Aware-Funktionen

In Android 10 wird die Erstellung von TCP/UDP-Sockets über Wi-Fi Aware-Datenpfade vereinfacht. 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 Out-of-Band kommuniziert werden, z. B. über Layer-2-Messaging über Bluetooth oder Wi-Fi Aware, oder In-Band über andere Protokolle wie mDNS ermittelt werden. Unter Android 10 können die Informationen im Rahmen der Netzwerkeinrichtung übermittelt werden.

Der Server kann Folgendes tun:

  • Initialisieren Sie ein 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.

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 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 sehr viel Arbeitsspeicher benötigt, was sich besonders negativ auf die Leistung von Android-Geräten mit wenig Arbeitsspeicher auswirkt.

Wenn eine App, die auf einem Go-Gerät mit Android 9 oder niedriger ausgeführt wird, die Berechtigung SYSTEM_ALERT_WINDOW erhält, behält sie die 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 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 Einstellungen-Bildschirm weiter, auf dem angezeigt wird, 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. Auch hier gilt, dass diese Einschränkungen nicht für Apps gelten, 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 vom Nutzer Berechtigungen benötigt, hat er die Möglichkeit, die Berechtigungen der App anzupassen, 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 ein Nutzer eine App ausführt, die vor Kurzem nicht aktualisiert wurde. Für Apps, die über andere App-Shops vertrieben werden, gelten im Jahr 2019 ähnliche Anforderungen an das Ziel-API-Level. Weitere Informationen zu diesen Anforderungen finden Sie unter Ausweitung 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 Chiffrierverfahren sind weniger sicher als die ähnlichen Chiffrierverfahren, die GCM verwenden. Die meisten Server unterstützen entweder sowohl die GCM- als auch die CBC-Varianten dieser Chiffrierverfahren oder keine von beiden.

App-Nutzung

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

Änderungen bei HTTPS-Verbindungen

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

Die android.preference-Bibliothek ist veraltet

Die android.preference-Bibliothek wird ab Android 10 nicht mehr unterstützt. Entwickler sollten stattdessen die AndroidX-Einstellungsbibliothek verwenden, die Teil von Android Jetpack ist. Weitere Ressourcen zur Unterstützung der Migration und Entwicklung finden Sie im aktualisierten Leitfaden für 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 Paket java.util.zip vorgenommen, das ZIP-Dateien verarbeitet. Durch diese Änderungen wird das Verhalten der Bibliothek zwischen Android und anderen Plattformen, die java.util.zip verwenden, einheitlicher.

Aufblasvorrichtung

In früheren Versionen wurde bei einigen Methoden in der Klasse Inflater eine IllegalStateException ausgegeben, wenn sie nach einem Aufruf von end() aufgerufen wurden. In Android 10 wird für diese Methoden stattdessen eine NullPointerException ausgelöst.

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 wird durch die 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

Viele Apps, die die Kamera verwenden, gehen davon aus, dass sich das Gerät, wenn es im Hochformat konfiguriert ist, auch physisch 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, z. B. Falt-Smartphones, geändert. Diese Annahme kann bei diesen Geräten dazu führen, dass die Kameraansicht entweder falsch gedreht oder skaliert (oder beides) angezeigt wird.

Anwendungen, die auf API-Level 24 oder höher ausgerichtet sind, sollten android:resizeableActivity explizit festlegen und die erforderliche Funktionalität für die Verarbeitung des Multi-Window-Betriebs bereitstellen.

Tracking der Akkunutzung

Ab Android 10 werden die Statistiken zur Akkunutzung von SystemHealthManager zurückgesetzt, wenn das Gerät nach einem wichtigen Ladevorgang vom Stromnetz getrennt wird. Im Allgemeinen ist ein wichtiges Ladeereignis entweder: Das Gerät wurde vollständig aufgeladen oder das Gerät wurde von fast leer zu fast vollständig aufgeladen.

Vor Android 10 wurden die Statistiken zum Akkuverbrauch immer dann 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. Diese ältere Funktion ermöglichte die Initiierung der Datenfreigabe zwischen Geräten über Nahfeldkommunikation (NFC). Außerdem stellen wir mehrere zugehörige NFC-APIs ein. Android Beam ist weiterhin optional für Gerätehersteller verfügbar, die es verwenden möchten. Es wird jedoch nicht mehr aktiv weiterentwickelt. Android unterstützt weiterhin andere NFC-Funktionen und APIs. Anwendungsfälle wie das Lesen von Tags und Zahlungen funktionieren weiterhin wie erwartet.

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

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

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

Das Ergebnis von split() beginnt nicht mehr mit einem leeren String („“), wenn am Anfang der Eingabe eine Übereinstimmung mit der Breite null vorliegt. Das wirkt sich auch auf String.split() aus. "x".split("") gibt jetzt beispielsweise {"x"} zurück, während es in älteren Android-Versionen {"", "x"} zurückgegeben hat. "aardvark".split("(?=a)" gibt jetzt {"a", "ardv", "ark"} anstelle von {"", "a", "ardv", "ark"} zurück.

Das Ausnahmeverhalten bei ungültigen Argumenten wurde ebenfalls verbessert:

  • appendReplacement(StringBuffer, String) löst jetzt eine 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 die Ersetzung String mit einem $ endet. Bisher wurde in diesem Fall keine Ausnahme ausgelöst.
  • replaceFirst(null) ruft reset() nicht mehr für Matcher auf, wenn eine NullPointerException ausgelöst wird. NullPointerException wird jetzt auch ausgelöst, wenn es keine Übereinstimmung gibt. Bisher wurde sie nur ausgelöst, wenn es eine Übereinstimmung gab.
  • start(int group), end(int group) und group(int group) geben jetzt eine allgemeinere IndexOutOfBoundsException zurück, wenn der Gruppenindex außerhalb des gültigen Bereichs liegt. Bisher wurde bei diesen 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 Verlaufs standardmäßig auf TOP_BOTTOM festgelegt. Dies ist eine Änderung gegenüber früheren Android-Versionen, in denen der Standardwert LEFT_RIGHT war.

Als Workaround können Sie auf die neueste Version von AAPT2 aktualisieren. Das Tool legt dann für Legacy-Apps, für die keine Winkelmessung angegeben ist, eine Winkelmessung von 0 fest.

Logging für serialisierte Objekte mit der Standard-SUID

Ab Android 7.0 (API-Level 24) wurde die Plattform für serialisierbare Objekte korrigiert.serialVersionUID Diese Korrektur betraf keine 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 das alte, falsche Standard-serialVersionUID angewiesen ist, protokolliert das System eine Warnung und schlägt eine Codekorrektur vor.

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.
  • Die serialisierte Klasse verwendet die Standardeinstellung serialVersionUID, anstatt serialVersionUID explizit festzulegen.
  • Der Standardwert für serialVersionUID unterscheidet sich von dem Wert, der verwendet würde, wenn die App auf API‑Level 24 oder höher ausgerichtet wäre.serialVersionUID

Diese Warnung wird einmal für jede betroffene Klasse protokolliert. Die Warnmeldung enthält einen Vorschlag zur Behebung des Problems: Sie sollten serialVersionUID explizit auf den Standardwert festlegen, der berechnet würde, wenn die App auf API‑Level 24 oder höher ausgerichtet wäre. Mit diesem Fix können Sie dafür sorgen, dass 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 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 der von truncate() zurückgegebene „errno“-Wert ignoriert, in Android 10 wird jedoch eine IOException ausgelöst. Wenn Sie das alte Verhalten benötigen, müssen Sie nativen Code verwenden.