Android WifiDisplay分析一：相关Service的启动

网址：http://www.2cto.com/kf/201404/290996.html

最近在学习Android 4.4上面的WifiDisplay(Miracast)相关的模块，这里先从WifiDisplay用到的各个Service讲起，然后再从WifiDisplaySettings里面讲解打开wfd的流程。首先看下面的主要几个Service的架构图：

相关Service的启动

图中主要有以下几个模块，DisplayManagerService、MediaRouterService、WifiDisplayAdapter和WifiDisplayController。其中：

DisplayManagerService用于管理系统显示设备的生命周期，包含物理屏幕、虚拟屏幕、wifi display等，它用一组DiaplayAdapter来管理这些显示设备。

MediaRouterService用于管理各个应用程序的多媒体播放的行为。

MediaRouter用于和MediaRouterService交互一起管理多媒体的播放行为，并维护当前已经配对上的remote display设备，包括Wifi diplay、蓝牙A2DP设备、chromecast设备。

WifiDisplayAdapter是用于DisplayManagerService管理Wifi display显示的adapter。

WifiDisplayController用于控制扫描wifi display设备、连接、断开等操作。

先来顺着上面的架构图看各个Service的启动。首先来看DisplayManagerService，在SystemServer中先创建一个DisplayManagerService对象，然后调用systemReady方法：

?
在DisplayManagerService的构造函数中，首先获取SYSTEM_HEADLESS属性，用于表明系统是否支持headless模式，默认为0。然后创建一个DisplayManagerHandler用于处理DisplayManagerService中的消息，mSigleDisplayDemoMode用于开发模式中。然后给自己发送MSG_REGISTER_DEFAULT_DISPLAY_ADAPTER，我们到DisplayManagerHandler看如何处理这个消息：

?
处理MSG_REGISTER_DEFAULT_DISPLAY_ADAPTER消息就是调用registerDefaultDisplayAdapter来注册一个默认的DiaplayAdapter，DisplayManagerService维护一组DiaplayAdapter，用于管理这些显示设备。默认的DiaplayAdapter就是系统的物理屏幕，通过Surface flinger来控制输出。

?
管理surface finger的知识就不讲解了。接着来看systemReady函数中会发送MSG_REGISTER_ADDITIONAL_DISPLAY_ADAPTERS，这里就会调用registerAdditionalDisplayAdapters来注册其它的显示设备：

?
这里主要注册三种DisplayAdapter，一种是OverlayDiaplayAdapter用于开发模式用；一种是WifiDisplayAdapter用于wifi display，也是我们接下来要讲的；还有一种是虚拟显示。接下来只看registerWifiDisplayAdapterLocked：

?
这里会创建WifiDisplayAdapter对象，我们到它的构造函数中去分析，并调用registerDisplayAdapterLocked添加到mDisplayAdapter中，这里会回调WifiDisplayAdapter的registerLocked方法：

?
PersistentDateStore用于持久性存储连过的wifi display设备，用于在WifiDisplaySettings中显示前面已经连接过的设备列表。SupportsProtectedBuffer与gralloc显示相关。在registerLocked通过updateRememberedDisplaysLocked去加载/data/system/display-manager-state.xml中保存过的列表，并记录在mRememberedDisplays中。接着实例化一个WifiDisplayController对象，同时注册对ACTION_DISCONNECT的receiver。接着到WifiDisplayController去分析，注意WifiDisplayController最后一个参数用于回调通知WifiDisplayAdapter相关状态的改变，比如wifi display打开/关闭、wifi display连接/断开等。

?
这里主要注册WifiP2pReceiver用于接收处理WIFI_P2P_STATE_CHANGED_ACTION、WIFI_P2P_PEERS_CHANGED_ACTION、WIFI_P2P_CONNECTION_CHANGED_ACTION、WIFI_P2P_THIS_DEVICE_CHANGED_ACTION消息，然后注册ContentObserver来监控Settings.Global这个数据库里面的WIFI_DISPLAY_ON、WIFI_DISPLAY_CERTIFICATION_ON和WIFI_DISPLAY_WPS_CONFIG，这里比较重要，我们后面会看到在WifiDisplaySettings里面enable wifi display的时候，就会走到这个地方来。接着调用updateSettings来处理默认是否打开Wifi display，这里默认是关闭的，我们后面再来分析这一块。

接着来看MediaRouterService和MediaRouter，MediaRouter通过AIDL调用MediaRouterService的实现来完成一些工作。在SystemServer启动MediaRouterService的时候，主要创建一个MediaRouterService，然后调用它的systemRunning方法，代码如下：

