Verhaltensänderungen: Apps, die auf API 29+ ausgerichtet sind

Unter Android 10 wurden Änderungen am Systemverhalten vorgenommen, die sich auf deine App auswirken können. Die auf dieser Seite aufgeführten Änderungen gelten ausschließlich für Apps mit Ausrichtung auf API 29 oder höher. Wenn deine App targetSdkVersion auf „29“ festlegt oder sollten Sie Ihre App an diese Verhaltensweisen anpassen, sofern zutreffend.

Sehen Sie sich auch die Liste der Verhaltensänderungen an, die alle Apps betreffen mit Android 10.

Aktualisierungen von Einschränkungen für Nicht-SDK-Schnittstellen

Um die Stabilität und Kompatibilität der Apps sicherzustellen, wurden Einschränkungen mit denen Nicht-SDK-Schnittstellen deine App unter Android 9 (API-Level 28) verwenden kann. Android 10 enthält aktualisierte Listen eingeschränkter Nicht-SDK-Schnittstellen basierend auf der Zusammenarbeit mit Android-Entwicklern und die neuesten internen Tests. Unser Ziel ist es, Alternativen sind verfügbar, bevor wir Nicht-SDK-Schnittstellen einschränken.

Wenn deine App nicht auf Android 10 (API-Level 29) ausgerichtet ist, gibt es einige dieser Änderungen nicht sofort betreffen. Obwohl Sie derzeit einige Nicht-SDK-Schnittstellen (abhängig vom Ziel-API-Level Ihrer App) die Verwendung einer Nicht-SDK-Methode oder eines Nicht-SDK-Felds birgt immer ein hohes Risiko, dass Ihre

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 Planung auf SDK-Alternativen umstellen. Dennoch ist uns bewusst, dass einige Apps Anwendungsfälle für die Verwendung von Nicht-SDK-Schnittstellen. Wenn Sie keine Alternative finden eine Nicht-SDK-Schnittstelle für eine Funktion in Ihrer App nutzen, Neue öffentliche API anfordern

Weitere Informationen findest du unter Updates zu Einschränkungen für Nicht-SDK-Schnittstellen in Android 10. und siehe Einschränkungen für Nicht-SDK-Schnittstellen.

Geteilte Erinnerung

Ashmem hat das Format von Dalvik-Karten in /proc/<pid>/maps geändert. und betrifft Apps, die die Kartendatei direkt parsen. App-Entwickler sollten das Format „/proc/<pid>/maps“ auf Geräten mit Android 10 oder höher testen und entsprechend parsen, wenn die App von Dalvik-Map-Formaten abhängt.

Für Android 10 ausgerichtete Apps können Ashmem nicht direkt verwenden (/dev/ashmem) und müssen stattdessen über die ASharedMemory-Klasse. Außerdem können Apps keine direkten IOCTLs an vorhandene Ashmem-Dateideskriptoren erstellen. Stattdessen muss entweder die ASharedMemory-Klasse des NDK oder die Android-Java- APIs zum Erstellen von Regionen im gemeinsamen Arbeitsspeicher Diese Änderung erhöht die Sicherheit und Robustheit bei der Arbeit mit gemeinsam genutztem Arbeitsspeicher, wodurch Leistung und Sicherheit verbessert werden von Android insgesamt.

Ausführungsberechtigung für Basisverzeichnis der App entfernt

Die Ausführung von Dateien aus dem beschreibbaren Basisverzeichnis der App 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 aufrufen direkt für Dateien im Basisverzeichnis der App.

Außerdem können Apps, die auf Android 10 ausgerichtet sind, ausführbaren Code aus Dateien, die mit dlopen() geöffnet wurden, nicht im Arbeitsspeicher ändern und erwarten, dass diese Änderungen auf die Festplatte geschrieben werden, da die Bibliothek nicht über einen beschreibbaren Dateideskriptor PROT_EXEC zugeordnet werden kann. Dazu gehören alle Dateien mit gemeinsam genutzten Objekten (.so) mit Textverschiebungen

Die Android-Laufzeit akzeptiert nur vom System generierte OAT-Dateien

Die Android-Laufzeit (ART) ruft dex2oat nicht mehr über die Anwendung auf . Diese Änderung bedeutet, dass ART nur OAT-Dateien akzeptiert, die vom generiert hat.

