Versionshinweise zu Android 9

Auf dieser Seite werden die wichtigsten Funktionen von Android 9 zusammengefasst und Links zu weiteren Informationen bereitgestellt. Diese Funktionszusammenfassungen sind nach dem Speicherort der Dokumentation der Funktion auf dieser Website organisiert. Eine Anleitung zum Verschieben und Umbenennen von Abschnitten finden Sie in den Website-Änderungen vom August 2018.

Entwickeln

Generisches System-Image (GSI)

Ein generisches System-Image (GSI) ist ein System-Image mit angepassten Konfigurationen für Android-Geräte. Generic System Image (GSI) enthält Details zu den Unterschieden zwischen GSIs für Geräte, die mit Android 9 ausgeliefert werden, und Geräten, die auf Android 9 umgestellt werden.

Architektur

Hardware Abstraction Layer (HAL)

Abwärtskompatibilität des HIDL-Frameworks

Die Überprüfung der Abwärtskompatibilität des HIDL-Frameworks ist eine Methode, um die Abwärtskompatibilität des Frameworks zu überprüfen.

Dynamisch verfügbare HALs

Dynamische HALs unterstützen das dynamische Herunterfahren von Android-Hardware-Subsystemen, wenn sie nicht verwendet oder nicht benötigt werden.

HIDL

HIDL MemoryBlock

HIDL MemoryBlock ist eine abstrakte Schicht, die auf hidl_memory, HIDL @1.0::IAllocator und HIDL @1.0::IMapper basiert. Sie ist für HIDL-Dienste mit mehreren Speicherblöcken konzipiert, die sich einen einzigen Speicher-Heap teilen.

Gerätebaum-Overlays

Komprimierte Overlays

Unter Android 9 und höher werden komprimierte Overlays im DTBO-Image (Device Tree Blob Overlay) unterstützt, wenn Version 1 des Headers der Gerätebaum-Tabelle verwendet wird.

Aktualisierungen von Gerätebaum-Overlays

Unter Android 9 und höher muss der Bootloader den einheitlichen Gerätebaum-Blob an den Kernel übergeben, bevor die in den Gerätebaum-Overlays (Device Tree Overlays, DTOs) definierten Eigenschaften geändert werden.

Versionierung von DTBO-Bildüberschriften

Android 9 und höher enthalten ein Versionsfeld im DTBO-Image-Header.

Überprüfung durch die DTBO

Unter Android 9 und höher ist eine DTBO-Partition erforderlich. Wenn Knoten hinzugefügt oder Änderungen an den Eigenschaften im SoC-Gerätebaum vorgenommen werden sollen, muss der Bootloader einen gerätespezifischen Gerätebaum dynamisch über den SoC-Gerätebaum legen. Weitere Informationen finden Sie unter Kompilieren und überprüfen.

Kernel-Compliance

Android 9 und höher enthält Anforderungen, die sich auf den Kernel, seine Schnittstellen und die Verwendung von DTBOs auswirken. Weitere Informationen finden Sie auf den folgenden Seiten:

Anbieter NDK

Designänderungen

Informationen zu VNDK-Designänderungen in Android 9 und höher finden Sie auf den folgenden Seiten:

ABI-Checker

Auf der Seite ABI-Stabilität wird der ABI-Checker (Application Binary Interface) beschrieben, der dafür sorgt, dass Änderungen an VNDK-Bibliotheken die ABI-Compliance einhalten.

VNDK-Snapshots

Ein System-Image kann VNDK-Snapshots verwenden, um Anbieter-Images die richtigen VNDK-Bibliotheken zur Verfügung zu stellen, auch wenn System- und Anbieter-Images aus verschiedenen Android-Versionen erstellt werden.

Anbieter-Interface-Objekt (VINTF-Objekt)

Auf den folgenden Seiten im Abschnitt Objekt der Anbieteroberfläche werden Änderungen in Android 9 und höher beschrieben:

Zeitplan für die Einstellung von HIDL

Auf den folgenden Seiten wird beschrieben, wie HIDL HALs in Android eingestellt und entfernt werden:

Bootloader

Produktpartitionen

Unter Android 9 und höher können /product-Partitionen mit dem Android-Build-System erstellt werden. Bisher wurde unter Android 8.x die Trennung von SoC-spezifischen Komponenten (System-on-a-Chip) von der Partition /system in die Partition /vendor erzwungen, ohne Speicherplatz für OEM-spezifische Komponenten bereitzustellen, die mit dem Android-Build-System erstellt wurden.

Einhaltung der Richtlinie zum kanonischen Bootgrund

Auf der Seite Canonical Boot Reason (Kanonischer Bootgrund) werden die Änderungen an der Bootgrundspezifikation des Bootloaders in Android 9 und höher beschrieben.

System als Root

Alle Geräte, die mit Android 9 oder höher auf den Markt kommen, müssen system-as-root verwenden. Dabei wird ramdisk.img mit system.img (auch als „no-ramdisk“ bezeichnet) zusammengeführt, das wiederum als rootfs bereitgestellt wird.

Versionierung der Boot-Image-Kopfzeile

