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

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

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

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

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

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

1 背景知識(shí)

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

安卓系統(tǒng)是在Linux 內(nèi)核的基礎(chǔ)上構(gòu)建的,為了滿足移動(dòng)設(shè)備的需求,安卓系統(tǒng)引入了新的組件.如圖1所示,安卓系統(tǒng)主要分為4 層,從上到下分別是應(yīng)用程序?qū)?、?yīng)用程序框架層、安卓原生庫和運(yùn)行時(shí)層、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)用程序框架層主要包括了能被移動(dò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 的輸入請(qǐng)求,比如OpenGL 和SGL,分別負(fù)責(zé)3D 和2D 圖形的渲染.安卓運(yùn)行時(shí)則包括虛擬機(jī)和核心Java 庫,安卓5.0 之前使用的是Dalvik 虛擬機(jī),5.0 之后則使用更快的ART 虛擬機(jī),其作用與Java 虛擬機(jī)類似,但運(yùn)行的是.dex 格式的文件.核心庫則提供了Java 編程語言核心庫的大多數(shù)功能,比如文件訪問,網(wǎng)絡(luò)訪問等.

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

1.2 安卓音頻播放

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

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

Audio 主要包括以下幾個(gè)部分:音頻應(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 會(huì)在應(yīng)用程序框架層創(chuàng)建對(duì)應(yīng)的音頻解碼器,對(duì)播放的源文件進(jìn)行解碼,故MediaPlayer 可以播放多種格式的聲音文件,例如MP3,AAC,WAV,OGG,MIDI 等.而AudioTrack 不創(chuàng)建解碼器,故只能播放已經(jīng)解碼的PCM 流,其對(duì)應(yīng)的文件格式是WAV 格式的音頻文件.MediaPlayer 和AudioTrack 之間還是有聯(lián)系的,MediaPlayer 在應(yīng)用程序框架層仍需要?jiǎng)?chuàng)建AudioTrack,把解碼后的PCM 數(shù)據(jù)流傳遞給AudioTrack,AudioTrack 再傳遞給AudioFlinger 進(jìn)行混音,然后才傳遞給硬件播放.

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

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

圖3 PCM 文件格式

2 方案設(shè)計(jì)

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

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

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

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

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

通過對(duì)安卓系統(tǒng)源碼以及這些安卓應(yīng)用的分析發(fā)現(xiàn),雖然它們實(shí)現(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)用建立對(duì)應(yīng)關(guān)系,還需要收集播放此音頻數(shù)據(jù)的安卓應(yīng)用的相關(guān)信息,故在AudioTrack 中添加相應(yīng)的代碼將應(yīng)用的信息也保存下來.

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

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

由于有些安卓應(yīng)用會(huì)將音量調(diào)節(jié)為0,故即使音頻數(shù)據(jù)不是無聲的音頻數(shù)據(jù),還要進(jìn)行進(jìn)一步的檢測(cè).這里采用的方式是追蹤函數(shù)序列.安卓系統(tǒng)在調(diào)節(jié)音量時(shí),會(huì)產(chǎn)生特定的函數(shù)調(diào)用序列.在安卓7.0 系統(tǒng)中,當(dāng)用戶按下音量側(cè)鍵調(diào)節(jié)音量時(shí),系統(tǒng)會(huì)先調(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ù)實(shí)例化MediaSessionLegacyHelper,再調(diào)用其成員函數(shù)sendAdjustVolumeBy(),在sendAdjustVolumeBy() 函數(shù)中通過binder 機(jī)制調(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é)音量,則不會(huì)產(chǎn)生這個(gè)函數(shù)調(diào)用的序列.因此,只要追蹤是否有此函數(shù)調(diào)用序列,便可判斷應(yīng)用是否在用戶未知的情況下對(duì)音量進(jìn)行了調(diào)節(jié).

3 實(shí)驗(yàn)分析

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

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

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

3.2 實(shí)驗(yàn)結(jié)果分析

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

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

表1 音頻長(zhǎng)度與檢測(cè)正確率

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

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

表2 界定閾值和正確率

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

因?yàn)闄z測(cè)腳本以系統(tǒng)Service 的形式運(yùn)行在后臺(tái),經(jīng)測(cè)試,修改后的系統(tǒng)對(duì)用戶使用體驗(yàn)沒有影響.

4 結(jié)論與展望

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