Versionshinweise zu Android 9

Auf dieser Seite werden die wichtigsten Funktionen des Android 9-Release zusammengefasst und Links zu weiteren Informationen bereitgestellt. Diese Funktionszusammenfassungen sind nach dem Dokumentationsort der Funktion auf dieser Website organisiert. Eine Anleitung zum Verschieben und Umbenennen von Abschnitten finden Sie unter Website-Updates vom August 2018.

Entwickeln

Generisches Systemimage (GSI)

Ein generisches Systemimage (GSI) ist ein Systemimage mit angepassten Konfigurationen für Android-Geräte. Das generische Systemimage (GSI) enthält Details zu den Unterschieden zwischen GSIs für Geräte, die mit Android 9 eingeführt werden, und Geräten, die auf Android 9 aktualisiert werden.

Architektur

Hardwareabstraktionsschicht (HAL)

Abwärtskompatibilität des HIDL-Frameworks

Die Überprüfung der Abwärtskompatibilität des HIDL-Frameworks ist eine Methode zur Überprüfung der Abwärtskompatibilität des Frameworks.

Dynamisch verfügbare HALs

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

HIDL

HIDL MemoryBlock

HIDL MemoryBlock ist eine abstrakte Ebene, die auf hidl_memory, HIDL @1.0::IAllocator und HIDL @1.0::IMapper basiert. Er ist für HIDL-Dienste konzipiert, die mehrere Speicherblöcke haben, die sich einen einzelnen Speicher-Heap teilen.

Device Tree-Overlays

Komprimierte Overlays

Unter Android 9 und höher werden komprimierte Overlays im Image des Gerätebaum-Blob-Overlays (Device Tree Blob Overlay, DTBO) 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 das vereinheitlichte Gerätebaum-Blob an den Kernel übergeben, bevor die in den Gerätebaum-Overlays (Device Tree Overlays, DTOs) definierten Eigenschaften geändert werden.

Versionsverwaltung von DTBO-Bildheadern

Unter Android 9 und höher ist im Header des DTBO-Images ein Versionsfeld enthalten.

DTBO-Überprüfung

Unter Android 9 und höher ist eine DTBO-Partition erforderlich. Wenn Sie dem SoC-Gerätebaum Knoten hinzufügen oder Änderungen an den Eigenschaften vornehmen möchten, muss der Bootloader dynamisch einen gerätespezifischen Gerätebaum über den SoC-Gerätebaum legen. Weitere Informationen finden Sie unter Kompilieren und Überprüfen.

Kernel-Compliance

Unter Android 9 und höher gelten 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-Prüfung

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-Konformität beibehalten.

VNDK-Snapshots

Ein System-Image kann VNDK-Snapshots verwenden, um die richtigen VNDK-Bibliotheken für Anbieter-Images bereitzustellen, auch wenn System- und Anbieter-Images aus verschiedenen Android-Versionen erstellt werden.

Anbieterschnittstellenobjekt (VINTF-Objekt)

Auf den folgenden Seiten im Abschnitt Vendor Interface Object (Anbieterschnittstellenobjekt) werden die Ä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. Unter Android 8.x wurde die Trennung von SoC-spezifischen Komponenten von der Partition /system zur Partition /vendor erzwungen, ohne dass Speicherplatz für OEM-spezifische Komponenten reserviert wurde, die aus dem Android-Build-System erstellt wurden.

Einhaltung des kanonischen Startgrunds

Auf der Seite Canonical Boot Reason werden Änderungen an der Spezifikation für den Boot-Grund des Bootloaders in Android 9 und höher beschrieben.

System als Root

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

Versionsverwaltung von Boot-Image-Headern

In Android 9 und höher enthält der Boot-Image-Header ein Feld zur Angabe der Header-Version. Der Bootloader muss dieses Versionsfeld prüfen und den Header entsprechend parsen.

DTBO in der Wiederherstellung

Um OTA-Fehler aufgrund von Abweichungen zwischen dem Wiederherstellungsimage und der DTBO-Partition auf Geräten, die keine A/B‑Geräte sind, zu vermeiden, muss das Wiederherstellungsimage Informationen aus dem DTBO-Image enthalten.