Unter Android 9 und höher enthält der Boot-Image-Header ein Feld, das die Headerversion angibt. Der Bootloader muss dieses Versionsfeld prüfen und den Header entsprechend parsen.

DTBO in der Wiederherstellung

Um OTA-Fehler aufgrund von Abweichungen zwischen dem Wiederherstellungs-Image und der DTBO-Partition auf Nicht-A/B-Geräten zu vermeiden, muss das Wiederherstellungs-Image Informationen aus dem DTBO-Image enthalten.

Anzeige

Display-Aussparungen

Mit Displayausschnitten können App-Entwickler ein immersives, randloses Display schaffen und gleichzeitig Platz für wichtige Sensoren auf der Vorderseite der Geräte lassen.

Vorschläge drehen

Die Bildschirmausrichtung wurde in Android 9 und höher aktualisiert. Es gibt jetzt eine Einstellung, mit der Nutzer die Bildschirmausrichtung auf Quer- oder Hochformat festlegen können, auch wenn sich die Geräteposition ändert.

Synchronisierte App-Übergänge

Synchronisierte App-Übergänge ermöglichen neue App-Übergangsanimationen.

Textklassifizierung (früher TEXTCLASSIFIER)

Android 9 und höher enthalten einen Textklassifizierungsdienst, der die empfohlene Methode zur Implementierung der Textklassifizierung ist, sowie eine Standarddienstimplementierung.

Breitfarbiger Farbraum

Android 9 und höher unterstützen Wide-Gamut-Farben, darunter:

  • High Dynamic Range (HDR)
  • Inhalte werden im BT2020-Farbraum verarbeitet, aber nicht als Endzieldatenraum

Damit Farben mit erweitertem Farbraum verwendet werden können, muss der gesamte Displaystack eines Geräts (z. B. Bildschirm, Hardware-Composer, GPU) Farben mit erweitertem Farbraum oder Pufferformate unterstützen. Geräte müssen nicht die Unterstützung für Inhalte mit großem Farbraum angeben, auch wenn die Hardware dies unterstützt. Die Wide-Gamut-Farbe sollte jedoch aktiviert sein, um die Hardware optimal nutzen zu können. Um inkonsistente visuelle Darstellungen zu vermeiden, sollte die Wide-Gamut-Farbwiedergabe während der Laufzeit nicht deaktiviert werden.

Kompatibilität

Android Compatibility Definition Document

Das Compatibility Definition Document (CDD) für Android 9 basiert auf den vorherigen Versionen und enthält Updates für neue Funktionen sowie Änderungen an den Anforderungen für zuvor veröffentlichte Funktionen.

Einstellungen

Bessere App-Widgets

Das Android App Widget Framework bietet eine bessere Sichtbarkeit der Nutzerinteraktionen, insbesondere wenn ein Nutzer Widgets löscht oder manuell hinzufügt. Diese Funktion ist standardmäßig in Launcher3 verfügbar.

Hersteller müssen ihre Launcher-Apps (die im Lieferumfang der Geräte enthalten sind) aktualisieren, um diese Funktion zu unterstützen, sofern sie nicht auf Launcher3 basieren. OEMs müssen das neue Feld widgetFeatures in ihrem Standard-Launcher unterstützen.

Die Funktion funktioniert nur dann Ende-zu-Ende, wenn die Launcher sie wie erwartet implementieren. AOSP enthält eine Beispielimplementierung. Den bereitgestellten Beispielcode finden Sie unter der AOSP-Änderungs-ID Iccd6f965fa3d61992244a365efc242122292c0ca.

Benachrichtigungen über Gerätestatusänderungen an Paketinstallationsprogramme

Ein geschützter System-Broadcast kann an Apps gesendet werden, die die Berechtigung INSTALL_PACKAGES haben, wenn sich Eigenschaften wie die Sprache oder die Displaydichte ändern. Empfänger können im Manifest registriert werden und ein Prozess wird aktiviert, um die Übertragung zu empfangen. Dies ist nützlich für Paketinstallationsprogramme, die bei solchen Änderungen zusätzliche App-Komponenten installieren möchten. Das ist jedoch selten, da die Konfigurationsänderungen, die diese Übertragung auslösen können, selten sind.

Der Quellcode für Benachrichtigungen zu Gerätestatusänderungen befindet sich unter platform/frameworks/base an den folgenden Stellen:

  • api/system-current.txt
  • core/java/android/content/Intent.java
  • core/res/AndroidManifest.xml
  • services/core/java/com/android/server/am/ActivityManagerService.java

Informationsarchitektur

Änderungen an der Informationsarchitektur der Einstellungen-App bieten mehr Funktionen und eine einfachere Implementierung.

Tests

Atest

Mit dem Befehlszeilentool Atest können Sie Android-Tests lokal erstellen, installieren und ausführen. Dadurch werden Wiederholungen von Tests erheblich beschleunigt, ohne dass Sie die Befehlszeilenoptionen des Trade Federation-Testharness kennen müssen.

Compatibility Test Suite

CTS-Downloads

CTS-Pakete (Compatibility Test Suite), die Android 9 unterstützen, finden Sie auf der Seite CTS-Downloads. Der Quellcode für die enthaltenen Tests kann mit dem android-cts-9.0_r1-Tag im Open-Source-Baum synchronisiert werden.

