Android Miracast(Wi-Fi Display)

1、基础知识简介

        Miracast是Wi-Fi联盟（Wi-Fi Alliance）对支持Wi-Fi Display功能的设备的认证名称。通过Miracast认证的设备将在最大程度内保持对Wi-Fi Display功能的支持和兼容。由此可知，Miracast考察的就是Wi-Fi Display。而Wi-Fi Display的核心功能就是让设备之间通过Wi-Fi无线网络来分享视音频数据。以一个简单的应用场景为例：有了Wi-Fi Display后，手机和电视机之间可以直接借助Wi-Fi，而无需硬连线（如HDMI）就可将手机中的视频投递到TV上去显示。
        Miracast依赖的Wi-Fi技术项有：
        （1）Wi-Fi Direct，也就是Wi-Fi P2P。它支持在没有AP（Access Point）的情况下，两个Wi-Fi设备直连并通信。
        （2）Wi-Fi Protected Setup：用于帮助用户自动配置Wi-Fi网络、添加Wi-Fi设备等。
        （3）11n/WMM/WPA2：其中，11n就是802.11n协议，它将11a和11g提供的Wi-Fi传输速率从56Mbps提升到300甚至600Mbps。WMM是Wi-Fi Multimedia的缩写，是一种针对实时视音频数据的QoS服务。而WPA2意为Wi-Fi Protected Acess第二版，主要用来给传输的数据进行加密保护。
        上述的Wi-Fi技术中，绝大部分功能由硬件厂商实现。
而在Android中，对Miracast来说最重要的是两个基础技术：
        （1）Wi-Fi Direct：该功能由Android中的WiFiP2pService来管理和控制。
        （2）Wi-Fi Multimedia：为了支持Miracast，Android 4.2对MultiMedia系统也进行了修改。

2、Miracast的大体工作流程

Miracast以session为单位来管理两个设备之间的交互的工作，主要步骤包括（按顺序）：
（1）Device Discovery：通过Wi-Fi P2P来查找附近的支持Wi-Fi P2P的设备。
（2）Device Selection：当设备A发现设备B后，A设备需要提示用户。用户可根据需要选择是否和设备B配对。
（3）Connection Setup：Source和Display设备之间通过Wi-Fi P2P建立连接。根据Wi-Fi Direct技术规范，这个步骤包括建立一个Group Owner和一个Client。此后，这两个设备将建立一个TCP连接，同时一个用于RTSP协议的端口将被创建用于后续的Session管理和控制工作。
（4）Capability Negotiation：在正式传输视音频数据前，Source和Display设备需要交换一些Miracast参数信息，例如双方所支持的视音频格式等。二者协商成功后，才能继续后面的流程。
（5）Session Establishment and streaming：上一步工作完成后，Source和Display设备将建立一个Miracast Session。而后就可以开始传输视音频数据。Source端的视音频数据将经由MPEG2TS编码后通过RTP协议传给Display设备。Display设备将解码收到的数据，并最终显示出来。
（6）User Input back channel setup：这是一个可选步骤。主要用于在传输过程中处理用户发起的一些控制操作。这些控制数据将通过TCP在Source和Display设备之间传递。
（7）Payload Control：传输过程中，设备可根据无线信号的强弱，甚至设备的电量状况来动态调整传输数据和格式。可调整的内容包括压缩率，视音频格式，分辨率等内容。
（8）Session teardown：停止整个Session。
        通过对上面背景知识的介绍，读者可以发现：Miracast本质就是一个 基于Wi-Fi的网络应用。 这个应用包括服务端和客户端。另外，服务端和客户端必须支持RTP/RTSP等网络协议和相应的编解码技术。

3、Android Miracast功能实现介绍

Miracast的Android实现涉及到系统的多个模块，包括：
（1）MediaPlayerService及相关模块：原因很明显，因为Miracast本身就牵扯到RTP/RTSP及相应的编解码技术。
（2）SurfaceFlinger及相关模块：SurfaceFlinger的作用是将各层UI数据混屏并投递到显示设备中去显示。现在，SurfaceFlinger将支持多个显示设备。而支持Miracast的远端设备也做为一个独立的显示设备存在于系统中。
（3）WindowManagerService及相关模块：WindowManagerService用于管理系统中各个UI层的位置和属性。由于并非所有的UI层都会通过Miracast投递到远端设备上。例如手机中的视频可投递到远端设备上去显示，但假如在播放过程中，突然弹出一个密码输入框（可能是某个后台应用程序发起的），则这个密码输入框就不能投递到远端设备上去显示。所以，WindowManagerService也需要修改以适应Miracast的需要。
（4）DisplayManagerService及相关模块：DisplayManagerService服务是Android 4.2新增的，用于管理系统中所有的Display设备。

3.1、SurfaceFlinger对Miracast的支持

相比前面的版本，Android 4.2中SurfaceFlinger的最大变化就是增加了一个名为DisplayDevice的抽象层。相关结构如图3所示：

