安卓手机APP开发__媒体开发部分__分享声音的输入

安卓手机APP开发__媒体开发部分__分享声音的输入

目录

概述

安卓10之前的版本的行为

安卓10的行为

共享场景

小助手+普通的APP

[有可读取权的服务 + 普通的APP](#有可读取权的服务 + 普通的APP)

两个普通的APP

[语音电话 + 普通的APP](#语音电话 + 普通的APP)


概述

声音的输入通常来自于内嵌的麦克风,还有外置的麦克网,或者是一个附加到一个设备上的

一个音频接口.声音输入也能来自于一个电话的会话.

有时候,两个或者是多个APP可能都要捕捉同一个音频输入.他们可能是执行不同的任务.

例如,一些APP接收声音可能是录制,像一个简单的语音录音机,然而,其它的APP可能是监听,

像是谷歌的小助手或者是一个可读取性的设备,为了对语音指令进行响应.

在每一个情况下,这些APP都要接收音频输入.这里,我们使用的捕捉这个术语,是无关于一个

是在录制还是仅在监听.

如果两个或者多个APP要同时捕捉音频,这有一个问题,是从同一个音频源向多个目标进行传递

声音信号的问题.这里描述了安卓系统如何在捕捉音频信号的多个APP之间共享音频输入的方法.

安卓10之前的版本的行为

安卓10之前的时候,输入的音频流在一个时间点仅能被一个APP捕捉信号.如果

一些APP准备录制或者是监听音频时,你的APP能创建一个音频记录的对象,

但是当你调用音频记录的开始录制的方法时,将返回一个错误,录制并没有开始.

这个规则的一个例外是当一个有特权的APP(像谷歌小助手,或者是一个有读取权的服务)

有权限android.permission.CAPTURE_AUDIO_HOTWORD,并且使用的音频源的类型是HOTWORD

在这个情况下,其它的APP能开始录制.当发生特权APP中止时,一个新的APP开始捕捉输入.

在安卓9中添加一个更改:仅在前台运行中的APP能够捕捉音频输入.当一个APP没有一个前台的服务

或者是前台的用户界面组件开始捕捉信号时,APP继续运行,但是仅能接收到静默的声音状态,

甚至它是唯一的APP在那个时候捕捉音频.

安卓10的行为

安卓10的行为是"先来,先服务".一旦一个APP开始捕捉音频了,没有其它的APP

能读取音频的输入了,一直到APP捕捉音频的操作停止了.

安卓10强调了一个优先权的模式,在运行中的APP之间,能够切换输入的音频流.

在绝大部分情况下,如果一个新的APP要求音频输入,先前捕捉信号的APP会继续

运行,但接收到的是静音.在一些情况下,系统能继续向各个APP投递音频.

各种共享场景在下面做解释.

这个模式与音频焦点处理多个APP播放的方式是类似的.然而,音频焦点是被

程序化的请求来管理的,这里的输入模式的切换是基于优先级的策略,当一个新的

APP开始捕捉音频时自动切换的.

对于捕捉音频的目的,安卓区分了两类的APP:

由用户安装的普通的APP

在设备上预安装的特权APP.这包括了谷歌小助手和所有的有读取权的服务.

此外,一个APP被区别对待,看的是它是否使用了"隐私敏感的"音频源

CAMCORDER 或者是 VOICE_COMMUNICATION.

使用和共享音频输入的优先级规则如下:

特权APP比普通的APP有更高的优先权.

有可见的前台用户界面的APP比后台的APP有更高的优先权.

从一个隐私敏感的音频源捕捉音频的APP比没有从隐私敏感的

音频源捕捉音频的APP的优先权更高

两个普通权限的APP不能同时捕捉音频。

在一些情况下,一个有特权的APP能和其它的APP共享音频输入。

如果两个后台APP有相同的捕捉音频的优先级,那么后一个APP开始捕捉音频时,

它的优先级更高一点

共享场景

当两个APP试图捕捉音频时,它们都可能接收到输入的信号,或者是它们中的一个可能接收到静音。

这里有四个主要的场景:

小助手+普通的APP

有可读取权的服务 + 普通的APP

两个普通的APP

语音电话 + 普通的APP

小助手+普通的APP

小助手是一个特权的APP,因为它是一个预安装的APP,并且它有角色RoleManager.ROLE_ASSISTANT

任何其它的预安装的APP,有这个角色的APP,也有类似的待遇。

安卓共享音频输入,是基于如下的这些规则:

小助手能接收到音频(无论它在前台还是在后台)只要不是其它的APP

正在捕捉隐私敏感的音频源就行。

如果小助手没有在屏幕的顶层上有可见的用户界面组件的话,其它APP可以接收音频输入。

注意的是,当小助手在后台,其它的APP没有从隐私敏感的音频源捕捉信号时,两者都可以接收

音频输入。

有可读取权的服务 + 普通的APP

一个有可读取权的服务,需要一个严格的声明。

安卓共享音频输入,是基于如下的这些规则:

如果服务的用户界面在屏幕的顶层可见,服务和APP都接收音频输入。

这个行为提供了控制语音电话或者是有语音指令的视频捕捉的功能。

如果服务没在屏幕的顶层可见,这种情况就类似于两个普通的APP的情况了。

两个普通的APP

当两个APP在并发地捕捉信号时,仅有一个APP接收到了音频,另一个是静音。

安卓共享音频输入,是基于如下的这些规则:

如果没有APP是隐私敏感的,用户界面在屏幕顶层可见的APP,来接收音频。

如果没有APP有用户界面,开始捕捉音频的APP,现在更可能在接收音频。

如果一个APP是隐私敏感的,它接收音频,另一个不接收音频。即使是另一个

有用户界面在屏幕顶层可见,或者是它刚才还在接收音频。

如果两个APP都是隐私敏感的,开始捕捉音频的APP,现在更可能在接收音频,而另一个接收静音。

语音电话 + 普通的APP

一个语音电话是活动的,如果音频模式,由AudioManager.getMode()返回的是

MODE_IN_CALL 或者是 MODE_IN_COMMUNICATION.

安卓共享音频输入,是基于如下的这些规则:

电话总是在接收音频。

如果APP是有可读取性权限的服务时,它能够捕捉音频。

如果一个APP是一个预安装的特权APP,并且有权限CAPTURE_AUDIO_OUTPUT时

这个APP能够捕捉语音电话的音频。

为了捕捉语音电话的上连接,下连接,或者是两者都有,APP必须指定

音频源是MediaRecorder.AudioSource.VOICE_UPLINK 或者 MediaRecorder.AudioSource.VOICE_DOWNLINK, 并且/或者是设备AudioDeviceInfo.TYPE_TELEPHONY.

相关推荐
海棠AI实验室15 分钟前
AI的进阶之路:从机器学习到深度学习的演变(一)
人工智能·深度学习·机器学习
hunteritself18 分钟前
AI Weekly『12月16-22日』:OpenAI公布o3,谷歌发布首个推理模型,GitHub Copilot免费版上线!
人工智能·gpt·chatgpt·github·openai·copilot
IT古董1 小时前
【机器学习】机器学习的基本分类-强化学习-策略梯度(Policy Gradient,PG)
人工智能·机器学习·分类
centurysee1 小时前
【最佳实践】Anthropic:Agentic系统实践案例
人工智能
mahuifa1 小时前
混合开发环境---使用编程AI辅助开发Qt
人工智能·vscode·qt·qtcreator·编程ai
四口鲸鱼爱吃盐1 小时前
Pytorch | 从零构建GoogleNet对CIFAR10进行分类
人工智能·pytorch·分类
蓝天星空1 小时前
Python调用open ai接口
人工智能·python
睡觉狂魔er1 小时前
自动驾驶控制与规划——Project 3: LQR车辆横向控制
人工智能·机器学习·自动驾驶
scan7242 小时前
LILAC采样算法
人工智能·算法·机器学习
leaf_leaves_leaf2 小时前
win11用一条命令给anaconda环境安装GPU版本pytorch,并检查是否为GPU版本
人工智能·pytorch·python