CTS-Optionen

Für Android 9 werden CTS v2 der folgende Befehl und das folgende Argument hinzugefügt:

  • run retry wiederholt alle Tests, die in den vorherigen Sitzungen fehlgeschlagen oder nicht ausgeführt wurden.
  • ‘--shard-count spaltet einen CTS-Lauf in eine bestimmte Anzahl unabhängiger Chunks auf, um sie parallel auf mehreren Geräten auszuführen.

Außerdem wurde der zuvor nicht dokumentierte Befehl --retry-type in die entsprechende CTS v2-Konsolenbefehlsreferenz aufgenommen.

Secure Element-Dienst (SE)

Der Secure Element-Dienst sucht nach global von der Plattform unterstützten Secure Elements. Dazu wird ermittelt, ob Geräte eine SE HAL-Implementierung haben und wenn ja, wie viele. Dieser wird als Grundlage zum Testen der API und der zugrunde liegenden Secure Element-Implementierung verwendet.

Sensorfusionsbox

Das Sensor Fusion Box wird in der Camera Image Test Suite (Camera ITS) für den Sensor Fusion Test und den Multi-Camera Sync Test verwendet. Es bietet eine einheitliche Testumgebung zum Messen der Zeitstempelgenauigkeit der Kamera und anderer Sensoren für Android-Smartphones. Weitere Informationen finden Sie auf den folgenden Seiten:

ITS-in-a-Box mit Weitwinkel

Das ITS-in-a-Box für Kameras mit Weitwinkel ist ein automatisiertes System, mit dem sowohl Kamerasysteme mit Weitwinkel als auch mit Normalwinkel im Kamera-ITS getestet werden können.

Anbieter-Testsuite

Hostcontroller-Architektur

Die VTS-Hostcontrollerarchitektur (Vendor Test Suite) ist die Architektur des VTS-Test-Frameworks, das in den cloudbasierten Testbereitstellungsdienst integriert ist.

HAL-Tests, die den Dienstnamen berücksichtigen

VTS-Dienstname-basierte HAL-Tests unterstützen das Abrufen des Dienstnamens einer bestimmten HAL-Instanz basierend auf dem Gerät, auf dem VTS-Tests ausgeführt werden.

HAL-Testbarkeitsprüfung

Die VTS HAL-Testbarkeitsprüfung umfasst eine Laufzeitmethode, mit der anhand der Gerätekonfiguration ermittelt wird, welche VTS-Tests für das jeweilige Geräteziel übersprungen werden sollen.

Infrastruktur für automatisierte Tests

Die automatisierte Testinfrastruktur ist eine VTS-Infrastruktur für automatisierte VTS-, CTS- oder andere Tests auf Partnergeräten mit dem generischen AOSP-System-Image (GSI).

Fehlerbehebung

Erweiterte Telemetrie

Unter Android wird unter Telemetrie die automatische Erfassung von Nutzungs- und Diagnosedaten zu Geräten, dem Android-System und Apps verstanden. In früheren Android-Versionen war der Telemetrie-Stack eingeschränkt und erfasste nicht die Informationen, die zum Identifizieren und Beheben von Problemen mit der Systemzuverlässigkeit sowie mit Geräten oder Apps erforderlich sind. Das machte es schwierig, wenn nicht unmöglich, die Grundursachen von Problemen zu identifizieren.

Android 9 enthält die statsd-Telemetriefunktion, die dieses Problem löst, indem bessere Daten schneller erfasst werden. statsd erfasst App-Nutzung, Akku- und Prozessstatistiken sowie Abstürze. Die Daten werden analysiert und zur Verbesserung von Produkten, Hardware und Diensten verwendet.

Weitere Informationen finden Sie unter frameworks/base/cmds/statsd/.

Sicherheitsfunktionen

App-Signatur

Das APK-Signaturschema Version 3 unterstützt die APK-Schlüsselrotation.

Unterstützung biometrischer Verfahren

Android 9 enthält die öffentliche Klasse BiometricPrompt, mit der Apps die Unterstützung der biometrischen Authentifizierung geräte- und modalitätsunabhängig einbinden können. Weitere Informationen zur Integration Ihres biometrischen Stacks mit BiometricPrompt finden Sie unter Biometrie.

Dynamische Analyse

Android 9 unterstützt mehr Tools zur Behebung und Analyse von Exploits.

Control Flow Integrity (CFI)

Die Integrität der Programmabfolge (Control Flow Integrity, CFI) ist ein Sicherheitsmechanismus, der Änderungen am ursprünglichen Kontrollflussgraphen eines kompilierten Binärprogramms verhindert. Dadurch wird die Durchführung solcher Angriffe erheblich erschwert.

Kernel CFI

Zusätzlich zur standardmäßig aktivierten System-CFI wird in Android 9 und höher auch die Kernel-Kontrollflussintegrität (Control Flow Integrity, CFI) unterstützt.

Verschlüsselung

Dateibasierte Verschlüsselung

Die dateibasierte Verschlüsselung (File-Based Encryption, FBE) wurde aktualisiert, damit sie mit adaptable storage funktioniert. Neue Geräte sollten die dateibasierte Verschlüsselung anstelle der Datenträgervollverschlüsselung verwenden.