Anzeige

Display-Aussparungen

Displayausschnitte ermöglichen App-Entwicklern, immersive Edge-to-Edge-Erlebnisse zu schaffen und gleichzeitig Platz für wichtige Sensoren auf der Vorderseite von Geräten zu lassen.

Vorschläge drehen

Aktualisierungen des Verhaltens bei der Bildschirmdrehung Android 9 und höher unterstützen eine nutzerorientierte Steuerung, mit der die Bildschirmdrehung auf das Quer- oder Hochformat festgelegt werden kann, 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 enthält einen Text Classifier-Dienst, der die empfohlene Methode zur Implementierung der Textklassifizierung ist, sowie eine Standarddienstimplementierung.

Breite Farbskala

Android 9 und höher unterstützt Wide-Gamut-Farben, einschließlich:

  • High Dynamic Range (HDR)
  • Inhalte im BT2020-Farbraum verarbeiten, aber nicht als Endziel-Datenraum

Damit ein Gerät Farben mit großem Farbumfang darstellen kann, muss der gesamte Display-Stack (z. B. Bildschirm, Hardware-Composer, GPU) Farben mit großem Farbumfang oder Pufferformate unterstützen. Geräte müssen nicht angeben, dass sie Inhalte mit großem Farbraum unterstützen, auch wenn die Hardware dies tut. Die Funktion „Breiter Farbraum“ sollte jedoch aktiviert sein, um die Hardware optimal zu nutzen. Um eine inkonsistente Darstellung zu vermeiden, sollte die Funktion für Wide-Gamut-Farben während der Laufzeit nicht deaktiviert werden.

Kompatibilität

Android Compatibility Definition Document

Das Android 9 Compatibility Definition Document (CDD) baut auf früheren Versionen auf 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 von Nutzerinteraktionen, insbesondere wenn ein Nutzer Widgets löscht oder manuell hinzufügt. Diese Funktion ist standardmäßig in Launcher3 enthalten.

Hersteller müssen ihre Launcher-Apps (die mit Geräten ausgeliefert werden) aktualisieren, um diese Funktion zu unterstützen, sofern sie nicht auf Launcher3 basieren. OEMs müssen das neue widgetFeatures-Feld in ihrem Standardlauncher unterstützen.

Die Funktion funktioniert nur dann vollständig, wenn die Launcher sie wie erwartet implementieren. AOSP enthält eine Beispielimplementierung. Den bereitgestellten Beispielcode finden Sie in der AOSP-Change-ID Iccd6f965fa3d61992244a365efc242122292c0ca.

Benachrichtigungen über Änderungen des Gerätestatus für Paketinstallationsprogramme

Eine geschützte System-Broadcast kann an Apps mit der Berechtigung INSTALL_PACKAGES gesendet werden, wenn sich Eigenschaften wie das Gebietsschema oder die Anzeigedichte ändern. Empfänger können im Manifest registriert werden und ein Prozess wird aktiviert, um den Broadcast zu empfangen. Dies ist nützlich für Paketinstallationsprogramme, die bei solchen Änderungen zusätzliche Komponenten von Apps installieren möchten. Das ist jedoch ungewöhnlich, da die Konfigurationsänderungen, die diesen Broadcast auslösen können, selten sind.

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

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

Informationsarchitektur

Durch Änderungen an der Informationsarchitektur für die Einstellungen werden mehr Funktionen und eine einfachere Implementierung ermöglicht.

Tests

Atest

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

Compatibility Test Suite

CTS-Downloads

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

CTS-Optionen

Für Android 9 erhält CTS v2 das folgende Kommando und Argument:

  • run retry wiederholt alle Tests, die in den vorherigen Sitzungen fehlgeschlagen sind oder nicht ausgeführt wurden.
  • ‘--shard-count unterteilt einen CTS-Lauf in eine bestimmte Anzahl unabhängiger Chunks, die parallel auf mehreren Geräten ausgeführt werden können.

Außerdem wurde der bisher nicht dokumentierte Befehl --retry-type in dieselbe CTS v2-Konsolenbefehlsreferenz aufgenommen.

