Android 10 enthält Ä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 ändern, dass diese Verhaltensweisen korrekt unterstützt werden.
Lesen Sie sich auch die Liste der Verhaltensänderungen durch, die sich auf alle Apps auswirken, die auf Android 10 ausgeführt werden.
Hinweis : Zusätzlich zu den auf dieser Seite aufgeführten Änderungen führt Android 10 eine große Anzahl von datenschutzbezogenen Änderungen und Einschränkungen ein, darunter:
- Speicherplatz mit Begrenzung
- 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, dienen dem Schutz der Privatsphäre der Nutzer. Weitere Informationen dazu, wie Sie diese Änderungen unterstützen können, finden Sie auf der Seite Änderungen am Datenschutz.
Aktualisierte Einschränkungen für Nicht-SDK-Schnittstellen
Um die Stabilität und Kompatibilität von Apps zu verbessern, hat die Plattform damit begonnen, einzuschränken, welche nicht zu SDKs gehörenden Schnittstellen Ihre 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 Sie Ihre App nicht auf Android 10 (API-Level 29) ausrichten, wirken sich einige dieser Änderungen möglicherweise nicht sofort auf Sie aus. Derzeit können Sie jedoch einige Nicht-SDK-Schnittstellen verwenden (je nach 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 das herauszufinden. Wenn Ihre App Nicht-SDK-Schnittstellen verwendet, sollten Sie mit der Planung einer Migration zu SDK-Alternativen beginnen. Uns ist jedoch bewusst, 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-Benutzeroberfläche für eine Funktion in Ihrer App finden, sollten Sie eine neue öffentliche API anfordern.
Weitere Informationen finden Sie unter Änderungen an den Einschränkungen für Nicht-SDK-Schnittstellen in Android 10 und Einschränkungen für Nicht-SDK-Schnittstellen.
Gemeinsam genutzter Arbeitsspeicher
Ashmem hat das Format der Dalvik-Maps in /proc/<pid>/maps geändert. Dies wirkt sich auf Apps aus, die die Maps-Datei 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.
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 gemeinsamen Speicher zugreifen.
Außerdem können Apps keine direkten IOCTLs an vorhandene Ashmem-Dateibeschreibungen senden. Stattdessen müssen sie entweder die ASharedMemory-Klasse des NDK oder die Android Java APIs zum Erstellen von gemeinsam genutzten Speicherbereichen verwenden. Durch diese Änderung werden Sicherheit und Robustheit bei der Arbeit mit gemeinsam genutztem Arbeitsspeicher erhöht, was die Leistung und Sicherheit von Android insgesamt verbessert.
Ausführungsberechtigung für das 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 direkt auf 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 über einen beschreibbaren Dateideskriptor PROT_EXEC zugeordnet werden kann. Dazu gehören alle Dateien mit freigegebenen Objekten (.so) mit Textumordnungen.
Die Android-Laufzeit akzeptiert nur systemgenerierte OAT-Dateien
Die Android Runtime (ART) ruft dex2oat nicht mehr über den Anwendungsvorgang 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 von der Android Runtime (ART) durchgeführte AOT-Kompilierung (Ahead-of-Time) zu Laufzeitabstürzen führen, wenn die Klassenpfad-Umgebung zur Kompilierungs- und zur Laufzeit nicht identisch war. 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.systemnicht AOT-kompiliert. Das liegt daran, dass ART zur Laufzeit nicht über die benutzerdefinierte Implementierung der Klassensuche informiert ist. - Sekundäre DEX-Dateien, also DEX-Dateien, die manuell von Apps geladen werden, die nicht im primären APK enthalten sind, werden im Hintergrund AOT-kompiliert. Das liegt daran, dass die Kompilierung bei der Erstnutzung zu teuer sein kann, was zu einer unerwünschten Latenz vor der Ausführung führt. Für Apps wird empfohlen, Splits zu verwenden und sekundäre Dex-Dateien zu entfernen.
- 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 den Berechtigungen für Full-Screen-Intents
Für Apps, die auf Android 10 oder höher ausgerichtet sind und Benachrichtigungen mit Full-Screen-Intents verwenden, muss in der Manifestdatei der App die Berechtigung USE_FULL_SCREEN_INTENT angefordert werden. 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 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 auf Android 10 ausgeführt wird, funktionieren die Methoden onResume() und onPause() unterschiedlich. Wenn mehrere Apps gleichzeitig im Modus mit mehreren Fenstern oder mehreren Displays angezeigt werden, befinden sich alle oben angezeigten Aktivitäten in sichtbaren Stapeln im fortgesetzten Zustand. Nur eine davon, die „oberste fortgesetzte“ Aktivität, hat jedoch den Fokus. Bei Versionen vor Android 10 kann jeweils nur eine Aktivität im System fortgesetzt werden. Alle anderen sichtbaren Aktivitäten werden pausiert.
„Focus“ darf nicht mit der „obersten fortgesetzten“ Aktivität verwechselt werden. Das System ordnet Aktivitäten anhand 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, aber nicht den Fokus haben (z. B. wenn der Benachrichtigungs-Schirm maximiert ist).
Unter Android 10 (API-Level 29) und höher können Sie den Rückruf onTopResumedActivityChanged() abonnieren, um benachrichtigt zu werden, wenn Ihre Aktivität die oberste fortgesetzte Position erhält oder verliert. Dies entspricht dem fortgesetzten Zustand 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.
Auch das Verhalten des Manifestattributs resizeableActivity hat sich geändert. Wenn eine App resizeableActivity=false unter 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 wechselt.
Mit dem in Android 10 eingeführten Attribut android:minAspectRatio können Sie die Bildschirmseitenverhältnisse angeben, 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 entwerfen.