AudioPolicyManager::setDeviceConnectionState 流程(一)

  当有线耳机插入/拔出或蓝牙耳机的插入/拔出等,这些事件都会引起Audio Route的重新配置。重新配置的过程实在AudioPolicyManager::setDeviceConnectionState中实现的。

/*status_t AudioPolicyManager::setDeviceConnectionState(audio_devices_t device, audio_policy_dev_state_t state,const char *device_address)*/

  该函数有三个参数,device:连接设备,state:连接状态,device_address:设备地址

  以有线耳机插入为例,device = 0x4 / 0x8(4环/3环),state = 0 / 1(拔出/插入), device_address = NULL.

  完整流程可以分为以下几个步骤:

  Step1:device check,判断该device是否为Output device or Input devices,若两者都不是,则表示该设备不合理。

  Step2:state check,根据state状态来进入不同的switch block内。因为分析的是耳机插入,这里会进到插入block。

  Step3:outputs check,寻找该device对应可以使用的Outputs,该Outputs由两部分组成,一个是当前存在并且mSupportDevices支持该device的mOutputs;另一个是从剩余的profiles中生成的。

  Step4:check output是否需要切换。

  Step5:close no needed ouputs

  Step6:set output devices

时间: 2024-11-05 11:37:27

AudioPolicyManager::setDeviceConnectionState 流程(一)的相关文章

Android AudioPolicyService和AudioPolicyManager

AudioPolicyService是Android音频系统的两大服务之一,另一个服务是AudioFlinger,这两大服务都在系统启动时有 MediaSever加载,加载的代码位于:frameworks\base\media\mediaserver \main_mediaserver.cpp.AudioFlinger主要负责管理音频数据处理以及和硬件抽象层相关的工作.本文主要介绍 AudioPolicyService.AudioPolicyService           AudioPoli

Android FM模块学习之一 FM启动流程

转自:http://blog.csdn.net/tfslovexizi/article/details/41283743 最近在学习FM模块,FM是一个值得学习的模块,可以从上层看到底层.上层就是FM的按扭操作和界面显示,从而调用到FM底层驱动来实现广播收听的功能. 看看Fm启动流程:如下图: 先进入FMRadio.java类,onCreate初始化一些数据,画出FM界面,启动fm在onStart()方法里启动FMRadioService.java (调用bindToService(this,

Android -- Audio Native服务之启动流程分析(一)

Android -- Audio Native服务之启动流程分析(一) Android中的Audio系统是比较庞大.繁杂的一部分内容, 其中会涉及较多的音频编解码.多媒体制式与Android Audio HAL设备管理的知识.随着Android的发展,其所支持的音频设备也变得越来丰富,如扬声器.耳机.听筒等等:这种变化也为Android管理如此丰富的音频设备以及如何正确.合理地切换音频输出提出了更高的要求.面对如此繁杂的管理要求,我们分析Android Audio服务的历程想必也不会轻松.接下来

耳机插拔流程

1.1      耳机 在Android系统中,有线耳机分两种,一种带mic,一种不带mic,带mic的耳机被称为Headset,不带mic的耳机被称为HeadPhone.在audio.h中,有以下几个设备来表示耳机: AUDIO_DEVICE_OUT_WIRED_HEADSET             = 0x4, AUDIO_DEVICE_OUT_WIRED_HEADPHONE           = 0x8, AUDIO_DEVICE_IN_WIRED_HEADSET         =

#24 centos6(RHEL)系列操作系统的启动流程、与命令chkconfig、grub的使用

所有由rc脚本关闭或启动的链接文件的原文件都存在于/etc/rc.d/init.d,系统为了方便使用,为此目录创建了链接/etc/init.d 所有/etc/inid.d(/etc/rc.d/init.d)目录中的脚本执行方式: # /etc/init.d/srv_script {start|stop|restart|status} # service srv_script {start|stop|restart|status} chkconfig命令: chkconfig - updates

游戏测试经历的流程及发版本注意的问题(或许有遗漏)

一.测试流程: 1.测试人员需要参与需求会议,了解需求,如有必要,提出疑问点,产品修改正 2.需求确定后,编辑测试用例或者测试功能点 3.开发提交完毕后,执行测试用例(要求开发出电脑版,节约前期打包,安装包的时间) 4.发现bug,提交bug到禅道,并通知相关人员 5.开发组修正bug,禅道指派给测试人员,表明已修复 6.对已修正的bug,进行回归测试 7.修正完毕的bug在禅道上置为关闭 8.待电脑版功能验证完毕后,进行手机包测试 9.整体测试完毕,可以发布包 补充: 1.中途有修改需求,也需

汇编语言入门:流程控制

流程控制:顺序,分支,循环 程序计数器PC中存储当前执行的程序在EM中的位置 汇编里面,用比较.跳转实现流程控制. 1.顺序:PC+1(不一定加一,看指令长度) 2.分支循环,直接赋给PC值,执行指定地址的程序 有时候需要程序有一定的流程控制能力,它不是老老实实按照顺序来执行的,中间可能会跳过一些代码 修改PC值,不可用MOV指令,PC是特殊的寄存器,特殊对待,跳转指令修改其值. 跳转指令: 1 ja 大于时跳转 2 jae 大于等于 3 jb 小于 4 jbe 小于等于 5 je 相等 6 j

1.2软件生命周期&测试流程

软件的生命周期 可行性分析-需求分析-软件设计-软件编码-软件测试-软件维护 1.可行性分析 主要确定软件开发的目的和可行性(PM) 2.需求分析 对软件的功能进行详细的分析(PM),输出需求规格说明书(原型图) 3.软件设计(DEV) 把需求分析得到的结果转换为软件结构和数据结构,形成系统架构 概要设计:搭建架构.模块功能.接口连接和数据传输 详细设计:模块深入分析,对各模块组合进行分析,伪代码   包含数据库设计说明 4.软件编码(DEV) 可运行的程序代码 5.软件测试 5.1.单元测试(

敏捷流程

流程简介 第一步:找出完成产品需要做的事情--Product Backlog 第二步:决定当前的冲刺需要解决的事情--Sprint Backlog 第三步:冲刺 第四步:得到软件的一个增量版本,发布给用户 敏捷流程的问题和解法 第一步:在计划中体现依赖关系 第二步:技术能力和交流能力 第三步:定义好任务 第四步:得到一个增量的软件发布 敏捷的团队: 自主管理 自我组织 多功能型 敏捷流程的经验教训: 敏捷宣言表明的是一些优先级 Scrum Master不是一个官,而是一个没有执行权力的沟通者 一