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

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 in deiner App targetSdkVersion auf „29“ oder höher festgelegt ist, solltest du sie so anpassen, dass diese Verhaltensweisen gegebenenfalls unterstützt werden.

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

Hinweis : Zusätzlich zu den auf dieser Seite aufgeführten Änderungen werden mit Android 10 zahlreiche datenschutzbezogene Änderungen und Einschränkungen eingeführt, darunter:

  • Begrenzter Speicher
  • Zugriff auf die Seriennummer des USB-Geräts
  • WLAN aktivieren, deaktivieren und konfigurieren
  • Berechtigungen zur Standortermittlung für Konnektivitäts-APIs

Diese Änderungen, die sich auf Apps mit dem Ziel-API-Level 29 oder höher auswirken, verbessern den Datenschutz für Nutzer. Weitere Informationen dazu, wie Sie diese Änderungen unterstützen können, finden Sie auf der Seite Datenschutzänderungen.

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

Um die Stabilität und Kompatibilität von Apps zu gewährleisten, wurde mit Android 9 (API-Level 28) damit begonnen, die Verwendung von Nicht-SDK-Schnittstellen durch Apps einzuschränken. 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 du nicht auf Android 10 (API-Level 29) abzielst, betreffen dich einige dieser Änderungen möglicherweise nicht sofort. Derzeit können Sie zwar einige Nicht-SDK-Schnittstellen verwenden (abhängig vom 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 auf Nicht-SDK-Schnittstellen basiert, sollten Sie mit der Planung einer Migration zu SDK-Alternativen beginnen. Wir wissen jedoch, dass es für einige Apps gültige Anwendungsfälle für die Verwendung von Nicht-SDK-Schnittstellen gibt. Wenn Sie keine Alternative zur Verwendung einer Nicht-SDK-Schnittstelle für eine Funktion in Ihrer App finden, sollten Sie eine neue öffentliche API anfordern.

Weitere Informationen finden Sie unter Updates to non-SDK interface restrictions in Android 10 und Restrictions on non-SDK interfaces.

Gemeinsamer Speicher

Ashmem hat das Format von Dalvik-Maps in /proc/<pid>/maps geändert, was sich auf Apps auswirkt, die die Maps-Datei 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-Zuordnungsformaten abhängt.

Apps, die auf Android 10 ausgerichtet sind, können ashmem (/dev/ashmem) nicht direkt verwenden. Stattdessen müssen sie über die ASharedMemory-Klasse des NDK auf den freigegebenen Speicher zugreifen. Außerdem können Apps keine direkten IOCTLs für vorhandene ashmem-Dateideskriptoren erstellen. Stattdessen müssen sie entweder die ASharedMemory-Klasse des NDK oder die Android Java APIs verwenden, um gemeinsam genutzte Speicherbereiche zu erstellen. Diese Änderung erhöht die Sicherheit und Robustheit bei der Arbeit mit gemeinsam genutztem Speicher und verbessert die Leistung und Sicherheit von Android insgesamt.

Ausführungsberechtigung für das Basisverzeichnis der App entfernt

Das Ausführen von Dateien direkt vom beschreibbaren App-Home-Verzeichnis aus 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 Home-Verzeichnis der App aufrufen.

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

Android Runtime akzeptiert nur systemgenerierte 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-Korrektheit in ART erzwingen

In der Vergangenheit konnte die Ahead-of-Time-Kompilierung (AOT) durch die Android Runtime (ART) zu Laufzeitabstürzen führen, wenn die Klassenpfadumgebung zur Kompilierzeit und zur Laufzeit nicht identisch war. Unter Android 10 und höher müssen diese Umgebungskontexte immer identisch sein. Das führt zu folgenden Verhaltensänderungen:

  • Benutzerdefinierte Klassenlader, d. h. von Anwendungen geschriebene Klassenlader, werden im Gegensatz zu Klassenladern aus dem Paket dalvik.system nicht AOT-kompiliert. Das liegt daran, dass ART die benutzerdefinierte Implementierung der Klassensuche zur Laufzeit nicht kennt.
  • Sekundäre DEX-Dateien, also DEX-Dateien, die manuell von Apps geladen werden, die sich nicht im primären APK befinden, werden im Hintergrund AOT-kompiliert. Das liegt daran, dass die Kompilierung bei der ersten Verwendung möglicherweise zu aufwendig ist, was zu unerwünschter Latenz vor der Ausführung führt. Für Apps wird empfohlen, Splits zu verwenden und keine sekundären DEX-Dateien mehr zu nutzen.
  • Gemeinsam genutzte Bibliotheken in Android (die Einträge <library> und <uses-library> in einem Android-Manifest) werden mit einer anderen Klassenladerhierarchie implementiert als in früheren Versionen der Plattform.

Änderungen der Berechtigungen für Vollbild-Intents

Apps, die auf Android 10 oder höher ausgerichtet sind und Benachrichtigungen mit Full-Screen Intents verwenden, müssen die Berechtigung USE_FULL_SCREEN_INTENT in der Manifestdatei ihrer App anfordern. Dies ist eine normale Berechtigung, die das System der anfragenden App automatisch gewährt.

Wenn eine App, die auf Android 10 oder höher ausgerichtet ist, versucht, eine Benachrichtigung mit einem Vollbild-Intent zu erstellen, ohne die erforderliche Berechtigung anzufordern, ignoriert das System den Vollbild-Intent und gibt die folgende Protokollnachricht aus:

Package your-package-name: Use of fullScreenIntent requires the USE_FULL_SCREEN_INTENT permission

Unterstützung für faltbare Geräte

Android 10 enthält Änderungen, die faltbare Geräte und Geräte mit großen Displays unterstützen.

Wenn eine App unter Android 10 ausgeführt wird, funktionieren die Methoden onResume() und onPause() anders. Wenn mehrere Apps gleichzeitig im Multi-Window- oder Multi-Display-Modus angezeigt werden, befinden sich alle fokussierbaren Top-Aktivitäten in sichtbaren Stapeln im Status „RESUMED“, aber nur eine davon, die „oberste fortgesetzte“ Aktivität, hat tatsächlich den Fokus. Bei Versionen vor Android 10 kann jeweils nur eine einzelne Aktivität im System fortgesetzt werden. Alle anderen sichtbaren Aktivitäten werden pausiert.

Verwechseln Sie „Fokus“ nicht mit der Aktivität „topmost resumed“. Das System weist Aktivitäten Prioritäten basierend auf der Z-Reihenfolge zu, um den Aktivitäten, mit denen der Nutzer zuletzt interagiert hat, eine höhere Priorität zu geben. Eine Aktivität kann „top-resumed“ sein, aber nicht den Fokus haben (z. B. wenn die Benachrichtigungsleiste maximiert ist).

In Android 10 (API-Level 29) und höher können Sie den Callback onTopResumedActivityChanged() abonnieren, um benachrichtigt zu werden, wenn Ihre Aktivität die oberste fortgesetzte Position erhält oder verliert. Dies entspricht dem Status „Fortgesetzt“ vor Android 10 und kann nützlich sein, 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 unter Android 10 (API-Level 29) oder höher resizeableActivity=false festlegt, wird sie möglicherweise in den Kompatibilitätsmodus versetzt, wenn sich die verfügbare Bildschirmgröße ändert oder die App von einem Bildschirm auf einen anderen verschoben wird.

Apps können das in Android 10 eingeführte Attribut android:minAspectRatio verwenden, um die von der App unterstützten Seitenverhältnisse anzugeben.

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

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