Metadatenverschlüsselung

Android 9 und höher unterstützen die Verschlüsselung von Metadaten, sofern die Hardware dies zulässt. Bei der Metadatenverschlüsselung werden alle nicht verschlüsselten Inhalte mithilfe der dateibasierten Verschlüsselung und eines einzigen Schlüssels verschlüsselt, der zum Zeitpunkt des Starts vorhanden ist.

Schlüsselspeicher

Android 9 und höher enthält Keymaster 4, das diese Funktionen bietet.

StrongBox

Android 9 und höher unterstützen Android Keystore-Schlüssel, die in einer physisch separaten CPU gespeichert und verwendet werden, die speziell für Hochsicherheitsanwendungen entwickelt wurde, z. B. ein eingebettetes Secure Element (SE). StrongBox Keymaster ist eine Implementierung der Keymaster HAL in sicherer standortunabhängiger Hardware. Ein StrongBox hat folgende Eigenschaften:

  • Discrete CPU
  • Integrierter sicherer Speicher
  • Hochwertiger echter Zufallszahlengenerator
  • Manipulationssichere Verpackung
  • Seitenkanalresistenz

Sicherer Schlüsselimport

Um einen Schlüssel sicher in Keymaster 4 zu importieren, wird ein extern erstellter Schlüssel mit einer Spezifikation der Berechtigungen verschlüsselt, die festlegen, wie der Schlüssel verwendet werden darf.

3DES-Unterstützung

Keymaster 4 unterstützt 3DES für die Kompatibilität mit älteren Systemen, die 3DES verwenden.

Versionsbindung

Um die modulare Struktur von Treble zu unterstützen und die Bindung von system.img an boot.img aufzuheben, wurde in Keymaster 4 das Modell der Bindung der Schlüsselversion geändert, sodass für jede Partition separate Patchebenen vorhanden sind. So kann jede Partition unabhängig aktualisiert werden und es wird gleichzeitig ein Rollback-Schutz bereitgestellt.

Android Protected Confirmation API

Auf unterstützten Geräten, auf denen Android 9 installiert ist, können Entwickler die Android Protected Confirmation API verwenden. Mit dieser API können Apps eine Instanz von ConfirmationPrompt verwenden, um dem Nutzer eine Aufforderung zur Genehmigung einer kurzen Erklärung anzuzeigen. Mit dieser Erklärung kann eine App noch einmal bestätigen, dass der Nutzer eine sensible Transaktion wie eine Zahlung ausführen möchte.

SELinux

SELinux-Sandbox pro App

Die Anwendungs-Sandbox bietet neue Schutzmaßnahmen und Testfälle, um sicherzustellen, dass alle nicht privilegierten Apps, die auf Android 9 und höher ausgerichtet sind, in einzelnen SELinux-Sandboxes ausgeführt werden.

SELinux-Änderungen für Treble

Updates für Treble SELinux in Android 9 und höher sind auf mehreren Seiten im Abschnitt zu SELinux dokumentiert.

Anbieter-Init

Vendor init schließt die Lücke in der Treble-System-/Anbieteraufteilung, indem eine separate SELinux-Domain verwendet wird, um /vendor-Befehle mit anbieterspezifischen Berechtigungen auszuführen.

Systemeigenschaften

Unter Android 9 wird verhindert, dass Systemeigenschaften unnötigerweise zwischen system- und vendor-Partitionen freigegeben werden. Außerdem gibt es eine Methode, um für Konsistenz zwischen freigegebenen Systemeigenschaften zu sorgen.

SELinux-Attributtests

Android 9 enthält neue Buildzeittests, mit denen sichergestellt wird, dass alle Dateien an bestimmten Speicherorten die entsprechenden Attribute haben. Beispiel: Alle Dateien in sysfs haben das erforderliche Attribut sysfs_type.

Audio

Hochauflösende Audioeffekte

Zu den Verbesserungen bei Audioeffekten in hoher Auflösung gehören die Umwandlung der Effektverarbeitung von int16 in das Float-Format sowie eine Erhöhung der gleichzeitigen Client-Ausgabetracks, des maximalen Client-/Server-Speichers und der Gesamtzahl der gemischten Tracks.

Kamera

Externe USB-Kameras

Android 9 und höher unterstützt die Verwendung von Plug-and-Play-USB-Kameras (d. h. Webcams) mit der standardmäßigen Android Camera2 API und der HIDL-Schnittstelle der Kamera.

Bewegungserkennung

Kamerageräte können Bewegungserkennung bewerben.

Unterstützung mehrerer Kameras

Die Unterstützung mehrerer Kameras umfasst die API-Unterstützung für Geräte mit mehreren Kameras über ein neues logisches Kameragerät, das aus zwei oder mehr physischen Kameras besteht, die in dieselbe Richtung zeigen.

Sitzungsparameter

Durch die Implementierung von Sitzungsparametern können Verzögerungen reduziert werden, da Kameraclients einen Teil der kostenintensiven Anfrageparameter im Rahmen der Initialisierungsphase der Aufnahmesitzung aktiv konfigurieren können.