?
上面的方法比较简单，主要就是接收ACTION_USER_SWITCHED，这是关于多用户切换的操作。MediaRouterService的工作比较少，主要都是MediaRouter通过AIDL调用完成，接下来去看MediaRouter的部分，在Android官方文档中有说明MediaRouter的调用方法：

A MediaRouter is retrieved through

Context.getSystemService()

of a

Context.MEDIA_ROUTER_SERVICE

. 这样系统是实例化一个MediaRouter对象并返回，下面来看它的构造函数：

?
MediaRouter中主要通过Static对象来实现其大多数的方法，Static就是一个单例模式，先看Static的构造函数，也可以通过上面的图看到，MediaRouter包含DisplayManager对象和MediaRouterService的BpBinder引用，MediaRouter还持有AudioService的BpBind，用于控制audio数据的输出设备，例如可以用于蓝牙A2DP中使用。接着看Static的startMonitoringRoutes方法：

?
首先注册系统中默认的AudioVideo输出设备，如果有处于活动状态的wifi display连接，就记录下当前处于活动连接的设备，默认为空。上面会注册两个broadcastReceiver，一个用于接收ACTION_WIFI_DISPLAY_STATUS_CHANGED，另一个接收VOLUME_CHANGED_ACTION，我们主要看前面接收ACTION_WIFI_DISPLAY_STATUS_CHANGED的receiver，如下：

?
上面接收ACTION_WIFI_DISPLAY_STATUS_CHANGED，从Intent里面取出WifiDisplayStatus对象，WifiDisplayStatus内部的变量如下：

mFeatureState	表明现在wifi display是关闭还是打开状态
mScanState	表现现在wifi display是否在scanning状态
mActiveDisplayState	表明现在wifi display是在连接还是无连接状态
mActiveDisplay	处于正在连接或者连接中的WifiDisplay对象
mDisplays	扫描到的WifiDisplay对象数组
mSessionInfo	用于过Miracast认证时用

然后向DisplayManager注册一个回调函数，当有显示设备增加、删除或者改变的时候，就会有相应的回调函数来通知Static对象。接着绑定MediaRouterService：

?

Enable WifiDisplay

当用户进入WifiDisplaySettings界面，会调用其对应的onCreate和onStart方法：

?
首先注册对ACTION_WIFI_DISPLAY_STATUS_CHANGED的receiver，这个broadcast会在WifiDisplayAdapter里面当wifi display的状态发送改变时发送，包括扫描到新的设备、开始连接、连接成功、断开等消息都会被这个receiver接收到，后面我们会来分析这个receiver干了什么，然后在onStart中想MediaRouter对象注册一个callback函数，用于获取系统中remote display的相关回调信息。然后类似WifiDisplayController一样，注册一些对数据库改变的ContentObserver。接着来看MediaRouter.addCallback的实现：

?
Static的mCallbacks是一个CopyOnWriteArrayList数组，记录所有注册到MediaRouter中的回调函数。如果已经向MediaRouter注册过这个callback，则更新相关的type和flag；如果没有注册，则新建一个CallbackInfo对象并添加到mCallbacks数组中。然后调用Static的updateDiscoveryRequest去更新是否需要发送Discovery request请求：

?
这个函数体比较长，主要通过注册的一系列的callback类型来决定是否要进行wifiDisplay scan的动作，根据在WifiDisplaySettings里面注册callback的方法： mRouter.addCallback(MediaRouter.ROUTE_TYPE_REMOTE_DISPLAY, mRouterCallback,
MediaRouter.CALLBACK_FLAG_PERFORM_ACTIVE_SCAN)，上面函数中的activeScanWifiDisplay会为true，接着会调用DisplayManagerService中的startWifiDisplayScan，如下图。

这里会通过WifiDisplayAdapter调用到WifiDisplayController的updateScanState动作，我们到updateScanState中去分析：

?
当初次进入到WifiDisplaySettings中，并没有去optionMenu中enable wifi display时，上面code中的mWfdEnabled为false，所以会跳出前面的if语句；后面的else语句中mDiscoverPeersInProgress也为false，因为这个变量只有在scan时才会被置为true。
接着来分析当用户点击了optionMenu中enable wifi display后的流程，先看WifiDisplaySettings的代码：

?
这里首先改变OptionMenu的状态，并置mWifiDisplayOnSetting为上次MenuItem相反的状态，然后改变Settings.Global数据库中WIFI_DISPLAY_ON的指为1。前面我们介绍过，在WifiDisplaySettings和WifiDisplayController都有注册ContentObserver来监控这个值的变化。其中WifiDisplaySettings在监控到这个值的变化后，主要是调用MediaRouter和DisplayManager的方法去获取系统中已经扫描到的remote display设备，并更新到listview列表上，显然这时候还没有开始scan，所以listview列表为空。接着看WifiDisplayController处理ContentOberver的代码：

