Android启动错误“Waiting for sevice media.audio_flinger”的解决方案(全）

最新推荐文章于 2024-09-26 09:44:15 发布
最新推荐文章于 2024-09-26 09:44:15 发布
阅读量4.2k 收藏 1
点赞数
CC 4.0 BY-SA版权
分类专栏： android
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/kulolun/article/details/8534333
本文详细阐述了在Android系统中安装国外电子市场应用后遇到的Waiting for service media.audio_flinger错误，分析了系统启动时未启动mediasever服务的原因，并提供了具体的解决方案。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

今天发现我们的android系统安装了国外的一个电子市场后，这个APK无法运行，发现是“Waiting for sevice media.audio_flinger”。


系统启动时没有启动medaisever服务

具体为init.rc中的

service media /system/bin/mediaserver
   user media
    group system audio camera graphics inet net_bt net_bt_admin

不能被注释掉。





Android P Audio系统笔记：AudioPolicy&AudioFlinger初始化
zjy764219923的专栏
09-27 1622
AudioPolicy&AudioFlinger初始化
Android音频系统之AudioPolicyService的启动及audio_policy.conf的加载（Android5.1）
achina2011jy的博客
11-12 2012
一、引入： ，在Android中，应用进行音频回放或者录音，最终在hal层需要选择用哪个输入/输出设备，而设备的加载，就跟audio_policy.conf息息相关，本博文分析的内容就是Android原生音频audio_policy.conf加载的过程（Android5.1）。 二、源码分析： 1.AudioPolicyService服务的启动： 与音频相关的服务AudioFlinger和Audi...
Binder—ServiceManager 启动过程
韭菜鲜肉大馄饨的专栏
07-21 733
Binder—ServiceManager 启动过程一、main：入口函数1.1 binder_open：打开和映射 Binder 设备文件1.2 binder_become_context_manager：注册为 Binder 进程间通信机制的上下文管理者1.3 binder_loop：循环等待 Client 进程请求二、ServiceManager 启动过程时序图 一、main：入口函数 [–>service_manager.c, main()] int main(int argc, char *
关于shizuku系统级免root调用执行命令行等等系统方法的方案
qq_41340838的博客
06-09 3052
安卓无线调试调用部分root命令
Android Audio System 之二：AudioFlinger
热门推荐
DroidPhone的专栏
10-19 4万+
引言     AudioFlinger是Android音频系统的两大服务之一，另一个服务是AudioPolicyService，这两大服务都在系统启动时有MediaSever加载，加载的代码位于：frameworks/base/media/mediaserver/main_mediaserver.cpp。AudioPolicyService的相关内容请参考另一编文章：《Android Audio System 之三： AudioPolicyService 和 AudioPolicyManager 》http
Ubuntu18.04上编译AOSP最新版(Android Pie)遇到的问题及解决方法
Cbcwestwolf的博客
11-29 6142
在使用Ubuntu18.04 编译(build) AOSP时，遇到了以下错误。 一开始我选择lunch的是aosp_arm64-eng，即： source build/envsetup.sh lunch aosp_arm64-eng make -j16 #取决于机器的cpu核心数量 emulator 但是运行emulator之后，在输出信息没有error或者failed的情况下，emulator...
MediaPlayer播放视频与AudioFlinger交互流程
xqzhan的专栏
03-24 825
status_t MediaPlayerService::Client::setDataSource(         const char *url, const KeyedVector *headers) { player_type playerType = MediaPlayerFactory::getPlayerType(this, url);         sp p = setD
售后重启不开机
u012900947的博客
01-03 2488
一、背景介绍 售后机器不开机，经分析是分区损坏导致异常发生 二、分析过程 1.  从现象上看是手机有些是卡在开机动画或者开机第一帧反复重启或者不开机 2. 卡在第一帧的（一是卡在lk logo，二是卡在kernel log）需要打印出来串口log分析，卡在开机动画的可以抓取离线log（mtk平台在不开机状态下可以用GAT工具抓取） 第一种情况： 在优化第N个应用，优化到最后一个
服务、启动-Android音频系统之AudioFlinger(一)-by小雨
weixin_33834910的博客
04-15 193
首先声明，我是一个菜鸟。一下文章中出现技术误导情况盖不负责      1.1 AudioFlinger     在上面的框架图中，我们可以看到AudioFlinger(上面简称AF)是全部音频系统的核心与难点。作为Android系统中的音频中枢，它同时也是一个系统服务，启到承上(为下层供提拜访接口)启下(通过HAL来理管音频备设)的作用。只有理解了AudioFlinger，才能以此为基础更好...
Android深入浅出之Audio 第二部分 AudioFlinger分析
七夜雪主
07-16 1534
一 目的本文承接Audio第一部分的AudioTrack，通过AudioTrack作为AF（AudioFlinger）的客户端，来看看AF是如何完成工作的。在AT（AudioTrack）中，我们涉及到的都是流程方面的事务，而不是系统Audio策略上的内容。WHY？因为AT是AF的
pixel 8 的音频配置 media.audio_flinger media.audio_policy
zhang_jia_quan的博客
09-26 1681
Primary:Secondary:Primary:Secondary:Primary:Secondary:Primary:Secondary:
【Android Audio】dumpsys media.audio_flinger 分析【基于Android Q 】【不定期更新文章】
...
09-08 8879
AudioFlinger dumpsys1、第一部分​​​​2、第二部分 dumpsys media.audio_flinger 1、第一部分​​​​ 1、Output thread：表示当前线程为输出流的线程 2、I/O handle：表示当前的线程handle 3、Standby：no表示当前线程在运行。 4、Sample rate：采样率 6、HAL foramt：送给audio hal的格式 13、Output device：当前线程处理的数据输出到的音频设备 30、flags：标记输出流hal
audio框架学习-Audio_Flinger分析
永不秃头的程序员的博客
01-29 2008
文章目录一、代码位置二、audio服务启动2.1 main服务2.2 audioflinger添加到系统服务中2.3 audioflinger的对外接口 之前记录过audioTrack的笔记，这次继续参考audioFlinger相关的代码并做笔记； 参考文档：https://www.cnblogs.com/innost/archive/2011/01/15/1936425.html和https://blog.csdn.net/zyuanyun/article/details/60890534?spm=100
Android音频系统之AudioFlinger
michaelcao1980的专栏
01-06 1万+
1.1 AudioFlinger 在上面的框架图中，我们可以看到AudioFlinger(下面简称AF)是整个音频系统的核心与难点。作为Android系统中的音频中枢，它同时也是一个系统服务，启到承上(为上层提供访问接口)启下(通过HAL来管理音频设备)的作用。只有理解了AudioFlinger，才能以此为基础更好地深入到其它模块，因而我们把它放在前面进行分析。   1.1.1
AudioFlinger启动过程分析(android_audio)
we1less的博客
07-06 396
参考https://blog.csdn.net/zyuanyun/article/details/60890534#t4 首先来分析一下AudioFlinger 1.加载哪个so文件? 文件名是什么? 文件名从何而来? 参考上一篇https://blog.csdn.net/we1less/article/details/118424539 openDevice hardware/interfaces/audio/2.0/default/DevicesFactory.cpp 环节 aud...
Audio System 七 之 AudioFlinger
|~~~热爱生活、努力学习的小伙汁~~~|
09-30 1849
Audio System 七 之 AudioFlinger十二、深入剖析Android音频之AudioFlinger12.1 总体框架12.2 AudioFlinger12.2.1 AudioFlinger 服务的启动 和 运行12.2.2 音频设备的管理12.2.2.1 加载设备loadHwModule()12.2.2.2 打开音频输出通道openOutput()12.2.2.2.1 查找合适...
androidP audio system (三) ---＞ audioFlinger
android
09-03 849
audioFlinger介绍audioFlinger的启动和运行AudioFlinger 对音频设备的管理 介绍 我们前面知道AudioFlinger是android audio的核心内容，启动了承上启下的左右，向上向上层提供音频应用层所需的功能接口，向下直接接触 audio hal来管理音频设备。 audioFlinger的启动和运行 贴士： 一下代码讲解均是androidP 源码 frameworks/av/media/audioserver/audioserver.rc service audi
Android学习（十）AudioFlinger(1)
chuankuo5917的博客
10-13 281
AudioFlinger AudioFlinger驻留于MediaServer进程中： int main(int argc, char** argv){ sp<ProcessState> proc(ProcessState::self());...
Android音频系统AudioFlinger详解 超级干货
WolfKingzyh的博客
01-16 7935
深入理解Android音频框架AudioTrack到AudioFlinger、AudioMix的整个过程
dumpsys media.audio_flinger和dumpsys media.audio_policy的区别与分析
最新发布
07-01
<think>我们正在分析Android系统中的两个关键dumpsys命令：`media.audio_flinger`和`media.audio_policy`。根据引用内容，我们可以总结如下：1.**dumpsysmedia.audio_flinger**：聚焦于音频系统的硬件层，主要用于分析音频处理过程中的底层问题，如卡顿、延迟、欠载（underrun）等。它提供了关于音频流、混音器状态、硬件设备使用情况等详细信息（引用[2]）。 2. **dumpsys media.audio_policy**：聚焦于音频策略层，主要处理音频路由策略、设备选择、音量控制等策略相关的问题。它适合诊断音频路由错误（例如音频输出到错误的设备）或设备不匹配问题（引用[2]）。 ###功能详细对比| **功能/特性**|**dumpsysmedia.audio_flinger**| **dumpsys media.audio_policy**| |-----------------------|----------------------------------------------------------|----------------------------------------------------------| |**核心关注点**|音频硬件交互、混音过程、缓冲区状态|音频策略决策（路由、设备选择、音量策略）| |**适用问题类型**|卡顿、延迟、欠载、播放中断|路由错误（如音频未从预期设备输出）、设备切换失败| |**输出内容示例**|活动音频流、混音器状态、硬件设备状态、缓冲区状态|当前音频策略配置、可用设备列表、活动策略、音量曲线|| **调试场景**|播放异常（如杂音、断断续续）、录音延迟|蓝牙耳机无法切换、外放与听筒切换失败|###实际应用建议-当遇到音频播放卡顿、延迟或录音异常时，优先使用`dumpsysmedia.audio_flinger`检查硬件层状态（引用[3]）。 -当音频输出设备错误（例如本该从蓝牙输出却从扬声器输出），或音量控制异常时，使用`dumpsysmedia.audio_policy`检查策略配置（引用[2]）。 ###分析流程示例（车机音频问题）1.**初步定位**：通过`logcat`查看应用层错误日志。2.**分层诊断**：-使用`dumpsysmedia.audio_policy`确认音频路由策略是否正确。-若路由正常但仍有卡顿，再通过`dumpsys media.audio_flinger`分析硬件缓冲区和混音器状态。 3. **深度工具辅助**：结合`systrace`观察系统级延迟（引用[3]）。###典型输出解读####audio_flinger片段```plaintextHardware status:Mastervolume:1.000000Stream volumes:- STREAM_MUSIC:1.000000Active tracks:Track name: AudioTrack,SessionID:123, Bufferstatus:512/1024frames``` 这里关注`Buffer status`（缓冲区填充状态），若值持续偏低则可能导致欠载（播放中断）。#### audio_policy片段```plaintextDevices:- Device:0x8 (AUDIO_DEVICE_OUT_BLUETOOTH_A2DP), Name: "BTSpeaker"- Device:0x2 (AUDIO_DEVICE_OUT_SPEAKER),Name:"Built-in Speaker"Activepolicy:Outputformusic:device=0x8(BTSpeaker)``` 此处确认音乐流是否按预期路由到蓝牙设备。###总结- **audio_flinger**：硬件执行层监控，解决“播放是否流畅”问题。- **audio_policy**：策略决策层监控，解决“音频去哪儿了”问题（引用[2][3]）。 §§相关问题§§1.如何解读`dumpsysmedia.audio_flinger`输出的缓冲区状态？2.`dumpsysmedia.audio_policy`中如何判断音量策略是否生效？3.Android音频问题分析中，`logcat`和`systrace`如何配合dumpsys使用？</think>### Android `dumpsys media.audio_flinger` 与 `dumpsys media.audio_policy` 功能对比分析 #### 1. **核心功能定位** - **`media.audio_flinger`** 聚焦 **音频硬件交互层**，直接管理音频流的混音、播放和硬件设备操作。 核心功能： - 实时监控音频缓冲区状态（欠载/溢出） - 跟踪混音器线程性能（延迟、卡顿） - 显示活跃音频轨道的硬件参数（采样率、帧数） - 诊断底层硬件异常（如 DMA 传输错误） *适用场景：音频播放卡顿、杂音、延迟问题分析* [^2][^3] - **`media.audio_policy`** 聚焦 **音频策略决策层**，管理音频路由规则和系统策略。 核心功能： - 显示当前音频设备路由状态（如蓝牙/扬声器切换） - 列出系统支持的音频输出/输入设备 - 检查音量策略和音频焦点冲突 - 验证策略规则匹配（如车载多音区控制） *适用场景：音频输出到错误设备、音量控制失效、多设备切换异常* [^2][^3] --- #### 2. **关键输出内容对比 | **特征** | `audio_flinger` 输出内容 | `audio_policy` 输出内容 | |-------------------------|--------------------------------------------------|---------------------------------------------| | **设备状态** | 硬件设备实时负载（如 DMA 缓冲区） | 可用设备列表及激活状态 | | **音频流** | 活动音频流详细参数（采样率、通道数、帧计数） | 音频流与设备的绑定关系 | | **性能指标** | 硬件级延迟数据、欠载(underrun)次数 | 路由策略执行时间 | | **策略配置** | 无 | 音量曲线、焦点策略、强制路由规则 | | **典型问题线索** | `Hardware status`/`Underrun` 字段 | `Devices`/`Outputs`/`Stream` 路由状态 | --- #### 3. **协同工作流程示例 ```mermaid graph LR A[应用请求播放音频] --> B(audio_policy 决策) B --> C{选择输出设备} C -->|蓝牙耳机| D[audio_flinger 驱动硬件] D --> E[监控缓冲区状态] E -->|欠载告警| F[audio_flinger 日志标记] ``` --- #### 4. **典型问题诊断指南 - **音频卡顿问题**： 先查 `audio_flinger` 的 `Underrun count`（缓冲区欠载次数），再结合 `systrace` 分析线程阻塞点 [^3] - **设备切换失败**： 检查 `audio_policy` 的 `Output devices` 是否包含目标设备，并验证 `Strategy` 匹配规则 [^2] - **音量异常**： 在 `audio_policy` 中确认音量曲线（`Curves for stream`）是否被修改，在 `audio_flinger` 验证硬件增益值 --- #### 5. **高级分析技巧 1. **关联日志过滤** ```bash adb logcat | grep -E "AudioFlinger|AudioPolicy" ``` 2. **时间戳对齐** 对比 `audio_flinger` 的帧时间戳和系统时钟，定位硬件延迟 3. **策略模拟测试** 通过 `audio_policy` 输出重建路由决策树 > 关键结论：`audio_flinger` 是音频流水线的"执行引擎"，`audio_policy` 是"导航系统"，二者协同保障 Android 音频架构运行 [^2][^3]。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值