Secure Element-Dienst (SE)

Der Secure Element-Dienst prüft, ob es global plattformunterstützte Secure Elements gibt. Dazu wird ermittelt, ob Geräte eine SE HAL-Implementierung haben und wenn ja, wie viele. Dies dient als Grundlage für das Testen der API und der zugrunde liegenden Implementierung des sicheren Elements.

Sensor-Fusion-Box

Die Sensorfusion-Box wird im Sensorfusion-Test und im Test zur Synchronisierung mehrerer Kameras der Camera Image Test Suite (Camera ITS) verwendet. Sie 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:

Weites Sichtfeld von ITS-in-a-box

Das ITS-in-a-box mit großem Sichtfeld ist ein automatisiertes System, mit dem sowohl Kamerasysteme mit großem Sichtfeld als auch mit normalem Sichtfeld in Camera ITS getestet werden können.

Vendor Test Suite

Hostcontroller-Architektur

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

HAL-Tests mit Dienstnamen

HAL-Tests mit VTS-Dienstnamen 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 sollten.

Infrastruktur für automatisierte Tests

Die automatisierte Testinfrastruktur ist eine VTS-Infrastruktur für automatisierte Tests von VTS, CTS oder anderen Tests auf Partnergeräten, auf denen das generische AOSP-Systemimage (GSI) ausgeführt wird.

Fehlerbehebung

Erweiterte Telemetrie

In Android ist Telemetrie der Prozess der automatischen Erfassung von Nutzungs- und Diagnoseinformationen zum Gerät, zum Android-System und zu Apps. In früheren Android-Versionen war der Telemetriestack eingeschränkt und erfasste nicht die Informationen, die zur Identifizierung und Behebung von Problemen mit der Systemzuverlässigkeit sowie Geräte- oder App-Problemen erforderlich sind. Dadurch war es schwierig, wenn nicht gar unmöglich, die Ursachen von Problemen zu ermitteln.

Android 9 enthält die statsd-Telemetriefunktion, die dieses Problem behebt, indem sie bessere Daten schneller erfasst. 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 integrieren können. Weitere Informationen zur Integration Ihres biometrischen Verfahrens, um BiometricPrompt einzuschließen, finden Sie unter Biometrisches Verfahren.

Dynamische Analyse

Android 9 bietet Unterstützung für weitere Tools zur Analyse und Eindämmung von Sicherheitslücken.

Control Flow Integrity (CFI)

Control Flow Integrity (CFI) ist ein Sicherheitsmechanismus, der Änderungen am ursprünglichen Kontrollflussdiagramm einer kompilierten Binärdatei verhindert und dadurch solche Angriffe deutlich erschwert.

Kernel CFI

Zusätzlich zu System-CFI, das standardmäßig aktiviert ist, bietet Android 9 und höher Unterstützung für Kernel-CFI.

Verschlüsselung

Dateibasierte Verschlüsselung

Die dateibasierte Verschlüsselung (File-Based Encryption, FBE) wurde aktualisiert, um mit adoptable storage zu funktionieren. Auf neuen Geräten sollte die dateibasierte Verschlüsselung anstelle der vollständigen Datenträgerverschlüsselung verwendet werden.

Verschlüsselung von Metadaten

Android 9 und höher unterstützt die Metadatenverschlüsselung, sofern die Hardware dies unterstützt. Bei der Metadatenverschlüsselung wird ein einzelner Schlüssel verwendet, der beim Booten vorhanden ist, um alle nicht verschlüsselten Inhalte mit der dateibasierten Verschlüsselung zu verschlüsseln.

Schlüsselspeicher

Android 9 und höher umfasst Keymaster 4 mit den folgenden Funktionen.

StrongBox

Android 9 und höher unterstützt Android-Schlüsselspeicher-Schlüssel, die in einer physisch separaten CPU gespeichert und verwendet werden, die speziell für Anwendungen mit hoher Sicherheit entwickelt wurde, z. B. ein eingebettetes Secure Element (SE). StrongBox Keymaster ist eine Implementierung der Keymaster-HAL in separater sicherer Hardware. Eine StrongBox hat folgende Eigenschaften:

  • Diskrete CPU
  • Integrierter sicherer Speicher
  • Hochwertiger echter Zufallszahlengenerator
  • Manipulationssichere Verpackung
  • Schutz vor Seitenkanalattacken

