Unter Android 10 gibt es Verhaltensänderungen, die sich auf deine App auswirken können.
Die auf dieser Seite aufgeführten Änderungen gelten für deine App, wenn sie unter Android 10 ausgeführt wird, unabhängig von der targetSdkVersion
der App. Sie sollten Ihre App testen und bei Bedarf ändern, um diese Änderungen korrekt zu unterstützen.
Wenn die targetSdkVersion Ihrer App 29
oder höher ist, müssen auch zusätzliche Änderungen unterstützt werden. Weitere Informationen finden Sie unter Änderungen des Verhaltens bei Apps mit Ausrichtung auf 29.
Hinweis : Zusätzlich zu den auf dieser Seite aufgeführten Änderungen bringt Android 10 zahlreiche datenschutzkonforme Änderungen und Einschränkungen mit sich, darunter:
- Hintergrundzugriff auf den Gerätestandort
- Beginn der Hintergrundaktivität
- Informationen zu gemeinsamen Interessen von Kontakten
- Zufällige Anordnung der MAC-Adresse
- Kamerametadaten
- Berechtigungsmodell
Diese Änderungen wirken sich auf alle Apps aus und verbessern den Datenschutz für Nutzer. Weitere Informationen dazu, wie du diese Änderungen unterstützen kannst, findest du auf der Seite Datenschutzänderungen.
Einschränkungen für Nicht-SDK-Schnittstellen
Um die Stabilität und Kompatibilität der App zu gewährleisten, hat die Plattform damit begonnen, festzulegen, welche Nicht-SDK-Schnittstellen deine 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 deine App nicht auf Android 10 (API-Level 29) ausgerichtet ist, betreffen dich einige dieser Änderungen möglicherweise nicht sofort. Sie können derzeit zwar einige Nicht-SDK-Schnittstellen verwenden (abhängig vom Ziel-API-Level Ihrer App), aber die Verwendung von Nicht-SDK-Methoden oder -Feldern birgt immer ein hohes Risiko für Probleme mit Ihrer App.
Wenn Sie sich nicht sicher sind, ob Ihre Anwendung Nicht-SDK-Schnittstellen verwendet, können Sie Ihre Anwendung testen, um das herauszufinden. Wenn Ihre App Nicht-SDK-Schnittstellen verwendet, sollten Sie mit der Planung einer Migration zu SDK-Alternativen beginnen. Trotzdem können einige Apps für die Verwendung von Nicht-SDK-Schnittstellen infrage kommen. 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 Aktualisierungen der 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 Gerät aktivieren. Wenn ein Nutzer die Bedienung über Gesten aktiviert, wirkt sich dies auf alle Apps auf dem Gerät aus, unabhängig davon, ob die App auf API-Level 29 ausgerichtet ist. Wenn der Nutzer beispielsweise vom Rand des Bildschirms nach unten 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 Gestensteuerung kompatibel ist, sollten Sie den App-Inhalt von Rand bis Rand erweitern und in Konflikt stehende Touch-Gesten entsprechend handhaben. Weitere Informationen finden Sie in der Dokumentation zu Gestensteuerung.
Logo: NDK
Android 10 umfasst die folgenden NDK-Änderungen.
Freigegebene Objekte dürfen keine Textverschiebungen enthalten
Unter Android 6.0 (API-Level 23) ist die Verwendung von Textverschiebungen in gemeinsam genutzten Objekten nicht zulässig. Code muss unverändert geladen werden und darf nicht geändert 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 die Gefahr, dass Fehler auftreten.
Änderungen an Bionic-Bibliotheken und dynamischen Verknüpfungspfaden
Ab Android 10 sind mehrere Pfade symbolische Links anstelle von regulären Dateien. Anwendungen, die darauf angewiesen sind, dass die Pfade normale Dateien sind, funktionieren möglicherweise nicht mehr:
/system/lib/libc.so
->/apex/com.android.runtime/lib/bionic/libc.so
/system/lib/libm.so
->/apex/com.android.runtime/lib/bionic/libm.so
/system/lib/libdl.so
->/apex/com.android.runtime/lib/bionic/libdl.so
/system/bin/linker
->/apex/com.android.runtime/bin/linker
Diese Änderungen gelten auch für die 64-Bit-Varianten der Datei, wobei lib/
durch lib64/
ersetzt wird.
Aus Kompatibilitätsgründen werden die Symlinks unter den alten Pfaden bereitgestellt. /system/lib/libc.so
ist z. B. ein Symlink für /apex/com.android.runtime/lib/bionic/libc.so
. dlopen(“/system/lib/libc.so”)
funktioniert also weiterhin, Apps werden jedoch einen Unterschied feststellen, wenn sie versuchen, die geladenen Bibliotheken tatsächlich durch Lesen von /proc/self/maps
oder ähnlich zu untersuchen. Dies ist nicht üblich. Wir haben jedoch 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ärprogramme/-bibliotheken, die dem Ausführungsspeicher zugeordnet sind
Ab Android 10 werden ausführbare Segmente der Binärdateien und Bibliotheken des Systems dem Arbeitsspeicher zugeordnet, der nur ausgeführt werden kann (nicht lesbar), um eine Härtungstechnik gegen Code-Wiederverwendungsangriffe zu gewährleisten. Wenn Ihre App Lesevorgänge in Speichersegmenten ausführt, die als „Nur Ausführung“ gekennzeichnet sind – sei es aufgrund von Programmfehlern, Sicherheitslücken oder beabsichtigter Speicherprüfung –, sendet das System ein SIGSEGV
-Signal an Ihre App.
Sie können feststellen, ob dieses Verhalten einen Absturz verursacht hat, indem Sie die zugehörige Tombstone-Datei in /data/tombstones/
untersuchen. Ein Absturz, der nur die Ausführung ermöglicht, enthält die folgende Abbruchmeldung:
Cause: execute-only (no-read) memory access error; likely due to data in .text.
Zur Umgehung dieses Problems bei der Durchführung von Vorgängen wie einer Speicherprüfung können Sie Segmente, die nur zum Ausführen ausgeführt werden, als Lesen + Ausführen markieren, indem Sie mprotect()
aufrufen. Wir empfehlen jedoch dringend, sie im Anschluss wieder auf „Nur ausführen“ zurückzusetzen, da diese Einstellung für die Zugriffsberechtigung einen besseren Schutz für Ihre Anwendung und Nutzer bietet.
Sicherheit
Android 10 umfasst die folgenden Sicherheitsänderungen.
TLS 1.3 ist standardmäßig aktiviert
Ab Android 10 ist TLS 1.3 standardmäßig für alle TLS-Verbindungen aktiviert. Hier sind einige wichtige Details zu unserer TLS 1.3-Implementierung:
- Die Cipher Suites von TLS 1.3 können nicht angepasst werden. Die unterstützten Cipher Suites von TLS 1.3 sind immer aktiviert, wenn TLS 1.3 aktiviert ist. Versuche, sie durch Aufrufen von
setEnabledCipherSuites()
zu deaktivieren, werden ignoriert. - Bei der Aushandlung von TLS 1.3 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. - Wenn
SSLEngine
-Instanzen unter älteren Android-Versionen einSSLHandshakeException
ausgeben, geben diese Instanzen unter Android 10 und höher stattdessen einSSLProtocolException
aus. - Der 0-RTT-Modus wird nicht unterstützt.
Bei Bedarf können Sie durch Aufrufen von SSLContext.getInstance("TLSv1.2")
eine SSLContext
abrufen, bei der TLS 1.3 deaktiviert ist.
Sie können Protokollversionen auch für einzelne Verbindungen aktivieren oder deaktivieren. Dazu rufen Sie setEnabledProtocols()
für ein entsprechendes Objekt auf.
Mit SHA-1 signierte Zertifikate sind in TLS nicht vertrauenswürdig
In Android 10 sind Zertifikate, die den SHA-1-Hash-Algorithmus verwenden, in TLS-Verbindungen nicht vertrauenswürdig. Root-Zertifizierungsstellen haben seit 2016 kein solches Zertifikat mehr ausgestellt und sie sind in Chrome und anderen wichtigen Browsern nicht mehr vertrauenswürdig.
Jeder Verbindungsversuch schlägt fehl, wenn die Verbindung zu einer Website führt, die ein SHA-1-Zertifikat bereitstellt.
Änderungen und Verbesserungen des KeyChain-Verhaltens
In einigen Browsern wie Google Chrome können Nutzer ein Zertifikat auswählen, wenn ein TLS-Server im Rahmen eines TLS-Handshakes eine Zertifikatanfragenachricht 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. Diese Eingabeaufforderung enthält insbesondere keine Auswahlmöglichkeiten, die nicht den Serverspezifikationen entsprechen.
Wenn keine vom Nutzer auswählbaren Zertifikate verfügbar sind, z. B. wenn keine Zertifikate mit der Serverspezifikation übereinstimmen oder auf einem Gerät keine Zertifikate installiert sind, wird keine Aufforderung zur Zertifikatsauswahl 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 bei TLS und Kryptografie
Es wurden mehrere kleinere Änderungen an den TLS- und Kryptografiebibliotheken unter Android 10 vorgenommen:
- Die Verschlüsselungen AES/GCM/NoPadding und ChaCha20/Poly1305/NoPadding geben genauere Puffergrößen aus
getOutputSize()
zurück. - Die Cipher Suite
TLS_FALLBACK_SCSV
wird bei Verbindungversuchen mit einem Max-Protokoll von TLS 1.2 oder höher weggelassen. Aufgrund von Verbesserungen bei den Implementierungen von TLS-Servern raten wir von einem TLS-externen Fallback ab. Stattdessen empfehlen wir, sich auf die Aushandlung der TLS-Version 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. - Intransparente Signaturschlüssel, z. B. aus dem Android-Schlüsselspeicher, 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:
Wenn deine App diese Broadcasts bei der Registrierung nur empfangen konnte, weil sie fixiert waren, verwende stattdessen bei der Initialisierung die entsprechende get()
-Methode, um die Informationen abzurufen.
Wi-Fi-Aware-Funktionen
Android 10 unterstützt jetzt die Erstellung von TCP/UDP-Sockets mit Wi-Fi-sensitiven Datenpfaden. Damit ein TCP/UDP-Socket mit einer ServerSocket
verbunden wird, muss das Clientgerät die IPv6-Adresse und den Port des Servers kennen. Dies musste bisher Out-of-Band übertragen werden, z. B. über BT oder Wi-Fi Aware Layer 2-Messaging oder mithilfe anderer Protokolle wie mDNS in Band erkannt werden. Unter 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 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 IPv6-Adresse und den vom Server bereitgestellten Port zu erhalten:
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 beim Zeichnen von Overlay-Fenstern übermäßig viel Arbeitsspeicher verbraucht wird, was die Leistung von Android-Geräten mit wenig Arbeitsspeicher besonders schadet.
Wenn eine App auf einem Gerät der Go-Edition mit Android 9 oder niedriger die Berechtigung SYSTEM_ALERT_WINDOW
erhält, behält die App die Berechtigung auch dann bei, wenn das Gerät auf Android 10 aktualisiert wird. Apps, die diese Berechtigung noch nicht haben, kann sie nach einem Upgrade des Geräts 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 zum Bildschirm Einstellungen weiter, auf dem er angezeigt wird, dass die Berechtigung aufgrund der Verlangsamung des Geräts nicht zulässig ist. 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
Geräte mit Android 10 oder höher warnen Nutzer, wenn sie zum ersten Mal eine App ausführen, die auf Android 5.1 (API-Level 22) oder niedriger ausgerichtet ist. Wenn für die App der Nutzer Berechtigungen erteilen 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 Nutzern diese Warnungen nur angezeigt, wenn sie eine App ausführen, die in letzter Zeit nicht aktualisiert wurde. Für Anwendungen, die über andere Stores vertrieben werden, gelten im Laufe des Jahres 2019 ähnliche Ziel-API-Anforderungen. 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-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 Cipher Suites sind weniger sicher als ähnliche Cipher Suites, die GCM verwenden. Die meisten Server unterstützen entweder die GCM- und die CBC-Varianten dieser Chiffresammlungen oder keine.
App-Nutzung
In Android 10 wurden folgende Änderungen am Verhalten der App-Nutzung vorgenommen:
UsageStats App-Nutzungsnutzung wird in - - wird in App-Nutzung in App -1 n-1 verwendet - Außerdem wird die Instant-App-Nutzung von Android 10 korrekt erfasst.
Graustufen pro App – eine Graustufen pro App.
Ablenkungsstatus pro App:
Sperrung und Wiedergabe – Android kann nicht wiedergegeben werden.
Änderungen der HTTPS-Verbindung
Wenn eine App mit Android 10 null
an setSSLSocketFactory()
übergibt, wird ein IllegalArgumentException
ausgelöst. 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 ab Android 10 eingestellt.
Entwickler sollten stattdessen die AndroidX-Präferenzbibliothek verwenden, die Teil von Android Jetpack ist. Weitere Ressourcen zur Unterstützung bei der Migration und Entwicklung finden Sie im aktualisierten Leitfaden für Einstellungen sowie in unserer öffentlichen Beispiel-App und in unserer Referenzdokumentation.
Änderungen an der Dienstprogrammbibliothek für ZIP-Dateien
Mit Android 10 werden die folgenden Änderungen an Klassen im Paket java.util.zip
eingeführt, das ZIP-Dateien verarbeitet. Durch diese Änderungen wird das Verhalten der Bibliothek unter Android und anderen Plattformen, die java.util.zip
verwenden, einheitlicher.
Luftpumpe
In früheren Versionen haben einige Methoden in der Klasse Inflater
eine IllegalStateException
ausgelöst, wenn sie nach einem Aufruf von end()
aufgerufen wurden.
In Android 10 geben diese Methoden stattdessen ein 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 gibt die Methode finish()
in ZipOutputStream
keinen ZipException
aus, wenn sie versucht, einen Ausgabestream für eine ZIP-Datei zu schreiben, die keine Dateien enthält.
Kameraänderungen
Bei vielen kamerabasierten Apps wird davon ausgegangen, dass sich das physische Gerät auch im Hochformat befindet, wenn sich das Gerät 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, wie z. B. faltbarer Smartphones, 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, sollten Sie explizit android:resizeableActivity
festlegen und die erforderlichen Funktionen für den Mehrfensterbetrieb bereitstellen.
Tracking der Akkunutzung
Ab Android 10 setzt SystemHealthManager
die Statistiken zur Akkunutzung zurück, sobald das Gerät nach einem wichtigen Ladeereignis vom Stromnetz getrennt wurde. Im Großen und Ganzen besteht ein wichtiges Ladeereignis entweder: Das Gerät ist vollständig aufgeladen oder es ist nicht mehr ausreichend entleert, sondern fast vollständig aufgeladen.
Vor Android 10 wurden die Statistiken zur Akkunutzung immer zurückgesetzt, wenn das Gerät vom Stromnetz getrennt wurde, unabhängig davon, wie wenig sich der Akkustand verändert hatte.
Einstellung von Android Beam
In Android 10 wird die ältere Funktion Android Beam zur Initiierung der geräteübergreifenden Datenfreigabe über die Nahfeldkommunikation (NFC) offiziell eingestellt. Außerdem stellen wir einige der zugehörigen NFC APIs ein. Android Beam bleibt 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 aus Tags und Zahlungen funktionieren weiterhin wie erwartet.
Verhaltensänderung bei java.math.BigDecimal.stripTrailingZeros()
BigDecimal.stripTrailingZeros()
behält nachgestellte Nullen nicht mehr als Sonderfall bei, wenn der Eingabewert Null ist.
Verhaltensänderungen für „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 der Breite Null vorliegt. Dies betrifft auch String.split()
. Beispielsweise gibt "x".split("")
jetzt {"x"}
zurück, während früher in älteren Android-Versionen {"", "x"}
zurückgegeben wurde.
"aardvark".split("(?=a)"
gibt jetzt {"a", "ardv", "ark"}
anstelle von {"", "a", "ardv", "ark"}
zurück.
Das Ausnahmeverhalten für ungültige Argumente wurde ebenfalls verbessert:
appendReplacement(StringBuffer, String)
gibt jetzt einenIllegalArgumentException
anstelle vonIndexOutOfBoundsException
aus, wenn der Ersatz-String
mit einem einzigen umgekehrten Schrägstrich endet, was nicht zulässig ist. Dieselbe Ausnahme wird jetzt ausgelöst, wenn der Ersatz-String
mit einem$
endet. Zuvor wurde in diesem Szenario keine Ausnahme ausgegeben.replaceFirst(null)
ruft nicht mehrreset()
für dieMatcher
auf, wenn einNullPointerException
ausgegeben wird.NullPointerException
wird jetzt auch ausgelöst, wenn es keine Übereinstimmung gibt. Bisher wurde sie nur bei einem Match geworfen.start(int group)
,end(int group)
undgroup(int group)
geben jetzt einen allgemeinerenIndexOutOfBoundsException
aus, wenn der Gruppenindex außerhalb des Bereichs liegt. Zuvor haben diese MethodenArrayIndexOutOfBoundsException
ausgelöst.
Der Standardwinkel für GradientDrawable ist jetzt TOP_BOTTOM
Wenn Sie in Android 10 eine GradientDrawable
in XML definieren und keine Winkelmessung angeben, wird die Ausrichtung des Gradienten standardmäßig auf TOP_BOTTOM
festgelegt.
Dies ist eine Änderung gegenüber früheren Android-Versionen, bei denen standardmäßig LEFT_RIGHT
verwendet wurde.
Wenn Sie auf die neueste Version von AAPT2 aktualisieren, legt das Tool als Behelfslösung für Legacy-Apps einen Winkelmesswert von 0 fest, wenn keine Winkelmessung angegeben ist.
Logging für serielle Objekte mit Standard-SUID
Ab Android 7.0 (API-Level 24) wurde auf der Plattform die Standard-serialVersionUID
für serielle Objekte korrigiert. Diese Fehlerkorrektur hatte keine Auswirkungen auf 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 dem alten, falschen, standardmäßigen serialVersionUID
basiert, protokolliert das System eine Warnung und schlägt eine Code-Korrektur vor.
Insbesondere wird eine Warnung protokolliert, wenn alle der folgenden Bedingungen erfüllt sind:
- Die App ist auf API-Level 23 oder niedriger ausgerichtet.
- Eine Klasse ist seriell.
- Die serielle Klasse verwendet den Standard-
serialVersionUID
, anstatt explizit einenserialVersionUID
festzulegen. - Die standardmäßige
serialVersionUID
unterscheidet sich von derserialVersionUID
, wenn die App auf API-Level 24 oder höher ausgerichtet ist.
Diese Warnung wird für jede betroffene Klasse einmal protokolliert.
Die Warnmeldung enthält eine vorgeschlagene Korrektur, bei der serialVersionUID
explizit auf den Standardwert gesetzt wird, 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 App, die auf API-Level 23 oder niedriger ausgerichtet ist, das Objekt 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-Standarddateien wie /dev/zero
, deren Größe nicht mit truncate()
geändert werden kann, nicht mehr unterstützt. Frühere Versionen von Android haben den von truncate()
zurückgegebenen Fehler verschluckt, aber Android 10 löst eine IOException aus. Wenn Sie das alte Verhalten benötigen, müssen Sie nativen Code verwenden.