2. 程式人生 > >ANDROID音訊系統散記之二：resample

ANDROID音訊系統散記之二：resample

阿新 • • 發佈：2019-02-07

預設的情況下，Android放音的取樣率固定為44.1khz，錄音的取樣率固定為8khz，因此底層的音訊裝置驅動只需設定好這兩個固定的取樣率。如果上層傳過來的取樣率與其不符的話，則Android Framework層會對音訊流做resample（重取樣）處理。

Resample的大致流程如下：

 
AudioResample作為最基本的類，回放和錄音resample最終都會呼叫到這個類；有興趣可以研究下resample的演算法和實現，這裡不闡述。
AudioMixer僅僅提供給回放使用的，這個類功能不僅僅是resample了，混音、音量設定都由這個類實現的。

錄音：
1、AudioFlinger::RecordThread是錄音執行緒類，每當有錄音請求時，進入AudioFlinger::openInput建立這個執行緒；
2、在建立這個執行緒的同時，呼叫readInputParameters，檢查上層傳過來的錄音取樣率是否與底層音訊介面固定的錄音取樣率一致；如果不一致，則呼叫AudioResampler::create建立一個resampler；
3、關於AudioFlinger::RecordThread::ThreadLoop，當錄音工作執行緒啟動後，會不斷迴圈該ThreadLoop方法，主要是：1）讀取底層音訊裝置獲取錄音資料mBytesRead = mInput->read(mRsmpInBuffer, mInputBytes); 2）對錄音資料做重取樣 mResampler->resample(mRsmpOutBuffer, framesOut, this);

放音：
1、AudioFlinger::MixerThread是預設的放音執行緒，派生自PlaybackThread，由AudioFlinger::openOutput負責建立；
2、MixerThread建立時，1）呼叫readOutputParameters獲取底層音訊介面固定的放音取樣率；2）建立一個AudioMixer；
3、關於AudioFlinger::MixerThread:: ThreadLoop，當放音工作執行緒啟動後，會不斷迴圈該TreadLoop方法，主要是：1）混合各track音訊資料mAudioMixer->process(); 2）將混合後的音訊資料寫到底層音訊裝置int bytesWritten = (int)mOutput->write(mMixBuffer, mixBufferSize);

Android預設的取樣率

之前有提及Android預設情況下，放音取樣率是44.1khz，錄音取樣率是8khz，分別通過AudioStreamIn::sampleRate()和AudioStreamOut::sampleRate()獲得。

一步一步跟下去，會發現是alsa_default.cpp裡面固定好的：
  1. // 放音引數配置  
  2. static alsa_handle_t _defaultsOut = {  
  3.     module      : 0,  
  4.     devices     : AudioSystem::DEVICE_OUT_ALL,  
  5.     curDev      : 0,  
  6.     curMode     : 0,  
  7.     handle      : 0,  
  8.     format      : SND_PCM_FORMAT_S16_LE, // AudioSystem::PCM_16_BIT  
  9.     channels    : 2,  
  10.     sampleRate  : DEFAULT_SAMPLE_RATE, // 放音取樣率，固定為44.1khz  
  11.     latency     : 200000, // Desired Delay in usec  
  12.     bufferSize  : DEFAULT_SAMPLE_RATE / 5, // Desired Number of samples  
  13.     modPrivate  : 0,  
  14. };  
  15. // 錄音引數配置  
  16. static alsa_handle_t _defaultsIn = {  
  17.     module      : 0,  
  18.     devices     : AudioSystem::DEVICE_IN_ALL,  
  19.     curDev      : 0,  
  20.     curMode     : 0,  
  21.     handle      : 0,  
  22.     format      : SND_PCM_FORMAT_S16_LE, // AudioSystem::PCM_16_BIT  
  23.     channels    : 1,  
  24.     sampleRate  : AudioRecord::DEFAULT_SAMPLE_RATE, // 錄音取樣率，固定為8khz  
  25.     latency     : 250000, // Desired Delay in usec  
  26.     bufferSize  : 2048, // Desired Number of samples  
  27.     modPrivate  : 0,  
  28. };  

