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.

Einschränkungen für Nicht-SDK-Schnittstellen

Um die Stabilität und Kompatibilität von Apps zu verbessern, hat die Plattform die Verwendung von nicht zu SDKs gehörenden Schnittstellen in Android 9 (API-Level 28) eingeschränkt. 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 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 dies 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 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 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 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 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 Gestennavigation.

NDK

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

Freigegebene Objekte dürfen keine Textverschiebungen 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 Anwendungen weiterhin gemeinsam genutzte Objekte mit Textverschiebungen verwenden, besteht ein hohes Risiko, Probleme zu verursachen.

Änderungen an Bionic-Bibliotheken und dynamischen Verknüpfungspfaden

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 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 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 Binärdateien und Bibliotheken des Systems zur Härtung von Code-Wiederverwendungsangriffen schreibgeschützten (nicht lesbaren) Arbeitsspeicher-Segmenten 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, 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, 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-Cipher-Suites 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 für jede Verbindung aktivieren oder deaktivieren, indem Sie setEnabledProtocols() in einem entsprechenden 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 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 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 Cipher Suite TLS_FALLBACK_SCSV wird bei Verbindungsversuchen mit einem maximalen Protokoll von TLS 1.2 oder höher ausgelassen. Aufgrund von Verbesserungen bei der TLS-Serverimplementierung raten wir davon ab, ein TLS-externes Fallback zu verwenden. 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:

• WIFI_P2P_CONNECTION_CHANGED_ACTION
• WIFI_P2P_THIS_DEVICE_CHANGED_ACTION

Wenn deine App diese Broadcasts bei der Registrierung empfangen hat, weil sie fixiert waren, verwende 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. 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. 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 holen 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:

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 vom Server bereitgestellte IPv6-Adresse und den 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. 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 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 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 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 der App Berechtigungen gewähren muss, hat er auch die Möglichkeit, die Berechtigungen der App anzupassen, bevor die App zum ersten Mal ausgeführt werden darf.

Aufgrund der Anforderungen an die Ziel-API von Google Play werden einem Nutzer diese Warnungen nur angezeigt, wenn er eine App ausführt, die in letzter 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-Cipher Suites 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:

• Mit 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 mit Android 10 eingestellt. Entwickler sollten stattdessen die AndroidX-Einstellungenbibliothek verwenden, die Teil von Android Jetpack ist. Weitere Ressourcen zur Unterstützung bei 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

In Android 10 wurden die folgenden Änderungen an Klassen im java.util.zip-Paket vorgenommen, das ZIP-Dateien verarbeitet. Durch diese Änderungen wird das Verhalten der Bibliothek zwischen Android und anderen Plattformen, die java.util.zip verwenden, einheitlicher.

Kompressor

In früheren Versionen wurde bei einigen Methoden der Klasse Inflater die Fehlermeldung IllegalStateException ausgegeben, wenn sie nach einem Aufruf von end() aufgerufen wurden. 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 falsch gedreht oder skaliert wird (oder beides).

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. 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 einige der zugehörigen 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 unterstützt jedoch weiterhin andere NFC-Funktionen und ‑APIs. 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.

Ä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.

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

• appendReplacement(StringBuffer, String) gibt jetzt einen IllegalArgumentException statt IndexOutOfBoundsException aus, wenn die Ersetzung String mit einem einzigen umgekehrten Schrägstrich endet. Dies ist nicht zulässig. 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. Zuvor wurde er nur bei einem Spiel geworfen.
• 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 einen GradientDrawable in XML definieren und keine Winkelmessung angeben, wird die Farbverlaufsausrichtung standardmäßig auf TOP_BOTTOM festgelegt. 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 Grad festgelegt, wenn keine Winkelmessung angegeben ist.

Logging für serialisierte Objekte mit der Standard-SUID

Ab Android 7.0 (API-Level 24) wurde die Standardeinstellung serialVersionUID für serialisierbare Objekte korrigiert. Apps, die auf API-Level 23 oder niedriger ausgerichtet sind, sind von dieser Korrektur nicht betroffen.

Ab Android 10 wird bei einer App, die auf API-Level 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.
• Die serialisierte Klasse verwendet die Standard-serialVersionUID, anstatt explizit einen 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 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. 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.