Puffer mit einem einzelnen Erzeuger und mehreren Verbrauchern

Der Kamerabuffer-Transport mit einem einzelnen Produzenten und mehreren Verbrauchern ist eine Reihe von Methoden, mit denen Kameraclients Ausgabeoberflächen dynamisch hinzufügen und entfernen können, während die Aufnahmesitzung aktiv ist und das Kamerastreaming läuft.

Konnektivität

Anrufe und Nachrichten

Datentarife implementieren

Android 9 und höher bietet verbesserte Unterstützung für Mobilfunkanbieter, die Datentarife mithilfe der SubscriptionPlan APIs implementieren.

Anruf-Apps von Drittanbietern

Android 9 und höher bietet APIs, mit denen Anruf-Apps von Drittanbietern eingehende Anrufe von Mobilfunkanbietern gleichzeitig verarbeiten und Anrufe in der Systemanrufliste protokollieren können.

Mobilfunkanbieter

Mobilfunkanbieter-Identifikation

In Android 9 wird in AOSP eine Datenbank mit Mobilfunkanbieter-IDs zur Identifizierung des Mobilfunkanbieters hinzugefügt. Die Datenbank minimiert doppelte Logik und fragmentierte App-Nutzung, da sie eine gemeinsame Möglichkeit zur Identifizierung von Mobilfunkanbietern bietet.

eSIM

Die eingebettete SIM-Karte (eSIM oder eUICC) ist die neueste Technologie, mit der Nutzer ein Mobilfunkanbieterprofil herunterladen und den Dienst eines Mobilfunkanbieters aktivieren können, ohne eine physische SIM-Karte zu haben. Unter Android 9 und höher bietet das Android-Framework Standard-APIs für den Zugriff auf eSIMs und die Verwaltung von Aboprofilen auf eSIMs. Weitere Informationen

Unterstützung mehrerer SIM-Karten für IMS-Einstellungen

Android 9 und höher bietet Verbesserungen an den Nutzereinstellungen für das IP Multimedia Subsystem (IMS). Sie können Voice over LTE (VoLTE), Videoanrufe und WLAN-Telefonie pro Abo einrichten, anstatt diese Einstellungen für alle Abos zu verwenden.

Übertragungen des SIM-Status

Unter Android 9 und höher wird Intent.ACTION_SIM_STATE_CHANGED eingestellt und es werden zwei separate Broadcasts für den Kartenstatus und den Status der Kartenanwendung hinzugefügt: TelephonyManager.ACTION_SIM_CARD_STATE_CHANGED und TelephonyManager.ACTION_SIM_APPLICATION_STATE_CHANGED.

Durch diese Änderungen müssen Empfänger, die nur wissen müssen, ob eine Karte vorhanden ist, nicht mehr auf Änderungen des Anwendungsstatus achten. Empfänger, die nur wissen müssen, ob Kartenanwendungen bereit sind, müssen auch nicht mehr auf Änderungen des Kartenstatus achten.

Die beiden neuen Übertragungen sind @SystemApis und nicht fixiert. Nur Empfänger mit der Berechtigung READ_PRIVILEGED_PHONE_STATE können die Übertragungen empfangen.

Die Intents werden nicht noch einmal gesendet, wenn Sie das Gerät entsperren. Empfänger, die von Übertragungen abhängen, die vor dem Entsperren gesendet wurden, müssen entweder directBootAware verwenden oder den Status nach dem Entsperren des Nutzers abfragen. Die Status können mit den entsprechenden APIs in TelephonyManager, getSimCardState() und getSimApplicationState() abgefragt werden.

WLAN

WLAN des Mobilfunkanbieters

Mit der Funktion WLAN des Mobilfunkanbieters können sich Geräte automatisch mit WLANs des Mobilfunkanbieters verbinden. In stark überlasteten Gebieten oder mit minimaler Mobilfunkabdeckung, z. B. in einem Stadion oder einer U-Bahn-Station, verbessert WLAN von Mobilfunkanbietern die Konnektivität und entlastet den Traffic.

MAC-Adressrandomisierung

Mit der MAC-Randomisierung können Geräte zufällige MAC-Adressen verwenden, wenn sie nach neuen Netzwerken suchen, während sie derzeit nicht mit einem Netzwerk verbunden sind. Unter Android 9 und höher kann eine Entwickleroption aktiviert werden, damit ein Gerät beim Verbinden mit einem WLAN eine zufällige MAC-Adresse verwendet.

WLAN automatisch aktivieren

Wenn die Funktion WLAN automatisch aktivieren aktiviert ist, wird das WLAN automatisch wieder aktiviert, wenn sich das Gerät in der Nähe eines gespeicherten WLANs mit einer ausreichend hohen relativen Empfangssignalstärkenanzeige (RSSI) befindet.

WLAN-Umlaufzeit

Mit der WLAN-RTT (Round Trip Time) können Geräte die Entfernung zu anderen unterstützenden Geräten messen, unabhängig davon, ob es sich um Zugangspunkte (APs) oder Wi‑Fi Aware-Peers handelt (sofern Wi‑Fi Aware auf dem Gerät unterstützt wird). Diese Funktion basiert auf dem IEEE 802.11mc-Protokoll und ermöglicht Apps eine verbesserte Standortgenauigkeit und -erkennung.