網上有談到Android這種音訊resample方式導致音質變差，我想修改起來應該也不是很難，以後找機會實踐一下。思路：先嚐試用上層傳過來的錄音取樣率來設定底層音訊裝置，如果設定成功則不需要resample，不成功才使用預設的取樣率。放音暫不能這樣改，因為放音可能要混合多個track的資料，而各個track的取樣率不一定是一樣的。

ALSA中resample處理？？

這章節我是用問號的，因為在這裡我的確困惑了，先細細道來。

一般來說，resample的流程是這樣：

  1. +---------------------+               +-------------------------------+  
  2. |   app sample rate   |               | Android Framework sample rate |  
  3. |      16khz          | <--resample-- |            8khz               | <--ALSA interface  
  4. +---------------------+               +-------------------------------+  

那麼ALSA interface用8khz的取樣率進行錄音就好。


但事實上我發現底層音訊裝置用其他的取樣率也是可以的。比如說44.1khz，我測量到I2S的ADCLRC是44.1khz並且CODEC的暫存器也是設定為44.1khz錄音取樣率，就這樣Android應用錄出來的聲音也是正常的。

可明明在alsa_default.cpp中設定的取樣率是8khz的，而且設定成功：

  1. err = snd_pcm_hw_params_set_rate_near(handle->handle, hardwareParams,  
  2.             &requestedRate, 0);  

返回來的requestedRate是8000，這是Android Framework固定的錄音取樣率。

那麼到底在哪裡進行了44.1khz->8khz的resample處理？唯一是在alsa-lib或alsa-driver裡面了，到目前為止我還未找到相關程式碼。

--------------------------------------------------------------------------------------------------------------------

2011/10/21

近期瑣事頗多，找房子租房子搬家一團糟，昨天終於全部搞定了。

回到正題，有關alsa的resample處理，應該是在alsa-lib中實現的。摘錄別人的分析，如下：

  1. snd_pcm_mmap_write_areas()函式迴圈寫入資料，直到資料為空，首先將找到對映記憶體pcm->running_areas的地址，然後呼叫snd_pcm_areas_copy()進行資料轉換，如sample rate、channels等（如果源資料和硬體支援格式一致，就簡單地通過memcpy拷貝資料），轉換成硬體支援格式對應的資料後，呼叫snd_pcm_mmap_commit()將轉換後的資料寫入對映記憶體。寫入由snd_pcm_dmix_mmap_commit()完成，在對資料進行混音(do_mix_areas)同時，寫入對映記憶體。  
我不能保證以上分析是否完全正確（事實上我跟蹤了一下，是有些出入）。由於alsa-lib太過臃腫複雜，我也懶得去細細分析，以後如果有空去研究的話，會對這裡的說法作一些更正。

拋棄alsa-lib，其實我們還是有其他選擇的，還記得ANDROID2.3音訊系統HAL提到的mini alsa-lib（android2.3.1-gingerbread/device/samsung/crespo/libaudio）嗎？我們可以從這裡分析，由於篇幅可能比較長，就獨立成章吧，待整理。。。

這篇是承接上一篇提到的底層resample處理，以Samsung的mini alsa-lib為例說明。

mini alsa-lib

這個mini alsa-lib位於android2.3.1-gingerbread/device/samsung/crespo/libaudio中。如之前所說alsa-lib實現了太多plugin的功能，顯得複雜臃腫。因此我建議如果想了解alsa在上層呼叫過程，最好從這個mini alsa-lib入手，就兩個原始檔：alsa_pcm.c和alsa_mixer.c，前者是pcm回放錄音介面，後者是mixer controls的控制介面。

