Auf dieser Seite werden die wichtigsten Funktionen des Android 16-Release zusammengefasst und Links zu weiteren Informationen bereitgestellt. Diese Funktionszusammenfassungen sind nach dem Speicherort der Dokumentation der jeweiligen Funktion auf dieser Website angeordnet.
Audio
Unterstützung für konfigurierbare Audiorichtlinien
Mit der HIDL HAL können Android-Anbieter einen alternativen Ansatz zur Angabe von Regeln für die Audioweiterleitung verwenden, die sogenannte konfigurierbare Audiorichtlinie (Configurable Audio Policy, CAP). Diese ist flexibler als die Standard-Engine, die für Smartphones verwendet wird. Bei der Migration zu AIDL HAL wurde die Unterstützung für CAP in Android 14 und 15 aufgrund von Ressourcenmangel nicht implementiert. Wir haben dieses Problem in Android 16 behoben, indem wir fehlende AIDL-Definitionen bereitgestellt und den Mechanismus zum Laden der CAP-Konfiguration durch das Framework geändert haben. Weitere Informationen finden Sie unter Unterstützung für konfigurierbare Audiorichtlinien in der AIDL HAL.
Wir haben das automatische Cuttlefish-Ziel umgestellt, um die CAP-AIDL-Implementierung zu nutzen und Partnern bei der Migration ihrer Produkte zu helfen.
Architektur
Generic Bootloader (GBL)
Mit Android 16 wird der neue Generic Bootloader (GBL) unterstützt. Das ist ein standardisierter, aktualisierbarer Bootloader, der den Android-Bootvorgang optimieren soll.
Weitere Informationen zu GBL finden Sie unter Generic Bootloader (GBL) – Übersicht.
Kompatibilität
Updates für Kameras mit ITS
Android 16 enthält Updates für die Camera Image Test Suite (ITS). Weitere Informationen finden Sie hier:
Compatibility Definition Document (CDD)
Das Compatibility Definition Document (CDD) für Android 16 wurde veröffentlicht.
Aktualisierungen der CTS-Prüfung für Bluetooth-MIDI-Tests
Um das Testverfahren zu vereinfachen und potenzielle Fehler zu reduzieren, können Sie unter Android 16 CTS-V-Bluetooth-MIDI-Loopback-Tests ohne USB-MIDI-Peripheriegerät ausführen.
Die spezifische Dokumentation zu dieser Änderung finden Sie unter CTS Verifier Bluetooth MIDI tests updates.
Aktualisierungen beim CTS-Prüfbarometer
Zur Unterstützung der Standortfunktionen von Android enthält Android 16 eine neue Reihe von CTS-V-Barometermesstests.
Eine Dokumentation zu dieser Änderung finden Sie unter CTS Verifier-Barometer-Messtests.
Aktualisierungen für CTS-Verifier-Tests auf mehreren Geräten
Zur Unterstützung der Konnektivitätsfunktionen von Android enthält Android 16 eine neue Reihe von CTS-V-Tests.
Die spezifische Dokumentation zu dieser Änderung finden Sie unter CTS Verifier-Updates für Multigerätetests.
Konnektivität
Identifikation des Android-Betriebssystems
Ab Android 16 enthält das Android-Framework einen GATT-Dienst (Generic Attribute) namens Android Information Service (AIS), mit dem Bluetooth-Geräte die Android API-Ebene als GATT-Eigenschaft des Dienstes lesen können. Über diesen Dienst können Bluetooth-Gerätehersteller feststellen, ob ein Bluetooth-Peripheriegerät mit einem zentralen Gerät gekoppelt ist, auf dem Android ausgeführt wird, und spezielle Logik basierend auf der API-Ebene verwalten.
Weitere Informationen finden Sie unter Identifikation des Android-Betriebssystems.
Notfallrückrufmodus
Android 16 führt die System-API EmergencyCallbackModeListener
ein, über die das IMS-Modul den Status des Notfallrückrufmodus über einen Callback abrufen kann, wenn das Gerät den Notfallrückrufmodus für SMS oder Anrufe aktiviert oder deaktiviert. Gerätehersteller können diese API verwenden, um die IMS-Registrierungsverwaltung zu implementieren und so die Anforderungen von Mobilfunkanbietern und 3GPP zu erfüllen. Wenn sich das Nutzergerät (UE) beispielsweise im Notfallrückrufmodus befindet, kann das IMS-Modul so konfiguriert werden, dass die Notfallregistrierung für einen bestimmten Zeitraum aufrechterhalten wird.
Das IMS-Modul kann die Notfallregistrierung auch abhängig vom Status des Notfallrückrufmodus aufrechterhalten, verlängern und kündigen.
IMS-Dienstaktualisierungen
In Android 16 werden System-APIs eingeführt, die Gerätehersteller und ‑anbieter für ihre IMS-Implementierung verwenden können. In der folgenden Tabelle sind die APIs aufgeführt, die befugte Apps zur Unterstützung von IMS-Diensten verwenden können:
Klasse | API |
---|---|
MmTelFeature |
EpsFallbackReason |
ImsTrafficType |
|
ImsTrafficDirection |
|
modifyImsTrafficSession |
|
startImsTrafficSession |
|
stopImsTrafficSession |
|
triggerEpsFallback |
|
ImsTrafficSessionCallback |
Alle |
ConnectionFailureInfo |
Alle |
TelephonyManager |
getImsPrivateUserIdentity |
getImsPublicUserIdentities |
|
getImsPcscfAddresses |
|
getSimServiceTable |
|
ImsCallSessionListener |
callSessionTransferred |
callSessionTransferFailed |
|
callSessionSendAnbrQuery |
|
SmsMessage |
getRecipientAddress |
Rangierungsmodul
In Android 16 wird das Modul „Ranging“ eingeführt, das die APIs für Entfernungsmesstechnologien wie Ultrabreitband, Bluetooth-Kanalsuche, Bluetooth-RSSI-Messung und WLAN-RTT (Round Trip Time) zusammenfasst. Weitere Informationen
- Rangordnung: Out-of-Band-Nachrichtensequenz und Nutzlastspezifikation
- Reichweite zwischen Geräten (Android Developers-Website)
WLAN-Hotspot-Updates
Mit Android 16 wird die Methode SoftApCallback#onClientsDisconnected
eingeführt, mit der eine Liste der getrennten Clients eines WLAN-Hotspots (Soft-AP) und der Grund für die Trennung für jeden Client abgerufen werden kann. Mit dieser Funktion können OEMs aus der Automobilbranche die erforderlichen Spezifikationen für projizierte Apps erfüllen und so die Konfigurierbarkeit und Funktionalität des Android-WLAN-Stacks verbessern.
Wenn Sie die Methode SoftApCallback#onClientsDisconnected
verwenden möchten, registrieren Sie einen Callback, um die Gerätefunktionen mit WifiManager#registerSoftApCallback
für einen Tethering-Hotspot oder WifiManager#registerLocalOnlyHotspotSoftApCallback
für einen lokal begrenzten Hotspot abzurufen.
Vorhandene registrierte Soft-AP-Callbacks müssen die Methode SoftApCallback#onClientsDisconnected
überschreiben. Weitere Informationen finden Sie unter Apps mit Hotspot-APIs entwickeln.
Eine Beispielimplementierung eines Tethered-Wi-Fi-Hotspots auf der Referenzseite „AAOS-Einstellungen für Autos“ mit SoftApCallback
finden Sie unter WifiTetheringHandler.java
.
Führen Sie die folgenden Unit-Tests und CTS Verifier-Tests aus, um Ihre Implementierung zu testen:
- Unit tests
- Administratoren:
atest packages/modules/Wifi/framework/tests/
- Dienste:
atest packages/modules/Wifi/service/tests/wifitests/
- Administratoren:
- CTS-Verifier-Tests:
atest CtsWifiSoftApTestCases
Anzeige
Desktop-Freiform-Fenster
Die Desktopfenster ermöglichen eine höhere Produktivität, da sie eine vertraute Benutzeroberfläche zum Anordnen und Ändern der Größe überlappender Fenster bieten. Informationen zur Unterstützung von Desktopfenstern finden Sie unter Mehrere Fenster unterstützen.
Interaktion
Haptik
Mit Android 16 werden APIs eingeführt, um die Haptikfragmentierung im Ökosystem zu reduzieren, die individuelle Geräteabstimmung zu vermeiden und Entwicklern und Endnutzern von Geräten eine umfassendere und ausdrucksstärkere Bewegungserfahrung zu bieten. Die neue Piecewise Linear Envelope API (PWLE) unterstützt die Erstellung normalisierter PWLE-Effekte, die auf ähnlichen Geräten ähnliche haptische Wahrnehmungen erzeugen.
Im Folgenden finden Sie eine Zusammenfassung, wie die neuen APIs in Android 16 die Haptik verbessern:
- Entwicklungskosten senken, indem die gerätespezifische Optimierung durch eine normalisierte Werteskala entfernt wird
- Erstellen Sie einen Basissatz von haptischen Primitiven für das System (z. B.
CLICK
,TICK
,LOW_TICK
,SLOW_RISE
,QUICK_RISE
,QUCK_FALL
,THUD
,SPIN
). - Unterstützung für das Erstellen und Komponieren parametrischer Effekte (Dauer, Amplitude und Frequenz).
- Unterstützung für den automatischen Schutz vor Überlastung der Haptik
- Multisensorische Erlebnisse wie kombinierte Haptik und Ton ermöglichen.
- Schließen Sie die Lücke bei den Entwicklerfunktionen für Haptik unter Android.
Wir empfehlen, die neuen normalisierten PWLE APIs zu integrieren und zu verwenden, um Standard-Haptik-Primitive zu aktivieren und Unterstützung für neue haptische Funktionen von Entwicklern bereitzustellen. Weitere Informationen finden Sie unter PWLE-Effekte implementieren.
Herzfrequenz-Basissensor
Unter Android 16 verwendet das Android-Framework die Berechtigung SENSOR_PERMISSION_READ_HEART_RATE
für Herzfrequenzsensoren, um die Kompatibilität zu gewährleisten. Unter Android 15 und niedriger verwendet das Framework die Berechtigung SENSOR_PERMISSION_BODY_SENSORS
. Weitere Informationen zum Herzfrequenz-Basissensortyp finden Sie unter Herzfrequenz.
Medien
HDR-Unterstützung
Android 16 bietet die folgenden Verbesserungen bei der HDR-Unterstützung:
- App-Fallback-Funktion (SDR als Fallback) über Media3 ExoPlayer und Bildauswahl
- Verbesserte Unterstützung von Screenshots für HDR-Inhalte. Weitere Informationen finden Sie unter HDR in Android-Screenshots.
- Höhere Konsistenz bei erstellten HDR-Inhalten.
Wir empfehlen Folgendes:
- Aktiviere HLG oder DolbyVision (8.4 mit HLG) standardmäßig in deiner Kamera-App.
- Ultra HDR standardmäßig für Fotos aktivieren
- App-Unterstützung für HLG-Videos und Ultra-HDR-Aufzeichnung
Framework für die Medienqualität
In Android 16 entwickeln wir ein neues Framework für Bild- und Audioqualität, um eine standardisierte API für Android-TV-Implementierungen zu schaffen. Dieses Framework bietet einen einheitlichen Ansatz für die Anpassung der Bildqualität (PQ) und Audioqualität (AQ) auf Android-Fernsehern und vereinfacht die Entwicklung für Anbieter. Diese Funktion bietet folgende Vorteile:
- Detaillierte Bildqualitätseinstellungen pro Stream, pro Nutzer und pro Eingabetyp auf dem Displayfeld mit einer Einstellung auf Systemebene für den gesamten Bildschirm, die für alle Apps verwendet werden kann
- Detaillierte Audioeinstellungen pro Stream und pro Gerät mit einer Einstellung auf Systemebene, die für alle Apps verwendet werden kann
Video-Codec
Mit Android 16 führen wir die Plattformunterstützung für den APV-Codec (Advanced Professional Video) ein. Der APV-Codec ist ein Intraframe-Codec mit hoher Bitrate, der es Creatorn ermöglicht, Aufnahmen und Bearbeitungen in höchster Qualität zu erstellen.
Außerdem plant Google, alle Nutzer von VP8, VP9 und AVC (H.264) auf AV1 umzustellen. App-Entwickler bevorzugen AV1, die nächste Generation von Codecs, um Transcodierungen im Backend zu vermeiden und die Latenz zu reduzieren. Hardware-Codecs werden weiterhin empfohlen, insbesondere für die Codierung, obwohl die Unterstützung für den AV1-Software-Codec verbessert wird.
Sie können AV1 für eine höhere Qualität, Zuverlässigkeit und Parallelität verwenden und die APV-Unterstützung in der Kamera- und Galerie-App in Betracht ziehen.
Leistung
Trade-In-Modus
Mit Android 16 wird der Trade-In-Modus eingeführt, mit dem Entwickler und Reseller den Systemstatus nach dem Zurücksetzen auf die Werkseinstellungen prüfen können.
Weitere Informationen finden Sie unter Informationen zur Systemgesundheit abrufen.
Berechtigungen
Aktualisierungen von Android-Rollen
Mit Android 16 werden die folgenden Rollen aktualisiert:
COMPANION_DEVICE_APP_STREAMING
: Für Anwendungsfälle zum Streamen, Streamen oder Spiegeln von Apps, die das Streamen, Streamen oder Spiegeln von einem Android-Gerät wie einem Smartphone oder Tablet auf einen Desktop- oder Laptop-Computer ermöglichen.COMPANION_DEVICE_NEARBY_DEVICE_STREAMING
: Für Anwendungsfälle für Android-Geräte wie Smartphones oder Tablets zum Streaming von Apps für vernetzte Fahrzeuge und XR-Geräte.
Weitere Informationen finden Sie unter Android-Rollen.
Sicherheit
Sicherheit von Mobilfunknetzen
In Android 16 wurden kleinere UX-Änderungen an der Ein/Aus-Schaltfläche für die 2G-Verbindung in den SIM-Einstellungen vorgenommen, um sie an den Rest der Einstellungen anzupassen. In Android 16 gibt es außerdem einen speziellen Bereich für Sicherheitsfunktionen für Mobilfunknetze namens Sicherheit des Mobilfunknetzes im Sicherheitscenter unter Einstellungen.
Geräteintegrität
Android 16 unterstützt Attestierungszertifikate von KeyMint Version 4.0. Zur Überprüfung der Integrität der geladenen APEX-Module enthalten KeyMint 4.0-Zertifikate ein neues Feld moduleHash
in der Struktur KeyDescription
.
Weitere Informationen finden Sie unter Schlüssel- und ID-Attestierung.
Speicher
Standardkontaktkonto
Android-Nutzer verlieren einige Kontakte, wenn sie zu einem anderen Gerät wechseln. Um den Verlust von Kontakten zu reduzieren, wird in Android 16 das Konzept eines Standardkontos für Kontakte eingeführt. Damit diese Funktion unterstützt wird, muss Ihre Kontakte App folgende Voraussetzungen erfüllen:
- Cloudsynchronisierungsoptionen bewerben, um den Verlust von Kontakten im Laufe der Zeit zu verhindern
- Nutzer fragen, ob sie ihre lokalen und SIM-Kontakte in die Standardkonten in der Cloud verschieben möchten
- Erstellen neuer lokaler und SIM-Kontakte erschweren
Updates
Nahtlose App-Updates
Wenn ein Paket aktualisiert wird, wird es angehalten und in einen eingefrorenen Zustand versetzt, damit es nicht ausgeführt wird, während sich sein Code und seine Ressourcen ändern. Bei großen, komplexen und systemkritischen Apps kann das Einfrieren von Paketen zu einer schlechten Nutzererfahrung führen, da abhängige Apps möglicherweise nicht ausgeführt werden können.
Unter Android 16 wird die Zeit, in der eine App nicht ausgeführt werden kann, verkürzt, indem dexopt
oder dex2oat
in eine frühere Phase des Installationsvorgangs verschoben wird. Durch diese Änderung wird die Zeit, in der eine App eingefroren ist, von mehreren Sekunden auf einige Millisekunden reduziert.