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

Android 10 enthält aktualisierte Änderungen am Systemverhalten, die sich auf Ihre 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 Ihrer App targetSdkVersion auf „29“ oder höher festgelegt ist, sollten Sie Ihre App gegebenenfalls so anpassen, dass diese Verhaltensweisen richtig 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 führt Android 10 eine Vielzahl von datenschutzbezogenen Änderungen und Einschränkungen ein, darunter die folgenden:

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

Diese Änderungen, die sich auf Apps mit API-Level 29 oder höher auswirken, verbessern den Datenschutz. 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, hat die Plattform in Android 9 (API-Level 28) begonnen, die Verwendung von Nicht-SDK-Schnittstellen durch Ihre App 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 Sie nicht auf Android 10 (API-Level 29) ausgerichtet sind, wirken sich einige dieser Änderungen möglicherweise nicht sofort auf Sie aus. Derzeit können Sie jedoch einige Nicht-SDK-Schnittstellen verwenden (abhängig vom Ziel-API-Level Ihrer App). Die Verwendung einer Nicht-SDK-Methode oder eines Nicht-SDK-Felds 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 das herauszufinden. Wenn Ihre App auf Nicht-SDK-Schnittstellen basiert, sollten Sie mit der Planung einer Migration zu SDK-Alternativen beginnen. Wir verstehen jedoch, dass einige Apps gültige Anwendungsfälle für die Verwendung von Nicht-SDK-Schnittstellen haben. 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 Updates to non-SDK interface restrictions in Android 10 und Restrictions on non-SDK interfaces.

Geteilte Erinnerung

Ashmem hat das Format von Dalvik-Maps in /proc/<pid>/maps geändert. Das 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 es 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, sondern müssen über die ASharedMemory-Klasse des NDK auf den gemeinsam genutzten Speicher zugreifen. Außerdem dürfen Apps keine direkten IOCTLs für vorhandene ashmem-Dateideskriptoren ausführen. Stattdessen müssen sie entweder die ASharedMemory-Klasse des NDK oder die Android-Java-APIs zum Erstellen von gemeinsam genutzten Speicherbereichen verwenden. Diese Änderung erhöht die Sicherheit und Robustheit bei der Arbeit mit gemeinsam genutztem Speicher und verbessert so die Leistung und Sicherheit von Android insgesamt.

Ausführungsberechtigung für das App-Home-Verzeichnis entfernt

Die Ausführung von Dateien aus dem beschreibbaren Basisverzeichnis der App ist ein W^X-Verstoß. Apps dürfen 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, 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 PROT_EXEC über einen beschreibbaren Dateideskriptor zugeordnet werden konnte. Dazu gehören alle Dateien mit gemeinsam genutzten Objekten (.so) mit Textverlagerungen.

Die Android-Laufzeit akzeptiert nur systemgenerierte OAT-Dateien

Die Android-Laufzeit (ART) ruft dex2oat nicht mehr aus dem 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 AOT-Kompilierung (Ahead-of-Time) durch die Android-Laufzeit (ART) 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. Das führt zu den folgenden Verhaltensänderungen:

  • Benutzerdefinierte Klassenlader, d. h. Klassenlader, die von Apps geschrieben wurden (im Gegensatz zu Klassenladern aus dem Paket dalvik.system), werden nicht AOT-kompiliert. Das liegt daran, dass ART zur Laufzeit keine Informationen zur benutzerdefinierten Implementierung der Klassensuche hat.
  • Sekundäre DEX-Dateien, d. h. die DEX-Dateien, die von Apps außerhalb des primären APK manuell geladen werden, werden im Hintergrund AOT-kompiliert. Das liegt daran, dass die Kompilierung bei der ersten Verwendung zu aufwendig sein kann, 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 Classloader-Hierarchie als in früheren Versionen der Plattform implementiert.

Änderungen bei Berechtigungen für Vollbild-Intents

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

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 Log-Meldung aus:

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

Unterstützung für faltbare Geräte

Android 10 bietet Ä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 Methoden onResume() und onPause() anders. Wenn mehrere Apps gleichzeitig im Mehrfenster- oder Mehrfachdisplaymodus angezeigt werden, befinden sich alle fokussierbaren Top-Aktivitäten in sichtbaren Stacks im Status „resumed“, aber nur eine von ihnen, die „oberste fortgesetzte“ Aktivität, hat tatsächlich den Fokus. Bei Versionen vor Android 10 kann jeweils nur eine Aktivität im System fortgesetzt werden. Alle anderen sichtbaren Aktivitäten werden pausiert.

Verwechseln Sie „Fokus“ nicht mit der Aktivität, die zuletzt fortgesetzt wurde. 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 geben. Eine Aktivität kann im Vordergrund fortgesetzt werden, ohne den Fokus zu 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 „resumed“ vor Android 10 und kann als Hinweis nützlich sein, wenn Ihre App exklusive oder Singleton-Ressourcen verwendet, die möglicherweise mit anderen Apps geteilt werden müssen.

Auch das Verhalten des Manifestattributs resizeableActivity> hat sich geändert. Wenn eine App resizeableActivity=false in 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 auf einen anderen verschoben wird.

Apps können das Attribut android:minAspectRatio verwenden, das in Android 10 eingeführt wurde, um die Bildschirmverhältnisse anzugeben, die von Ihrer 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-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.