给Android车载蓝牙音乐添加盘控控制功能

1. 方向盘事件转换

假设方向盘是通过lin总线转换的，最终来到安卓侧就是标准的keyevent:

/** Key code constant: Play/Pause media key. */
public static final int KEYCODE_MEDIA_PLAY_PAUSE= 85;
/** Key code constant: Stop media key. */              
public static final int KEYCODE_MEDIA_STOP      = 86;
/** Key code constant: Play Next media key. */
public static final int KEYCODE_MEDIA_NEXT      = 87;
/** Key code constant: Play Previous media key. */
public static final int KEYCODE_MEDIA_PREVIOUS  = 88;

按下方向盘的媒体控制键，安卓系统的inputdispatcher(相关介绍可以参考我的博客:

Android InputFlinger简单分析) 将会以上面定义的这种keycode上报事件。上报之后在

PhoneWindowManager中会进行响应:

//PhoneWindowManager.java
public int interceptKeyBeforeQueueing(KeyEvent event, int policyFlags) {
    ...
        case KeyEvent.KEYCODE_MEDIA_STOP:
        case KeyEvent.KEYCODE_MEDIA_NEXT:
    	case KeyEvent.KEYCODE_MEDIA_PREVIOUS:
    	  if 	(MediaSessionLegacyHelper.getHelper(mContext).
                 isGlobalPriorityActive()) {
                    result &= ~ACTION_PASS_TO_USER;
                }
                if ((result & ACTION_PASS_TO_USER) == 0) {
                    
                    mBroadcastWakeLock.acquire();
                    Message msg = mHandler.obtainMessage(
                        MSG_DISPATCH_MEDIA_KEY_WITH_WAKE_LOCK,
                            new KeyEvent(event));
                    msg.setAsynchronous(true);
                    msg.sendToTarget();
                }
                break;	
    ...
}
...
case MSG_DISPATCH_MEDIA_KEY_WITH_WAKE_LOCK:
	dispatchMediaKeyWithWakeLock((KeyEvent)msg.obj);
...
 //太多流转的代码就不列举了，不是本文重点
 //直接看MediaSessionManager.java
 public void dispatchMediaKeyEvent(@NonNull KeyEvent keyEvent, boolean needWakeLock) {                                                                                    
        try {
            mService.dispatchMediaKeyEvent(keyEvent, needWakeLock);
        } catch (RemoteException e) {
            Log.e(TAG, "Failed to send key event.", e);
        }
    }

2.MediaSession

​ 前一节我们讨论了事件分发的操作通过MediaSessionManager往MediaSessionService流转。

//MediaSessionService.java
public void dispatchMediaKeyEvent(KeyEvent keyEvent, boolean needWakeLock) {
    ...
        //一般全局优先的都是电话之类的
        //电话不是active状态的时候
        //dispatchMediaKeyEventLocked继续分发、/
       if (!isGlobalPriorityActive &&
         isVoiceKey(keyEvent.getKeyCode())) {
           handleVoiceKeyEventLocked(keyEvent, needWakeLock);
       } else {
           dispatchMediaKeyEventLocked(keyEvent, needWakeLock);
       }
    ...
}

这里注意了，dispatchMediaKeyEventLocked的调用，只有keyEvent的参数。这里只是表明了发生了什么事件？按下的按钮是播放,暂停,下一个,上一个等等。那么这个分发应该发给谁呢?让我们看看：

private void dispatchMediaKeyEventLocked(KeyEvent keyEvent, boolean needWakeLock) {
    //找出
    MediaSessionRecord session = mCurrentFullUserRecord.getMediaButtonSessionLocked();
    if (session != null) {
        //回调它
    } else if (
    	mCurrentFullUserRecord.mLastMediaButtonReceiver != null
                    || mCurrentFullUserRecord.mRestoredMediaButtonReceiver != null
    ){
        //回调它
    }
}

//MediaSessionService.FullUserRecord
private MediaSessionRecord getMediaButtonSessionLocked() {
            return isGlobalPriorityActiveLocked()
                    ? mGlobalPrioritySession : mPriorityStack.getMediaButtonSession();
        }

getMediaButtonSessionLocked:全局高优先级的session没有active则返回:

mPriorityStack.getMediaButtonSession();

看看mPriorityStack是个啥?

mPriorityStack = new MediaSessionStack(mAudioPlaybackMonitor, this);

是一个session stack.这个stack里存了一堆MediaSession.这个stack的mAudioPlaybackMonitor(总算和audio扯上关系了):

mAudioPlaybackMonitor = AudioPlaybackMonitor.getInstance(getContext(), mAudioService);

mAudioPlaybackMonitor是单例的。整个系统起来之后就只有一个。它就是AudioService的那个AudioPlaybackMonitor。

mPriorityStack拿它来作甚呢?