由图3可知：
（1）Surface系统定义了一个DisplayType的枚举，其中有代表手机屏幕的DISPLAY_PRIMARY和代表HDMI等外接设备的DISPLAY_EXTERNAL。比较有意思的是，作为Wi-Fi Display，它的设备类型是DISPLAY_VIRTUAL。
（2）再来看SurfaceFlinger类，其内部有一个名为mDisplays的变量，它保存了系统中当前所有的显示设备（DisplayDevice）。另外，SurfaceFlinger通过mCurrentState和mDrawingState来控制显示层的状态。其中，mDrawingState用来控制当前正在绘制的显示层的状态，mCurrentState表示当前所有显示层的状态。有这两种State显示层的原因是不论是Miracast还是HDMI设备，其在系统中存在的时间是不确定的。例如用户可以随时选择连接一个Miracast显示设备。为了不破坏当前正在显示的内容，这个新显示设备的一些信息将保存到CurrentState中。等到SurfaceFlinger下次混屏前再集中处理。
（3）mCurrentState和mDrawingState的类型都是SurfaceFlinger的内部类State。由图3可知，State首先通过layerSortedByZ变量保存了一个按Z轴排序的显示层数组（在Android中，显示层的基类是LayerBase），另外还通过displays变量保存了每个显示层对应的DisplayDeviceState。
（4）DisplayDeviceState的作用是保存对应显示层的DisplayDevice的属性以及一个ISurfaceTexure接口。这个接口最终将传递给DisplayDevice。
（5）DisplayDevice代表显示设备，它有两个重要的变量，一个是mFrameBufferSurface和mNativeWindow。mFrameBufferSurace是FrameBufferSurface类型，当显示设备不属于VIRTUAL类型的话，则该变量不为空。对于Miracast来说，显示数据是通过网络传递给真正的显示设备的，所有在Source端的SurfaceFlinger来说，就不存在FrameBuffer。故当设备为VIRTUAL时，其对应的mFrameBufferSurface就为空。而ANativeWindow是Android显示系统的老员工了。该结构体在多媒体的视频I/O、OpenGL ES等地方用得较多。而在普通的UI绘制中，ISurfaceTexture接口用得较多。不过早在Android 2.3，Google开发人员就通过函数指针将ANativeWindow的各项操作和ISurfaceTexture接口统一起来。
作为VIRTUAL的Miracast设备是如何通过DisplayDevice这一层抽象来加入到Surface系统中来的呢？下面这段代码对理解DisplayDevice的抽象作用极为重要。如图4所示。

由图4代码可知：
对于非Virtual设备，DisplayDevice的FrameBufferSurface不为空。而且SurfaceTextureClient的构造参数来自于FrameBufferSurface的getBufferQueue函数。
如果是Virtual设备，SurfaceTextureClient直接使用了State信息中携带的surface变量。

3.2、DisplayManagerService：

4、Android中Miracast动态工作流程介绍：

（1）当用户从 Settings程序 中选择 开启Miracast 并 找到匹配的Device 后，系统将通过 WiFiDisplayController的requestConnect函数向匹配设备发起连接。代码如图8所示：

（2）在图8中，最终将调用connect函数去连接指定的设备。connect函数比较中，其中最重要的是updateConnection函数，我们抽取其中部分代码来看，如图9所示：

        在图9所示的代码中，系统创建了一个RemoteDisplay，并在这个Display上监听（listen）。从注释中可知， 该RemoteDisplay就是和远端Device交互的RTP/RTSP通道。而且， 一旦有远端Device连接上，还会通过onDisplayConnected返回一个Surface对象。
（3）根据前面对SurfaceFlinger的介绍，读者可以猜测出 Miracast的重头好戏就在RemoteDisplay以及它返回的这个Surface上了。
确实如此， RemoteDisplay将调用MediaPlayerService的listenForRemoteDisplay函数，最终会得到一个Native的RemoteDisplay对象。相关类图如图10所示。

由图10可知，RemoteDisplay有三个重要成员变量：
（1）mLooper，指向一个ALooper对象。这表明RemoteDisplay是一个基于消息派发和处理的系统。
（2）mNetSession指向一个ANetWorkSession对象。从它的API来看，ANetworkSession提供大部分的网络操作。
（3）mSource指向一个WifiDisplaySource对象。它从AHandler派生，故它就是mLooper中消息的处理者。注意，图中的M1、M3、M5等都是Wi-Fi Display技术规范中指定的消息名。
RemoteDisplay构造函数中，WifiDisplaySource的start函数将被调用。如此，一个类型为kWhatStart的消息被加到消息队列中。该消息最终被WifiDisplaySource处理，结果是一个RTSPServer被创建。代码如图11所示：

        以后，客户端发送的数据都将通过类型为kWhatRTSPNotify的消息加入到系统中来。而这个消息的处理核心在onReceiveClientData函数中，它囊括了设备之间网络交互的所有细节。其核心代码如图12所示：

设备之间的交互将由Session来管理。在代码中，Session的概念由WifiSource的内部类PlaybackSession来表示。

        Android Miracast的实现中，需要重点理解SurfaceFlinger和RemoteDisplay模块。这部分的实现不仅代码量大，而且类之间，以及线程之间关系复杂。其他需要注意的点就是DisplayManagerService及相关模块。这部分内容在SDK中有相关API。应用开发者应关注这些新API是否能帮助自己开发出更有新意的应用程序。