安卓應(yīng)用中無聲音頻的收集與檢測①

顏宏冰,熊 焰,黃文超,孟昭逸

(中國科學(xué)技術(shù)大學(xué) 計算機科學(xué)與技術(shù)學(xué)院,合肥 230027)

目前安卓手機的市場份額越來越大,2017年已經(jīng)到達(dá)了85.9%.如此大的市場份額也意味著巨大的利益,很多廠商都進(jìn)入了這個市場,這使得安卓應(yīng)用的數(shù)量和安卓手機的功能迅速增長.現(xiàn)在安卓手機的計算能力,存儲能力,通信能力已經(jīng)達(dá)到一個相當(dāng)高的地步,甚至已經(jīng)能和個人PC 相媲美.但安卓手機性能的上升是以電池電量的加速消耗為代價的,而電池電量的增長速度跟不上手機性能的提升,這導(dǎo)致了現(xiàn)在手機的待機時間越來越短.

為了解決這個問題,許多研究都嘗試去優(yōu)化安卓的電量消耗的情況.方葵[1]考慮到手機開啟數(shù)據(jù)流量時耗電比平時高,設(shè)計了關(guān)閉屏幕時關(guān)閉數(shù)據(jù)流量的軟件；Martins 等[2]對安卓系統(tǒng)進(jìn)行了修改,降低耗電事件的發(fā)生頻率；Hoffmann 等[3]則是將應(yīng)用中的一些靜態(tài)配置參數(shù)改成可以調(diào)節(jié)的動態(tài)參數(shù),達(dá)到節(jié)省電量的目的.

這些方案在一定程度上優(yōu)化了安卓的耗電問題,但安卓系統(tǒng)中仍有很多的耗電問題亟待解決.目前一些安卓應(yīng)用為了在后臺長期?；?會在后臺占用系統(tǒng)資源.其中一種典型情況就是在后臺持有Audiomix 鎖并播放一些無聲數(shù)據(jù).這種行為會加快手機的電量消耗,同時由于占用了系統(tǒng)資源,還可能導(dǎo)致手機運行速度變慢,所以這種情況下應(yīng)當(dāng)終止應(yīng)用的后臺占用.但在安卓系統(tǒng)中,音頻數(shù)據(jù)的收集并不容易,雖然安卓提供了音頻播放的函數(shù),但并沒有提供音頻收集相關(guān)的函數(shù).同時很多安卓應(yīng)用并不使用安卓系統(tǒng)提供的音

頻播放函數(shù),而是自己實現(xiàn)了音頻播放的函數(shù).針對這個問題,本文提出了一種收集并檢測安卓中的音頻數(shù)據(jù)的方法.

1 背景知識

1.1 安卓系統(tǒng)架構(gòu)

安卓系統(tǒng)是在Linux 內(nèi)核的基礎(chǔ)上構(gòu)建的,為了滿足移動設(shè)備的需求,安卓系統(tǒng)引入了新的組件.如圖1所示,安卓系統(tǒng)主要分為4 層,從上到下分別是應(yīng)用程序?qū)印?yīng)用程序框架層、安卓原生庫和運行時層、Linux 內(nèi)核層[4,5].

圖1 安卓系統(tǒng)架構(gòu)

最上層的應(yīng)用層由直接和用戶交互的應(yīng)用組成,包括系統(tǒng)應(yīng)用比如日歷、瀏覽器、聯(lián)系人管理程序和普通應(yīng)用比如微博,微信,這些應(yīng)用都是Java 語言開發(fā)的.

下一層的應(yīng)用程序框架層主要包括了能被移動應(yīng)用重用和共享的一系列系統(tǒng)服務(wù),包括View System(構(gòu)建安卓應(yīng)用的UI,包括列表,網(wǎng)格,文本框等等),Resource Manager(訪問非代碼資源,如本地化的字符串,布局文件)等.

第三層中的安卓原生庫基本是由C/C++編寫的,負(fù)責(zé)特定的硬件設(shè)備結(jié)合或者響應(yīng)UI 的輸入請求,比如OpenGL 和SGL,分別負(fù)責(zé)3D 和2D 圖形的渲染.安卓運行時則包括虛擬機和核心Java 庫,安卓5.0 之前使用的是Dalvik 虛擬機,5.0 之后則使用更快的ART 虛擬機,其作用與Java 虛擬機類似,但運行的是.dex 格式的文件.核心庫則提供了Java 編程語言核心庫的大多數(shù)功能,比如文件訪問,網(wǎng)絡(luò)訪問等.

