사운드 트리거 기능을 사용하면 앱이 핫워드와 같은 특정 어쿠스틱 이벤트를 저전력 및 개인 정보 보호에 민감한 방식으로 리슨할 수 있습니다.
사운드 트리거의 사용 사례 예로는 어시스턴트와 Now Playing이 있습니다.
이 페이지에서는 사운드 트리거 아키텍처와 하드웨어 추상화 계층(HAL) 인터페이스에 관해 간략하게 설명합니다.
사운드 트리거 스택
사운드 트리거 하위 시스템은 그림 1과 같이 레이어로 빌드됩니다.
그림 1: 사운드 트리거 스택
다음 목록은 그림 1에 표시된 각 레이어를 자세하게 설명합니다.
HAL 레이어(녹색)에는 사운드 트리거 HAL(STHAL) 인터페이스를 구현하는 공급업체별 코드가 포함되어 있습니다.
SoundTriggerMiddleware(노란색)는 HAL 인터페이스 위에 있습니다. HAL과 통신하고 다양한 클라이언트 간 HAL 공유, 로깅, 권한 적용, 이전 HAL 버전과의 호환성 처리 등의 기능을 담당합니다.
SoundTriggerService(파란색) 시스템은 미들웨어 위에 있습니다.
텔레포니 및 배터리 이벤트와 같은 다른 시스템 기능과의 통합을 용이하게 합니다. 고유 ID로 색인이 생성된 사운드 모델의 데이터베이스도 유지합니다.
SoundTriggerService 레이어 위의 스택(갈색)은 어시스턴트 및 일반 앱과 관련된 기능을 별도로 처리합니다.
사운드 트리거 스택의 기능은 어쿠스틱 및 트리거 이벤트를 나타내는 개별 이벤트를 전달하는 것입니다. 대부분의 경우 사운드 트리거 스택은 오디오를 처리하지 않습니다. 앱이 트리거 이벤트를 수신하면 오디오 프레임워크를 통해 AudioRecord 객체를 열어 이벤트 시간 근처의 실제 오디오 스트림에 액세스합니다. 사운드 트리거 HAL API는 오디오 프레임워크와 함께 사용되는 트리거된 이벤트가 포함된 핸들을 제공합니다. 따라서 사운드 트리거 HAL과 오디오 HAL은 내부적으로 연결되므로 일반적으로 프로세스를 공유합니다.
사운드 트리거 HAL 인터페이스
사운드 트리거 HAL(STHAL) 인터페이스는 사운드 트리거 스택의 공급업체 관련 부분이고 핫워드와 기타 사운드의 하드웨어 인식을 처리합니다.
STHAL은 특정 종류의 사운드를 감지하도록 설계된 다른 알고리즘을 각각 실행하는 엔진을 하나 이상 제공합니다. STHAL이 트리거를 감지하면 프레임워크에 이벤트를 전송하고 감지를 중지합니다.
STHAL 인터페이스는 /hardware/interfaces/soundtrigger/ 아래에 지정됩니다.
ISoundTriggerHw 인터페이스는 주어진 시간에 감지 세션을 하나 이상 실행하고 어쿠스틱 이벤트를 수신하는 기능을 지원합니다.
ISoundTriggerHw.getProperties() 호출은 구현 설명과 기능이 포함된 Properties 구조를 반환합니다.
그림 2에서는 세션 설정의 기본 흐름을 설명합니다.
그림 2: STHAL 상태 다이어그램
다음 단계에서는 각 상태를 자세히 설명합니다.
HAL 클라이언트는 loadSoundModel()이나 loadPhraseSoundModel()을 사용하여 모델을 로드합니다. 제공된 모델 객체는 사용할 구현별 감지 알고리즘(엔진)과 이 알고리즘에 적용할 수 있는 매개변수를 나타냅니다. 성공하는 경우 이러한 메서드는 후속 호출에서 이 모델을 참조하는 데 사용되는 핸들을 반환합니다.
모델이 성공적으로 로드되면 HAL 클라이언트는 startRecognition()을 호출하여 감지를 시작합니다. 인식은 다음 이벤트 중 하나가 발생할 때까지 백그라운드에서 계속 실행됩니다.
이 모델에서 stopRecognition()이 호출되었습니다.
감지가 발생했습니다.
리소스 제약 조건(예: 우선순위가 높은 사용 사례가 시작된 경우)으로 인해 감지가 중단됩니다.
후자의 두 경우에는 로드 시 HAL 클라이언트가 등록한 콜백 인터페이스를 통해 인식 이벤트가 전송됩니다. 어떠한 경우든 이러한 이벤트가 발생하면 감지가 비활성화되고 더 이상 인식 콜백이 허용되지 않습니다.
같은 모델을 나중에 다시 시작할 수 있고 이 프로세스는 필요한 만큼 반복할 수 있습니다.
마지막으로 더 이상 필요하지 않은 비활성 모델을 unloadModel()을 통해 HAL 클라이언트에서 로드 취소합니다.
HAL 오류 처리
드라이버 구현 간의 안정적이고 일관된 동작을 보장하기 위해 Android 11에서는 HAL에서 반환된 모든 비성공 오류 코드를 프로그래밍 오류로 간주하고, 복구하려면 HAL 프로세스를 다시 시작해야 합니다. 이는 최후의 복구 전략이며, 제대로 작동하는 시스템에서는 이러한 상황이 발생하지 않을 것으로 예상됩니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-26(UTC)
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["필요한 정보가 없음","missingTheInformationINeed","thumb-down"],["너무 복잡함/단계 수가 너무 많음","tooComplicatedTooManySteps","thumb-down"],["오래됨","outOfDate","thumb-down"],["번역 문제","translationIssue","thumb-down"],["샘플/코드 문제","samplesCodeIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-26(UTC)"],[],[],null,["# Sound Trigger\n\nThe Sound Trigger feature provides apps with the ability to listen for certain\nacoustic events, like hotwords, in a low-power and privacy-sensitive manner.\nExample use cases of Sound Trigger are Assistant and Now Playing.\n\nThis page gives an overview of the Sound Trigger architecture and its HAL\n(Hardware Abstraction Layer) interface.\n\nSound Trigger stack\n-------------------\n\nThe Sound Trigger subsystem is built in layers as shown in Figure 1:\n\n**Figure 1:** Sound Trigger stack\n\nThe following list describes each layer shown in Figure 1 in more detail:\n\n- The **HAL layer** (in green) contains the vendor specific code which\n implements the [Sound Trigger HAL](#sthal-interface) (STHAL) interface.\n\n | **Note:** A direct implementation of the STHAL interface is recommended rather than as an adapter around an implementation of a legacy HAL.\n- The **`SoundTriggerMiddleware`** (in yellow) resides above the HAL\n interface. It communicates with the HAL and is responsible for functionalities\n such as sharing the HAL between different clients, logging, enforcing\n permissions and handling compatibility with older HAL versions.\n\n- The **`SoundTriggerService`** (in blue) system resides above the middleware.\n It facilitates integration with other system features, such as telephony and\n battery events. It also maintains a database of sound models, indexed by unique\n IDs.\n\n- Above the `SoundTriggerService` layer, the stack (in brown) handles features\n specific to Assistant and generic apps separately.\n\nThe function of the Sound Trigger stack is to deliver discrete events that\nrepresent acoustic, trigger events. In most cases, the Sound Trigger stack does\nnot deal with audio. Upon receipt of the trigger events, apps get access to the\nactual audio stream, surrounding the time of the events, by opening an\n`AudioRecord` object via the Audio framework. The Sound Trigger HAL APIs provide\na handle with the triggered event that is used with the Audio Framework. Hence,\nsince the Sound Trigger HAL and Audio HAL are connected under the hood, they\ntypically share a process.\n| **Note:** Since models and data types are opaque to the framework in the Sound Trigger subsystem, it is expected that apps and the HAL implementation maintain a \"hidden contract\", that is, the actual contents, format and semantics of those data types are agreed upon. Hence, apps using Sound Trigger are intended to be vendor provided rather than by independent developers.\n\nSound Trigger HAL interface\n---------------------------\n\nThe Sound Trigger HAL (STHAL) interface is the vendor specific part of the Sound\nTrigger stack and it handles hardware recognition of hotwords and other sounds.\nSTHAL provides one or more engines with each one running a different algorithm\ndesigned to detect a specific class of sounds. When STHAL detects a trigger, it\nsends an event to the framework and then stops the detection.\n\nThe STHAL interface is specified under `/hardware/interfaces/soundtrigger/`.\n\nThe `ISoundTriggerHw` interface supports the ability to have one or more\ndetection sessions running at a given time and to listen to acoustic events.\nA call to `ISoundTriggerHw.getProperties()` returns a `Properties` structure\ncontaining implementation description and capabilities.\n\nThe basic flow of setting up a session is explained as follows in Figure 2:\n\n**Figure 2:** STHAL state diagram\n\nThe following steps describe each state in more detail:\n\n1. The HAL client loads a model using `loadSoundModel()` or\n `loadPhraseSoundModel()`. The provided model object indicates which\n implementation-specific detection algorithm (engine) to use, as well as the\n parameters applicable for this algorithm. Upon success, these methods return a\n handle which is used to reference this model in subsequent calls.\n\n2. Once the model has been successfully loaded, the HAL client calls\n `startRecognition()` to begin detection. Recognition continues to run in the\n background until one of the following events occurs:\n\n 1. A `stopRecognition()` has been called on this model.\n 2. A detection has occurred.\n 3. Detection is aborted due to resource constraints, for example, when a higher priority use case has been initiated.\n\n In the latter two cases, a recognition event is sent via the callback\n interface that is registered by the HAL client upon loading. In all cases,\n after any of these events occur, the detection becomes inactive and no more\n recognition callbacks are allowed.\n\n The same model can be started again at a later time, and this process can be\n repeated as many times as needed.\n3. Finally, an inactive model that is no longer needed is unloaded by the HAL\n client via `unloadModel()`.\n\n| **Note:** When a model is started, the HAL client can call `forceRecognitionEvent()` to generate a forced recognition event. The returned event is similar to a normal recognition event, but has its status field set to `FORCED`. Such recognition events do not automatically stop the recognition. Instead, the model state remains running even after the event has been delivered.\n\nHandle HAL errors\n-----------------\n\nTo ensure reliable and consistent behavior between driver implementations, in\nAndroid 11, any non-success error codes returned from\nthe HAL are treated as programming errors, recovery from which requires\nrestarting the HAL process. This is a last-resort recovery strategy and the\nexpectation is that such cases won't occur in a properly working system.\n| **Note:** Although these errors are being called out as valid in the HAL API documentation, there is ambiguity as to when and under what states these error codes are returned and what the expected error recovery procedure is. Hence, Android 11 mandates stricter conformance of Sound Trigger HAL implementations at runtime than the lower versions of Android."]]