AOT-Korrektheit in ART erzwingen

Früher wurde die von Android-Geräten durchgeführte Kompilierung im Voraus Laufzeit (ART) konnte zu Laufzeitabstürzen führen, wenn die Klassenpfadumgebung nicht bei der Kompilierungszeit und der Laufzeit identisch. Unter Android 10 und höher müssen diese Umgebungskontexte immer gleich sein. Dies führt zu den folgenden Verhaltensänderungen:

• Benutzerdefinierte Lader, also von Apps geschriebene Lader, werden im Gegensatz zu Ladern aus dem Paket dalvik.system nicht AOT-kompiliert. Das liegt daran, dass ART zur Laufzeit nicht über die benutzerdefinierte Implementierung der Klassensuche Bescheid weiß.
• Sekundäre DEX-Dateien – d. h. die manuell von Apps geladenen DEX-Dateien, die nicht im primäres APK, werden im Hintergrund per AOT kompiliert. Das liegt daran, dass die Erstnutzung kann die Kompilierung zu teuer sein, was zu unerwünschter Latenz Ausführung. Beachten Sie, dass es bei Apps die Aufteilung von Splits und die Abkehr von sekundären DEX-Dateien werden empfohlen.
• Freigegebene Bibliotheken in Android (die Einträge <library> und <uses-library> in einem Android-Manifest) werden mit einer anderen Hierarchie des Klassenladers 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 müssen die USE_FULL_SCREEN_INTENT in der Manifest-Datei der App. Da es sich um eine normale Berechtigung handelt, wird sie der anfragenden App automatisch gewährt.

Wenn eine App, die auf Android 10 oder höher ausgerichtet ist, versucht, eine Benachrichtigung mit einem Full-Screen-Intent zu erstellen, ohne die erforderliche Berechtigung anzufordern, ignoriert das System den Full-Screen-Intent und gibt die folgende Protokollmeldung 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 läuft, onResume() und onPause()-Methoden funktionieren unterschiedlich. Wenn mehrere Apps gleichzeitig im Mehrfenstermodus oder Multi-Display-Modus, alle fokussierbaren Top-Aktivitäten in sichtbaren Stacks wieder aktiviert sind, aber nur eine davon, die „höchste fortgesetzt“, Aktivitäten, der Fokus liegt. Bei älteren Versionen als Android 10 wird nur eine können einzelne Aktivitäten im System fortgesetzt werden, alle anderen sichtbaren Aktivitäten pausiert sind.

„Fokus“ nicht verwechseln mit dem „höchsten fortgesetzt“ Aktivitäten. Das System weist der Prioritäten zu Aktivitäten basierend auf der Z-Reihenfolge, um den die Aktivitäten, mit denen der Nutzer zuletzt interagiert hat. Eine Aktivität kann oben fortgesetzt, aber nicht im Fokus (wenn beispielsweise die Benachrichtigungsleiste maximiert).

Unter Android 10 (API-Level 29) und höher können Sie den onTopResumedActivityChanged()-Callback um benachrichtigt zu werden, wenn Ihre Aktivität die oberste . Dies entspricht dem Status „Fortsetzen“ vor Android 10 und kann nützlich sein. um zu sehen, ob Ihre App exklusive oder Singleton-Ressourcen verwendet, die möglicherweise die mit anderen Apps geteilt werden.

Auch das Verhalten des Manifestattributs resizeableActivity hat sich geändert. Wenn eine App resizeableActivity=false unter Android 10 (API-Level 29) oder höher verwenden, wird möglicherweise in den Kompatibilitätsmodus versetzt wenn sich die verfügbare Bildschirmgröße ändert oder die App von einem Bildschirm eine andere.

Apps können die android:minAspectRatio das in Android 10 eingeführt wurde, um den Bildschirm Seitenverhältnisse, die Ihre App unterstützt.

Ab Version 3.5 enthält das Emulator-Tool von Android Studio virtuelle Geräte mit einem Bildschirm von 7,3 Zoll und 8 Zoll, um Ihren Code auf größeren Bildschirmen zu testen.

Weitere Informationen finden Sie unter Apps für faltbare Geräte entwickeln.