Sicherer Schlüsselimport

Um einen Schlüssel sicher in Keymaster 4 zu importieren, wird ein außerhalb des Geräts erstellter Schlüssel mit einer Spezifikation der Autorisierungen verschlüsselt, die definieren, wie der Schlüssel verwendet werden darf.

3DES-Unterstützung

Keymaster 4 umfasst 3DES zur Kompatibilität mit Legacy-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 für die Bindung der Schlüsselversion so geändert, dass für jede Partition separate Patch-Ebenen verwendet werden. So kann jede Partition unabhängig aktualisiert werden und es gibt trotzdem einen Rollback-Schutz.

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 anzuzeigen, in der er gebeten wird, einer kurzen Erklärung zuzustimmen. Mit dieser Bestätigung kann eine App noch einmal bestätigen, dass der Nutzer eine vertrauliche Transaktion wie eine Zahlung abschließen möchte.

SELinux

SELinux-Sandbox pro App

Die Anwendungs-Sandbox bietet neuen Schutz und neue Testläufe, um sicherzustellen, dass alle nicht privilegierten Apps, die auf Android 9 und höher ausgerichtet sind, in individuellen SELinux-Sandboxes ausgeführt werden.

Treble-SELinux-Änderungen

Aktualisierungen von Treble SELinux in Android 9 und höher werden auf mehreren Seiten im SELinux-Abschnitt dokumentiert.

Anbieterinitialisierung

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.

Systemattribute

In Android 9 wird die unnötige Freigabe von Systemeigenschaften zwischen system- und vendor-Partitionen eingeschränkt. Außerdem wird eine Methode bereitgestellt, um die Konsistenz zwischen freigegebenen Systemeigenschaften zu gewährleisten.

SELinux-Attributtests

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

Audio

Audioeffekte mit hoher Auflösung

Zu den Updates für Audioeffekte mit hoher Auflösung gehören die Umstellung der Effektverarbeitung von int16 auf das Float-Format sowie eine Erhöhung der Anzahl der gleichzeitigen Client-Ausgabetracks, des maximalen Client-/Serverspeichers und der Anzahl der gemischten Tracks insgesamt.

Kamera

Externe USB-Kameras

Android 9 und höher unterstützt die Verwendung von Plug-and-Play-USB-Kameras (d. h. Webcams) über die Standard-Android Camera2 API und die Kamera-HIDL-Schnittstelle.

Bewegungserkennung

Kamerageräte können die Funktion zur 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 Kamerageräten besteht, die in dieselbe Richtung zeigen.

Sitzungsparameter

Durch die Implementierung von Sitzungsparametern können Verzögerungen reduziert werden, da Kamera-Clients während der Initialisierungsphase der Aufnahmesitzung aktiv eine Teilmenge kostspieliger Anfrageparameter konfigurieren können.

Puffer mit einem Erzeuger und mehreren Verbrauchern

Single producer, multiple consumer camera buffer transport (Transport von Kamerabuffern mit einem Producer und mehreren Consumern) ist eine Reihe von Methoden, mit denen Kameraclienten Ausgabeflä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 eine verbesserte Unterstützung für Mobilfunkanbieter, die Datentarife implementieren, indem sie die SubscriptionPlan APIs verwenden.

Anruf-Apps von Drittanbietern

In Android 9 und höher sind APIs verfügbar, mit denen Drittanbieter-Anruf-Apps eingehende Anrufe von Mobilfunkanbietern gleichzeitig verarbeiten und Anrufe in der Anrufliste des Systems protokollieren können.

Mobilfunkanbieter

Identifizierung des Mobilfunkanbieters