alsa-lib其實也是通過操作/dev目錄的裝置節點來呼叫核心空間的音訊驅動介面，這點跟平常的字元裝置的呼叫方法一樣的。如open：

  1. struct pcm *pcm_open(unsigned flags)  
  2. {  
  3.     const char *dname;  
  4.     struct pcm *pcm;  
  5.     struct snd_pcm_info info;  
  6.     struct snd_pcm_hw_params params;  
  7.     struct snd_pcm_sw_params sparams;  
  8.     unsigned period_sz;  
  9.     unsigned period_cnt;  
  10.     LOGV("pcm_open(0x%08x)",flags);  
  11.     pcm = calloc(1, sizeof(struct pcm));  
  12.     if (!pcm)  
  13.         return &bad_pcm;  
  14.     if (flags & PCM_IN) {  
  15.         dname = "/dev/snd/pcmC0D0c"; //capture裝置節點  
  16.     } else {  
  17.         dname = "/dev/snd/pcmC0D0p"; //playback裝置節點  
  18.     }  
  19.     ...  
  20.     pcm->flags = flags;  
  21.     pcm->fd = open(dname, O_RDWR);  
  22.     if (pcm->fd < 0) {  
  23.         oops(pcm, errno, "cannot open device '%s'");  
  24.         return pcm;  
  25.     }  
  26.     if (ioctl(pcm->fd, SNDRV_PCM_IOCTL_INFO, &info)) {  
  27.         oops(pcm, errno, "cannot get info - %s");  
  28.         goto fail;  
  29.     }  
  30.     ...  
  31. }  

這裡不多考究這些介面實現。alsa_pcm.c中有個函式挺有趣的：
  1. static void param_set_mask(struct snd_pcm_hw_params *p, int n, unsigned bit)  
  2. {  
  3.     if (bit >= SNDRV_MASK_MAX)  
  4.         return;  
  5.     if (param_is_mask(n)) {  
  6.         struct snd_mask *m = param_to_mask(p, n);  
  7.         m->bits[0] = 0;  
  8.         m->bits[1] = 0;  
  9.         m->bits[bit >> 5] |= (1 << (bit & 31));  
  10.     }  
  11. }  

其中SNDRV_MASK_MAX和snd_mask的定義分別如下：

  1. #define SNDRV_MASK_MAX 256  
  2. struct snd_mask {  
  3.  __u32 bits[(SNDRV_MASK_MAX+31)/32];  
  4. };  
結合SNDRV_MASK_MAX和snd_mask來理解：可以mask的位數高達256，但是我們計算機字長是32位，因此用8個32位的陣列來構成一個256位的掩碼，param_set_mask函式就是這個掩碼進行設定。

其中m->bits[bit >> 5] |= (1 << (bit & 31));為核心語句，bit>>5其實就是bit除以32（即陣列元素長度）取得陣列下標，1 << (bit & 31)是掩碼位在陣列元素中的偏移量。如bit=255時，則陣列下標是7,即陣列bits最後一個元素，偏移量是1<<31，這時整個bits資料就是這樣：bits[7:0] = 0x80000000:0x00000000:0x00000000:0x00000000:0x00000000:0x00000000:0x00000000:0x00000000，這個256位的掩碼的最高位就置1了。當然在實際應用中並不會用到那麼高位的掩碼，這裡應該是為了方便以後擴充套件使用的，因此也只需要m->bits[0] = 0; m->bits[1] = 0，看來僅僅最多用到64位掩碼。

ADCLRC約束條件

在pcm_open中，有

  1. param_set_int(¶ms, SNDRV_PCM_HW_PARAM_RATE, 44100);  
  2. if (ioctl(pcm->fd, SNDRV_PCM_IOCTL_HW_PARAMS, ¶ms)) {  
  3.     oops(pcm, errno, "cannot set hw params");  
  4.     goto fail;  
  5. }  

可見，無論放音還是錄音，都是設定44.1khz的取樣率的。在我們的底層I2S驅動中，放音錄音也是固定一個取樣率44.1khz。為什麼這樣做？放音就罷了，Android由於需要混合各個track的資料，故把放音取樣率固定在44.1khz，而錄音為什麼也固定用44.1khz？注：這裡的取樣率直接對應硬體訊號ADCLRC/DACLRC頻率。

