Android java層音頻相關的分析與理解（三）調用相關

Android java層音頻相關的分析與理解（三）調用相關

Android中會有多個應用需要支援音訊播放。當同一時間內有多個應用需要輸出音訊時候，到底是全部輸出？還是輸出其中一個？假如輸出其中一個，那到底輸出哪個？以什麼標準去界定？為了處理這些關係。Android在2.3的時候引入了AudioFocus機制並沿用到現在。

 

1 AudioFocus簡介

 

AudioFocus是一個沒有優先順序概念的搶佔式的機制。一般情況下，最後申請使用AudioFoucs的應用或取得當前的AudioFocus從而將前面申請的應用給停掉。但是，有一種情況是特殊的，就是通話。通話作為手機的重要功能，從響鈴到通話接受，Telephony都會申請AudioFocus，所有應用都不能從Telephony中擷取音頻焦點，但Telephony可以從任何應用中擷取到AudioFocus。

 

當前Android6.0下AudioFocus有幾種狀態，分別為：

從上面AudioFocus的狀態可以看出，其實AudioFocus的狀態是對應的。當後一個應用去GainAudioFocus時，前一個應用就相對應地LossAudioFocus。後一個應用以什麼形式去Gain，前一個應該就會受到相應Loss的通知。但是，當前一個應用收到這個Loss通知時，應用怎麼處理是應用內部的事情。因為AudioFoucs機制是一個建議性而不是強制性的機制。應用使用這種機制只是使使用者體驗更加好，而不採用這套機制，甚至不遵循這套機制，對應用與系統本身來是，是沒有什麼影響的。

再補充說明一下，當應用通過AudioFocus機制去輸出音訊時候，它可以因為其他應用通過擷取AudioFocus去暫停輸出。但是，應用也可以不通過AudioFocus去輸出音頻。此時該應用的一切音訊輸出邏輯由本身控制。不受AudioFocus機制影響。

2 AudioFocus的實現

 

AudioFocus機制其實相當於一個棧。

 

如所示，AudioFocus機制是以棧的形式實現，位於棧頂的應用能擷取到AudioFocus從而能輸出音頻。非棧頂應用會暫時失去AudioFocus直至位於其上面的全部應用關閉或主動丟失AudioFocus。

AudioFocus的實現是從AudioManager.java開始的。

一般來說，應用內部會通過調用AudioManager的requestAudioFocus()方法去擷取AudioFocus。AudioManager這一次，與以往不同，不只是作為一個類似於傳遞者的角色直接擷取AudioService的控制代碼然後將參數傳遞過去，而是先通過一系列的判斷和封裝，通過2次重載，將應用的相關訊息儲存並調用AudioSercvice中的requestAudioFocus（），進一步處理擷取AudioFocus操作。

 

所以我們來看一下AudioManager的requestAudioFocus()的主要內容：

