Android 10 enthält aktualisierte Änderungen am Systemverhalten, die sich auf deine App auswirken können. Die auf dieser Seite aufgeführten Änderungen gelten ausschließlich für Apps, die auf API 29 oder höher ausgerichtet sind. Wenn Ihre Anwendung targetSdkVersion auf „29“ oder höher festlegt, sollten Sie Ihre Anwendung gegebenenfalls anpassen, damit diese Verhaltensweisen korrekt unterstützt werden.
Sieh dir auch die Liste der Verhaltensänderungen an, die alle Apps unter Android 10 betreffen.
Hinweis : Zusätzlich zu den auf dieser Seite aufgeführten Änderungen werden mit Android 10 zahlreiche datenschutzbasierte Änderungen und Einschränkungen eingeführt, darunter:
- Begrenzter Speicher
- Zugriff auf die Seriennummer des USB-Geräts
- Möglichkeit, WLAN zu aktivieren, zu deaktivieren und zu konfigurieren
- Berechtigungen zur Standortermittlung für Konnektivitäts-APIs
Diese Änderungen, die sich auf Apps auswirken, die auf API-Level 29 oder höher ausgerichtet sind, verbessern den Datenschutz für Nutzer. Weitere Informationen dazu, wie Sie diese Änderungen umsetzen können, finden Sie auf der Seite Änderungen beim Datenschutz.
Aktualisierungen von 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.
Geteilte Erinnerung
Ashmem hat das Format von Dalvik-Karten in /proc/<pid>/maps geändert. Dies betrifft Apps, die die Kartendatei direkt parsen. Anwendungsentwickler sollten das /proc/<pid>/maps-Format auf Geräten mit Android 10 oder höher testen und entsprechend parsen, wenn die App von Dalvik-Kartenformaten abhängt.
Apps, die auf Android 10 ausgerichtet sind, können Ashmem (/dev/ashmem) nicht direkt verwenden und müssen stattdessen über die ASharedMemory-Klasse des NDK auf gemeinsamen Speicher zugreifen.
Außerdem können Anwendungen keine direkten IOCTLs an vorhandene Ashmem-Dateideskriptoren erstellen. Stattdessen müssen sie entweder die Klasse ASharedMemory des NDK oder die Android Java APIs zum Erstellen von Regionen im gemeinsamen Arbeitsspeicher verwenden. Diese Änderung erhöht die Sicherheit und Stabilität bei der Arbeit mit gemeinsam genutztem Speicher, was die Leistung und Sicherheit von Android insgesamt verbessert.
Ausführungsberechtigung für Basisverzeichnis der App entfernt
Die Ausführung von Dateien aus dem beschreibbaren Basisverzeichnis der Anwendung ist ein W^X-Verstoß. Apps sollten nur den Binärcode laden, der in der APK-Datei einer App eingebettet ist.
Nicht vertrauenswürdige Apps, die auf Android 10 ausgerichtet sind, können execve() nicht direkt für Dateien im Basisverzeichnis der App aufrufen.
Apps, die auf Android 10 ausgerichtet sind, können außerdem keinen ausführbaren Code aus Dateien, die mit dlopen() geöffnet wurden, im Arbeitsspeicher ändern und erwarten, dass diese Änderungen auf das Laufwerk geschrieben werden, da die Bibliothek nicht über einen beschreibbaren Dateideskriptor PROT_EXEC zugeordnet werden kann. Dies gilt auch für Dateien mit freigegebenen Objekten (.so) mit Textverschiebungen.
Die Android-Laufzeit akzeptiert nur vom System generierte OAT-Dateien
Die Android-Laufzeit (ART) ruft dex2oat nicht mehr über den Anwendungsprozess auf. Diese Änderung bedeutet, dass die ART nur OAT-Dateien akzeptiert, die vom System generiert wurden.
AOT-Richtigkeit in ART erzwingen
In der Vergangenheit konnte die von der Android Runtime (ART) durchgeführte Kompilierung im Voraus (AOT) zu Laufzeitabstürzen führen, wenn die Klassenpfadumgebung zum Kompilierenzeitpunkt und der Laufzeit nicht dieselbe war. Ab Android 10 müssen diese Umgebungskontexte immer identisch sein, was zu folgenden Verhaltensänderungen führt:
- Benutzerdefinierte Klassenladeprogramme – d. h. von Apps geschriebene Klassenladeprogramme – werden im Gegensatz zu Klassenladeprogrammen aus dem
dalvik.system-Paket nicht AOT-kompiliert. Das liegt daran, dass ART die Implementierung der benutzerdefinierten Klassensuche zur Laufzeit nicht kennt. - Sekundäre DEX-Dateien, also die manuell von Apps geladenen DEX-Dateien, die nicht im primären APK enthalten sind, werden im Hintergrund AOT-kompiliert. Das liegt daran, dass die Kompilierung bei der ersten Verwendung zu teuer sein kann, was zu unerwünschter Latenz vor der Ausführung führt. Für Anwendungen wird empfohlen, Splits zu verwenden und sekundäre DEX-Dateien zu entfernen.
- Gemeinsam genutzte Bibliotheken in Android (die Einträge <library> und <uses-library> in einem Android-Manifest) werden in einer anderen Klassenladehierarchie implementiert als in früheren Versionen der Plattform.
Änderungen an Berechtigungen für Fullscreen-Intents
Apps, die auf Android 10 oder höher ausgerichtet sind und Benachrichtigungen mit Vollbild-Intents verwenden, müssen die Berechtigung USE_FULL_SCREEN_INTENT in der Manifestdatei ihrer App anfordern. Da es sich hierbei um eine normale Berechtigung handelt, wird sie vom System der anfragenden App automatisch zugewiesen.
Wenn eine App, die auf Android 10 oder höher ausgerichtet ist, versucht, eine Benachrichtigung mit einem Fullscreen-Intent zu erstellen, ohne die erforderliche Berechtigung anzufordern, ignoriert das System den Fullscreen-Intent und gibt die folgende Lognachricht aus:
Package your-package-name: Use of fullScreenIntent requires the USE_FULL_SCREEN_INTENT permission
Unterstützung faltbarer Geräte
Unter Android 10 gibt es Änderungen, die faltbare Geräte und Geräte mit großem Display unterstützen.
Wenn eine App unter Android 10 ausgeführt wird, funktionieren die Methoden onResume() und onPause() unterschiedlich. Wenn mehrere Apps gleichzeitig im Mehrfenster- oder Multi-Display-Modus erscheinen, befinden sich alle fokussierbaren Top-Aktivitäten in sichtbaren Stacks im Status „Fortsetzen“, aber nur eine von ihnen, die „höchste fortgesetzte“ Aktivität, hat den Fokus. Bei älteren Versionen als Android 10 kann immer nur eine einzelne Aktivität im System fortgesetzt werden. Alle anderen sichtbaren Aktivitäten werden pausiert.
Verwechseln Sie „Fokus“ nicht mit der „höchsten fortgesetzten“ Aktivität. Das System weist Aktivitäten basierend auf der Z-Reihenfolge Prioritäten zu, um den Aktivitäten, mit denen der Nutzer zuletzt interagiert hat, eine höhere Priorität zu verleihen. Eine Aktivität kann oben fortgesetzt werden, aber nicht im Fokus stehen (z. B. wenn die Benachrichtigungsleiste maximiert wird).
Unter Android 10 (API-Level 29) und höher können Sie den onTopResumedActivityChanged()-Callback abonnieren. Sie werden dann benachrichtigt, wenn Ihre Aktivität die höchste fortgesetzte Position erreicht oder verliert. Dies entspricht dem Status „Fortsetzen“ vor Android 10 und kann als Hinweis dienen, wenn Ihre App exklusive oder Singleton-Ressourcen verwendet, die möglicherweise mit anderen Apps geteilt werden müssen.
Das Verhalten des Manifestattributs resizeableActivity hat sich ebenfalls geändert. Wenn eine App resizeableActivity=false unter Android 10 (API-Level 29) oder höher festlegt, wird sie möglicherweise in den Kompatibilitätsmodus versetzt, wenn sich die verfügbare Bildschirmgröße ändert oder die App von einem Bildschirm zu einem anderen wechselt.
Apps können das in Android 10 eingeführte Attribut android:minAspectRatio verwenden, um die Bildschirmverhältnisse anzugeben, die von deiner App unterstützt werden.
Ab Version 3.5 umfasst das Emulator-Tool von Android Studio virtuelle 7,3"- und 8"-Geräte, mit denen Sie Ihren Code auf größeren Bildschirmen testen können.
Weitere Informationen finden Sie unter Apps für faltbare Geräte entwickeln.