Tonauslöser

Mit der Funktion „Geräuschtrigger“ können Apps auf bestimmte akustische Ereignisse wie Hotwords mit geringem Energieverbrauch und datenschutzfreundlich achten. Beispiele für Anwendungsfälle des Trigger-Ereignisses „Ton“ sind Assistant und „Aktuell wiedergegeben“.

Auf dieser Seite erhalten Sie einen Überblick über die Sound Trigger-Architektur und ihre HAL-Schnittstelle (Hardware Abstraktionsschicht).

Stack für den Trigger „Ton“

Das Sound Trigger-Subsystem ist in Schichten aufgebaut, wie in Abbildung 1 dargestellt:

sound_trigger_stack

Abbildung 1:Tontrigger-Stack

In der folgenden Liste werden die in Abbildung 1 gezeigten Ebenen detaillierter beschrieben:

  • Die HAL-Schicht (grün) enthält den anbieterspezifischen Code, der die Sound Trigger HAL-Schnittstelle (STHAL) implementiert.

  • Die SoundTriggerMiddleware (gelb) befindet sich über der HAL-Schnittstelle. Sie kommuniziert mit der HAL und ist für Funktionen wie die Freigabe der HAL zwischen verschiedenen Clients, das Logging, die Durchsetzung von Berechtigungen und die Kompatibilität mit älteren HAL-Versionen verantwortlich.

  • Das SoundTriggerService-System (blau) befindet sich über der Middleware. Sie ermöglicht die Einbindung in andere Systemfunktionen wie Telefonie- und Akkuereignisse. Außerdem wird eine Datenbank mit Audiomodellen verwaltet, die mit eindeutigen IDs indexiert ist.

  • Über der SoundTriggerService-Ebene verarbeitet der Stack (in braun) Funktionen, die speziell für Assistant und für allgemeine Apps vorgesehen sind, separat.

Die Funktion des Tontrigger-Stacks besteht darin, diskrete Ereignisse zu senden, die akustische Triggerereignisse darstellen. In den meisten Fällen verarbeitet der Stack „Sound Trigger“ keine Audioinhalte. Nach Erhalt der Triggerereignisse erhalten Apps Zugriff auf den tatsächlichen Audiostream, der sich um den Zeitpunkt der Ereignisse herum befindet, indem sie über das Audio-Framework ein AudioRecord-Objekt öffnen. Die HAL APIs für Sound Trigger bieten einen Handle für das ausgelöste Ereignis, das mit dem Audio Framework verwendet wird. Da die Sound Trigger HAL und die Audio HAL intern miteinander verbunden sind, teilen sie sich in der Regel einen Prozess.

HAL-Schnittstelle für den Soundtrigger

Die Sound Trigger HAL-Schnittstelle (STHAL) ist der anbieterspezifische Teil des Sound Trigger-Stacks und verarbeitet die Hardwareerkennung von Hotwords und anderen Tönen. STHAL bietet eine oder mehrere Engines, in denen jeweils ein anderer Algorithmus ausgeführt wird, der für die Erkennung einer bestimmten Klasse von Geräuschen entwickelt wurde. Wenn STHAL einen Trigger erkennt, sendet er ein Ereignis an das Framework und beendet dann die Erkennung.

Die STHAL-Schnittstelle wird unter /hardware/interfaces/soundtrigger/ angegeben.

Die ISoundTriggerHw-Benutzeroberfläche unterstützt die Möglichkeit, zu einem bestimmten Zeitpunkt eine oder mehrere Erkennungssitzungen auszuführen und akustische Ereignisse abzuhören. Ein Aufruf von ISoundTriggerHw.getProperties() gibt eine Properties-Struktur mit Implementierungsbeschreibung und Funktionen zurück.

Der grundlegende Ablauf zum Einrichten einer Sitzung wird in Abbildung 2 so erläutert:

sthal_state

Abbildung 2:STHAL-Zustandsdiagramm

In den folgenden Schritten werden die einzelnen Status genauer beschrieben:

  1. Der HAL-Client lädt ein Modell mit loadSoundModel() oder loadPhraseSoundModel(). Das bereitgestellte Modellobjekt gibt an, welcher implementierungsspezifische Erkennungsalgorithmus (Engine) verwendet werden soll, sowie die für diesen Algorithmus geltenden Parameter. Bei Erfolg geben diese Methoden einen Handle zurück, der bei nachfolgenden Aufrufen auf dieses Modell verweist.

  2. Nachdem das Modell erfolgreich geladen wurde, ruft der HAL-Client startRecognition() auf, um mit der Erkennung zu beginnen. Die Erkennung läuft im Hintergrund weiter, bis eines der folgenden Ereignisse eintritt:

    1. Für dieses Modell wurde ein stopRecognition() aufgerufen.
    2. Es wurde eine Erkennung durchgeführt.
    3. Die Erkennung wird aufgrund von Ressourceneinschränkungen abgebrochen, z. B. wenn ein Anwendungsfall mit höherer Priorität gestartet wurde.

    In den beiden letzteren Fällen wird ein Erkennungsereignis über die Callback-Schnittstelle gesendet, die beim Laden vom HAL-Client registriert wird. In allen Fällen wird die Erkennung nach einem dieser Ereignisse inaktiv und es werden keine Erkennungs-Callbacks mehr zugelassen.

    Das gleiche Modell kann später noch einmal gestartet werden. Dieser Vorgang kann beliebig oft wiederholt werden.

  3. Ein inaktives Modell, das nicht mehr benötigt wird, wird schließlich vom HAL-Client über unloadModel() entladen.

HAL-Fehler behandeln

Um ein zuverlässiges und einheitliches Verhalten zwischen Treiberimplementierungen zu gewährleisten, werden in Android 11 alle Fehlercodes, die nicht erfolgreich von der HAL zurückgegeben wurden, als Programmfehler behandelt. Für die Wiederherstellung ist ein Neustart des HAL-Prozesses erforderlich. Dies ist eine letzte Möglichkeit zur Wiederherstellung. Die Erwartung ist, dass solche Fälle in einem ordnungsgemäß funktionierenden System nicht auftreten.