首先需要了解一下I2S協議方面的知識。放音取樣率DACLRC，錄音取樣率ADCLRC都是通過同一個主時鐘MCLK分頻出來的。在底層音訊驅動中，一般有如下的結構體：

  1. struct _coeff_div {  
  2.     u32 mclk;  
  3.     u32 rate;  
  4.     u16 fs;  
  5.     u8 sr;  
  6.     u8 bclk_div;  
  7. };  
  8. /* codec hifi mclk clock divider coefficients */  
  9. static const struct _coeff_div coeff_div[] = {  
  10.     /* 8k */  
  11.     {12288000, 8000, 1536, 0x4, 0x0},  
  12.     /* 11.025k */  
  13.     {11289600, 11025, 1024, 0x8, 0x0},  
  14.     /* 16k */  
  15.     {12288000, 16000, 768, 0x5, 0x0},  
  16.     /* 22.05k */  
  17.     {11289600, 22050, 512, 0x9, 0x0},  
  18.     /* 32k */  
  19.     {12288000, 32000, 384, 0x7, 0x0},  
  20.     /* 44.1k */  
  21.     {11289600, 44100, 256, 0x6, 0x07},  
  22.     /* 48k */  
  23.     {12288000, 48000, 256, 0x0, 0x07},  
  24.     /* 96k */  
  25.     {12288000, 96000, 128, 0x1, 0x04},  
  26. };  

其中MCLK有兩個可配頻率，分別是12288000和11289600，前者用於8k、16k、32k、48k、96khz的分頻，後者用於11.025k、22.05k、44.1khz的分頻。具體算式是rate=mclk/fs，如44100=11289600/256。

看出問題了沒有？如果錄音取樣率設定為8khz，則MCLK必須轉變為12288000，此時DACLRC就會被改變（放音聲音會變得尖銳），不利於同時放音錄音。因此錄音取樣率是受其約束的，其實也不是一定是44.1khz，是11.025khz的倍數即可，能保證是可以從同一個MCLK分頻。

DownSampler

在android2.3.1-gingerbread/device/samsung/crespo/libaudio中，除了mini alsa-lib外，就是Samsung為Android寫的AudioHAL了，如AudioHardware.cpp，這相當於alsa_sound中的檔案。這個HAL有很大的通用性，移植到無通話功能的MID上都可以正常工作的，當然也保留Samsung的一些專用性，主要是通話語音通道處理。這裡不詳述這個音訊HAL檔案，如果對AudioFlinger和alsa_sound比較熟悉的話，會很快上手掌握。

