一 CarAudioService 初始化的起源
1 给APP的API接口
类AudioManager.java 的CarAudioManager.java
Car Audio API:它是提供给3rd APP调用的各个模块的接口,比如音频的API接口CarAudioManager。CarAudioManager和AudioManager类似,是CarAudioService的代理,与CarAudoService通过Binder进行跨进程通信,CarAudioManager运行在调用方的进程中。
目录:packages/services/Car/car-lib/src/android/car/media/CarAudioManager.java
//一些感兴趣的API
setGroupVolume
getGroupMaxVolume
getGroupMinVolume
getGroupVolume
setFadeTowardFront // 这个是直接通过AudioControl直接调整音箱前后声音的响度
setBalanceTowardRight // 这个是直接通过AudioControl直接调整音箱左右声音的响度
getVolumeGroupCount // 返回某个音区的volime group 数量
getVolumeGroupIdForUsage //返回某个音区中某一个Usage的VolumeGroup
getUsagesForVolumeGroupId //返回某个音区中某一个VolumeGroup的Usage
getVolumeGroupInfo
isPlaybackOnVolumeGroupActive
setPrimaryZoneMediaAudioRequestCallback //监听listen for request to play media audio in primary audio zone
mirror device 相关的接口
音量控制和音量变化回调接口
2 CarService
针对车机系统扩展的各种框架服务层,比如音频的扩展服务CarAudioService、Activity的扩展服务CarActivityService等。所有的这些扩展服务CarXXXService都是由CarService负责启动和管理生命周期。CarService会被打包进包名为"com.android.car"的CarService.apk中。它是一个System APP,SystemServer进程在启动时,会启动这个CarService。所以,所有的CarXXXService都是运行在"com.android.car"进程中的。源码位置:/packages/services/Car/service-builtin/和/packages/services/Car/service/
ps:
/packages/services/Car/service-builtin
这个目录中的文件改动,编译 make CarService
/packages/services/Car/service/ 这个里面的文件改动,
编译 make com.android.car.framework
Carservice 的加载时序图:
上图来源于Android13音频子系统分析(四)---座舱的多音区框架_carserviceimpl-优快云博客
说明:在ICarImpl.init()函数中,它会遍历调用所有框架服务的init()函数。所以,每个框架服务对象的初始化函数入口有两个:一个是其构造函数、一个是init()函数。
3 CarAudioService 的初始化(重点表达dynamic 路由注册部分)
3.1 CarAudioService init的时候调用setupDynamicRoutingLocked() 加载配置文件 car_audio_configuration.xml的详细时序图
说明:先解析car_audio_configuration.xml配置文件,得到音区,和音区关联的volumeGroups,然后是volumeGroups关联的device address,和device address关联的context(attribute)这些信息,然后封装成audiopolicy的mixer build rule策略,最后通过registerAudioPolicy接口注册到AudioPolicyManager的成员变量mPolicyMixes中,即AudioPolicyMixCollection集合中,留到后面播放声音的时候设备选择使用。
3.2 播放音乐时候根据上面注册的mPolicyMixes选择device 的流程
说明:应用播放声音 createTrack_l()的时候会在getOutputForAttrInt(...attribute)中使用上述注册的audio mixer policy 规则进行设备的选择
PS 如何再AAOS 上实现media 类型的 多声道播放,采用direct output(aaos 原生逻辑:这种存在一个风险是,因为direct output每次只能打开一个,如果前一个direct output没有关闭的情况下,应用就去打开播放,会存在打开direct output失败的情形,比如播放一个7.1.4声道的音乐,在接着播放一个5.1声道的音乐,那么在7.1.4音乐没有close的时候,5.1的音乐播放使用direct output会失败);其实可以修改这里,在赋值一个flag,让其走mixer 类型的output,不用每次使用都open/close.
使用direct output播放音乐的逻辑如下:
status_t AudioPolicyManager::getOutputForAttrInt(
3.3 AAOS audio 动态路由相关的XML
3.3.1 car_audio_configuration.xm
/device/generic/car/emulator/audio/car_audio_configuration.xml(这个定义zone\zoneconfig\volumegroup\device address\context等 audio mixer policy 策略)
一个典型的场景
3.3.2 audio_policy_configuration.xml
/device/generic/car/emulator/audio/audio_policy_configuration.xml(这个定义HW module name/attachedDevices/defaultOutputDevice/mixPorts/devicePorts/devicePort profile/devicePort profile gain/routes)
详细解读:
(1) module name:
(2)attachedDevices 和 defaultOutputDevices:
(3)mixPort
这里就是对应着audioflinger 中的各类playback / record 线程的名称,它也界定了这个线程对应的采样率、位数和声道数这些信息;还有一个逻辑是audiopolicymamager 初始化的时候会轮询各个mixPort,然后根据上面2中的attachedDevices去筛选支持的output/input mixport,并且是调用open去打开这个mixport,并且加入audiopolicymanager中的mOutputs list( direct output之后会close,Input的会关闭,其余的会一直保留);代码逻辑如下
(Talk is cheap, show me the code.)
(4) deviceport :这个就是定义 device Fe的名称了,这个需要在hal层对应的实现
车机上主要是根据 address name去做设备的区分的
(5)route 就是链接 上面的deviceport和mixport的通路,类似audiomanagerdaemon中的gateway的概率,将sink 和source 链接起来,形成一条独立的通路
4 车载HAL
需要OEM厂商实现的各种HAL层接口。源码位置:/hardware/interfaces/automotive/