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都不會影響應用的音頻輸出與輸入。