最下層的Linux 內(nèi)核層則是整個安卓系統(tǒng)的基礎(chǔ),安卓系統(tǒng)的功能最終都是通過Linux 內(nèi)核完成.它提供了硬件設(shè)備的抽象接口,以供上層使用.

1.2 安卓音頻播放

Audio 是整個安卓系統(tǒng)非常重要的一個組成部分,負(fù)責(zé)音頻數(shù)據(jù)的采集和輸出、音頻流的控制、音頻設(shè)備的管理、音量調(diào)節(jié)等,整體結(jié)構(gòu)如圖2所示.

圖2 安卓音頻系統(tǒng)結(jié)構(gòu)

Audio 主要包括以下幾個部分:音頻應(yīng)用框架(Audio Application Framework),音頻本地框架(Audio Native Framework),音頻服務(wù)(Audio Service),音頻硬件抽象層(Audio HAL).其中,音頻應(yīng)用框架和音頻本地框架負(fù)責(zé)音頻數(shù)據(jù)的播放和采集,以及音頻事務(wù)的綜合管理.音頻服務(wù)則由AudioPolicyService 和AudioFlinger 組成,前者負(fù)責(zé)制定音頻策略,比如音頻設(shè)備切換的策略選擇,音量調(diào)節(jié)等.后者則負(fù)責(zé)執(zhí)行策略,比如輸入輸出流設(shè)備的管理及音頻流數(shù)據(jù)的處理傳輸.硬件抽象層則負(fù)責(zé)與音頻硬件設(shè)備交互,由AudioFlinger 直接調(diào)用.

安卓中音頻播放主要有兩種方式:第一種是使用MediaPlayer 播放,第二種是使用AudioTrack 播放.這兩種播放方式最大的區(qū)別是MediaPlayer 會在應(yīng)用程序框架層創(chuàng)建對應(yīng)的音頻解碼器,對播放的源文件進(jìn)行解碼,故MediaPlayer 可以播放多種格式的聲音文件,例如MP3,AAC,WAV,OGG,MIDI 等.而AudioTrack 不創(chuàng)建解碼器,故只能播放已經(jīng)解碼的PCM 流,其對應(yīng)的文件格式是WAV 格式的音頻文件.MediaPlayer 和AudioTrack 之間還是有聯(lián)系的,MediaPlayer 在應(yīng)用程序框架層仍需要創(chuàng)建AudioTrack,把解碼后的PCM 數(shù)據(jù)流傳遞給AudioTrack,AudioTrack 再傳遞給AudioFlinger 進(jìn)行混音,然后才傳遞給硬件播放.

脈沖編碼調(diào)制(PCM)是一種編碼方式,一般用于對連續(xù)變化的模擬信號進(jìn)行抽樣、量化和編碼產(chǎn)生數(shù)字信號.安卓中的音頻一般都是PCM 編碼的.

PCM 文件的格式如圖3,根據(jù)采樣位數(shù)分為8 位,16 位,32 位,根據(jù)聲道數(shù)分為單聲道和雙聲道.文件中每個樣本值包含在一個數(shù)中,根據(jù)位數(shù)的不同,這個數(shù)占1、2 或者4 個字節(jié),并且其表示的范圍也有區(qū)別,比如8 位的PCM 文件每個樣本值的范圍是0 到255.位數(shù)越多,表示聲音的音質(zhì)越高.

圖3 PCM 文件格式

2 方案設(shè)計

為了達(dá)到收集并檢測安卓系統(tǒng)中無聲音頻的目的,有以下兩個挑戰(zhàn):第一,安卓系統(tǒng)中沒有現(xiàn)成的收集音頻數(shù)據(jù)的接口或函數(shù),并且安卓應(yīng)用可能不使用安卓應(yīng)用程序框架提供的音頻函數(shù),需要找到一個合適的位置插入代碼才能收集數(shù)據(jù)；第二,對于無聲音頻,沒有一個確定的識別標(biāo)準(zhǔn),需要根據(jù)實驗結(jié)果制定一個標(biāo)準(zhǔn).針對以上問題,本文設(shè)計了一個收集和檢測無聲音頻的系統(tǒng),如圖4所示.

圖中的安卓系統(tǒng)經(jīng)過修改后,可以收集到安卓應(yīng)用播放的PCM 音頻數(shù)據(jù),這些數(shù)據(jù)再被送到一個系統(tǒng)應(yīng)用中進(jìn)行檢測,這個系統(tǒng)應(yīng)用中包含了自定義的檢測腳本,用來判斷音頻數(shù)據(jù)是否是無聲的.因為需要實時檢測音頻數(shù)據(jù),所以將檢測腳本做成系統(tǒng)應(yīng)用集成在安卓系統(tǒng)中.經(jīng)過系統(tǒng)應(yīng)用檢測后,結(jié)果將返回給用戶.接下來就音頻數(shù)據(jù)收集和音頻數(shù)據(jù)檢測做詳細(xì)介紹.