Unter Android 9 wird in AOSP eine Mobilfunkanbieter-ID-Datenbank hinzugefügt, um die Mobilfunkanbieter-Identifizierung zu erleichtern. Die Datenbank minimiert doppelte Logik und fragmentierte App-Erlebnisse, da sie eine gemeinsame Möglichkeit bietet, Mobilfunkanbieter zu identifizieren.

eSIM

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

Unterstützung von Dual-SIM für IMS-Einstellungen

In Android 9 und höher wurden die Nutzereinstellungen für das IP Multimedia Subsystem (IMS) verbessert. Sie können VoLTE (Voice over LTE), Videoanrufe und WLAN-Telefonie für jedes Abo einzeln einrichten, anstatt diese Einstellungen für alle Abos zu teilen.

Übertragungen zum SIM-Status

In Android 9 und höher ist Intent.ACTION_SIM_STATE_CHANGED veraltet. Es werden zwei separate Broadcasts für den Kartenstatus und den Kartenanwendungsstatus 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 auf Änderungen des Anwendungsstatus reagieren. Empfänger, die nur wissen müssen, ob Kartenanwendungen bereit sind, müssen nicht auf Änderungen des Kartenstatus reagieren.

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

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

WLAN

WLAN eines Mobilfunkanbieters

Mit der Funktion WLAN des Mobilfunkanbieters können Geräte automatisch eine Verbindung zu WLANs herstellen, die vom Mobilfunkanbieter eingerichtet wurden. In Gebieten mit hoher Auslastung oder mit minimaler Mobilfunkabdeckung, z. B. in einem Stadion oder einer U-Bahn-Station, kann das WLAN des Mobilfunkanbieters die Verbindung verbessern und den Traffic entlasten.

MAC‑Randomisierung

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

WLAN automatisch aktivieren

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

WLAN-Umlaufzeit

Mit der WLAN-Round-Trip-Time (RTT) können Geräte die Entfernung zu anderen unterstützten 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 es Apps, eine höhere Standortgenauigkeit und ‑erkennung zu nutzen.

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 sollte. Diese Modelle bieten Nutzern eine zuverlässige und nahtlose Erfahrung, da sie Verbindungsunterbrechungen vermeiden.

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

Gleichzeitigkeit von WLAN-STA/AP

Gleichzeitigkeit von WLAN-STA/AP bedeutet, dass Geräte gleichzeitig im Stationsmodus (STA) und im Zugangspunktmodus (AP) betrieben werden können. Bei Geräten, die Dualband-Simultan-WLAN (DBS) unterstützen, ergeben sich dadurch Möglichkeiten wie die, das STA-WLAN nicht zu unterbrechen, wenn ein Nutzer einen Hotspot (SoftAP) aktivieren möchte.

Verbesserungen bei WiFiStateMachine

WifiStateMachine ist die Hauptklasse, die zum Steuern von WLAN-Aktivitäten, zum Koordinieren von Nutzereingaben (Betriebsmodi: Hotspot, Scan, Verbindung oder Aus) und zum Steuern von WLAN-Netzwerkaktionen (z. B. Scannen oder Verbinden) verwendet wird.

In Android 9 und höher wurden der WLAN-Framework-Code und die Implementierung von WifiStateMachine neu strukturiert. Dies führt zu einer geringeren Codegröße, einer leichter nachvollziehbaren WLAN-Steuerungslogik, einer verbesserten Steuerungsgranularität sowie einer erhöhten Abdeckung und Qualität von Unittests.

Auf übergeordneter Ebene kann sich WifiStateMachine in einem von vier Zuständen befinden:

  • Client-Modus (Verbindung und Scan möglich)
  • Nur scannen
  • SoftAP-Modus (WLAN-Hotspot)
  • Deaktiviert (WLAN vollständig deaktiviert)

Jeder WLAN-Modus hat unterschiedliche Anforderungen für die Ausführung von Diensten und sollte einheitlich eingerichtet werden, wobei nur die für den Betrieb relevanten Ereignisse verarbeitet werden. Die neue Implementierung beschränkt den Code auf Ereignisse, die sich auf diesen Modus beziehen. Dadurch wird die Debugging-Zeit verkürzt und das Risiko, aufgrund von Komplexität neue Fehler einzuführen, verringert. Neben der expliziten Verarbeitung der Modusfunktionalität wird das Thread-Management einheitlich gehandhabt und die Verwendung asynchroner Channels als Synchronisationsmechanismus entfällt.