?
这里主要置mWifiDisplayOnSetting为true，然后就调用updateWfdEnableState去更新wfd的状态：

?
首先调用WifiP2pMananger的setWFDInfo把与wifi display相关的信息设置到wpa_supplicant，这些信息包括enable状态、device type（指为source还是sink）、session available（当前可否连接）、control port（用于rtsp连接）、maxThroughput（吞吐量），这些信息最终会随着P2P的IE信息在扫描阶段被对方知道。接着会调用reportFeatureState来通知WifiDisplayAdapter相应状态的变化，这里我们先看一下下面的流程图来了解一下WifiDisplaySettings、MediaRouter、DisplayMananger、WifiDisplayAdapter、WifiDisplayController是如何相互通知信息的，这其中有简单的callback，也有发送/接收broadcast，如下图：

通过上面的图我们可以看到实线部分是调用关系，虚线部分是回调关系。接着我们来看reportFeatureState的实现：

?
直接回调WifiDisplayListener的onFeatureStateChanged，从上面的图我们可以看着WifiDisplayListener会由WifiDisplayAdapter注册的，去看这部分的实现：

?
这里最后通过WifiDisplayHandler的sendEmptyMessage的方法实现，目的是不要卡住了WifiDisplayController后面代码的执行，来看WifiDisplayHandler如何处理MSG_SEND_STATUS_CHANGE_BROADCAST：

?
上面的代码都比较简单，在getWifiDisplayStatusLocked中会根据WifiDisplayAdapter中的变量mFeatureState、mScanState、mActiveDisplayState、mActiveDisplay、mDisplays、mSessionInfo去构造一个WifiDisplayStatus对象，在前面我们介绍过这几个变量的含义了，当然这几个变量会从WifiDisplayListener的各个callback分别去改变自己的值。接着我们到MediaRouter中去看如何处理这个broadcastReceiver，前面我们已经讲过了，WifiDisplayStatusChangedReceiver会接收这个broadcast，然后调用updateWifiDisplayStatus来更新状态，我们稍后来看这部分的实现。回到WifiDisplayController的updateWfdEnableState方法中，接着会调用updateScanState方法开始扫描WifiDisplay设备：

?
handleScanStarted用于通知WifiDisplayAdapter扫描开始了，当然WifiDisplayAdapter也会发broadcast给MediaRouter。接着会调用tryDiscoverPeers：

?
这里调用WifiP2pManager的discoverPeers去扫描所有的p2p设备，比较重要是后面有发一个delay message，表示每间隔10秒就去发一下P2P_FIND。当然下了P2P_FIND命令后，并不能马上获取到对方设备，但因为我们前面有讲过在/data/system/display-manager-state.xml有保存过前面连接过的设备列表，所以这里会马上调用requestPeers去获取设备列表。当然在WifiDisplayController也会注册对WIFI_P2P_PEERS_CHANGED_ACTION的receiver，最终还是会调用reqeustPeers去获取所有扫描到的设备列表，下面来看这个函数的实现：

?
首先从扫描的设备列表中过滤掉不能做wifi display的设备，主要从三个方面过滤，一是纯粹的P2P设备，不会待用WfdInfo；第二是带有WfdInfo，但是暂时没有被enable；三是只能是PrimarySinkDevice，看起来Android还不支持SecondSink。并将过滤掉剩下的设备加入到mAvailableWifiDisplayPeers列表中，接着调用handleScanResults来组装WifiDisplay列表数组并notify给WifiDisplayAdapter：

?
这里首先根据mAvailableWifiDisplayPeers的数目创建一个WifiDisplay数组，然后一个个构造WifiDisplay对象，WifiDiplay对象包含以下几个变量：

mDeviceAddress	设备的Mac地址
mDeviceName	设备的名字
mDeviceAlias	设备的别名，一般为NULL
mIsAvailable	是否可用状态
mCanConnect	WfdInfo中的SessionAvailable是否为1
mIsRemembered	是否被记录的

接着调用updateDesiredDevice用于判断扫描到的这个设备是否是现在正在连接或者连接上的设备，如果是，则更新它的一些信息，以后在连接Wifi display的时候再来分析这一块。接着就会向WifiDisplayAdapter回调onScanResults，回调函数中带有已经扫描到的wifi display设备列表（如果有）：

?