Android 4.2 Wifi Display 之 Settings 源码分析（二）
作者：mznewfacer 时间：2012年12月7日
在上一回我们一块分析了WifiDisplay有关设备发现的部分，这一回将主要针对设备连接和建立数据流展开分析。
首先，回顾下应用层，当用户在搜寻完设备后，可以选择设备进行连接，当然正在进行连接或已经连接配对的设备，再次点击配置后，会弹出对话框供用户选择断开连接。
packages/apps/Settings/src/com/android/settings/wfd/WifiDisplaySettings.java
如同设备发现的调用流程，当用户选择设备进行连接后，程序会调用DisplayManager的connectWifiDisplay()函数接口。该函数会进一步根据DisplayManagerGlobal提供的单实例对象调用AIDL提供的接口函数connectWifiDisplay()，这又是上一回已经提到过的调用模式。其实际的调用实现是Displaymanager service中提供的connectWifiDisplay()函数，frameworks/base/services/java/com/android/server/display/DisplayManagerService.java
到此，我们容易发现连接WifiDisplay设备的函数调用流程与发现设备的流程一致，这里将不做多余解释（详见），在此会罗列出之后的基本流程。frameworks/base/services/java/com/android/server/display/WifiDisplayAdapter.java
frameworks/base/services/java/com/android/server/display/WifiDisplayController.java接下来，我们将重点看一看updateConnection()函数，此函数是建立Wifidisplay连接，监听RTSP连接的核心实现函数。至此，我们已经了解了建立WifiDisplay连接的基本流程，当然可以继续向底层深入，只要用户选择尝试连接并且已经确认处于连接断开的状态，则会调用WifiP2pManager中的connect()接口函数，该函数会向Channel中发送CONNECT信号，并注册监听器监听相应结果。在进入P2pStateMachine状态机后，WifiP2pService会分为两种情况进行处理。如果当前的设备不是P2P组的成员，WifiP2pService会调用WifiNative类中的p2pConnect()函数，该函数会继续向底层调用，最终会调用wifi.cwifi_send_command()命令，把groupnegotiation请求发送至wpa_supplicant供其处理；如果这个设备已经是P2P组的成员，或者自己通过WifiNative类中的p2pGroupAdd()函数创建了一个组，那么会进入GroupCreatedState，进一步会调用WifiNative类中的p2pInvite()函数向设备发送邀请请求。具体的有关wpa_supplicant同底层驱动的交互，以及wpa_supplicant同WifiMonitor与WifiP2pService状态机之间的调用流程以后有机会再讨论。在本文的最后，还想继续讨论一下监听RTSP连接的核心实现函数RemoteDisplay.listen(...)，
frameworks/base/media/java/android/media/RemoteDisplay.java
以上函数最终会调用JNI层的接口函数nativeListen()进行监听。至于CloseGuardmGuard.open()，不理解的话，我们就把它看作是Android提供的一种资源清理机制。接下来，可以具体看一下RemoteDisplay在JNI层的接口实现，
frameworks/base/core/jni/android_media_RemoteDisplay.cpp
这里采用了Binder通信机制，BpMediaPlayerService继承BpInterface<IMediaPlayerService>作为代理端，采用Bridge模式调用listenForRemoteDisplay()接口函数将上层的监听接口以及实例化的NativeRemoteDisplayClient代理对象传递至服务端BnMediaPlayerService进行处理。/frameworks/av/media/libmedia/IMediaPlayerService.cpp
进一步可以看到，NativeRemoteDisplayClient继承于BnRemoteDisplayClient，其实这是IRemoteDisplayClient接口的服务端实现。该类提供了三个接口函数onDisplayConnected()、onDisplayDisconnected()、onDisplayError()是frameworks/base/media/java/android/media/RemoteDisplay.java中RemoteDisplay.Listener{}的三个监听函数在JNI层的实现，特别的，对于onDisplayConnected()函数而言，调用android_view_Surface_createFromISurfaceTexture()函数创建surfaceObj并将其向RemoteDisplay中注册的监听线程传递并进行回调。frameworks/base/core/jni/android_media_RemoteDisplay.cpp
接下来，我们继续来看服务端BnMediaPlayerService的实现，其中onTransact函数用于接收来自BpMediaPlayerService发送的命令，如果命令为LISTEN_FOR_REMOTE_DISPLAY，则会读取相应数据并作为参数进行传递。这里的listenForRemoteDisplay()函数是纯虚函数，其实现是由派生类MediaPlayerService来完成的。最后，来看一看该函数的实际实现，frameworks/av/media/libmediaplayerservice/MediaPlayerService.cpp
其中，RemoteDisplay继承于BnRemoteDisplay，也采取了Binder通信机制,代理端BpRemoteDisplay与服务端BnRemoteDisplay的接口实现详见frameworks/av/media/libmedia/IRemoteDisplay.cpp。这里，值得一提的是，函数listenForRemoteDisplay()假设在同一时刻连接到指定网络端口iface的remotedisplay设备最多只有一个。换句话说，在同一时刻只有一个设备能作为WifiDisplay source端设备进行播放。最后，我们来看一看开启Wifidisplay source端的这个构造函数，frameworks/av/media/libmediaplayerservice/RemoteDisplay.cpp
其中mLooper,mNetSession, mSource分别为sp<ALooper>mLooper，sp<ANetworkSession>mNetSession以及sp<WifiDisplaySource>mSource等三个强指针，对强指针概念不清的请见此。此处是利用构造函数的初始化列表将这三个强指针指向这三个new出来的对象。之后便是利用这三个指针，调用类中的方法以开启Wifidisplay source端进行播放。这里，ALooper是关于线程以及消息队列等待处理管理相关的一个类。ANetworkSessions是管理所有与数据报文和数据流相关socket的一个单线程帮助类。在此处，该类负责管理与WifiDisplay播放相关的socket，其中相关的数据传递和消息返回通过AMessage类对象和方法进行。WifiDisplaySource光看命名就知道，其主要负责WifiDisplaysource端的开启关闭，以及与其相关的建立Rtsp服务器，管理所有支持的协议连接、数据流传递以及各个状态之间转换处理等内容。此外，该类还定义了关闭WifiDisplay source端，停止相关线程、关闭socket以及释放资源等内容。至此，有关WifiDisplay设备连接和建立数据流的流程已经交代清楚了，可以看到应用层建立的连接是与source端相关的。Sink端的主程序在frameworks/av/media/libstagefright/wifi-display/wfd.cpp中，与sink端实现相关的程序在frameworks/av/media/libstagefright/wifi-display/sink目录下面。关于source如何建立rtsp连接，开始通信，各个状态之间的转换以及与sink端的交互将在下回介绍。
- 1楼moritz_dev昨天 22:50
- 写的相当不错的，期待继续。方便的话，可以电邮交流cgmeco@163.com ：）