Verbesserungen bei der WLAN-Bewertung

Verbesserte WLAN-Bewertungsmodelle ermitteln schnell und genau, wann ein Gerät ein verbundenes WLAN verlassen oder ein neues WLAN betreten soll. Diese Modelle bieten Nutzern eine zuverlässige und nahtlose Nutzung, da Lücken in der Konnektivität vermieden werden.

Prüfen und optimieren Sie die RSSI-Werte in den config.xml-Ressourcen, insbesondere die folgenden:

  • config_wifi_framework_wifi_score_bad_rssi_threshold_5GHz
  • config_wifi_framework_wifi_score_entry_rssi_threshold_5GHz
  • config_wifi_framework_wifi_score_bad_rssi_threshold_24GHz
  • config_wifi_framework_wifi_score_entry_rssi_threshold_24GHz

WLAN-STA/AP-Parallelität

Die WLAN-STA/AP-Parallelität ist die Fähigkeit von Geräten, gleichzeitig im Station- (STA) und im Zugangspunkt-Modus (AP) zu arbeiten. Bei Geräten, die Dualband-WLAN (DBS) unterstützen, können so Funktionen wie die Unterbrechung des STA-WLANs verhindert werden, wenn ein Nutzer einen Hotspot (SoftAP) aktivieren möchte.

Verbesserungen bei WiFiStateMachine

WifiStateMachine ist die Hauptklasse, mit der WLAN-Aktivitäten gesteuert, Nutzereingaben koordiniert (Betriebsmodi: Hotspot, Scannen, Verbinden oder Aus) und WLAN-Netzwerkaktionen gesteuert werden (z. B. Scannen oder Verbinden).

In Android 9 und höher wurden der Code des WLAN-Frameworks und die Implementierung von WifiStateMachine neu gestaltet. Dies führt zu einer reduzierten Codegröße, einer einfacher zu verstehenden WLAN-Steuerungslogik, einer verbesserten Steuerungsgranularität sowie einer höheren Abdeckung und Qualität von Unit-Tests.

Im Allgemeinen kann das WLAN mitWifiStateMachine in einem der folgenden vier Status sein:

  • Client-Modus (kann eine Verbindung herstellen und nach Geräten suchen)
  • Nur-Scanmodus
  • SoftAP-Modus (WLAN-Hotspot)
  • Deaktiviert (WLAN vollständig deaktiviert)

Für jeden WLAN-Modus gelten unterschiedliche Anforderungen für die Ausführung von Diensten. Sie sollten daher einheitlich eingerichtet werden und nur die für den Betrieb relevanten Ereignisse verarbeiten. Bei der neuen Implementierung wird der Code auf Ereignisse beschränkt, die mit diesem Modus zusammenhängen. Dadurch wird der Zeitaufwand für die Fehlerbehebung reduziert und das Risiko verringert, dass aufgrund der Komplexität neue Fehler auftreten. Zusätzlich zur expliziten Verarbeitung der Modusfunktionen wird die Threadverwaltung einheitlich verwaltet und die Verwendung von asynchronen Kanälen als Synchronisierungsmechanismus wird eliminiert.

Aktualisierungen der WLAN-Berechtigungen

Unter Android 9 und höher ist die App-Berechtigung CHANGE_WIFI_STATE standardmäßig aktiviert. Sie können die Berechtigung für jede App auf der Seite „Einstellungen“ unter Einstellungen > Apps und Benachrichtigungen > Spezieller App-Zugriff > WLAN-Steuerung deaktivieren.

Apps müssen in der Lage sein, mit Fällen umzugehen, in denen die Berechtigung CHANGE_WIFI_STATE nicht erteilt wird.

Führen Sie zum Validieren dieses Verhaltens die roboelectric- und die manuellen Tests aus.

Für manuelle Tests:

  1. Gehen Sie zu Einstellungen > Apps und Benachrichtigungen > Spezieller App-Zugriff > WLAN-Steuerung.
  2. Wählen Sie die Berechtigung für Ihre App aus und deaktivieren Sie sie.
  3. Prüfen Sie, ob Ihre App das Szenario verarbeiten kann, in dem die CHANGE_WIFI_STATE-Berechtigung nicht erteilt wird.

Einstellung von WPS

Aufgrund von Sicherheitsproblemen wird Wi‑Fi Protected Setup (WPS) in WiFiManager eingestellt und in Android 9 und höher deaktiviert. WiFiDirect verwendet jedoch weiterhin WPS im WPA-Supplicant.

Grafik

Implementierung

Vulkan 1.1 API

Android 9 und höher unterstützen die Implementierung der Vulkan 1.1-Grafik-API.

WinScope-Tool zum Erfassen von Fensterübergängen

Android 9 und höher enthalten das WinScope-Tool zum Nachverfolgen von Fensterübergängen. WinScope bietet Infrastruktur und Tools zum Aufzeichnen und Analysieren des Fenstermanager-Status während und nach Übergängen. Es ermöglicht die Aufzeichnung und Schritt-für-Schritt-Wiedergabe von Fensterübergängen und zeichnet dabei den gesamten relevanten Fenstermanagerstatus in einer Trace-Datei auf. Mit diesen Daten können Sie den Übergang wiedergeben und Schritt für Schritt durchgehen.