如上個章節所說，底層錄音取樣率ADCLRC固定是44.1khz，那麼上層如果想要其他的取樣率如8khz，怎麼辦？resample無疑。由於這裡支援的錄音取樣率有：8000, 11025, 16000, 22050, 44100，都低於或等於44.1khz，則只需要downsample（同理從低取樣率轉換到高取樣率叫upsample）。如下是簡單的分析：

  1. status_t AudioHardware::AudioStreamInALSA::set(  
  2.     AudioHardware* hw, uint32_t devices, int *pFormat,  
  3.     uint32_t *pChannels, uint32_t *pRate, AudioSystem::audio_in_acoustics acoustics)  
  4. {  
  5.     if (pFormat == 0 || *pFormat != AUDIO_HW_IN_FORMAT) {  
  6.         *pFormat = AUDIO_HW_IN_FORMAT; //AudioSystem::PCM_16_BIT  
  7.         return BAD_VALUE;  
  8.     }  
  9.     if (pRate == 0) {  
  10.         return BAD_VALUE;  
  11.     }  
  12.     //getInputSampleRate：取得與引數sampleRate最接近的且被支援的取樣率  
  13.     //支援的取樣率有：8000, 11025, 16000, 22050, 44100  
  14.     //事實上，這裡傳入來的sampleRate必須是被支援的，否則返回BAD_VALUE  
  15.     uint32_t rate = AudioHardware::getInputSampleRate(*pRate);  
  16.     if (rate != *pRate) {  
  17.         *pRate = rate;  
  18.         return BAD_VALUE;  
  19.     }  
  20.     if (pChannels == 0 || (*pChannels != AudioSystem::CHANNEL_IN_MONO &&  
  21.         *pChannels != AudioSystem::CHANNEL_IN_STEREO)) {  
  22.         *pChannels = AUDIO_HW_IN_CHANNELS; //AudioSystem::CHANNEL_IN_MONO  
  23.         return BAD_VALUE;  
  24.     }  
  25.     mHardware = hw;  
  26.     LOGV("AudioStreamInALSA::set(%d, %d, %u)", *pFormat, *pChannels, *pRate);  
  27.     //getBufferSize：根據取樣率和聲道數確定buffer的大小  
  28.     //popCount：計算引數u有多少個非0位，其實現很有趣，大家可以研究下它的演算法  
  29.     mBufferSize = getBufferSize(*pRate, AudioSystem::popCount(*pChannels));  
  30.     mDevices = devices;  
  31.     mChannels = *pChannels;  
  32.     mChannelCount = AudioSystem::popCount(mChannels);  
  33.     mSampleRate = rate;  
  34.     //檢查mSampleRate是否與AUDIO_HW_OUT_SAMPLERATE（44.1khz）一致，否則需要down resample  
  35.     if (mSampleRate != AUDIO_HW_OUT_SAMPLERATE) {  
  36.         mDownSampler = new AudioHardware::DownSampler(mSampleRate,  
  37.                                                   mChannelCount,  
  38.                                                   AUDIO_HW_IN_PERIOD_SZ,  
  39.                                                   this);  
  40.         status_t status = mDownSampler->initCheck();  
  41.         if (status != NO_ERROR) {  
  42.             delete mDownSampler;  
  43.             LOGW("AudioStreamInALSA::set() downsampler init failed: %d", status);  
  44.             return status;  
  45.         }  
  46.         mPcmIn = new int16_t[AUDIO_HW_IN_PERIOD_SZ * mChannelCount];  
  47.     }  
  48.     return NO_ERROR;  
  49. }  

以上是set方法，檢查引數format、samplerate和channelcount的合法性，檢查samplerate是否與ADCLRC一致，如果不一致，則建立一個DownSampler。

我們再看看read方法程式碼片段：

  1. ssize_t AudioHardware::AudioStreamInALSA::read(void* buffer, ssize_t bytes)  
  2. {  
  3.         ......  
  4.         //檢查是否建立了DownSampler  
  5.         if (mDownSampler != NULL) {  
  6.             size_t frames = bytes / frameSize();  
  7.             size_t framesIn = 0;  
  8.             mReadStatus = 0;  
  9.             do {  
  10.                 size_t outframes = frames - framesIn;  
  11.                 //呼叫DownSampler的resample方法，該方法從音訊介面讀取pcm資料，然後對這些資料resample  
  12.                 mDownSampler->resample(  
  13.                         (int16_t *)buffer + (framesIn * mChannelCount),  
  14.                         &outframes);  
  15.                 framesIn += outframes;  
  16.             } while ((framesIn < frames) && mReadStatus == 0);  
  17.             ret = mReadStatus;  
  18.             bytes = framesIn * frameSize();  
  19.         } else {  
  20.             TRACE_DRIVER_IN(DRV_PCM_READ)  
  21.             //並未建立DownSampler，直接讀取pcm資料送到緩衝區  
  22.             ret = pcm_read(mPcm, buffer, bytes);  
  23.             TRACE_DRIVER_OUT  
  24.         }  
  25.         ......  
  26. }  
可知，當上層需要的samplerate與44.1khz不符時，會轉入DownSampler::resample處理：

1、呼叫AudioHardware::AudioStreamInALSA::getNextBuffer方法，獲取音訊pcm資料，存放到buffer，並計算下一次buffer的地址；

2、將buffer中的資料分解成各個聲道的資料並儲存到mInLeft和mInRight；

