2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main
대신 android-latest-release
를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
음성 상호작용 정보
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
Voice Interaction Service API는 다양한 음성 제어 앱을 위한 추상화를 제공합니다. 앱 구현은 앱 개발에 설명한 가이드라인에 따라 개발하면 됩니다.
이 통합 가이드의 콘텐츠는 이러한 앱을 특정 Android Automotive OS(AAOS) 시스템 이미지에 통합하는 방법을 설명합니다.
용어
다음 용어는 이 가이드에서 다음과 같이 사용됩니다.
- 지원 데이터: 음성 상호작용 세션이 시작되면 시스템은 뷰와 스크린샷을 캡처하고 이 정보를 세션에 전달할 수 있습니다. 앱은
Activity#onProvideAssistData()
와 Activity#onProvideAssistContent()
를 구현하여 추가 정보를 노출할 수 있습니다.
- 눌러서 말하기(PTT): 일반적으로 핸들에 있는 물리적 음성 제어 버튼입니다.
- RecognitionService(RS):
SpeechRecognizer
API를 통해 앱에서 사용하는 음성 인식 서비스입니다. VIA는 VoiceInteractionService
및 RecognitionService
를 모두 포함해야 합니다.
- 탭하여 말하기(TTT): 소프트웨어 음성 제어 버튼입니다(일반적으로 시스템 UI의 일부로 포함됨). Android에서는 이를 지원 동작이라고도 합니다.
VoiceInteractionService
: VIA 개발자가 구현하는 경량 시스템 서비스입니다. 선택한 서비스는 부팅 시 시스템 서비스와 결합하며 항상 실행됩니다.
- VoiceInteractionSession(VIS): 이 클래스는 사용자 상호작용 비즈니스 로직을 캡슐화합니다. 또한, 사용자에게 음성 상호작용 상태를 제시하고 VoiceInteractor 요청을 처리하며 지원 및 스크린샷 데이터를 수신하는 역할을 합니다.
- VoiceInteractionSessionService(VSS): VIA의 일부인 서비스로 음성 상호작용 세션을 처리합니다. 이 서비스는 사용자와 음성 상호작용 중에 Android 시스템 서비스와 결합합니다. 이 세션의 모든 비즈니스 로직은
VoiceSession
클래스에 구현됩니다.
이 서비스는 단일 사용자 음성 세션 중에만 활성 상태가 유지됩니다.
- 음성 상호작용 앱(VIA). 음성 제어를 사용하여 작동하도록 설계된 Android 앱입니다(어시스턴트라고 함). 이러한 앱은 매니페스트에
VoiceInteractionService
를 포함하여 식별할 수 있습니다.
이러한 앱은 시스템에서 한 번에 하나만 기본값으로 선택할 수 있습니다.
기본 앱만 활성 상태로 유지되며(시스템 서비스에 결합됨), 눌러서 말하기(PTT) 또는 탭하여 말하기(TTT) 이벤트를 수신할 수 있습니다.
책임
이 표에서는 각 당사자가 해야 하는 작업을 설명합니다.
자동차 제조업체(OEM) |
AOSP |
앱 개발자 |
- AAOS와 호환되는 인포테인먼트 시스템을 빌드합니다.
- DSP 핫워드 감지 지원(선택사항)을 포함하여 오디오 입력과 출력을 구현합니다.
- 음성 상호작용 서비스의 시스템 권한을 부여합니다.
- 앱의 설정 화면 액세스에 관한
VoiceInteractionService 요구사항을 준수합니다.
|
VoiceInteractionService 및 관련 API를 정의하고 발전시킵니다.
- VIA 개발자에게 API 문서, 샘플 코드, 기타 지원 자료를 제공합니다.
- 요구사항 및 권장사항을 포함하여 UX 가이드를 제공합니다.
|
VoiceInteractionService API, RecognitionService API, NotificationListenerService API를 구현합니다(앱 개발에서 자세한 설명 참고).
- 각 자동차 설계 시스템에 맞게 OEM에서 조정할 수 있도록 맞춤설정이 가능한 UI를 제공합니다.
|
UX 요구사항
OEM은 고객에게 우수한 사용자 환경을 제공할 궁극적인 책임이 있습니다.
OEM은 사전 설치된 모든 음성 상호작용 서비스가 미리 로드된 어시스턴트: UX 가이드에서 설명하는 요구사항을 충족하는지 확인해야 합니다.
핵심 어시스턴트 환경
자동차 음성 상호작용 애플리케이션(VIA)은 다음 작업을 실행합니다.
- [필수] 시스템에서 처리하는 음성 상호작용 트리거(PTT, TTT)에 응답해야 합니다.
- [필수] 진행 상태(예: 수신 대기, 처리, 실행)를 시각적으로 표시해야 합니다.
- [필수] 음성 또는 소리를 사용하여 사용자 요청을 이해하고 완료했음을 표시해야 합니다.
- [필수] 다른 앱의 음성 인식기 역할을 해야 합니다(SpeechRecognizer API 참고).
- [권장] 핫워드 트리거에 응답해야 합니다.
- [허용] 사용자가 VIA를 구성할 수 있는 설정 활동(예: 권한, 핫워드 구성 및 로그인)을 표시할 수 있습니다.
- [허용] 지원 데이터를 처리할 수 있습니다(
Intent#ACTION_ASSIST
).
- [허용] Keyguard(잠금 화면)에서 음성 상호작용을 지원할 수 있습니다.
구성요소
개략적으로 음성 상호작용 앱은 다음과 같은 구성요소와 상호작용합니다.

