AudioFlinger駐留于MediaServer進程中。回顧一下它的代碼,如下所示:
**Main_MediaServer.cpp**
~~~
int main(int argc, char** argv)
{
sp<ProcessState> proc(ProcessState::self());
sp<IServiceManager>sm = defaultServiceManager();
....
//很好,AF和APS都駐留在這個進程
AudioFlinger::instantiate();
AudioPolicyService::instantiate();
....
ProcessState::self()->startThreadPool();
IPCThreadState::self()->joinThreadPool();
}
~~~
1. AudioFlinger的構造
**AudioFlinger.cpp**
~~~
void AudioFlinger::instantiate() {
defaultServiceManager()->addService( //把AF添加到ServiceManager中
String16("media.audio_flinger"), new AudioFlinger());
}
~~~
再來看它的構造函數:
**AudioFlinger.cpp**
~~~
AudioFlinger::AudioFlinger(): BnAudioFlinger(),
mAudioHardware(0), //代表Audio硬件的HAL對象
mMasterVolume(1.0f),mMasterMute(false), mNextThreadId(0)
{
mHardwareStatus= AUDIO_HW_IDLE;
//創建代表Audio硬件的HAL對象
mAudioHardware = AudioHardwareInterface::create();
mHardwareStatus = AUDIO_HW_INIT;
if(mAudioHardware->initCheck() == NO_ERROR) {
//設置系統初始化的一些值,有一部分通過Audio HAL設置到硬件中
setMode(AudioSystem::MODE_NORMAL);
setMasterVolume(1.0f);
setMasterMute(false);
}
}
~~~
AudioHardwareInterface是Android對代表Audio硬件的封裝,屬于HAL層。HAL層的具體功能,由各個硬件廠商根據所選硬件的情況來實現,多以動態庫的形式提供。這里,簡單分析一下Audio HAL的接口,至于其具體實現就不做過多的探討了。
2. AudioHardwareInterface介紹
AudioHardwareInterface接口的定義在AudioHardwareInterface.h中。先看看它。
**AudioHardwareInterface.h::AudioHardwareInterface聲明**
~~~
class AudioHardwareInterface
{
public:
virtual ~AudioHardwareInterface() {}
//用于檢查硬件是否初始化成功,返回的錯誤碼定義在include/utils/Errors.h
virtual status_t initCheck() =0;
//設置通話音量,范圍從0到1.0
virtual status_t setVoiceVolume(float volume) = 0;
/*
設置除通話音量外的其他所有音頻流類型的音量,范圍從0到1.0,如果硬件不支持的話,
這個功能會由軟件層的混音器完成
*/
virtual status_t setMasterVolume(float volume) = 0;
/*
設置模式,NORMAL的狀態為普通模式,RINGTONE表示來電模式(這時聽到的聲音是來電鈴聲)
IN_CALL表示通話模式(這時聽到的聲音是手機通話過程中的語音)
*/
virtual status_t setMode(intmode) = 0;
// 和麥克相關
virtual status_t setMicMute(bool state) = 0;
virtual status_t getMicMute(bool* state) = 0;
// 設置/獲取配置參數,采用key/value的組織方式
virtual status_t setParameters(const String8& keyValuePairs) = 0;
virtual String8 getParameters(const String8& keys) = 0;
// 根據傳入的參數得到輸入緩沖的大小,返回0表示其中某個參數的值Audio HAL不支持
virtualsize_t getInputBufferSize(uint32_tsampleRate, int format,
int channelCount) = 0;
/*下面這幾個函數非常重要 */
/*
openOutputStream:創建音頻輸出流對象(相當于打開音頻輸出設備)
AF可以往其中write數據,指針型參數將返回該音頻輸出流支持的類型、聲道數、采樣率等
*/
virtual AudioStreamOut* openOutputStream(
uint32_tdevices,
int *format=0,
uint32_t*channels=0,
uint32_t*sampleRate=0,
status_t*status=0) = 0;
//關閉音頻輸出流
virtual void closeOutputStream(AudioStreamOut* out) = 0;
/* 創建音頻輸入流對象(相當于打開音頻輸入設備),AF可以read數據*/
virtual AudioStreamIn* openInputStream(
uint32_tdevices,
int *format,
uint32_t*channels,
uint32_t *sampleRate,
status_t*status,
AudioSystem::audio_in_acoustics acoustics) = 0;
virtual void closeInputStream(AudioStreamIn* in) =0;
//關閉音頻輸入流
virtual status_t dumpState(int fd, const Vector<String16>&args) = 0;
//靜態create函數,使用設計模式中的工廠模式,具體返回的對象由廠商根據硬件的情況決定
staticAudioHardwareInterface* create();
......
};
~~~
根據上面的代碼,可以得出以下結論:
- AudioHardwareInterface管理音頻輸出設備對象(AudioStreamOut)和音頻輸入設備對象(AudioStreamIn)的創建。
- 通過AudioHardwareInterface可設置音頻系統的一些參數。
圖7-6表示AudioHardwareInterface和音頻輸入輸出對象之間的關系以及它們的派生關系:
:-: 
圖7-6 AudioHardwareInterface關系圖
從圖7-6中還可看出:
* 音頻輸出/輸入對象均支持設置參數(由setParameters完成)。
>[info] **說明**:AudioHardwareInterface最重要的功能是創建AudioStreamOut 和AudioStreamIn,它們分別代表音頻輸出設備和音頻輸入設備。從這個角度說,是AudioHardwareInterface管理著系統中所有的音頻設備。Android引入的HAL層,大大簡化了應用層的工作,否則不管是使用libasound(AlSA提供的用戶空間庫)還是ioctl來控制音頻設備,都會非常麻煩。
- 前言
- 第1章 閱讀前的準備工作
- 1.1 系統架構
- 1.1.1 Android系統架構
- 1.1.2 本書的架構
- 1.2 搭建開發環境
- 1.2.1 下載源碼
- 1.2.2 編譯源碼
- 1.3 工具介紹
- 1.3.1 Source Insight介紹
- 1.3.2 Busybox的使用
- 1.4 本章小結
- 第2章 深入理解JNI
- 2.1 JNI概述
- 2.2 學習JNI的實例:MediaScanner
- 2.3 Java層的MediaScanner分析
- 2.3.1 加載JNI庫
- 2.3.2 Java的native函數和總結
- 2.4 JNI層MediaScanner的分析
- 2.4.1 注冊JNI函數
- 2.4.2 數據類型轉換
- 2.4.3 JNIEnv介紹
- 2.4.4 通過JNIEnv操作jobject
- 2.4.5 jstring介紹
- 2.4.6 JNI類型簽名介紹
- 2.4.7 垃圾回收
- 2.4.8 JNI中的異常處理
- 2.5 本章小結
- 第3章 深入理解init
- 3.1 概述
- 3.2 init分析
- 3.2.1 解析配置文件
- 3.2.2 解析service
- 3.2.3 init控制service
- 3.2.4 屬性服務
- 3.3 本章小結
- 第4章 深入理解zygote
- 4.1 概述
- 4.2 zygote分析
- 4.2.1 AppRuntime分析
- 4.2.2 Welcome to Java World
- 4.2.3 關于zygote的總結
- 4.3 SystemServer分析
- 4.3.1 SystemServer的誕生
- 4.3.2 SystemServer的重要使命
- 4.3.3 關于 SystemServer的總結
- 4.4 zygote的分裂
- 4.4.1 ActivityManagerService發送請求
- 4.4.2 有求必應之響應請求
- 4.4.3 關于zygote分裂的總結
- 4.5 拓展思考
- 4.5.1 虛擬機heapsize的限制
- 4.5.2 開機速度優化
- 4.5.3 Watchdog分析
- 4.6 本章小結
- 第5章 深入理解常見類
- 5.1 概述
- 5.2 以“三板斧”揭秘RefBase、sp和wp
- 5.2.1 第一板斧--初識影子對象
- 5.2.2 第二板斧--由弱生強
- 5.2.3 第三板斧--破解生死魔咒
- 5.2.4 輕量級的引用計數控制類LightRefBase
- 5.2.5 題外話-三板斧的來歷
- 5.3 Thread類及常用同步類分析
- 5.3.1 一個變量引發的思考
- 5.3.2 常用同步類
- 5.4 Looper和Handler類分析
- 5.4.1 Looper類分析
- 5.4.2 Handler分析
- 5.4.3 Looper和Handler的同步關系
- 5.4.4 HandlerThread介紹
- 5.5 本章小結
- 第6章 深入理解Binder
- 6.1 概述
- 6.2 庖丁解MediaServer
- 6.2.1 MediaServer的入口函數
- 6.2.2 獨一無二的ProcessState
- 6.2.3 時空穿越魔術-defaultServiceManager
- 6.2.4 注冊MediaPlayerService
- 6.2.5 秋風掃落葉-StartThread Pool和join Thread Pool分析
- 6.2.6 你徹底明白了嗎
- 6.3 服務總管ServiceManager
- 6.3.1 ServiceManager的原理
- 6.3.2 服務的注冊
- 6.3.3 ServiceManager存在的意義
- 6.4 MediaPlayerService和它的Client
- 6.4.1 查詢ServiceManager
- 6.4.2 子承父業
- 6.5 拓展思考
- 6.5.1 Binder和線程的關系
- 6.5.2 有人情味的訃告
- 6.5.3 匿名Service
- 6.6 學以致用
- 6.6.1 純Native的Service
- 6.6.2 扶得起的“阿斗”(aidl)
- 6.7 本章小結
- 第7章 深入理解Audio系統
- 7.1 概述
- 7.2 AudioTrack的破解
- 7.2.1 用例介紹
- 7.2.2 AudioTrack(Java空間)分析
- 7.2.3 AudioTrack(Native空間)分析
- 7.2.4 關于AudioTrack的總結
- 7.3 AudioFlinger的破解
- 7.3.1 AudioFlinger的誕生
- 7.3.2 通過流程分析AudioFlinger
- 7.3.3 audio_track_cblk_t分析
- 7.3.4 關于AudioFlinger的總結
- 7.4 AudioPolicyService的破解
- 7.4.1 AudioPolicyService的創建
- 7.4.2 重回AudioTrack
- 7.4.3 聲音路由切換實例分析
- 7.4.4 關于AudioPolicy的總結
- 7.5 拓展思考
- 7.5.1 DuplicatingThread破解
- 7.5.2 題外話
- 7.6 本章小結
- 第8章 深入理解Surface系統
- 8.1 概述
- 8.2 一個Activity的顯示
- 8.2.1 Activity的創建
- 8.2.2 Activity的UI繪制
- 8.2.3 關于Activity的總結
- 8.3 初識Surface
- 8.3.1 和Surface有關的流程總結
- 8.3.2 Surface之乾坤大挪移
- 8.3.3 乾坤大挪移的JNI層分析
- 8.3.4 Surface和畫圖
- 8.3.5 初識Surface小結
- 8.4 深入分析Surface
- 8.4.1 與Surface相關的基礎知識介紹
- 8.4.2 SurfaceComposerClient分析
- 8.4.3 SurfaceControl分析
- 8.4.4 writeToParcel和Surface對象的創建
- 8.4.5 lockCanvas和unlockCanvasAndPost分析
- 8.4.6 GraphicBuffer介紹
- 8.4.7 深入分析Surface的總結
- 8.5 SurfaceFlinger分析
- 8.5.1 SurfaceFlinger的誕生
- 8.5.2 SF工作線程分析
- 8.5.3 Transaction分析
- 8.5.4 關于SurfaceFlinger的總結
- 8.6 拓展思考
- 8.6.1 Surface系統的CB對象分析
- 8.6.2 ViewRoot的你問我答
- 8.6.3 LayerBuffer分析
- 8.7 本章小結
- 第9章 深入理解Vold和Rild
- 9.1 概述
- 9.2 Vold的原理與機制分析
- 9.2.1 Netlink和Uevent介紹
- 9.2.2 初識Vold
- 9.2.3 NetlinkManager模塊分析
- 9.2.4 VolumeManager模塊分析
- 9.2.5 CommandListener模塊分析
- 9.2.6 Vold實例分析
- 9.2.7 關于Vold的總結
- 9.3 Rild的原理與機制分析
- 9.3.1 初識Rild
- 9.3.2 RIL_startEventLoop分析
- 9.3.3 RIL_Init分析
- 9.3.4 RIL_register分析
- 9.3.5 關于Rild main函數的總結
- 9.3.6 Rild實例分析
- 9.3.7 關于Rild的總結
- 9.4 拓展思考
- 9.4.1 嵌入式系統的存儲知識介紹
- 9.4.2 Rild和Phone的改進探討
- 9.5 本章小結
- 第10章 深入理解MediaScanner
- 10.1 概述
- 10.2 android.process.media分析
- 10.2.1 MSR模塊分析
- 10.2.2 MSS模塊分析
- 10.2.3 android.process.media媒體掃描工作的流程總結
- 10.3 MediaScanner分析
- 10.3.1 Java層分析
- 10.3.2 JNI層分析
- 10.3.3 PVMediaScanner分析
- 10.3.4 關于MediaScanner的總結
- 10.4 拓展思考
- 10.4.1 MediaScannerConnection介紹
- 10.4.2 我問你答
- 10.5 本章小結