Der Quellcode des WinScope-Tools befindet sich unter platform/development/tools/winscope.

Interaktion

Auto-Audio

Automotive Audio beschreibt die Audioarchitektur für Android-Implementierungen im Automobilbereich.

Die HAL für neuronale Netze (Neural Networks, NN) definiert eine Abstraktion der verschiedenen Beschleuniger. Die Treiber für diese Accelerators müssen dieser HAL entsprechen.

Fahrzeug-HAL

Unter Fahrzeugeigenschaften werden Änderungen an der HAL-Schnittstelle des Fahrzeugs beschrieben.

GNSS-Satellitenauswahl

Wenn Sie mit neuen GNSS-HALs (Global Navigation Satellite System, Version 1.1 und höher) arbeiten, überwacht das Android-Framework die Android-Einstellungen. Partner können die Einstellungen über Google Play-Dienste oder andere Systemupdates ändern. Mit diesen Einstellungen wird der GNSS HAL mitgeteilt, ob bestimmte GNSS-Satelliten nicht verwendet werden sollen. Dies kann bei anhaltenden GNSS-Satelliten- oder -Konstellationsfehlern nützlich sein oder um schneller auf Probleme bei der GNSS HAL-Implementierung zu reagieren, die auftreten können, wenn Konstellationen mit unterschiedlichen Zeitsystemen und externen Ereignissen kombiniert werden, z. B. bei Übergängen zwischen Schaltsekunden, Tagen oder Wochen.

GNSS-Hardwaremodell

Unter Android 9 kann die GNSS HAL-Version 1.1 oder höher Informationen zur Hardware-API an die Plattform weitergeben. Die Plattform muss die IGnssCallback-Oberfläche implementieren und einen Handle an die HAL übergeben. Die GNSS-HAL gibt die Informationen zum Hardwaremodell über die Methode LocationManager#getGnssHardwareModelName() weiter. Gerätehersteller sollten diese Informationen nach Möglichkeit mit ihren GNSS HAL-Anbietern abstimmen.

Berechtigungen

Aktualisierungen der nutzungsbasierten Zugriffssteuerung konfigurieren

Discretionary Access Control (DAC) konfigurieren enthält Updates für den Android-ID-Mechanismus (AIDs), um die Dateisystemfunktionen zu erweitern.

Berechtigungen für privilegierte Apps auf die Zulassungsliste setzen

Wenn unter Android 9 und höher Berechtigungen abgelehnt werden sollen, bearbeiten Sie die XML-Datei so, dass das Tag deny-permission anstelle des in früheren Releases verwendeten Tags permission verwendet wird.

Daten

Verbesserungen bei der Bandbreitenschätzung

Android 9 bietet eine verbesserte Unterstützung für die Bandbreitenschätzung. Android-Apps können für Videoanrufe und Videostreaming geeignetere Auflösungseinstellungen vornehmen, wenn sie auf die verfügbare Datenbandbreite zugreifen können.

Auf Geräten mit Android 6.0 oder höher ruft ein Anrufer, der eine Bandbreitenschätzung für ein Mobilfunknetz benötigt, ConnectivityManager.requestBandwidthUpdate() auf. Das Framework kann dann eine geschätzte Downlink-Bandbreite bereitstellen.

Auf Geräten mit Android 9 oder höher wird der Rückruf onCapabilitiesChanged() jedoch automatisch ausgelöst, wenn sich die geschätzte Bandbreite erheblich ändert. Der Aufruf von requestBandwidthUpdate() ist dann nicht erforderlich. Die zugehörigen Werte getLinkDownstreamBandwidthKbps() und getLinkUpstreamBandwidthKbps() werden mit aktualisierten Informationen aus der Bitübertragungsschicht ausgefüllt.

Außerdem können Geräte die LTE-Zellenbandbreiten über ServiceState.getCellBandwidths() prüfen. So können Anwendungen ermitteln, wie viel Bandbreite (Frequenz) in einer bestimmten Zelle verfügbar ist. Informationen zur Zellbandbreite sind über ein ausgeblendetes Menü verfügbar, damit Feldtester die aktuellsten Informationen abrufen können.

eBPF-Traffic-Monitoring

Das eBPF-Netzwerkverkehrstool verwendet eine Kombination aus Kernel- und Userspace-Implementierung, um die Netzwerknutzung auf einem Gerät seit dem letzten Start zu überwachen. Dieses Tool bietet zusätzliche Funktionen wie Socket-Tagging, die Trennung von Vordergrund- und Hintergrund-Traffic sowie eine UID-spezifische Firewall, um Apps je nach Gerätestatus den Netzwerkzugriff zu blockieren.

Zu niedrigeren APIs zurückkehren

Geräte können jetzt aus zukünftigen Versionen des Betriebssystems wiederhergestellt werden. Das ist besonders nützlich, wenn Nutzer ihr Smartphone ersetzt haben, es aber dann verloren oder kaputt gemacht haben.