//MediaSessionStack.java 
//（开始我的业余翻译）
//如果有需要，更新media button session
//media button session是那个会接收media button事件的session
//我们会把media button事件发送给the lastly played app(最后播放的app)
//如果那个app有media session,它的session将收到media buttion事件
    public void updateMediaButtonSessionIfNeeded() {
        //getSortedAudioPlaybackClientUids的注释:
        //返回经过排序的有激活的audio playback的uid列表
        //The UID whose audio playback becomes active at the last comes first.
        //最后播放的放在最前面，后进先出嘛，所以这里的数据结构是栈
        //感觉自己好聪明
        IntArray audioPlaybackUids = mAudioPlaybackMonitor.getSortedAudioPlaybackClientUids();                                                                               
        for (int i = 0; i < audioPlaybackUids.size(); i++) {
            //找到udi对应的mediasession
            MediaSessionRecord mediaButtonSession =
                    findMediaButtonSession(audioPlaybackUids.get(i));
            if (mediaButtonSession != null) {
            // Found the media button session.    
                //然后cleanup
                mAudioPlaybackMonitor.cleanUpAudioPlaybackUids(
                    mediaButtonSession.getUid());
                if (mMediaButtonSession != mediaButtonSession) {
                    //更新mMediaButtonSession的值
                    updateMediaButtonSession(mediaButtonSession);
                }
                return;
            }
        }
    }

mPriorityStack把mAudioPlaybackMonitor用来和mediasession做一个映射，并且根据audio的播放状态的变化做一个刷新。

前面这个updateMediaButtonSessionIfNeeded函数会在app调用了addSession的时候调用:

public void addSession(MediaSessionRecord record) {
    mSessions.add(record);
    updateMediaButtonSessionIfNeeded();
}

将应用创建的MediaSession加到MediaSessionStack的mSessions中进行管理,并且更新

mMediaButtonSession.这样，前面mPriorityStack.getMediaButtonSession();调用过来的时候，才能给出一个可以响应盘控事件的MediaSession.

3.车载蓝牙音乐为什么不行

前面1,2说了这么多情景提要，貌似app想使用盘控，new一个MediaSession并，addSession，加个回调，监控盘控事件就可以了。可实际情况不是这样的。具体缘由，且听我慢慢道来。

前面第二节中提到过这么一个函数:getSortedAudioPlaybackClientUids.

//AudioPlaybackMonitor.java
public IntArray getSortedAudioPlaybackClientUids() {
        Log.d(TAG,"getSortedAudioPlaybackClientUids");
        IntArray sortedAudioPlaybackClientUids = new IntArray();
        synchronized (mLock) { sortedAudioPlaybackClientUids.addAll(mSortedAudioPlaybackClientUids);
        }
        return sortedAudioPlaybackClientUids;
    }

主要关联的是这个mSortedAudioPlaybackClientUids.

车载蓝牙音乐播放的时候（连接手机，在手机端播放，车机端蓝牙的角色是sink）.mSortedAudioPlaybackClientUids的size为0.我擦，为什么是这样!!!let me find out why so it is!

mSortedAudioPlaybackClientUids是在什么地方添加的?

//直接搜索mSortedAudioPlaybackClientUids.add
//只有一个地方
//AudioPlaybackMonitor.java
//alled when the {@link AudioPlaybackConfiguration} is updated.
public void dispatchPlaybackConfigChange(List<AudioPlaybackConfiguration> configs,
                                         boolean flush) {
    ...
        mSortedAudioPlaybackClientUids.add(0, config.getClientUid());
    ...
}

好的，按照惯例，捋一遍调用堆栈。过程就不聊了，直接上结论:

1.AudioTrack,MediaPlayer,SoundPool都extends PlayerBase .获得了一些公共能力，比如

//PlayerBase.java
void baseStart() {
    ...
                mState = AudioPlaybackConfiguration.PLAYER_STATE_STARTED;
    //请注意，并记住这个playerEvent方法
                getService().playerEvent(mPlayerIId, mState);
   ...
    }

getService返回的是IAudioService.

是的，就是那个在在SystemServer中启动的audio_service.

2.AudioTrack的play方法会调用到PlayerBase的1中说的这个baseStart方法，MediaPlayer的start方法也是，当然SoundPool的play方法也是。

也就是说只要app调用了Android中这三者中的其中一个去播放声音，都会自动调用到PlayerBase的baseStart方法，也即AudioService的playerEvent方法

3.看看第一步baseStart中调用的playerEvent方法长什么样?

//AudioService.java 
public void playerEvent(int piid, int event) {
        mPlaybackMonitor.playerEvent(piid, event, Binder.getCallingUid());                           
    }
//PlaybackActivityMonitor.java
public void playerEvent(int piid, int event, int binderUid) {
    ...
        dispatchPlaybackChange(event == AudioPlaybackConfiguration.PLAYER_STATE_RELEASED);
    ...
}
private void dispatchPlaybackChange(boolean iplayerReleased) {
    ...
        pmc.mDispatcherCb.dispatchPlaybackConfigChange(...省略)
    ...
}

