Auto-Audio

Android Automotive OS (AAOS) baut auf dem wichtigsten Android-Audio-Stack auf, die Anwendungsfälle für den Betrieb als Infotainmentsystem in einem Fahrzeug unterstützen. Der AAOS ist für Infotainment-Töne (Medien, Navigation, Kommunikation), ist aber nicht direkt für Glocken und Warnungen verantwortlich, strenge Anforderungen bezüglich Verfügbarkeit und Zeitvorgaben. Während AAOS Signale und Mechanismen, mit denen das Fahrzeug den Ton steuern kann. Letztendlich bleibt es beim Fahrzeug. welche Töne vor dem Fahrer gespielt werden sollen bei Fahrgästen, und sorgen dafür, dass sicherheitsrelevante Geräusche und gesetzlich vorgeschriebene Geräusche ohne Unterbrechung zu hören.

Die Medienumgebung des Fahrzeugs wird von Android verwaltet. wie der Radio-Tuner sollte durch Apps dargestellt werden, die Audioinhalte verarbeiten können. Medien-Schlüsselereignisse für die Quelle.

Bei Android 11 wurden die folgenden Änderungen an Audioinhalten für Autos vorgenommen Support:

• Automatische Auswahl des Audiobereichs auf Grundlage der verknüpften Nutzer-ID
• Neue Systemnutzungen zur Unterstützung von automobilspezifischen Geräuschen
• Unterstützung des HAL-Audiofokus
• Verzögerter Audiofokus für nicht vorübergehende Streams
• Nutzereinstellung zur Steuerung der Interaktion zwischen Navigation und Anrufen

Android-Sounds und -Streams

Automotive-Audiosysteme verarbeiten die folgenden Töne und Streams:

Abbildung 1: Diagramm: Streamorientierte Architektur

Android verwaltet Geräusche von Android-Apps und steuert diese Apps. und leiten ihre Töne an Ausgabegeräte am HAL basierend auf dem Ton:

• Logische Streams, auch als Quellen im Kernaudio bezeichnet Nomenklatur sind mit Audioattributen getaggt.
• Physische Streams, auch als Geräte in der Kernaudioausgabe bezeichnet Nomenklatur, erhalten nach dem Vermischen keine Kontextinformationen.