Aktualisierungen der WLAN-Berechtigung

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 Einstellungsseite unter Einstellungen > Apps & Benachrichtigungen > Spezieller App-Zugriff > WLAN-Steuerung deaktivieren.

Apps müssen in der Lage sein, Fälle zu verarbeiten, in denen die Berechtigung CHANGE_WIFI_STATE nicht erteilt wird.

Um dieses Verhalten zu prüfen, führen Sie die Robolectric-Tests und manuellen Tests aus.

Für manuelle Tests:

  1. Gehen Sie zu Einstellungen > Apps & 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 Berechtigung CHANGE_WIFI_STATE nicht erteilt wird.

Einstellung von WPS

Aus Sicherheitsgründen ist Wi-Fi Protected Setup (WPS) in WiFiManager veraltet 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ützt die Implementierung der Vulkan 1.1-Grafik-API.

WinScope-Tool für das Tracing von Fensterübergängen

Android 9 und höher enthält das WinScope-Tool zum Aufzeichnen von Fensterübergängen. WinScope bietet Infrastruktur und Tools zum Aufzeichnen und Analysieren des Fenstermanagerstatus während und nach Übergängen. Damit können Fensterübergänge aufgezeichnet und durchlaufen werden, während alle relevanten Fensterverwaltungsstatus in einer Tracedatei aufgezeichnet werden. Sie können diese Daten verwenden, um die Umstellung zu wiederholen und durchzugehen.

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

Interaktion

Audio im Auto

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

Das Neural Networks (NN) HAL definiert eine Abstraktion der verschiedenen Beschleuniger. Die Treiber für diese Beschleuniger müssen diesem HAL entsprechen.

Fahrzeug-HAL

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

GNSS-Satellitenauswahl

Bei Verwendung neuer GNSS-HALs (Global Navigation Satellite System) (v1.1+) überwacht das Android-Framework die Android-Einstellungen. Partner können die Einstellungen über die Google Play-Dienste oder andere Systemupdates ändern. Diese Einstellungen geben an, 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 wie Schaltsekunden, Tages- oder Wochennummern-Rollovers gemischt werden.

GNSS-Hardwaremodell

In 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-Schnittstelle implementieren und einen Handle an die HAL übergeben. Die GNSS HAL übergibt die Informationen zum Hardwaremodell über die Methode LocationManager#getGnssHardwareModelName(). Gerätehersteller sollten mit ihren GNSS HAL-Anbietern zusammenarbeiten, um diese Informationen nach Möglichkeit bereitzustellen.

Berechtigungen

Aktualisierungen der diskretionären Zugriffssteuerung konfigurieren

Konfigurieren der DAC (Discretionary Access Control) enthält Aktualisierungen des Mechanismus für Android-IDs (AIDs) zum Erweitern der Dateisystemfunktionen.

Berechtigungen für privilegierte Apps auf die Zulassungsliste setzen

Wenn in Android 9 und höher Berechtigungen verweigert werden sollen, bearbeiten Sie das XML, sodass anstelle des in früheren Releases verwendeten permission-Tags das deny-permission-Tag 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 besser geeignete 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 onCapabilitiesChanged()-Callback jedoch automatisch ausgelöst, wenn sich die geschätzte Bandbreite erheblich ändert. Der Aufruf von requestBandwidthUpdate() hat dann keine Auswirkungen. Die zugehörigen getLinkDownstreamBandwidthKbps()- und getLinkUpstreamBandwidthKbps()-Felder werden mit aktualisierten Informationen aus der physischen Schicht gefü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 verborgenes Menü verfügbar, damit Feldtester die aktuellen Informationen abrufen können.

eBPF-Traffic-Monitoring