2.1 音頻數(shù)據(jù)采集

安卓中沒有可以直接收集音頻的函數(shù),為了能收集安卓應(yīng)用播放的音頻,需要對安卓的源碼進(jìn)行相應(yīng)修改.但實驗中發(fā)現(xiàn),如果在Java 層添加代碼來收集音頻數(shù)據(jù),約有40%的安卓應(yīng)用是收集不到音頻數(shù)據(jù)的.通過進(jìn)一步分析,這些應(yīng)用沒有使用安卓系統(tǒng)中Java 層的MediaPlayer 來播放音頻,而是在自定義的動態(tài)鏈接庫中實現(xiàn)了相關(guān)的函數(shù),進(jìn)一步調(diào)用底層的Native 函數(shù)播放音頻.

圖4 音頻收集和檢測系統(tǒng)框架

通過對安卓系統(tǒng)源碼以及這些安卓應(yīng)用的分析發(fā)現(xiàn),雖然它們實現(xiàn)的播放音頻的函數(shù)細(xì)節(jié)上有區(qū)別,但是最終都是由Audiotrack 調(diào)用write 函數(shù)或者processAudioBuffer 函數(shù),向共享內(nèi)存中寫入需要播放的音頻數(shù)據(jù),再傳遞到AudioFlinger 進(jìn)行播放.所以只需要在write 函數(shù)和processAudioBuffer 函數(shù)中插入截取音頻數(shù)據(jù)的代碼,就可以采集到相應(yīng)的音頻數(shù)據(jù).此外,為了將音頻數(shù)據(jù)與應(yīng)用建立對應(yīng)關(guān)系,還需要收集播放此音頻數(shù)據(jù)的安卓應(yīng)用的相關(guān)信息,故在AudioTrack 中添加相應(yīng)的代碼將應(yīng)用的信息也保存下來.

2.2 音頻數(shù)據(jù)識別

收集到安卓應(yīng)用播放的音頻數(shù)據(jù)后,需要對音頻數(shù)據(jù)進(jìn)行識別,判斷其是否是無聲的音頻數(shù)據(jù).但PCM 音頻數(shù)據(jù)是否無聲這個問題沒有具體的判別標(biāo)準(zhǔn),因為PCM 音頻數(shù)據(jù)描述的是時域振動,本文考慮的情況是如果PCM 音頻數(shù)據(jù)波動的數(shù)據(jù)點占總數(shù)的比例小于某個閾值時,就認(rèn)為PCM 數(shù)據(jù)是無聲的音頻數(shù)據(jù).根據(jù)此規(guī)則,可以對PCM 文件進(jìn)行解析,并判斷文件中包含的是否是無聲的音頻數(shù)據(jù).

由于有些安卓應(yīng)用會將音量調(diào)節(jié)為0,故即使音頻數(shù)據(jù)不是無聲的音頻數(shù)據(jù),還要進(jìn)行進(jìn)一步的檢測.這里采用的方式是追蹤函數(shù)序列.安卓系統(tǒng)在調(diào)節(jié)音量時,會產(chǎn)生特定的函數(shù)調(diào)用序列.在安卓7.0 系統(tǒng)中,當(dāng)用戶按下音量側(cè)鍵調(diào)節(jié)音量時,系統(tǒng)會先調(diào)用frameworks/base/core/java/com/android/internal/policy/P honeWindow.java 中 的onKeyDown() 函 數(shù),在onKeyDown()函數(shù)中,又調(diào)用了./base/media/java/android/media/session/MediaSessionLegacyHelper.java 中的MediaSessionLegacyHelper.getHelper(),通過getHelper 靜態(tài)函數(shù)實例化MediaSessionLegacyHelper,再調(diào)用其成員函數(shù)sendAdjustVolumeBy(),在sendAdjustVolumeBy() 函數(shù)中通過binder 機制調(diào)用./base/services/core/java/com/android/server/media/Me diaSessionService.java 中MediaSessionService 的成員函數(shù)dispatchAdjustVolume(),最后在此函數(shù)中間接調(diào)用了adjustSuggestedStreamVolume().而如果應(yīng)用直接調(diào)節(jié)音量,則不會產(chǎn)生這個函數(shù)調(diào)用的序列.因此,只要追蹤是否有此函數(shù)調(diào)用序列,便可判斷應(yīng)用是否在用戶未知的情況下對音量進(jìn)行了調(diào)節(jié).