Aus Gründen der Zuverlässigkeit sollten externe Töne (aus unabhängigen Quellen (z. B. durch Glockenton für Gurtgurte) außerhalb von Android verwaltet werden, HAL oder sogar in separater Hardware. Systemimplementierungen müssen einen Mixer bereitstellen, einen oder mehrere Audiostreams von Android akzeptiert und diese mit den externen Schallquellen, die für das Fahrzeug.

Die HAL-Implementierung und der externe Mixer sind dafür verantwortlich, sicherheitskritische Umgebungsgeräusche sind zu hören und können in den von Android bereitgestellten und sie auf geeignete Lautsprecher weiterleiten.

Android-Töne

Apps können einen oder mehrere Spieler haben, die über die Standard-Android-App APIs (z. B. AudioManager zur Fokussteuerung oder MediaPlayer für Streaming) zum Ausgeben eines oder mehrerer logischer Audio-Datenströme. Diese Daten kann es sich um Single-Channel-Mono oder 7.1-Surround-Sound handeln, wird aber geroutet und behandelt aus einer einzigen Quelle stammen. Der App-Stream ist mit AudioAttributes verknüpft. die dem System Hinweise darüber geben, wie die Audioinhalte wiedergegeben werden sollen.

Die logischen Streams werden über AudioService gesendet und an einen (und nur einen) der verfügbaren physischen Ausgabestreams, von denen jeder die Ausgabe ist eines Mixers in AudioFlinger. Nachdem die Audioattribute vermischt wurden in einen physischen Stream übertragen werden, sind sie nicht mehr verfügbar.

Jeder physische Stream wird dann an den Audio-HAL zum Rendern auf die Hardware. In Automobil-Apps kann die Rendering-Hardware lokale Codecs sein. (ähnlich Mobilgeräten) oder einen Remote-Prozessor im gesamten Fahrzeug Netzwerk. In jedem Fall ist es die Aufgabe der Audio-HAL-Implementierung, tatsächlichen Stichprobendaten an, da sie hörbar werden.

Externe Streams

Soundstreams, die nicht über Android geleitet werden dürfen (zur Zertifizierung oder Timing-Gründe) können direkt an den externen Mischer gesendet werden. Ab Android 11 Der HAL kann nun den Fokus für diese externen Geräusche anfordern, um Android darüber zu informieren damit sie geeignete Maßnahmen wie das Pausieren von Medien oder anderen davon abhalten, sich zu fokussieren.

Ob es sich bei externen Streams um Medienquellen handelt, die mit dem Ton interagieren sollen Umgebung, die Android generiert (z. B. die MP3-Wiedergabe beenden, wenn ein externer Tuner aktiviert ist, sollten diese externen Streams durch einen Android-App Eine solche App würde Audiofokus im Namen der Medienquelle anfordern statt auf den HAL und reagiert auf Fokusbenachrichtigungen durch Start/Stopp der externen Quelle nach Bedarf, um den Fokus auf Android zu lenken . Die App ist auch für die Verarbeitung von Schlüsselereignissen von Medien verantwortlich, z. B. Wiedergabe/Pause. Ein Vorschlag zum Steuern solcher externen Geräte ist HwAudioSource.

Ausgabegeräte

Auf Audio-HAL-Ebene hat der Gerätetyp AUDIO_DEVICE_OUT_BUS bietet ein generisches Ausgabegerät für die Verwendung in Audiosystemen von Fahrzeugen. Der Bus Gerät unterstützt adressierbare Ports, wobei jeder Port der Endpunkt für einen physischer Stream) und wird voraussichtlich der einzige unterstützte Ausgabegerätetyp in ein Fahrzeug.

Bei einer Systemimplementierung kann ein Busport für alle Android-Töne verwendet werden, In diesem Fall vermischt Android alles und stellt es in einem Stream bereit. Alternativ kann der HAL einen Busport für jeden CarAudioContext bereitstellen, um die Verwendung für einen beliebigen Tontyp. Dadurch kann der HAL um die verschiedenen Töne nach Bedarf zu kombinieren.

Die Zuweisung von Audiokontexten zu Ausgabegeräten erfolgt über car_audio_configuration.xml

Mikrofoneingang

Beim Aufzeichnen von Audio empfängt der Audio-HAL ein openInputStream. -Aufruf, der ein AudioSource-Argument enthält, das angibt, wie die Funktion muss verarbeitet werden.

Die VOICE_RECOGNITION-Quelle (insbesondere Google Assistant) erwartet einen Stereo-Mikrofonstream, ein Echounterdrückungseffekt (falls verfügbar), aber keine andere Verarbeitung angewendet wird. Beamforming muss von Assistant übernommen werden.

Mehrkanal-Mikrofoneingang

Wenn Sie Audio von einem Gerät mit mehr als zwei Kanälen (Stereo) aufnehmen möchten, verwenden Sie einen statt der Positionsindexmaske (z. B. CHANNEL_IN_LEFT. Beispiel:

final AudioFormat audioFormat = new AudioFormat.Builder()
    .setEncoding(AudioFormat.ENCODING_PCM_16BIT)
    .setSampleRate(44100)
    .setChannelIndexMask(0xf /* 4 channels, 0..3 */)
    .build();
final AudioRecord audioRecord = new AudioRecord.Builder()
    .setAudioFormat(audioFormat)
    .build();
audioRecord.setPreferredDevice(someAudioDeviceInfo);

Wenn sowohl setChannelMask als auch setChannelIndexMask festgelegt sind, verwendet AudioRecord nur den Wert, der von setChannelMask (maximal zwei Kanäle).

Gleichzeitige Aufnahme

Ab Android 10 unterstützt das Android-Framework das gleichzeitige Erfassen aber mit Einschränkungen, um die Privatsphäre der Nutzer zu schützen. Als Teil virtuelle Quellen wie AUDIO_SOURCE_FM_TUNER werden ignoriert und dürfen daher gleichzeitig mit einer normalen Eingabe (z. B. dem Mikrofon) aufgenommen werden. HwAudioSources werden auch nicht als Teil der gleichzeitigen Aufnahmebeschränkungen.

Apps, die für AUDIO_DEVICE_IN_BUS-Geräte oder mit Sekundäre AUDIO_DEVICE_IN_FM_TUNER-Geräte müssen explizit auf zur Identifizierung dieser Geräte und zur Verwendung von AudioRecord.setPreferredDevice() um die Logik der Android-Quellauswahl zu umgehen.

Audionutzungen

AAOS verwendet hauptsächlich AudioAttributes.AttributeUsages zum Routing, zur Lautstärkeanpassung und zur Fokusverwaltung. Nutzungen sind ein Darstellung des „Warum“ der Stream wiedergegeben wird. Daher werden alle Streams und Audiofokus-Anfragen sollte eine Nutzung für die Audiowiedergabe angeben. Wann? nicht speziell beim Erstellen eines AudioAttributes-Objekts festgelegt wurde, der Standardwert ist USAGE_UNKNOWN. Obwohl dies derzeit gleich behandelt wird, wie USAGE_MEDIA, sollte dieses Verhalten nicht für Medien genutzt werden, Wiedergabe starten.

Systemnutzung

Mit Android 11 wurden die Systemnutzungen eingeführt. Diese Nutzungen verhalten sich ähnlich wie die bisherigen Einsatzmöglichkeiten, außer dass System-APIs erforderlich sind. zu verwenden sind, sowie android.permission.MODIFY_AUDIO_ROUTING. Das neue Systemnutzung:

• USAGE_EMERGENCY
• USAGE_SAFETY
• USAGE_VEHICLE_STATUS
• USAGE_ANNOUNCEMENT

Um eine AudioAttributes mit einer Systemnutzung zu erstellen, verwenden Sie AudioAttributes.Builder#setSystemUsage statt setUsage. Aufruf dieser Methode ohne Systemnutzung führt dazu, dass ein IllegalArgumentException ausgegeben wird. Wenn außerdem in einem Builder festgelegt wurde, wird eine IllegalArgumentException beim Erstellen.

Herausfinden, welche Nutzung mit einem AudioAttributes verbunden ist rufen Sie AudioAttributes#getSystemUsage auf. Dadurch wird die zugehörige Nutzung oder Systemnutzung zurückgegeben.

Audiokontexte

Um die Konfiguration von AAOS-Audio zu vereinfachen, wurden ähnliche Nutzungen gruppiert in CarAudioContext. Diese Audiokontexte werden im gesamten CarAudioService zum Definieren von Routing, Lautstärkegruppen und Audiofokus zu verstehen.

Die Audiokontexte in Android 11 sind:

Zuordnung zwischen Audiokontexten und -verwendungen. Hervorgehobene Zeilen sind für neue Systemnutzungen.

Mehrzonen-Audio

Neue Anwendungsfälle für die Automobilbranche mit der Plattform interagieren und separate Medien nutzen möchten. Für Beispielsweise kann ein Fahrer Musik in der Kabine abspielen, während Beifahrer auf dem Rücksitz ein YouTube-Video auf dem Rückdisplay ansehen. Mit der Funktion „Mehrzonen-Audio“ da verschiedene Audioquellen gleichzeitig in verschiedenen Bereichen des Fahrzeugs.

Ab Android 10 können OEMs Audio mit Mehrzonen-Audio in separate Zonen verschieben. Jede Zone ist eine Sammlung von Geräten im Fahrzeug. mit eigenen Volume-Gruppen, Routing-Konfiguration für Kontexte und Fokus zu verstehen. Auf diese Weise könnte die Hauptkabine als ein Audiogerät konfiguriert werden. und die Kopfhöreranschlüsse auf der Rückseite sind als zweite Zone konfiguriert.

Die Zonen werden als Teil von car_audio_configuration.xml definiert. CarAudioService liest dann die Konfiguration und unterstützt AudioService Sie leiten Audiostreams basierend auf ihrer zugehörigen Zone weiter. Jede Zone definiert weiterhin für das Routing auf Basis von Kontexten und der Anwendungs-UID. Wenn ein Spieler erstellt wird, bestimmt CarAudioService, für welche Zone der Spieler mit welchem Gerät das AudioFlinger-Gerät verknüpft ist. an den die Audiodaten weitergeleitet werden sollen.

Der Fokus wird außerdem für jede Audiozone separat gehalten. Dies ermöglicht in verschiedenen Zonen, um unabhängig Audio zu produzieren, ohne die sich gegenseitig beeinträchtigen, während Anwendungen gleichzeitig Änderungen in sich auf ihren Bereich konzentrieren. CarZonesAudioFocus innerhalb von CarAudioService ist für die Fokussierung auf den jeweiligen .

Abbildung 2. Mehrzonen-Audio konfigurieren

Audio-HAL

Automotive-Audioimplementierungen basieren auf dem standardmäßigen Android-Audio-HAL, und umfasst Folgendes:

• IDevice.hal Erstellt Eingabe- und Ausgabestreams, übernimmt die Hauptlautstärke und Stummschaltung und verwendet: <ph type="x-smartling-placeholder">
  </ph>
  • createAudioPatch Zum Erstellen externer/externer Patches zwischen Geräten.
  • IDevice.setAudioPortConfig() für die Lautstärke für jeden physischen Stream.
• IStream.hal Neben den Eingabe- und Ausgabevarianten verwaltet das Streaming von Audio-Samples zur und von der Hardware.

Automobil: Gerätetypen

Die folgenden Gerätetypen sind für Plattformen im Automobilbereich relevant.

Audiogeräte konfigurieren

Für Android sichtbare Audiogeräte müssen in /audio_policy_configuration.xml mit den folgenden Komponenten:

• Modulname. Unterstützt „primär“ (für Anwendungsfälle im Automobilbereich), „A2DP“, „remote_submix“ und „USB“. Modulname und entsprechendes Audio Treiber sollte in audio.primary.$(variant).so kompiliert werden.
• devicePorts. Enthält eine Liste mit Gerätedeskriptoren für alle Ein- und Ausgaben (einschließlich fest angeschlossener Geräte und Wechseldatenträger), die auf die Sie in diesem Modul zugreifen können.
• Für jedes Ausgabegerät können Sie die Verstärkungsregelung definieren, Minimal-/Maximal-/Standard-/Schrittwerte in Millibel (1 Millibel = 1/100 dB = 1/1000 bel).
• Mit dem Adressattribut einer devicePort-Instanz können Sie auch wenn es mehrere Geräte mit demselben Gerätetyp AUDIO_DEVICE_OUT_BUS
• mixPorts. Enthält eine Liste aller Ausgabe- und Eingabestreams, die vom Audio-HAL. Jede mixPort-Instanz kann als physischer Stream betrachtet werden, Android AudioService.
• Routen planen. Definiert eine Liste möglicher Verbindungen zwischen Eingabe und Ausgabe oder zwischen Stream und Gerät.

Im folgenden Beispiel wird das Ausgabegerät „bus0_phone_out“ definiert, in dem alle Android-Audiostreams werden durch „mixer_bus0_phone_out“ gemischt. Die Route nimmt die Ausgabestream von mixer_bus0_phone_out an Gerät bus0_phone_out.

<audioPolicyConfiguration version="1.0" xmlns:xi="http://www.w3.org/2001/XInclude">
    <modules>
        <module name="primary" halVersion="3.0">
            <attachedDevices>
                <item>bus0_phone_out</item>
<defaultOutputDevice>bus0_phone_out</defaultOutputDevice>
            <mixPorts>
                <mixPort name="mixport_bus0_phone_out"
                         role="source"
                         flags="AUDIO_OUTPUT_FLAG_PRIMARY">
                    <profile name="" format="AUDIO_FORMAT_PCM_16_BIT"
                            samplingRates="48000"
                            channelMasks="AUDIO_CHANNEL_OUT_STEREO"/>
                </mixPort>
            </mixPorts>
            <devicePorts>
                <devicePort tagName="bus0_phone_out"
                            role="sink"
                            type="AUDIO_DEVICE_OUT_BUS"
                            address="BUS00_PHONE">
                    <profile name="" format="AUDIO_FORMAT_PCM_16_BIT"
                            samplingRates="48000"
                            channelMasks="AUDIO_CHANNEL_OUT_STEREO"/>
                    <gains>
                        <gain name="" mode="AUDIO_GAIN_MODE_JOINT"
                                minValueMB="-8400"
                                maxValueMB="4000"
                                defaultValueMB="0"
                                stepValueMB="100"/>
                    </gains>
                </devicePort>
            </devicePorts>
            <routes>
                <route type="mix" sink="bus0_phone_out"
                       sources="mixport_bus0_phone_out"/>
            </routes>
        </module>
    </modules>
</audioPolicyConfiguration>