Das eBPF-Tool für Netzwerk-Traffic verwendet eine Kombination aus Kernel- und Nutzerbereichsimplementierung, um die Netzwerknutzung auf einem Gerät seit dem letzten Gerätestart zu überwachen. Dieses Tool bietet zusätzliche Funktionen wie das Taggen von Sockets, das Trennen von Vordergrund- und Hintergrund-Traffic sowie eine Firewall pro UID, um Apps je nach Gerätestatus den Netzwerkzugriff zu verwehren.

Auf niedrigere APIs zurücksetzen

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

Wenn ein OEM die Sicherungs-Agents für eines der Systempakete (android, system, settings) ändert, sollten diese Agents Sicherungssätze, die auf höheren Versionen der Plattform erstellt wurden, ohne Absturz und mit der Wiederherstellung von mindestens einigen Daten verarbeiten können.

Verwenden Sie einen Validator, um nach ungültigen Werten in den Sicherungsdaten zu suchen 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. Eine zusätzliche Implementierung ist nur erforderlich, wenn der Gerätehersteller einen der im ROM enthaltenen Sicherungs-Agents erweitert oder einen benutzerdefinierten Agent hinzufügt.

Diese Funktion ermöglicht die Wiederherstellung von Systemen aus zukünftigen Versionen der Plattform. Es ist jedoch davon auszugehen, dass die wiederhergestellten Daten nicht vollständig sind. Die folgenden Anleitungen gelten für die folgenden Sicherungs-Agents:

  • PackageManagerBackupAgent unterstützt zukünftige Versionen der Sicherungsdaten über die Formatversionierung. Erweiterungen hier müssen mit dem aktuellen Wiederherstellungscode kompatibel sein oder den Anweisungen in der Klasse folgen, die das Erhöhen der entsprechenden Konstanten umfassen.

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

  • SettingsBackupAgent gibt restoreAnyVersion = true in Android 9 und höher an. Teilweise Unterstützung über Validatoren Eine Einstellung kann aus einer höheren API-Version wiederhergestellt werden, wenn im Zielbetriebssystem ein Validator dafür vorhanden ist. Jede Einstellung muss von einem Validator begleitet werden. Weitere Informationen finden Sie im Kurs.

  • Bei jedem benutzerdefinierten Sicherungs-Agent, der im ROM enthalten ist, sollte der Versionscode erhöht werden, wenn eine inkompatible Änderung am Sicherungsdatenformat vorgenommen wird. Außerdem sollte restoreAnyVersion = false (Standard) verwendet werden, wenn der Agent nicht für die Verarbeitung von Sicherungsdaten aus einer zukünftigen Version des Codes vorbereitet ist.

Unternehmen

Verbesserungen bei verwalteten Profilen

Durch UX-Änderungen für verwaltete Profile können Nutzer das verwaltete Profil leichter erkennen, darauf zugreifen und es steuern.

OTAs pausieren

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

Leistung

Health 2.0

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

APK-Caching-Lösung

Android 9 und höher umfasst 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 platzieren, der hauptsächlich in der leeren B-Partition auf neuen Geräten mit A/B-Partitionierung gespeichert ist, ohne den für Nutzer sichtbaren Datenbereich zu beeinträchtigen.

Profilgesteuerte Optimierung

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

Write-Ahead-Logging

Ein spezieller Modus von SQLiteDatabase namens Compatibility Write-Ahead Logging (WAL) ermöglicht es einer Datenbank, journal_mode=WAL zu verwenden und gleichzeitig maximal eine Verbindung pro Datenbank aufrechtzuerhalten.

Bootzeiten

In Android 9 wird die Optimierung der Startzeit geändert, wie unter Optimizing Boot Times beschrieben.

Leistung

Einschränkungen bei der Hintergrundnutzung

In Android 9 und höher gibt es Einschränkungen für den Hintergrund, mit denen Nutzer Apps einschränken können, die möglicherweise Akkuleistung verbrauchen. 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

Unter Android 9 werden Geräte ohne Akku eleganter als in früheren Releases behandelt. In Android 9 wurde der Code für akkulose Geräte entfernt, bei denen standardmäßig davon ausgegangen wurde, dass ein Akku vorhanden ist, der zu 100 % aufgeladen ist und sich in gutem Zustand befindet, und dass der Thermistor eine normale Temperatur anzeigt.