3 實驗分析

實驗使用的安卓手機是Google Nexus 6p,安卓系統(tǒng)的版本是7.0.實驗中做為檢測樣本的安卓應(yīng)用來自于豌豆莢應(yīng)用市場.

3.1 安卓應(yīng)用選取

考慮到要收集安卓應(yīng)用中的音頻數(shù)據(jù),檢測的應(yīng)用主要是游戲和音樂這兩個分類下的,因為這兩個分類下的安卓應(yīng)用可以比較好的收集音頻數(shù)據(jù).

3.2 實驗結(jié)果分析

實驗共檢測了50 個安卓應(yīng)用.實驗中發(fā)現(xiàn),音頻文件的長度以及檢測音頻數(shù)據(jù)腳本中設(shè)置的PCM 數(shù)據(jù)波動的數(shù)據(jù)點占總數(shù)的比例閾值對于最后的實驗結(jié)果都會產(chǎn)生影響,故實驗中通過設(shè)置不同的值來尋找最合適的參數(shù)值.

表1是設(shè)置收集的音頻文件的長度不同值時的檢測結(jié)果.對于表中所列的每個音頻長度,實驗中對每個應(yīng)用都隨機截取了三次音頻數(shù)據(jù),綜合三次分析的結(jié)果,來判斷音頻數(shù)據(jù)是否是無聲的.

表1 音頻長度與檢測正確率

可以看到,當(dāng)音頻長度為5 秒時,檢測的正確率比較低.原因是音頻播放時可能會出現(xiàn)某一小段音頻恰好沒有聲音的情況,如果截取的音頻剛好是這一小段中的一部分,就可能會導(dǎo)致錯誤的判斷.這種情況下,雖然截取的音頻文件時無聲的,但實際上就整個音頻來看的話還是要判斷為不是無聲的.為了減少這種情況的發(fā)生,應(yīng)該盡可能截取比較長的音頻文件.從表中數(shù)據(jù)能得出結(jié)論:截取的音頻文件的長度越長,檢測的正確率越高.因為音頻文件越長意味著其囊括的范圍越大,這樣更能反映音頻的真實情況.

表2是設(shè)置PCM 數(shù)據(jù)波動的數(shù)據(jù)點占總數(shù)的比例閾值為不同的值時得到的結(jié)果.

表2 界定閾值和正確率

可以看到,當(dāng)閾值設(shè)置的很低,比如0.1%時,檢測的正確率也會比較低.當(dāng)閾值升高,檢測的正確率也會提升,但閾值過大時,又會出現(xiàn)正確率下降的情況.分析音頻數(shù)據(jù)發(fā)現(xiàn),閾值很低時,如果音頻數(shù)據(jù)波動的數(shù)據(jù)點集中在某一段,而數(shù)據(jù)點數(shù)目又不足以產(chǎn)生聲音,這種情況下無聲的音頻數(shù)據(jù)就可能被識別為有聲的.而當(dāng)閾值很高時,如果有聲音的音頻數(shù)據(jù)段比較短,其包含的數(shù)據(jù)點數(shù)目占總體數(shù)據(jù)點的比值達(dá)不到閾值,就會將有聲的音頻數(shù)據(jù)誤判為無聲的.

因為檢測腳本以系統(tǒng)Service 的形式運行在后臺,經(jīng)測試,修改后的系統(tǒng)對用戶使用體驗沒有影響.

4 結(jié)論與展望

本文主要關(guān)注的問題是安卓中無聲音頻的收集和檢測,因為安卓系統(tǒng)本身并未提供音頻數(shù)據(jù)的收集手段,并且對于無聲音頻也沒有確定的衡量標(biāo)準(zhǔn),故本文通過修改安卓源碼,并調(diào)節(jié)無聲數(shù)據(jù)檢測腳本中的相關(guān)參數(shù),解決了安卓中無聲數(shù)據(jù)的收集和檢測問題.在實驗中發(fā)現(xiàn),僅憑后臺播放無聲數(shù)據(jù)這一點還不能確定安卓應(yīng)用是否是惡意在后臺占用系統(tǒng)資源來實現(xiàn)后臺保活的,故接下來的研究工作是要收集更多安卓應(yīng)用運行時的相關(guān)信息,結(jié)合本文實驗的實驗結(jié)果,提高檢測的準(zhǔn)確率.