Verhaltensänderungen: Apps, die auf API 29 und höher ausgerichtet sind

Unter Android 10 wurden aktualisierte Änderungen des Systemverhaltens vorgenommen, 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 setzt, sollten Sie sie gegebenenfalls so ändern, dass dieses Verhalten ordnungsgemäß unterstützt wird.

Sehen Sie sich unbedingt auch die Liste der Verhaltensänderungen an, die sich auf alle Apps unter Android 10 auswirken.

Hinweis : Zusätzlich zu den auf dieser Seite aufgeführten Änderungen bringt Android 10 zahlreiche datenschutzkonforme Änderungen und Einschränkungen mit sich, darunter:

• Begrenzter Speicher
• Zugriff auf die Seriennummer des USB-Geräts
• WLAN aktivieren, deaktivieren und konfigurieren
• Berechtigungen zur Standortermittlung für Verbindungs-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 du diese Änderungen unterstützen kannst, findest du auf der Seite Datenschutzänderungen.

Updates zu 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.

Geteilte Erinnerung

Ashmem hat das Format von Dalvik-Karten in /proc/<pid>/maps geändert, was sich auf Anwendungen auswirkt, die die Kartendatei direkt parsen. Anwendungsentwickler sollten das Format /proc/<pid>/maps auf Geräten mit Android 10 oder höher testen und entsprechend parsen, wenn die App von Dalvik-Kartenformaten abhängig ist.

Apps, die auf Android 10 ausgerichtet sind, können ashmem (/dev/ashmem) nicht direkt verwenden und müssen stattdessen über die ASharedMemory-Klasse der NDK auf den freigegebenen Speicher zugreifen. Darüber hinaus können Anwendungen keine direkten IOCTLs zu vorhandenen Ashmem-Dateideskriptoren erstellen. Stattdessen müssen sie zum Erstellen von Regionen mit gemeinsam genutztem Arbeitsspeicher entweder die ASharedMemory-Klasse des NDK oder die Android Java APIs verwenden. Diese Änderung erhöht die Sicherheit und Robustheit beim Arbeiten mit gemeinsam genutztem Speicher, wodurch die Leistung und Sicherheit von Android insgesamt verbessert wird.

Ausführungsberechtigung für das Stammverzeichnis der App entfernt

Die Ausführung von Dateien aus dem Basisverzeichnis der beschreibbaren Anwendung stellt einen W^X-Verstoß dar. 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.

Außerdem können Apps, die auf Android 10 ausgerichtet sind, keinen ausführbaren Code aus Dateien ändern, die mit dlopen() geöffnet wurden, und erwarten, dass diese Änderungen auf das Laufwerk geschrieben werden, da die Bibliothek PROT_EXEC nicht über einen beschreibbaren Dateideskriptor zugeordnet werden konnte. Dies schließt alle freigegebenen Objektdateien (.so) mit Textverschiebungen ein.

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

Die Android-Laufzeit (ART) ruft dex2oat nicht mehr aus dem Anwendungsprozess auf. Diese Änderung bedeutet, dass ART nur OAT-Dateien akzeptiert, die vom System generiert wurden.

AOT-Richtigkeit in ART erzwingen

In der Vergangenheit konnte die vorzeitige Kompilierung (AOT) durch die Android Runtime (ART) zu Laufzeitabstürzen führen, wenn die Klassenpfadumgebung bei der Kompilierungszeit und der Laufzeit nicht dieselbe war. Bei Android 10 und höher müssen diese Umgebungskontexte immer gleich sein, was zu folgenden Verhaltensänderungen führt:

• Benutzerdefinierte Klassenladeprogramme, d. h. Klassenladeprogramme, die von Apps geschrieben werden, werden im Gegensatz zu Klassenladeprogrammen aus dem Paket dalvik.system nicht über AOT kompiliert. Das liegt daran, dass ART die Implementierung des benutzerdefinierten Klassen-Lookups zur Laufzeit nicht kennen kann.
• Sekundäre DEX-Dateien, d. h. die von Apps, die nicht im primären APK nicht enthaltenen, manuell geladen werden, werden im Hintergrund AOT-kompiliert. Das liegt daran, dass die Kompilierung bei der ersten Verwendung zu teuer sein kann, was zu einer unerwünschten Latenz vor der Ausführung führt. Beachten Sie, dass für Anwendungen empfohlen wird, Splits zu verwenden und sich von sekundären DEX-Dateien zu entfernen.
• Gemeinsam genutzte Bibliotheken unter Android (die Einträge <library> und <uses-library> in einem Android-Manifest) werden mit einer anderen Hierarchie des Klassenladeprogramms implementiert als in früheren Versionen der Plattform.

Berechtigungsänderungen für Fullscreen-Intents

Apps, die auf Android 10 oder höher ausgerichtet sind und Benachrichtigungen mit Vollbild-Intents verwenden, müssen in der Manifestdatei der App die Berechtigung USE_FULL_SCREEN_INTENT anfordern. Dies ist eine normale Berechtigung, die vom System der anfragenden App automatisch erteilt wird.

Wenn eine App für Android 10 oder höher 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 für faltbare Smartphones

Bei Android 10 gibt es Änderungen, die faltbare Smartphones 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 Mehrfenstermodus angezeigt werden, befinden sich alle fokussierbaren Top-Aktivitäten in sichtbaren Stacks im fortgesetzten Status, aber nur eine davon, die „höchste fortgesetzte“ Aktivität, liegt im Fokus. Bei Versionen vor Android 10 kann immer nur eine Aktivität im System gleichzeitig fortgesetzt werden. Alle anderen sichtbaren Aktivitäten werden pausiert.

Verwechseln Sie „Fokus“ nicht mit der Aktivität „Zuletzt fortgesetzt“. 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 fortgesetzt, aber nicht im Fokus sein (z. B. wenn die Benachrichtigungsleiste maximiert ist).

Unter Android 10 (API-Level 29) und höher können Sie den onTopResumedActivityChanged()-Callback abonnieren, um benachrichtigt zu werden, wenn Ihre Aktivität die höchste fortgesetzte Position erreicht oder verliert. Dies entspricht dem Status „Fortsetzen“ vor Android 10 und kann als Hinweis nützlich sein, wenn Ihre App exklusive oder Singleton-Ressourcen verwendet, die möglicherweise für andere Apps freigegeben werden müssen.

Das Verhalten des Manifestattributs resizeableActivity hat sich ebenfalls geändert. Wenn eine App in Android 10 (API-Level 29) oder höher die Option resizeableActivity=false festlegt, wird sie möglicherweise in den Kompatibilitätsmodus versetzt, wenn sich die verfügbare Bildschirmgröße ändert oder wenn die App von einem Bildschirm zum anderen wechselt.

Apps können mit dem in Android 10 eingeführten Attribut android:minAspectRatio die Bildschirmverhältnisse angeben, die von deiner App unterstützt werden.

Ab Version 3.5 enthält 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 Smartphones und Tablets entwickeln.