public int requestAudioFocus (OnAudioFocusChangeListener l,            @NonNull AudioAttributes requestAttributes,            int durationHint,            int flags,            AudioPolicy ap) throws IllegalArgumentException {        ……//一系列的參數判斷        int status = AUDIOFOCUS_REQUEST_FAILED;        //將申請AudioFocus的應用的listener放進mAudioFocusIdListenerMap中registerAudioFocusListener(l);        IAudioService service = getService();        try {            //調用AudioService的requestAudioFocus()            status = service.requestAudioFocus(requestAttributes, durationHint, mICallBack,                    mAudioFocusDispatcher, getIdForAudioFocusListener(l),                    getContext().getOpPackageName() /* package name */, flags,                    ap != null ? ap.cb() : null);        } catch (RemoteException e) {            Log.e(TAG, "Can't call requestAudioFocus() on AudioService:", e);        }        return status;    }

在requestAudioFocus()中，與以往的稍有不同的是，requestAudioFocus()先一步對傳入的參數進行處理，並將申請應用的listener放進了mAudioFocusIdListenerMap中儲存。而傳入的參數中，多了mAudioFocusDispatcher和getIdForAudioFocusListener(l)。getIdForAudioFocusListener(l)很明顯，就是將這個listener的名字傳進去。那mAudioFocusDispatcher到底是幹什麼的呢？

 

接下來，我們先來關注一下mAudioFocusDispatcher：

 

    private final IAudioFocusDispatcher mAudioFocusDispatcher = new IAudioFocusDispatcher.Stub() {        public void dispatchAudioFocusChange(int focusChange, String id) {            Message m = mAudioFocusEventHandlerDelegate.getHandler().obtainMessage(focusChange, id);            mAudioFocusEventHandlerDelegate.getHandler().sendMessage(m);        }    };

 

從上面我們可以看出，mAudioFocusDispatcher是IaudioFocusDispatcher的一個實現。他裡面有一個方法，負責調用mAudioFocusEventHandlerDelegate去處理訊息的內容。那mAudioFocusEventHandlerDelegate又是幹什麼呢？我們繼續往下看。

    private class FocusEventHandlerDelegate {        private final Handler mHandler;        FocusEventHandlerDelegate() {            Looper looper;            if ((looper = Looper.myLooper()) == null) {                looper = Looper.getMainLooper();            }            if (looper != null) {                // implement the event handler delegate to receive audio focus events                mHandler = new Handler(looper) {                    @Override                    public void handleMessage(Message msg) {                        OnAudioFocusChangeListener listener = null;                        synchronized(mFocusListenerLock) {                            listener = findFocusListener((String)msg.obj);                        }                        if (listener != null) {                            Log.d(TAG, "AudioManager dispatching onAudioFocusChange("                                    + msg.what + ") for " + msg.obj);                            listener.onAudioFocusChange(msg.what);                        }                    }                };            } else {                mHandler = null;            }        }        Handler getHandler() {            return mHandler;        }    }

從上面我們可以看出，調用mAudioFocusEventHandlerDelegate就是為了回調傳入的listener的onAudioFocusChange方法去處理相關的內容。那明明可以直接通過l.onAudioFocusChange(focusChange)去處理這些資訊，為什麼要多此一舉專門用一個handle去處理了？於是我去查了一下啊，原因如下：因為這個回調尚在Binder的調用線程中，如果在這裡因為使用者傳入的listener的代碼有問題而爆出異常或阻塞甚至惡意拖延，則會導致Binder的另一端因異常而崩潰或阻塞。所以到此為止，AudioService已經盡到了通知的義務，應該通過Handler將後續的操作發往另外一個線程，使AudioService儘可能遠離回調現實的影響。

 

所以，現在我們可以進入AudioService去看一下到底AudioService是怎樣處理的。

AudioService. requestAudioFocus()如下：

public int requestAudioFocus(AudioAttributes aa, int durationHint, IBinder cb,            IAudioFocusDispatcher fd, String clientId, String callingPackageName, int flags,            IAudioPolicyCallback pcb) {        // 檢測許可權        if ((flags & AudioManager.AUDIOFOCUS_FLAG_LOCK) == AudioManager.AUDIOFOCUS_FLAG_LOCK) {     //奇怪的地方1            if (AudioSystem.IN_VOICE_COMM_FOCUS_ID.equals(clientId)) {                if (PackageManager.PERMISSION_GRANTED != mContext.checkCallingOrSelfPermission(                            android.Manifest.permission.MODIFY_PHONE_STATE)) {                    Log.e(TAG, "Invalid permission to (un)lock audio focus", new Exception());                    return AudioManager.AUDIOFOCUS_REQUEST_FAILED;                }            } else {                //註冊一個AudioPolicy去擷取AudioFocus                synchronized (mAudioPolicies) {    //奇怪的地方2                    if (!mAudioPolicies.containsKey(pcb.asBinder())) {                        Log.e(TAG, "Invalid unregistered AudioPolicy to (un)lock audio focus");                        return AudioManager.AUDIOFOCUS_REQUEST_FAILED;                    }                }            }        }        return mMediaFocusControl.requestAudioFocus(aa, durationHint, cb, fd,                clientId, callingPackageName, flags);    }

在上面假如仔細看的話，有2個地方會覺得很奇怪。第一個，AudioManager.AUDIOFOCUS_FLAG_LOCK ，第二個mAudioPolicies。AudioManager.AUDIOFOCUS_FLAG_LOCK代表著AudioFocus被鎖定的狀態。處於這種狀態下假如應用需要擷取AudioFoucs，首先得去registerAudioPolicy。這就和AudioPolicy相關。

 

在這裡AudioPolicy與AudioPolicyService一點關係的沒有。前者在java層，只是負責提供簡單的音頻路由和音頻焦點的管理；後者處於C++層負責處理音頻相關的路由策略。在這裡，由於我們一般不會用到AudioPoluicy和AudioManager.AUDIOFOCUS_FLAG_LOCK，所以這個會在4.3稍作解析就過了。

 

回到AudioService. requestAudioFocus(),我們其實可以發現，真正處理AudioFocus的，是MediaFocusControl……

所以現在就來看一下MediaFocusControl是怎麼處理的。

 

   protected int requestAudioFocus(AudioAttributes aa, int focusChangeHint, IBinder cb,            IAudioFocusDispatcher fd, String clientId, String callingPackageName, int flags) {         ……        //跳過各種判斷        synchronized(mAudioFocusLock) {          ……            //通過AudioFocusDeathHandler對申請AudioFocus的應用進行監聽            AudioFocusDeathHandler afdh = new AudioFocusDeathHandler(cb);            try {                cb.linkToDeath(afdh, 0);            } catch (RemoteException e) {                ……                return AudioManager.AUDIOFOCUS_REQUEST_FAILED;            }            // mFocusStack就是AudioFocus機制所在的棧// 如果申請AudioFocus的應用已經擷取的AudioFocus，不作任何處理            if (!mFocusStack.empty() && mFocusStack.peek().hasSameClient(clientId)) {                ……            }            // 如果已經在Stack中已經存在去這個應用的請求，就先remove掉它            removeFocusStackEntry(clientId, false /* signal */, false /*notifyFocusFollowers*/);                        //建立一個FocusRequester對象            final FocusRequester nfr = new FocusRequester(aa, focusChangeHint, flags, fd, cb,                    clientId, afdh, callingPackageName, Binder.getCallingUid(), this);            if (focusGrantDelayed) {                //處於可延遲擷取AudioFocus狀態（正在通話）下，先把它放進Stack中                final int requestResult = pushBelowLockedFocusOwners(nfr);                if (requestResult != AudioManager.AUDIOFOCUS_REQUEST_FAILED) {                    notifyExtPolicyFocusGrant_syncAf(nfr.toAudioFocusInfo(), requestResult);                }                return requestResult;            } else {                                if (!mFocusStack.empty()) {                    //使上一個佔有AudioFocus的應用失去AudioFocus                    propagateFocusLossFromGain_syncAf(focusChangeHint);                }                //將當前的request放在棧頂                mFocusStack.push(nfr);            }            //通知系統該應用擷取AudioFocus            notifyExtPolicyFocusGrant_syncAf(nfr.toAudioFocusInfo(),                    AudioManager.AUDIOFOCUS_REQUEST_GRANTED);        }//synchronized(mAudioFocusLock)        return AudioManager.AUDIOFOCUS_REQUEST_GRANTED;    }

 

在這裡我們可以看到真正的requestAudioFocus()處理。其實主要的流程就是：

1） 判斷是否需要延遲擷取AudioFocus（通話狀態），判斷應用是否已經擁有AudioFocus等等。

2） 讓上一個佔有AudioFocus的應用失去AudioFocus，並通過一系列的操作回調它的onAudioFocusChange方法。（流程較簡單，不詳細敘述了）

3） 將當前應用FocusRequester放到棧頂，並通知系統當前應用擷取AudioFocus

 

失去AudioFocus的操作（abandonAudioFocus）和requestAudioFocus是大同小異的。所以在這裡也不詳細說明了。

 

3 AudioPolicy的使用

最後在這裡簡單說一下java層的AudioPolicy的理解。AudioService會有一個HashMap的對象mAudioPolicies，裡面儲存著所有registerAudioPolicy()過的應用的資訊。通過registerAudioPolicy()我們可以對AudioFocus進行鎖定並不允許不註冊AudioPolicy的應用修改。但是這個功能其實我們大部分時候都不會用到。

音頻調用相關就簡單分析到這。再重申一下，AudioFocus是一個建議非強制機制，我們不適用AudioFocus都不會影響應用的音訊輸出與輸入。