Versionshinweise zu Android 9

Diese Seite fasst die wichtigsten Funktionen der Android 9-Version zusammen und bietet Links zu zusätzlichen Informationen. Diese Funktionszusammenfassungen sind nach dem Dokumentationsort der Funktion auf dieser Website geordnet. Eine Anleitung zum Verschieben und Umbenennen von Abschnitten finden Sie in den Website-Updates vom August 2018 .

Bauen

Generisches System-Image (GSI)

Ein generisches Systemabbild (GSI) ist ein Systemabbild 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 gestartet werden, und Geräte, die auf Android 9 aktualisiert werden.

Die Architektur

Hardware-Abstraktionsschicht (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 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. Es ist für HIDL-Dienste konzipiert, die über mehrere Speicherblöcke verfügen, die sich einen einzigen Speicherheap teilen.

Gerätebaum-Overlays

Komprimierte Overlays

Android 9 und höher bietet Unterstützung für komprimierte Overlays im DTBO-Bild (Device Tree Blob Overlay), wenn Version 1 des Headers der Gerätebaumtabelle verwendet wird.

DTO-Updates

Android 9 und höher erfordert, dass der Bootloader den einheitlichen Gerätebaum-Blob an den Kernel übergibt, bevor er die in den Gerätebaum-Overlays (DTOs) definierten Eigenschaften ändert.

DTBO-Image-Header-Versionierung

Android 9 und höher enthält ein Versionsfeld im DTBO-Bildheader.

DTBO-Überprüfung

Für Android 9 und höher ist eine DTBO-Partition erforderlich. Um Knoten hinzuzufügen oder Änderungen an den Eigenschaften im SoC-DT vorzunehmen, muss der Bootloader dynamisch einen gerätespezifischen DT über den SoC-DT legen. Weitere Informationen finden Sie unter Kompilieren und Verifizieren .

Kernel-Konformität

Für 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 diesen Seiten:

Anbieter NDK

Design-Änderungen

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

ABI-Checker

Auf der Seite „ABI-Stabilität“ wird der ABI-Prüfer (Application Binary Interface) beschrieben, der sicherstellt, dass an VNDK-Bibliotheken vorgenommene Änderungen die ABI-Konformität wahren.

VNDK-Schnappschüsse

Ein System-Image kann VNDK-Snapshots verwenden, um Anbieter-Images die richtigen VNDK-Bibliotheken bereitzustellen, selbst wenn System- und Anbieter-Images aus unterschiedlichen Android-Versionen erstellt werden.

Anbieterschnittstellenobjekt (VINTF-Objekt)

Auf den folgenden Seiten im Abschnitt „Vendor Interface Object“ werden Aktualisierungen in Android 9 und höher beschrieben:

HIDL-Abkündigungsplan

Auf den folgenden Seiten wird beschrieben, wie Android HIDL-HALs ablehnt und entfernt:

Bootloader

Produktpartitionen

Android 9 und höher unterstützt das Erstellen von /product Produktpartitionen mithilfe des Android-Buildsystems. Zuvor erzwang Android 8.x die Trennung von System-on-Chip (SoC)-spezifischen Komponenten von der /system Partition zur /vendor Partition, ohne Platz für OEM-spezifische Komponenten bereitzustellen, die aus dem Android-Build-System erstellt wurden.

Einhaltung kanonischer Startgründe

Auf der Seite Canonical Boot Reason werden Änderungen an der Spezifikation des Bootloader-Startgrunds in Android 9 und höher beschrieben.

System als Root

Alle Geräte, die mit Android 9 und höher gestartet werden, müssen system-as-root verwenden, wodurch ramdisk.img in system.img (auch bekannt als no-ramdisk) zusammengeführt wird, das wiederum als rootfs gemountet wird.

Versionierung des Boot-Image-Headers

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

DTBO im Aufschwung

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

Anzeige

Ausschnitte anzeigen

Displayausschnitte ermöglichen es App-Entwicklern, immersive, randlose Erlebnisse zu schaffen und gleichzeitig Platz für wichtige Sensoren auf der Vorderseite der Geräte zu lassen.

Vorschläge drehen

Zu den Aktualisierungen des Bildschirmdrehverhaltens von Android 9 und höher gehört die Unterstützung einer benutzerorientierten Steuerung, um die Bildschirmdrehung entweder im Quer- oder Hochformat festzulegen, selbst 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 umfasst einen Textklassifizierungsdienst , der die empfohlene Methode zur Implementierung der Textklassifizierung darstellt, sowie eine Standarddienstimplementierung.

Breites Farbspektrum

Android 9 und höher bietet Unterstützung für einen breiten Farbraum, einschließlich:

  • Hoher Dynamikbereich (HDR)
  • Verarbeiten von Inhalten im BT2020-Farbraum, jedoch nicht als Endziel-Datenraum

Um Farben mit großem Farbumfang zu verwenden, muss der gesamte Anzeigestapel eines Geräts (z. B. Bildschirm, Hardware-Composer, GPU) Farben oder Pufferformate mit großem Farbumfang unterstützen. Geräte müssen keine Unterstützung für Inhalte mit großem Farbspektrum beanspruchen, selbst wenn die Hardware dies unterstützt. Allerdings sollte Wide-Gamut-Farben aktiviert sein, um die Hardware optimal nutzen zu können. Um ein inkonsistentes visuelles Erlebnis zu vermeiden, sollte der Wide-Gamut-Farbraum während der Laufzeit nicht deaktiviert werden.

Kompatibilität

Dokument zur Definition der Android-Kompatibilität

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

Einstellungen

Bessere App-Widgets

Das Android-App-Widget-Framework bietet eine bessere Sichtbarkeit der Benutzerinteraktionen, insbesondere wenn ein Benutzer Widgets löscht oder manuell hinzufügt. Diese Funktionalität ist standardmäßig in Launcher3 enthalten.

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

Beachten Sie, dass die Funktion nur dann durchgehend funktioniert, wenn die Launcher sie wie erwartet implementieren. AOSP enthält eine Beispielimplementierung. Den bereitgestellten Beispielcode finden Sie in der AOSP-Änderungs-ID Iccd6f965fa3d61992244a365efc242122292c0ca.

Benachrichtigungen über Gerätestatusänderungen an Paketinstallationsprogramme

Eine geschützte Systemübertragung kann an Apps gesendet werden, die über die INSTALL_PACKAGES Berechtigung verfügen, wenn sich Eigenschaften wie Gebietsschema oder Anzeigedichte ä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 Paketinstallateure, die bei solchen Änderungen zusätzliche Komponenten von Apps installieren möchten, was ungewöhnlich ist, da die Konfigurationsänderungen, die diese Übertragung auslösen können, selten sind.

Der Quellcode für die Benachrichtigung über Gerätestatusänderungen befindet sich an den folgenden Orten 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

Änderungen an der Informationsarchitektur für die Einstellungen-App sorgen für mehr Funktionalität und eine einfachere Implementierung.

Tests

Ein Test

Mit dem Atest- Befehlszeilentool können Sie Android-Tests lokal erstellen, installieren und ausführen und so die Wiederholung von Tests erheblich beschleunigen, ohne dass Kenntnisse über die Befehlszeilenoptionen des Trade Federation-Test-Harness erforderlich sind.

Kompatibilitätstestsuite

CTS-Downloads

Compatibility Test Suite (CTS)-Pakete, die Android 9 unterstützen, sind auf der CTS-Downloads- Seite 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 den folgenden Befehl und das folgende Argument :

  • run retry wiederholt alle Tests, die in den vorherigen Sitzungen fehlgeschlagen sind oder nicht ausgeführt wurden.
  • '--shard-count teilt die Ausführung eines CTS in eine bestimmte Anzahl unabhängiger Blöcke auf, um auf mehreren Geräten parallel ausgeführt zu werden.

Darüber hinaus wurde der zuvor nicht dokumentierte Befehl --retry-type derselben CTS v2-Konsolenbefehlsreferenz hinzugefügt.

Secure Element (SE)-Dienst

Der Secure Element-Dienst prüft, ob von der globalen Plattform unterstützte sichere Elemente vorhanden sind, indem er ermittelt, ob und wie viele Geräte über eine SE HAL-Implementierung verfügen. Dies dient als Grundlage zum Testen der API und der zugrunde liegenden Implementierung sicherer Elemente.

Sensorfusionsbox

Die Sensorfusionsbox wird im Sensorfusionstest und Multikamera-Synchronisierungstest der Camera Image Test Suite (Camera ITS) verwendet und bietet eine konsistente Testumgebung zum Messen der Zeitstempelgenauigkeit der Kamera und anderer Sensoren für Android-Telefone. Weitere Informationen finden Sie auf diesen Seiten:

Großes Sichtfeld ITS-in-a-box

Das Weitfeld-Sichtfeld ITS-in-a-box ist ein automatisiertes System zum Testen von Kamerasystemen mit Weitfeld-Sichtfeld (WFoV) und regulärem Sichtfeld (RFoV) im Kamera-ITS.

Anbieter-Testsuite

Host-Controller-Architektur

Die Host-Controller-Architektur der Vendor Test Suite (VTS) ist die Architektur des VTS-Test-Frameworks, das in seinen cloudbasierten Testbereitstellungsdienst integriert ist.

Dienstnamenbasierter HAL-Test

HAL-Tests mit Kenntnis des VTS-Dienstnamens 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 zur Verwendung der Gerätekonfiguration, um zu ermitteln, welche VTS-Tests für dieses Geräteziel übersprungen werden sollten.

Automatisierte Testinfrastruktur

Die automatisierte Testinfrastruktur ist eine VTS-Infrastruktur zum automatisierten Testen von VTS, CTS oder anderen Tests auf Partnergeräten, auf denen das AOSP Generic System Image (GSI) ausgeführt wird.

Debuggen

Erweiterte Telemetrie

In Android ist Telemetrie der Prozess der automatischen Erfassung von Nutzungs- und Diagnoseinformationen über das Gerät, das Android-System und Apps. In früheren Android-Versionen war der Telemetrie-Stack begrenzt und erfasste nicht die Informationen, die zur Identifizierung und Lösung von Systemzuverlässigkeits- und Geräte- oder App-Problemen erforderlich waren. Dies machte es schwierig, wenn nicht sogar unmöglich, die Grundursachen von Problemen zu identifizieren.

Android 9 enthält die statsd Telemetriefunktion, die diesen Mangel behebt, indem bessere Daten schneller erfasst werden. statsd sammelt App-Nutzungs-, Batterie- und Prozessstatistiken sowie Abstürze. Die Daten werden analysiert und zur Verbesserung von Produkten, Hardware und Dienstleistungen genutzt.

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

Sicherheitsfunktionen

App-Signierung

Das v3-APK-Signaturschema unterstützt die APK-Schlüsselrotation.

Biometrische Unterstützung

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 Biometrie-Stacks mit BiometricPrompt finden Sie unter Biometrie .

Dynamische Analyse

Android 9 bietet Unterstützung für weitere Exploit-Abwehr- und Analysetools .

Kontrollflussintegrität (CFI)

Kontrollflussintegrität (CFI) ist ein Sicherheitsmechanismus, der Änderungen am ursprünglichen Kontrollflussdiagramm einer kompilierten Binärdatei verhindert, wodurch die Durchführung solcher Angriffe erheblich erschwert wird.

Kernel-CFI

Neben System-CFI, das standardmäßig aktiviert ist, bietet Android 9 und höher Unterstützung für Kernel Control Flow Integrity (CFI) .

Verschlüsselung

Dateibasierte Verschlüsselung

Die dateibasierte Verschlüsselung (FBE) wurde aktualisiert, um mit anpassbarem Speicher zu funktionieren. Neue Geräte sollten eine dateibasierte Verschlüsselung anstelle einer vollständigen Festplattenverschlüsselung verwenden.

Metadatenverschlüsselung

Android 9 und höher bietet Unterstützung für Metadatenverschlüsselung , sofern Hardwareunterstützung vorhanden ist. Bei der Metadatenverschlüsselung verwendet ein einzelner Schlüssel, der beim Booten vorhanden ist, die dateibasierte Verschlüsselung, um alle unverschlüsselten Inhalte zu verschlüsseln.

Schlüsselspeicher

Android 9 und höher enthält Keymaster 4 , das über diese Funktionen verfügt.

Geldschrank

Android 9 und höher umfasst Unterstützung für Android Keystore-Schlüssel, die in einer physisch separaten CPU gespeichert und verwendet werden, die speziell für Hochsicherheitsanwendungen entwickelt wurde, beispielsweise ein eingebettetes sicheres Element (SE) . StrongBox Keymaster ist eine Implementierung des Keymaster HAL in diskreter sicherer Hardware. Eine StrongBox verfügt über:

  • Diskrete CPU
  • Integrierter sicherer Speicher
  • Hochwertiger echter Zufallszahlengenerator
  • Manipulationssichere Verpackung
  • Seitenkanalwiderstand

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 Berechtigungen verschlüsselt, die definieren, wie der Schlüssel verwendet werden darf.

3DES-Unterstützung

Keymaster 4 enthält 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, hat Keymaster 4 das Schlüsselversionsbindungsmodell geändert, um für jede Partition separate Patch-Level zu haben. Dadurch kann jede Partition unabhängig aktualisiert werden, während gleichzeitig ein Rollback-Schutz gewährleistet ist.

Android-geschützte Bestätigungs-API

Unterstützte Geräte, die mit installiertem Android 9 gestartet werden, bieten Entwicklern die Möglichkeit, die Android Protected Confirmation API zu verwenden. Mit dieser API können Apps eine Instanz von ConfirmationPrompt verwenden, um dem Benutzer eine Aufforderung anzuzeigen und ihn aufzufordern, eine kurze Erklärung zu genehmigen. Mit dieser Anweisung kann eine App erneut bestätigen, dass der Benutzer eine sensible Transaktion abschließen möchte, beispielsweise eine Zahlung.

SELinux

App-spezifische SELinux-Sandbox

Die Anwendungssandbox verfügt über neue Schutzmaßnahmen und Testfälle, um sicherzustellen, dass alle nicht privilegierten Apps, die auf Android 9 und höher abzielen, individuelle SELinux-Sandboxen ausführen.

Dreifache SELinux-Änderungen

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

Anbieter-Init

Vendor Init schließt die Lücke in der Treble-System/Anbieter-Aufteilung, indem es eine separate SELinux-Domäne verwendet, um /vendor Befehle mit herstellerspezifischen Berechtigungen auszuführen.

Systemeigenschaften

Android 9 verhindert, dass Systemeigenschaften unnötigerweise zwischen system und vendor geteilt werden, und bietet eine Methode zur Gewährleistung der Konsistenz zwischen gemeinsam genutzten Systemeigenschaften.

SELinux-Attributtests

Android 9 enthält neue Build-Time-Tests , die sicherstellen, dass alle Dateien an bestimmten Speicherorten über die entsprechenden Attribute verfügen. Beispielsweise verfügen alle Dateien in sysfs über das erforderliche Attribut sysfs_type .

Audio

Hochauflösende Audioeffekte

Zu den Aktualisierungen für hochauflösende Audioeffekte gehören die Konvertierung der Effektverarbeitung vom int16- in das Float-Format sowie eine Erhöhung der gleichzeitigen Client-Ausgabespuren, des maximalen Client-/Serverspeichers und der Gesamtzahl der gemischten Spuren.

Kamera

Externe USB-Kameras

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

Bewegungsverfolgung

Kamerageräte können die Fähigkeit zur Bewegungsverfolgung ankündigen .

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 die gleiche Richtung zeigen.

Sitzungsparameter

Durch die Implementierung von Sitzungsparametern können Verzögerungen reduziert werden, da Kamera-Clients im Rahmen der Initialisierungsphase der Aufnahmesitzung eine Teilmenge kostspieliger Anforderungsparameter aktiv konfigurieren können.

Einzelproduzent, Puffer für mehrere Konsumenten

Beim Kamerapuffertransport für einen einzelnen Produzenten und mehrere Verbraucher handelt es sich um eine Reihe von Methoden, die es Kamera-Clients ermöglichen, Ausgabeoberflächen dynamisch hinzuzufügen und zu entfernen, während die Aufnahmesitzung aktiv ist und das Kamera-Streaming läuft.

Konnektivität

Anrufen und Nachrichten senden

Implementieren Sie Datenpläne

Android 9 und höher bietet verbesserte Unterstützung für Netzbetreiber, die Datenpläne mithilfe der SubscriptionPlan-APIs implementieren .

Anruf-Apps von Drittanbietern

Android 9 und höher bietet APIs, die es Anruf-Apps von Drittanbietern (3P) ermöglichen, gleichzeitig eingehende Anrufe von Mobilfunkanbietern zu verarbeiten und Anrufe im Systemanrufprotokoll zu protokollieren.

Träger

Identifizierung des Spediteurs

In Android 9 fügt AOSP eine Carrier-ID-Datenbank hinzu, um die Carrier-Identifizierung zu erleichtern. Die Datenbank minimiert doppelte Logik und fragmentierte App-Erlebnisse, indem sie eine gemeinsame Möglichkeit zur Identifizierung von Netzbetreibern bietet.

eSIM

Embedded SIM (eSIM oder eUICC) ist die neueste Technologie, die es Mobilfunknutzern ermöglicht, ein Mobilfunkanbieterprofil herunterzuladen und den Dienst eines Mobilfunkanbieters zu aktivieren, ohne über eine physische SIM-Karte zu verfügen. In Android 9 und höher stellt das Android-Framework Standard-APIs für den Zugriff auf eSIM und die Verwaltung von Abonnementprofilen auf eSIM bereit. Weitere Informationen finden Sie unter:

Multi-SIM-Unterstützung für IMS-Einstellungen

Android 9 und höher bietet Verbesserungen an den Benutzereinstellungen für das IP-Multimedia-Subsystem (IMS) . Sie können Voiceover-LTE (VoLTE), Videoanrufe und Wi-Fi-Anrufe pro Abonnement einrichten, anstatt diese Einstellungen für alle Abonnements zu teilen.

SIM-Statusübertragungen

In Android 9 und höher ist Intent.ACTION_SIM_STATE_CHANGED veraltet und 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 .

Mit diesen Änderungen müssen Empfänger, die nur wissen müssen, ob eine Karte vorhanden ist, nicht auf Änderungen des Anwendungsstatus achten, und Empfänger, die nur wissen müssen, ob Kartenanwendungen bereit sind, müssen nicht auf Änderungen im Kartenstatus achten.

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

Die Absichten werden nicht erneut gesendet, wenn Sie das Gerät entsperren. Empfänger, die auf Broadcasts angewiesen sind, die vor dem Entsperren gesendet werden, müssen entweder directBootAware verwenden oder den Status nach dem Entsperren durch den Benutzer abfragen. Die Zustände können über die entsprechenden APIs im TelephonyManager getSimCardState() und getSimApplicationState() abgefragt werden.

W-lan

Mobilfunkanbieter-WLAN

Mit der Carrier-Wi-Fi- Funktion können Geräte automatisch eine Verbindung zu vom Carrier implementierten Wi-Fi-Netzwerken herstellen. In Bereichen mit hohem Verkehrsaufkommen oder mit minimaler Mobilfunkabdeckung, wie etwa einem Stadion oder einer U-Bahn-Station, trägt Carrier-WLAN dazu bei, die Konnektivität zu verbessern und den Datenverkehr zu entlasten.

MAC-Randomisierung

Durch die MAC-Randomisierung können Geräte zufällige MAC-Adressen verwenden, wenn sie nach neuen Netzwerken suchen, obwohl sie derzeit keinem Netzwerk zugeordnet sind. In Android 9 und höher kann eine Entwickleroption aktiviert werden, um zu veranlassen, dass ein Gerät beim Herstellen einer Verbindung mit einem Wi-Fi-Netzwerk eine zufällige MAC-Adresse verwendet.

WLAN automatisch einschalten

Wenn die Funktion „Wi-Fi automatisch einschalten“ aktiviert ist, wird Wi-Fi automatisch wieder aktiviert, wenn sich das Gerät in der Nähe eines gespeicherten Wi-Fi-Netzwerks mit einem ausreichend hohen relativen Empfangssignalstärkeindikator (RSSI) befindet.

Wi-Fi-Roundtripzeit

Mit der Wi-Fi Round Trip Time (RTT) können Geräte die Entfernung zu anderen unterstützenden Geräten messen, unabhängig davon, ob es sich um Access Points (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 die Nutzung einer verbesserten Standortgenauigkeit und -erkennung.

Verbesserungen bei der WLAN-Bewertung

Verbesserte Wi-Fi-Bewertungsmodelle bestimmen schnell und genau, wann ein Gerät ein verbundenes Wi-Fi-Netzwerk verlassen oder in ein neues Wi-Fi-Netzwerk eintreten sollte. Diese Modelle bieten Benutzern ein zuverlässiges und nahtloses Erlebnis, indem sie Konnektivitätslücken vermeiden.

Überprü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

Wi-Fi STA/AP-Parallelität

Unter Wi-Fi STA/AP-Parallelität versteht man die Fähigkeit von Geräten, gleichzeitig im Stations- (STA) und Access Point-Modus (AP) zu arbeiten. Für Geräte, die simultanes Dualband-WLAN (DBS) unterstützen, eröffnet dies Möglichkeiten, wie zum Beispiel, dass STA-WLAN nicht unterbrochen wird, wenn ein Benutzer einen Hotspot (SoftAP) aktivieren möchte.

WiFiStateMachine-Verbesserungen

WifiStateMachine ist die Hauptklasse, die zum Steuern der Wi-Fi-Aktivität, zum Koordinieren von Benutzereingaben (Betriebsmodi: Hotspot, Scannen, Verbinden oder Aus) und zum Steuern von Wi-Fi-Netzwerkaktionen (z. B. Scannen oder Verbinden) verwendet wird.

In Android 9 und höher werden der Wi-Fi-Framework-Code und die Implementierung von WifiStateMachine neu strukturiert, was zu einer reduzierten Codegröße, einer einfacher zu verfolgenden Wi-Fi-Steuerungslogik, einer verbesserten Steuerungsgranularität und einer größeren Abdeckung und Qualität von Komponententests führt .

Auf hoher Ebene ermöglicht WifiStateMachine , dass sich Wi-Fi in einem von vier Zuständen befindet:

  • Client-Modus (kann eine Verbindung herstellen und scannen)
  • Nur-Scan-Modus
  • SoftAP-Modus (WLAN-Hotspot)
  • Deaktiviert (WLAN vollständig ausgeschaltet)

Jeder Wi-Fi-Modus stellt unterschiedliche Anforderungen an die Ausführung von Diensten und sollte einheitlich eingerichtet werden, sodass nur die für den Betrieb relevanten Ereignisse verarbeitet werden. Die neue Implementierung beschränkt den Code auf Ereignisse im Zusammenhang mit diesem Modus, wodurch die Debugging-Zeit und das Risiko der Einführung neuer Fehler aufgrund der Komplexität reduziert werden. Zusätzlich zur expliziten Handhabung der Modusfunktionalität wird die Thread-Verwaltung auf konsistente Weise gehandhabt und die Verwendung asynchroner Kanäle als Mechanismus zur Synchronisierung entfällt.

Aktualisierungen der WLAN-Berechtigungen

In 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 CHANGE_WIFI_STATE Berechtigung nicht erteilt wird.

Um dieses Verhalten zu validieren, führen Sie die roboterelektrischen und manuellen Tests durch.

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. Stellen Sie sicher, dass Ihre App das Szenario verarbeiten kann, in dem die CHANGE_WIFI_STATE Berechtigung nicht erteilt wird.

WPS-Veraltung

Aufgrund von Sicherheitsproblemen ist das 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 zur Ablaufverfolgung von Fensterübergängen

Android 9 und höher enthält das WinScope-Tool zum Verfolgen von Fensterübergängen. WinScope bietet Infrastruktur und Tools zum Aufzeichnen und Analysieren des Fenstermanagerstatus während und nach Übergängen. Es ermöglicht das Aufzeichnen und Durchlaufen von Fensterübergängen, während alle relevanten Fenstermanagerzustände in einer Trace-Datei aufgezeichnet werden. Sie können diese Daten verwenden, um den Übergang erneut abzuspielen und zu durchlaufen.

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

Interaktion

Automotive-Audio

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

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

Fahrzeug HAL

Fahrzeugeigenschaften beschreiben Änderungen an der Fahrzeug-HAL-Schnittstelle.

GNSS-Satellitenauswahl

Bei der Arbeit mit neuen HALs des globalen Navigationssatellitensystems (GNSS) (v1.1+) überwacht das Android Framework die Android-Einstellungen. Partner können die Einstellungen über Google Play-Dienste oder andere Systemaktualisierungen ändern. Diese Einstellungen teilen dem GNSS-HAL mit, ob bestimmte GNSS-Satelliten nicht verwendet werden sollen. Dies kann bei anhaltenden GNSS-Satelliten- oder Konstellationsfehlern nützlich sein oder um schneller auf GNSS-HAL-Implementierungsprobleme zu reagieren, die beim Mischen von Konstellationen mit unterschiedlichen Zeitsystemen und externen Ereignissen wie Schaltsekunden-, Tages- oder Wochennummernüberschlägen auftreten können .

GNSS-Hardwaremodell

In Android 9 kann die GNSS HAL-Version 1.1 oder höher Informationen über die Hardware-API an die Plattform weitergeben. Die Plattform muss die IGnssCallback Schnittstelle implementieren und ein Handle an die HAL übergeben. Der GNSS-HAL übergibt die Hardwaremodellinformationen über die Methode LocationManager#getGnssHardwareModelName() . Gerätehersteller sollten nach Möglichkeit mit ihren GNSS-HAL-Anbietern zusammenarbeiten, um diese Informationen bereitzustellen.

Berechtigungen

Konfigurieren diskreter Zugriffskontrollaktualisierungen

Die Konfiguration der diskretionären Zugriffskontrolle (DAC) enthält Aktualisierungen des Android-IDs-Mechanismus (AIDs) zur Erweiterung der Dateisystemfunktionen.

Berechtigungen für privilegierte Apps auf die Whitelist setzen

Wenn in Android 9 und höher Berechtigungen vorhanden sind, die verweigert werden sollten, bearbeiten Sie die XML-Datei so, dass das Tag deny-permission anstelle des in früheren Versionen verwendeten permission Tags verwendet wird.

Daten

Verbesserungen bei der Bandbreitenschätzung

Android 9 bietet verbesserte Unterstützung für die Bandbreitenschätzung. Android-Apps können für Videoanrufe und Videostreaming passendere 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 wünscht, ConnectivityManager.requestBandwidthUpdate() auf, und das Framework stellt möglicherweise eine geschätzte Downlink-Bandbreite bereit.

Aber auf Geräten mit Version 9 oder höher wird der Rückruf onCapabilitiesChanged() automatisch ausgelöst, wenn sich die geschätzte Bandbreite erheblich ändert, und der Aufruf von requestBandwidthUpdate() ist ein No-Op; Die zugehörigen getLinkDownstreamBandwidthKbps() und getLinkUpstreamBandwidthKbps() werden mit aktualisierten Informationen gefüllt, die von der physischen Schicht bereitgestellt werden.

Darüber hinaus können Geräte über ServiceState.getCellBandwidths() die LTE-Zellenbandbreiten überprüfen. Dadurch können Anwendungen bestimmen, wie viel Bandbreite (Frequenz) in einer bestimmten Zelle verfügbar ist. Informationen zur Zellbandbreite sind über ein verstecktes Menü verfügbar, sodass Feldtester die aktuellsten Informationen überprüfen können.

eBPF-Verkehrsüberwachung

Das eBPF-Netzwerkverkehrstool verwendet eine Kombination aus Kernel- und User-Space-Implementierung, um die Netzwerknutzung auf einem Gerät seit dem letzten Gerätestart zu überwachen. Dieses Tool bietet zusätzliche Funktionen wie Socket-Tagging, die Trennung von Vorder- und Hintergrundverkehr und eine UID-Firewall, um Apps je nach Gerätestatus vom Netzwerkzugriff zu blockieren.

Wiederherstellung auf niedrigere APIs

Geräte können jetzt von zukünftigen Versionen des Betriebssystems wiederhergestellt werden. Dies ist besonders nützlich, wenn Benutzer ihre Telefone aktualisiert, sie dann aber verloren oder kaputt gemacht haben.

Wenn ein OEM die Backup-Agenten für eines der Systempakete (Android, System, Einstellungen) ändert, sollten diese Agenten die Wiederherstellung von Backup-Sätzen, die auf höheren Versionen der Plattform erstellt wurden, ohne Absturz und mit der Wiederherstellung zumindest einiger Daten bewältigen.

Erwägen Sie die Verwendung eines Validators, um bestimmte Sicherungsdaten auf ungültige Werte zu prüfen und nur gültige Daten wiederherzustellen, wie in core/java/android/provider/SettingsValidators.java .

Die Funktion ist standardmäßig aktiviert. Die SettingsBackupAgent-Unterstützung 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 Backup-Agenten (oder fügt einen benutzerdefinierten Agenten hinzu).

Diese Funktion ermöglicht Systemwiederherstellungen von zukünftigen Versionen der Plattform; Es ist jedoch davon auszugehen, dass die wiederhergestellten Daten nicht vollständig sind. Die folgenden Anweisungen gelten für die folgenden Backup-Agenten:

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

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

  • SettingsBackupAgent gibt restoreAnyVersion = true in Android 9 und höher an. Teilweise Unterstützung besteht über Validatoren. Eine Einstellung kann aus einer höheren API-Version wiederhergestellt werden, wenn im Zielbetriebssystem ein Validator dafür vorhanden ist. Das Hinzufügen einer Einstellung sollte von ihrem Validator begleitet sein. Weitere Informationen finden Sie in der Klasse.

  • Jeder im ROM enthaltene benutzerdefinierte Backup-Agent sollte seinen Versionscode jedes Mal erhöhen, wenn eine inkompatible Änderung am Backup-Datenformat vorgenommen wird, und restoreAnyVersion = false (Standardeinstellung) sicherstellen, wenn sein Agent nicht für den Umgang mit Backup-Daten aus einer zukünftigen Version von vorbereitet ist ihren Code.

Unternehmen

Verwaltete Profilverbesserungen

UX-Änderungen für verwaltete Profile erleichtern es Benutzern, das verwaltete Profil zu identifizieren, darauf zuzugreifen und es zu steuern.

OTAs pausieren

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

Leistung

Gesundheit 2.0

Android 9 und höher enthält android.hardware.health HAL 2.0, ein Hauptversions-Upgrade von health@1.0 HAL. Weitere Informationen finden Sie auf diesen Seiten:

APK-Caching-Lösung

Android 9 und höher beinhaltet 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 größtenteils in der leeren B-Partition auf neuen A/B-partitionierten Geräten gespeichert ist, ohne den benutzerseitigen Datenraum zu beeinträchtigen.

Profilgeführte Optimierung

Android 9 und höher unterstützt die Verwendung der profilgesteuerten Optimierung (PGO) von Clang auf nativen Android-Modulen, die über Blueprint-Build-Regeln verfügen.

Write-Ahead-Protokollierung

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

Bootzeiten

Android 9 ändert die Optimierung der Startzeit, wie unter „Startzeiten optimieren“ beschrieben.

Leistung

Hintergrundbeschränkungen

Android 9 und höher enthält Hintergrundbeschränkungen , die es Benutzern ermöglichen, Apps einzuschränken, die möglicherweise den Akku belasten. Das System schlägt möglicherweise auch vor, Apps zu deaktivieren, die sich negativ auf den Zustand eines Geräts auswirken.

Batterielose Geräte

Android 9 geht eleganter mit batterielosen Geräten um als in früheren Versionen. Android 9 entfernt Code für batterielose Geräte, die standardmäßig davon ausgingen, dass ein Akku vorhanden, zu 100 % geladen und in gutem Zustand war und auf dem Thermistor eine normale Temperatur angezeigt wurde.