由于成功会师，所以我忽略了很多细节。省略了很多代码。

也就是说只要app调用了java的AudioTrack或者MediaPlayer或者SoundPool.就会调用我们在前面讨论的dispatchPlaybackConfigChange方法。

前面说过了，dispatchPlaybackConfigChange会把当前播放的MediaSession加入

mSortedAudioPlaybackClientUids。

其他先不展开讲了。我们今天聊的是车机蓝牙音乐！

车机蓝牙音乐为什么不会被加进去？难道他们用的不是java的AudioTrack，MediaPlayer,SoundPool？注意，我强调的是java!!!

展示我找到的证据吧:

//system/bt/btif/src/btif_avrcp_audio_track.cc
//这里再次明确下，我们本文聊的场景是车机蓝牙音乐，就是手机连接车机，手机的音频
//数据通过a2dp送到车机，车机的蓝牙角色是sink
void* BtifAvrcpAudioTrackCreate(参数省略){
    ...
    track = new android::AudioTrack(参数省略);
    ...
}

其他就先不聊了，毕竟已经进入了蓝牙领域了，不是我擅长的了。

这里我想说的是他们调用的是native的AudioTrack类。这就是问题所在了，谷歌估计是没考虑到这种情况吧。总之使用AudioTrack.cpp这个文件中的native AudioTrack类进行播放的app,播放状态都不会被track(这里是追踪的意思)。

4.解决问题

既然我们找到了问题所在。我们就想方设法调用AudioService的playerEvent方法就好了(不要问为什么不是playerBase,我还得让AudioTrack继承PlayerBase类，费劲！)。

我们查看了下PlayerBase的源码，发现:

//PlayerBase.cpp
PlayerBase::PlayerBase() {
    ...
        sp<IBinder> binder = defaultServiceManager()->checkService(String16("audio"));
    	mAudioManager = interface_cast<IAudioManager>(binder);
    ...
}

是的，你没看错，cpp代码是直接可以bind java的service的。

稍等

说个题外话(binder调用使用到的接口文件):

//IAudioManager.h
class IAudioManager : public IInterface
{
public:
	// These transaction IDs must be kept in sync with the method order from
    // IAudioService.aidl.
    // transaction IDs for the unsupported methods are commented out
        ADJUSTSUGGESTEDSTREAMVOLUME           = IBinder::FIRST_CALL_TRANSACTION,
        ADJUSTSTREAMVOLUME                    = IBinder::FIRST_CALL_TRANSACTION + 1,
        PLAYER_EVENT                          = IBinder::FIRST_CALL_TRANSACTION + 70,
}

前面的两行注释让我解决了一个binder调用死活不成功的问题。

IAudioManager方法的定义要和java层的IAudioService.aidl保持一致。主要是方法的偏移

比如说这个:

IBinder::FIRST_CALL_TRANSACTION + 70,//我说的偏移就是这个70

FIRST_CALL_TRANSACTION指向第一个方法ADJUSTSUGGESTEDSTREAMVOLUME，如果java层的IAudioService.aidl有添加方法（比如说AudioManager添加新的接口给app调用，AudioService就需要添加对应的方法实现，IAudioService.aidl就要添加对应的方法定义）。这种时候PLAYER_EVENT对应的偏移，比如说原生是69,我这里改成70就是因为前面多了一个方法。我能想到比较笨的方法就是数方法个数。

回到这个问题的解决方法:

//AudioTrack.cpp
AudioTrack::AudioTrack(
...
    //这个参数是我自己加的默认参数，默认值就是false.这样，只有蓝牙改成true才会启动这个功能。这样能保证改动的影响最小。
   bool isNeedTrackInNative 
   ) {
   	...
    if(mIsNeedTrackInNative) {
    	sp<IBinder> binder = defaultServiceManager()->checkService(String16("audio"));
    	mAudioManager = interface_cast<IAudioManager>(binder);
    }
    ...
   }

binding成功audio这个service就可以愉快地调用了。

status_t AudioTrack::start()                                 
{
    ...
        mAudioManager->playerEvent(mPIId,PLAYER_STATE_STARTED);
    ...
}

void AudioTrack::stop()
{
    ...
        mAudioManager->playerEvent(mPIId,PLAYER_STATE_STOPPED);
    ...
}

void AudioTrack::pause()
{
 	...
        mAudioManager->playerEvent(mPIId,PLAYER_STATE_PAUSED);
    ...
}

AudioTrack::~AudioTrack()
{
    ...
        mAudioManager->releasePlayer(mPIId);
    	mAudioManager.clear();
    ...
}

然后，对应的BtifAvrcpAudioTrackCreate调用的地方也有加上给他唯一定义的参数。这点来说C++的这个默认参数机制真心好用。函数的定义可以变，可以加参数，还不影响之前调用这个函数的那些代码。牛逼牛逼!

好的，问题解决，文章写完，收工！