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 deine App targetSdkVersion auf „29“ oder höher festlegt, solltest du sie gegebenenfalls so ändern, dass diese Verhaltensweisen richtig unterstützt werden.

Sieh dir 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 führt Android 10 eine Vielzahl von Änderungen und Einschränkungen im Hinblick auf den Datenschutz ein, darunter die folgenden:

  • Begrenzter Speicher
  • Zugriff auf die Seriennummer des USB-Geräts
  • Möglichkeit, WLAN zu aktivieren, zu deaktivieren und zu konfigurieren
  • Standortberechtigungen 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 zur Unterstützung dieser Änderungen findest du auf der Seite Änderungen im Hinblick auf den Datenschutz.

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

Um die Stabilität und Kompatibilität von Apps zu gewährleisten, hat die Plattform in Android 9 (API-Level 28) die Verwendung von Nicht-SDK-Schnittstellen durch Apps eingeschränkt. 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. Unser Ziel ist es, sicherzustellen, dass öffentliche Alternativen verfügbar sind, bevor wir Nicht-SDK-Schnittstellen einschränken.

Wenn du nicht auf Android 10 (API-Level 29) ausgerichtet bist, wirken sich einige dieser Änderungen möglicherweise nicht sofort auf dich aus. Obwohl du derzeit einige Nicht-SDK-Schnittstellen verwenden kannst (je nach Ziel-API-Level deiner App), birgt die Verwendung einer Nicht-SDK-Methode oder eines Nicht-SDK-Felds immer ein hohes Risiko, dass deine App nicht mehr funktioniert.

Wenn du dir nicht sicher bist, ob deine App Nicht-SDK-Schnittstellen verwendet, kannst du das testen, um das herauszufinden. Wenn deine App auf Nicht-SDK-Schnittstellen basiert, solltest du 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 du keine Alternative zur Verwendung einer Nicht-SDK-Schnittstelle für ein Feature in deiner App findest, solltest du eine neue öffentliche API anfordern.

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

Gemeinsamer Speicher

Ashmem hat das Format von Dalvik-Maps in /proc/<pid>/maps geändert. Dies wirkt sich auf Apps aus, 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-Map-Formaten abhängt.

Apps, die auf Android 10 ausgerichtet sind, können Ashmem (/dev/ashmem) nicht direkt verwenden, sondern müssen über die Klasse des NDK ASharedMemory auf den gemeinsamen Speicher zugreifen. Außerdem können Apps keine direkten IOCTLs für vorhandene Ashmem-Dateideskriptoren ausführen, sondern müssen entweder die ASharedMemory-Klasse des NDK oder die Android Java APIs zum Erstellen von Bereichen mit gemeinsamem Speicher verwenden. Diese Änderung erhöht die Sicherheit und Robustheit bei der Arbeit mit gemeinsamem Speicher und verbessert die Leistung und Sicherheit von Android insgesamt.

Ausführungsberechtigung für das App-Home-Verzeichnis 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 der 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 kann. Dazu gehören alle Dateien mit gemeinsam genutzten Objekten (.so) mit Text-Relokationen.

Android-Laufzeitumgebung akzeptiert nur vom System generierte OAT-Dateien

Die Android-Laufzeitumgebung (Android Runtime, ART) ruft dex2oat nicht mehr aus dem Anwendungsprozess auf. Das 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), die von der Android-Laufzeitumgebung (ART) durchgeführt wurde, zu Laufzeitabstürzen führen, wenn die Classpath-Umgebung zur Kompilierzeit und zur Laufzeit nicht identisch war. Unter Android 10 und höher müssen diese Umgebungskontexte immer identisch sein, was zu den folgenden Verhaltensänderungen führt:

  • Benutzerdefinierte Classloader, d. h. Classloader, die von Apps geschrieben wurden (im Gegensatz zu Classloadern aus dem Paket dalvik.system), werden nicht AOT-kompiliert. Das liegt daran, dass ART zur Laufzeit keine Informationen zur benutzerdefinierten Class-Lookup-Implementierung hat.
  • Sekundäre DEX-Dateien, d. h. DEX-Dateien, die manuell von Apps geladen werden, die nicht in der primären APK enthalten sind, werden im Hintergrund AOT-kompiliert. Das liegt daran, dass die Kompilierung bei der ersten Verwendung zu aufwendig sein kann und zu unerwünschten Latenzen vor der Ausführung führt. Für Apps wird empfohlen, Splits zu verwenden und keine sekundären DEX-Dateien mehr zu verwenden.
  • Gemeinsam genutzte Bibliotheken in Android (die Einträge <library> und <uses-library> in einem Android-Manifest) werden mit einer anderen Classloader-Hierarchie implementiert als in früheren Versionen der Plattform.

Änderungen an Berechtigungen für Vollbild-Intents

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

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 Bildschirmen unterstützen.

Wenn eine App unter Android 10 ausgeführt wird, funktionieren die onResume() und onPause() Methoden anders. Wenn mehrere Apps gleichzeitig im Mehrfenstermodus oder Mehrbildschirmmodus angezeigt werden, befinden sich alle fokussierbaren Top-Aktivitäten in sichtbaren Stacks im wiederaufgenommenen Zustand. Nur eine von ihnen, die „oberste wiederaufgenommene“ Aktivität, hat den Fokus. Unter Versionen vor Android 10 kann jeweils nur eine Aktivität im System wiederaufgenommen werden. Alle anderen sichtbaren Aktivitäten werden pausiert.

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

Unter Android 10 (API-Level 29) und höher kannst du den onTopResumedActivityChanged() Callback abonnieren, um benachrichtigt zu werden, wenn deine Aktivität die oberste wiederaufgenommene Position erhält oder verliert. Dies entspricht dem wiederaufgenommenen Zustand vor Android 10 und kann als Hinweis dienen, wenn deine App exklusive oder Singleton-Ressourcen verwendet, die möglicherweise für andere Apps freigegeben werden müssen.

Das Verhalten des resizeableActivity Manifestattributs 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 wenn die App von einem Bildschirm zu einem anderen verschoben wird.

Apps können das android:minAspectRatio Attribut verwenden, das in Android 10 eingeführt wurde, um die Bildschirm verhältnisse anzugeben, die von deiner App unterstützt werden.

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

Weitere Informationen findest du unter Apps für faltbare Geräte entwickeln.