3、由於原始的音訊pcm資料取樣率是44.1khz的，呼叫resample_2_1將資料轉為22.05khz取樣率；

4、1) 如果上層需要的samplerate=11.025khz，呼叫resample_2_1將資料取樣率從22.05khz轉換到11.025khz；

      2) 如果上層需要的samplerate=8khz，呼叫resample_441_320將資料取樣率從11.025khz轉換到8khz；

5、如果上層需要的samplerate=16khz，呼叫resample_441_320將資料取樣率從22.05khz轉換到16khz。

可見真正的resample處理是在resample_2_1()和resample_441_320()這兩個函式中。前者是對倍數2的取樣率進行resample的，如44100->22050, 22050->11025, 16000->8000等；後者是對比率為441/320的取樣率進行resample的，如44100->32000, 22050->16000, 11025->8000等。



相關推薦

ANDROID音訊系統散記之二：resample

預設的情況下，Android放音的取樣率固定為44.1khz，錄音的取樣率固定為8khz，因此底層的音訊裝置驅動只需設定好這兩個固定的取樣率。如果上層傳過來的取樣率與其不符的話，則Android Framework層會對音訊流做resample（重取樣）處理。 Resamp

ANDROID音訊系統散記之二：resample-1

Android上的resample處理 預設的情況下，Android放音的取樣率固定為44.1khz，錄音的取樣率固定為8khz，因此底層的音訊裝置驅動只需設定好這兩個固定的取樣率。如果上層傳過來的取樣率與其不符的話，則Android Framework層會對音訊流做resample（重取樣）處理。 Re

ANDROID音訊系統散記之三：resample-2

這篇是承接上一篇提到的底層resample處理，以Samsung的tiny alsa-lib為例說明。 tiny alsa-lib 這個tiny alsa-lib位於android2.3.1-gingerbread/device/samsung/crespo/libau

linux學習之二：Linux磁盤與文件管理系統

roo 針對 mkf 維護 def 都是 linu mke2fs remount 上次寫了Linux檔案與操作，這次繼續寫Linux磁盤與文件管理系統。 首先，我們要先來認識一下EXT2文件系統，這是Linux最傳統的磁盤系統。 1.EXT2文件系統 在說文件系統以前還是要

CAN匯流排學習記錄之二：系統結構與幀結構

CAN匯流排系統結構 CAN 控制器  接收控制單元中微處理器發出的資料，處理資料並傳給 CAN 收發器 CAN 收發器 將資料傳到匯流排 or 從匯流排接收資料給 CAN 控制器 CAN 資料傳遞終端 避免資料傳輸終了反射回來 CAN 資料匯流排 傳輸資料的資料線，兩根：CAN-hig

Android列表用法之二：實戰ListView高階用法

在我們的專案中，並不是所有列表都是簡單的使用。類似於新聞列表、QQ聊天列表等，具有圖文並排的列表，每個item都有它不同的佈局型別，都有其不同的實現方式。這類複雜的列表表現形式，在各類知名應用當中，不可或缺的存在著。今天我們就來看看，使用ListView能不能實現此類複雜佈局。 今天的例

Android編譯系統分析之幾個關鍵點（二）

已開通新的部落格，後續文字都會發到新部落格 http://www.0xfree.top Android 編譯系統解析系列文件 解析lunch的執行過程以及make執行過程中include檔案的順序 Android編譯系統分析之lunch分析 Android

Spring Boot 系統之二：Spring Boot 修改預設埠號和context path

上一篇檔案我們通過一個例項進行了spring boot 入門，我們發現tomcat埠號和上下文（context path）都是預設的，如果我們對於這兩個值有特殊需要的話，需要自己制定的時候怎麼辦呢？ 一、解決辦法 1、編寫application.properties，用來重寫Spring B

Android APIDemos 研讀之二：android.graphics.Camera 源文地址 : http://blog.csdn.net/sharetop/article/details/5277655

        Android APIDemos 研讀之二：android.graphics.Camera      源文地址 : http:/

Python貓薦書系統之二：《Python最佳實踐指南》