Wenn ein OEM die Sicherungsagenten für eines der Systempakete (android, system, settings) ändert, sollten diese Agenten die Wiederherstellung von Sicherungssätzen, die mit höheren Versionen der Plattform erstellt wurden, ohne Absturz und mit der Wiederherstellung mindestens einiger Daten bewältigen.

Sie können einen Validator verwenden, um ungültige Werte in bestimmten Sicherungsdaten zu prüfen und nur gültige Daten wiederherzustellen, wie in core/java/android/provider/SettingsValidators.java.

Die Funktion ist standardmäßig aktiviert. Die Unterstützung von SettingsBackupAgent für die Wiederherstellung aus zukünftigen Versionen kann über Settings.Global.OVERRIDE_SETTINGS_PROVIDER_RESTORE_ANY_VERSION deaktiviert werden. Es ist keine zusätzliche Implementierung erforderlich, es sei denn, der Gerätehersteller erweitert einen der im ROM enthaltenen Sicherungsagenten oder fügt einen benutzerdefinierten Agenten hinzu.

Mit dieser Funktion können Sie das System aus zukünftigen Versionen der Plattform wiederherstellen. Es ist jedoch davon auszugehen, dass die wiederhergestellten Daten unvollständig sind. Die folgende Anleitung gilt für die folgenden Sicherungsagenten:

  • PackageManagerBackupAgent unterstützt zukünftige Versionen der Sicherungsdaten über die Formatversionierung. Erweiterungen hier müssen mit dem aktuellen Wiederherstellungscode kompatibel sein oder der Anleitung in der Klasse folgen, einschließlich der Erhöhung der entsprechenden Konstanten.

  • SystemBackupAgent gibt restoreAnyVersion = false unter Android 9 und höher an. Die Wiederherstellung aus höheren API-Versionen wird nicht unterstützt.

  • SettingsBackupAgent gibt unter Android 9 und höher restoreAnyVersion = true an. Über Validator wird eine teilweise Unterstützung angeboten. Eine Einstellung kann aus einer höheren API-Version wiederhergestellt werden, wenn im Zielbetriebssystem ein Validator dafür vorhanden ist. Wenn Sie eine Einstellung hinzufügen, muss auch der zugehörige Validator hinzugefügt werden. Weitere Informationen finden Sie im Kurs.

  • Jeder im ROM enthaltene benutzerdefinierte Sicherungsagent sollte seinen Versionscode jedes Mal erhöhen, wenn eine inkompatible Änderung am Sicherungsdatenformat vorgenommen wird. Außerdem sollte restoreAnyVersion = false (Standard) festgelegt werden, wenn der Agent nicht für die Verarbeitung von Sicherungsdaten aus einer zukünftigen Version seines Codes geeignet ist.

Unternehmen

Verbesserungen bei verwalteten Profilen

Durch die Änderungen an der Nutzererfahrung für verwaltete Profile können Nutzer das verwaltete Profil leichter identifizieren, darauf zugreifen und verwalten.

OTAs pausieren

Mit einer neuen @SystemApi können Geräteeigentümer OTA-Updates, einschließlich Sicherheitsupdates, auf unbestimmte Zeit pausieren.

Leistung

Google Gesundheit 2.0

Android 9 und höher enthalten android.hardware.health HAL 2.0, ein wichtiges Versionsupgrade von health@1.0 HAL. Weitere Informationen finden Sie auf den folgenden Seiten:

APK-Caching-Lösung

Android 9 und höher bieten eine APK-Caching-Lösung für die schnelle Installation vorinstallierter Apps auf einem Gerät, das A/B-Partitionen unterstützt. OEMs können Preloads und beliebte Apps im APK-Cache ablegen, der hauptsächlich in der leeren B-Partition auf neuen Geräten mit A/B-Partitionierung gespeichert wird, ohne den für Nutzer sichtbaren Datenspeicher zu beeinträchtigen.

Profilbasierte Optimierung

Android 9 und höher unterstützt die Verwendung der profilbasierten Optimierung (PGO) von Clang für native Android-Module mit Blueprint-Build-Regeln.

Write-Ahead-Logging

Ein spezieller Modus von SQLiteDatabase namens Kompatibilitäts-Write-Ahead-Logging (WAL) ermöglicht es einer Datenbank, journal_mode=WAL zu verwenden und dabei maximal eine Verbindung pro Datenbank beizubehalten.

Bootzeiten

In Android 9 wurde die Optimierung der Bootzeit geändert, wie unter Bootzeit optimieren beschrieben.

Leistung

Einschränkungen im Hintergrund

Android 9 und höher bieten Hintergrundeinschränkungen, mit denen Nutzer Apps einschränken können, die den Akku belasten. Das System schlägt möglicherweise auch vor, Apps zu deaktivieren, die sich negativ auf den Zustand eines Geräts auswirken.

Geräte ohne Akku

Android 9 unterstützt akkulose Geräte eleganter als in früheren Releases. In Android 9 wurde der Code für akkulose Geräte entfernt, bei denen standardmäßig davon ausgegangen wurde, dass ein Akku vorhanden, zu 100 % geladen und in gutem Zustand ist und dass die Temperatur am Thermistor normal ist.