그림 1. 음성 상호작용에 관여하는 구성요소
자세한 내용은 다음과 같습니다.
VoiceInteractionManagerService
: 이 시스템 서비스는 기본 VIA를 관리하고 기본 VIA 기능을 시스템의 다른 부분에 노출합니다.
RecognitionService
: 이 서비스는 음성 인식 기능을 시스템의 다른 앱에 노출합니다.
SoundTrigger
: 핫워드 관리를 구현합니다. 구현된 핫워드 관리는 AlwaysOnHotwordDetector를 통해 VIA에서 사용할 수 있습니다.
MediaRecorder
: 핫워드 감지(CPU 사용 시) 및 음성 인식용 오디오 입력 액세스를 제공합니다.
PhoneWindowManager
/CarInputService
: 이러한 서비스는 VoiceInteractionManagerService
를 통해 다른 구성요소 간에 PTT를 VIA로 라우팅하는 키 이벤트를 처리합니다.
User
: 사용자는 트리거(PTT, TTT, 핫워드) 또는 음성 플레이트 UI를 통해 VIA와 상호작용합니다.
- CarService, Notifications, Media, Telephony, ContactsProvider 등:
VoiceInteractionSession에서 사용자의 명령어를 처리하기 위해 사용하는 서비스 및 앱입니다.
Automotive 관련 개념
AAOS는 다음과 같은 측면에서 Android와 다릅니다.
- 일반적인 어시스턴트 기능 외에도 AAOS VIA는 차량 기능(예: HVAC, 좌석, 내부 조명)을 제어할 수 있습니다. 이러한 기능은 독점 권한 허용 목록에 설명한 대로 OEM이 액세스 권한을 올바르게 구성한 경우 CarPropertyManager API를 사용하여 통합될 수 있습니다(자세한 내용은 차량 속성 읽기 참고).
- 맞춤설정 및 일관성은 다른 폼 팩터보다 Automotive에서 더 중요합니다. 이러한 가이드라인을 구현하는 방법에 관한 자세한 내용은 맞춤설정을 참고하세요.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(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-27(UTC)"],[],[],null,["# About voice interaction\n\nThe Voice Interaction Service API provides an abstraction over different\npotential voice control apps. Implementations can be developed following the guidelines\ndescribed in\n[App development](/docs/automotive/voice/voice_interaction_guide/app_development).\nThe content in this integration guide describes how to integrate these apps into\na specific Android Automotive OS (AAOS) system image.\n\nTerminology\n-----------\n\nThese terms are used through this guide:\n\n- **Assist data.** When a voice interaction session is started, the system is able to capture views and screenshots, and pass this information to the session. Apps can expose additional information by implementing [Activity#onProvideAssistData()](https://developer.android.com/reference/android/app/Activity#onProvideAssistData(android.os.Bundle)) and [Activity#onProvideAssistContent()](https://developer.android.com/reference/android/app/Activity#onProvideAssistContent(android.app.assist.AssistContent)).\n- **[Push-to-talk (PTT)](https://developer.android.com/reference/android/service/voice/VoiceInteractionSession#SHOW_SOURCE_PUSH_TO_TALK)**. Physical voice control button, usually located in the steering wheel.\n- **RecognitionService (RS).** Voice recognition service used by apps through the [SpeechRecognizer](https://developer.android.com/reference/android/speech/SpeechRecognizer)`\n ` API. VIAs must include both the `VoiceInteractionService` *and* the `RecognitionService`.\n- **[Tap-to-talk (TTT)](https://developer.android.com/reference/android/service/voice/VoiceInteractionSession#SHOW_SOURCE_ASSIST_GESTURE)** . Software voice control button, usually included as part of the system UI). In Android this is also referred to as *Assist Gesture*.\n- **[VoiceInteractionService](https://developer.android.com/reference/android/service/voice/VoiceInteractionService)**. Lightweight system service implemented by the VIA developer. The selected service is bound from system service on boot, and is always running.\n- **VoiceInteractionSession (VIS).** This class encapsulates the user interaction business logic. It is responsible for presenting the user with status of the voice interaction, handling VoiceInteractor requests and receiving assist and screenshot data.\n- **VoiceInteractionSessionService (VSS).** A service, part of a VIA, responsible for handling a voice interaction session. This service is bound from Android's system service during a voice interaction with a user. All business logic of this session is implemented in the `VoiceSession` class. This service is only guaranteed to stay alive during a single user voice session.\n- **Voice Interaction App (VIA).** Android app designed to serve as a voice control (referred to as *assistant* ). These apps can be identified by including a `VoiceInteractionService` in their manifest. Only one of these apps can be selected as *default* at a time in the system. Only the default app will be maintained alive (bound from a system service), and will be the receiver of [Push-To-Talk (PTT)](https://developer.android.com/reference/android/service/voice/VoiceInteractionSession#SHOW_SOURCE_PUSH_TO_TALK) or [Tap-To-Talk (TTT)](https://developer.android.com/reference/android/service/voice/VoiceInteractionSession#SHOW_SOURCE_ASSIST_GESTURE) events.\n\nResponsibilities\n----------------\n\nThis table describes the responsibilities of each party.\n\n| Car Manufacturers (OEMs) | AOSP | App Developers |\n|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| - Build a [compatible](/compatibility/android-cdd) infotainment system with AAOS. - Implement audio input and output, optionally including DSP hotword detection support. - Grant system-privileged permissions for the voice interaction services. - Respect `VoiceInteractionService` requirements regarding access to app's settings screens. | - Define and evolve `VoiceInteractionService` and related APIs. - Provide API documentation, sample code and other support material to VIA developers. - Provide UX guidance with requirements and recommendations. | - Implement `VoiceInteractionService` API, RecognitionService API and NotificationListenerService API (see detailed description at [App development](/docs/automotive/voice/voice_interaction_guide/app_development)). - Provide a customizable UI that can be adjusted by OEMs to match each car design system. |\n\nUX requirements\n---------------\n\nOEMs have the ultimate responsibility of providing a good user experience to customers.\nOEMs must ensure that the all pre-installed voice interaction services fulfill the\nrequirements described in\n[Preloaded Assistants: UX Guidance](/static/docs/automotive/voice/voice_interaction_guide/preloaded-assistants_UX-guidelines.pdf).\n\nCore assistant experience\n-------------------------\n\nAn automotive Voice Interaction Application (VIA) performs the following actions:\n\n- \\[MUST\\] Respond to system-handled voice interaction triggers (PTT, TTT).\n- \\[MUST\\] Display a visual representation of their progress (for example, listening, processing, and fulfilling).\n- \\[MUST\\] Use voice or sounds to indicate understanding and completion of user requests.\n- \\[MUST\\] Serve as a speech recognizer for other apps (see the [SpeechRecognizer\n API](https://developer.android.com/reference/android/speech/SpeechRecognizer)).\n- \\[SHOULD\\] Respond to a hotword trigger.\n- \\[MAY\\] Display a settings activity where users can configure this VIA (for example, permissions, hotword configuration, and sign-in).\n- \\[MAY\\] Handle assist data ([Intent#ACTION_ASSIST](https://developer.android.com/reference/android/content/Intent#ACTION_ASSIST))\n- \\[MAY\\] Support voice interaction from Keyguard (lock screen).\n\nComponents\n----------\n\nAt a high level, a voice interaction app interacts with these actors:\n\n**Figure 1.** Voice interaction actors\n\nDetails:\n\n- `VoiceInteractionManagerService`. This system service is responsible for managing the default VIA, and exposing its functionality to the rest of the system.\n- `RecognitionService`. This service exposes speech recognition capabilities to other apps in the system.\n- `SoundTrigger`. Implements hotword management and it's available to VIAs through the AlwaysOnHotwordDetector.\n- `MediaRecorder`. Provides access to audio input for both hotword detection (when using CPU) and speech recognition.\n- `PhoneWindowManager`/`CarInputService`. These services are responsible (among other things) for handling key events, routing PTT to the VIA, by means of the `VoiceInteractionManagerService`.\n- `User`. The user interacts with a VIA by means of Triggers (PTT, TTT, Hotword) or the Voice Plate UI.\n- **CarService, Notifications, Media, Telephony, ContactsProvider, and so on.** Services and apps used by the VoiceInteractionSession to fulfill the user's commands.\n\nAutomotive-specific concepts\n----------------------------\n\nAAOS diverges from Android in the following aspects:\n\n- Besides normal Assistant functionalities, AAOS VIAs can control vehicle functions (for example, HVAC, seats, and interior lights). These functionalities can be integrated using the CarPropertyManager API (see more at [Read a\n vehicle property](/docs/automotive/voice/voice_interaction_guide/fulfilling_commands#vehicle-property)) provided OEMs configure access correctly as described in [Privileged permission allowlisting](/docs/core/permissions/perms-allowlist).\n- Customization and consistency are more relevant in Automotive than in any other form factor. See [Customization](/docs/automotive/voice/voice_interaction_guide/integration_flows#customization) to read more about implementing these guidelines."]]