在介紹今天的書目之前，我想先跟大家介紹一下這個薦書系列。本系列打算聚焦Python領域的書籍，初期選書的標準主要有兩條：一是要有中文版，二是要有免費開源的線上資源，原因很簡單，技術書籍由於其特殊性，線上閱讀的體驗是最佳的，不管是排版、獲取原始碼、摘錄筆記還是分享交流，

擁抱 Android Studio 之二：Android Studio 與 Gradle 深入

關於學習方式 曾經跟朋友討論過我們所接受過的大學工科教育，都是一上來先學基礎理論，最後再來一個金工實習。一開始不知道為什麼而學，學不進去，荒廢了基礎，等到金工實習的時候，又發現基礎不牢，後悔不已。 考慮到傳統教育方式的不足之處，筆者在組織本系列文章的時候是先講入門例項，進而

物聯網安全研究之二：IoT系統攻擊面定義分析

在前文中，我們瞭解了IoT技術的基本架構，本文我將來說說IoT安全，在此過程中，我們會嘗試定義一種新方法來理解IoT安全，同時也會建立一個結構化流程來方便認知IoT相關的攻擊研究和滲透測試。 依據前文我們定義的IoT體系結構，現在我們可以非常清晰地分離出物聯網系統的各種

【U3D系統架構教程——開發篇】之二：Log日誌系統2.0

這篇文章由唐三胖ヾ(•ω•`)o網路整理總結，將告訴你如何開發一個高效率的日誌系統。 通過這篇文章，你可以知道 1）C#特性Condtional 2）開發2.0版的日誌系統 開篇介紹 通過上一章節的介紹，我們已經實現了重寫的日誌

Appium+Python 自動化測試之二：啟動APP（Android篇）

android版本 inf 環境 哪些 aapt code div port ons 前一篇寫了環境安裝，這篇記錄是記錄如何啟動APP以及啟動APP之前要做哪些事。 Appium 啟動APP至少需要5個參數，分別是‘platformName‘，‘platformVersio

android學習軌跡之二：Android許可權標籤uses-permission的書寫位置

場景 想獲取手機內所有聯絡人。並且AndroidManifest.xml中也添加了 <uses-permission android:name="android.permission.READ_CONTACTS" />  許可權程式碼。  可是一樣出現 Permission denail. .

UNIX v6原始碼分析除錯之二：單步除錯系統程式碼 main函式之 kinit1

    環境搭建完成，該學習Main.c的main函數了。先貼上main函式的實現。int main(void) { kinit1(end, P2V(4*1024*1024)); // phys page allocator kvmalloc(); // k

Android 音訊系統：從 AudioTrack 到 AudioFlinger

1. Android 音訊框架概述 Audio 是整個 Android 平臺非常重要的一個組成部分，負責音訊資料的採集和輸出、音訊流的控制、音訊裝置的管理、音量調節等，主要包括如下部分： Audio Application Framework：音訊

Android知識體系梳理筆記二：AIDL進階之Binder機制

為什麼學習Binder機制 Binder是Android系統中最重要的特性之一；正如其名“粘合劑”所喻，它是系統間各個元件的橋樑，Android系統的開放式設計也很大程度上得益於這種及其方便的跨程序通訊機制。 Binder是一種程序間通訊機制，能幫助我們進行

Android音訊系統之音訊框架

Android的音訊系統在很長一段時間內都是外界詬病的焦點。的確，早期的android系統在音訊處理上相比於iOS有一定的差距，這也是很多專業的音樂播放軟體開發商沒有推出Android平臺產品的一個重要原因。但這並不代表它的音訊框架一無是處，相反，基於Linux系統的

Android O 之二：HIDL相關介紹

在上一篇部落格裡，大致介紹了下Android O 中treble計劃的一些背景與相關基本架構，這一篇中跟大家一起來探討下HIDL相關的內容。Android HAL型別 在此之前的ANDROID版本當中Android HAL沒有什麼特殊的特殊的，也麼有什麼分類，但是從andro