由於自己的工作內容是和android 系統audio 相關，雖然只是調用了Android的幾個NDK接口進行音頻數據的采集以及轉碼工作，但是我還是趁着這個契機好好的認真的學習一下android audio的整體框架，來豐富自己的知識庫。在此記錄下自己的學習過程，如果有幸有人在此和我討論以及分享自己的內容，那么我將不勝感激。話不多說，直接進入正題。
雖然具有爭議，但是我仍然認為android系統在本質上與linux系統沒有區別，只是對linux系統上的部分系統組件進行了添加以及優化。在用戶空間上增加了一套完整的framework框架來實現自己的特定功能需求，所以liunx系統上的很多概念仍然在安卓系統之上仍然適用。
在傳統的linux系統上，一個依賴於具體的物理設備的用戶系統，大概分為幾個部分：物理硬件、操作系統、設備驅動（內核空間）以及用戶程序，對此在安卓上也仍然適用。
不過在Android系統上，為了避免Linux系統的對於軟件開源的具體要求，將傳統的設備驅動程序進行了再次拆分為驅動程序以及用戶空間的驅動程序（HAL）。通過這種設計，部分硬件廠商就可以將具有自主產權的設計功能放在HAL層實現，只需要向外提供接口以及動態庫就可以，不必將源碼開源。隨着安卓系統的逐步發展，這種方式在安卓系統上以及成為主流。（部分商用Linux系統項目也將這部分內容借鑒過來了）。
對於用戶程序，安卓系統設計了一條自己的框架，通過使用這套框架，應用程序開發人員就可以不用關注於底層特別復雜的邏輯設計，只要關注於自己應用業務就可以了。
至此就形成了安卓系統的整個設計生態。對於Android 的Audio軟件架構如下：
（1）由廠商自定義的Audio HAL或者是安卓自帶的tinyalsa程序與Linux kernel 驅動程序構建成了安卓系統與硬件交互的最底層軟件程序
（2）AudioPolicy與AndroidFlinger為核心構建了Android audio framework層，直接與最底層程序進行交互。
主要職責為：
向HAL層寫入音頻數據進行音頻播放。從HAL層采集音頻數據進行音頻數據傳輸或者保存。（audioFlinger）
根據應用場景以及具體配置，對音頻通路的控制，即在什么場景之下，聲音應該從哪個設備上發聲（audioPolicy通過控制audioFlinger來進行實現）
（3）audioTrack以及audioRecord為Android audio framework層對上層提供的接口，用戶應用程序可以通過audio Track與Audio fligner進行交互。（用戶可以通過audioSystem與audioPolicy進行交互）
（4）應用程序負責客戶業務需求的實現。
這樣由下到上就構築了andriod audio的基本框架。