Android Wi-Fi Display(Miracast)介绍
Android Wi-Fi Display(Miracast)
介绍2012年11月中旬,Google发布了Android 4.2。虽然它和Android 4.1同属Jelly Bean系列,但却添加了很多新的功能。其中,在显示部分,Android 4.2在Project Butter基础上再接再厉,新增了对Wi-Fi Display功能的支持。由此也导致整个显示架构发生了较大的变化。
本文首先介绍Wi-Fi Display的背景知识,然后再结合代码对Android 4.2中Wi-Fi Display的实现进行介绍。
一背景知识介绍
Wi-Fi Display经常和Miracast联系在一起。实际上,Miracast是Wi-Fi联盟(Wi-Fi Alliance)对支持Wi-Fi Display功能的设备的认证名称。通过Miracast认证的设备将在最大程度内保持对Wi-Fi Display功能的支持和兼容。由此可知,Miracast考察的就是Wi-Fi Display(本文后续将不再区分Miracast和Wi-Fi Display)。而Wi-Fi Display的核心功能就是让设备之间通过Wi-Fi无线网络来分享视音频数据。以一个简单的应用场景为例:有了Wi-Fi Display后,手机和电视机之间可以直接借助Wi-Fi,而无需硬连线(如HDMI)就可将手机中的视频投递到TV上去显示[①]。以目前智能设备的发展趋势来看,Wi-Fi Display极有可能在较短时间内帮助我们真正实现多屏互动。
从技术角度来说,Wi-Fi Display并非另起炉灶,而是充分利用了现有的Wi-Fi技术。图1所示为Wi-Fi Display中使用的其他Wi-Fi技术项。
由图1可知,Miracast依赖的Wi-Fi技术项[②]有:
Wi-Fi Direct,也就是Wi-Fi P2P。它支持在没有AP(Access Point)的情况下,两个Wi-Fi设备直连并通信。
Wi-Fi Protected Setup:用于帮助用户自动配置Wi-Fi网络、添加Wi-Fi设备等。
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来说最重要的是两个基础技术:
Wi-Fi Direct:该功能由Android中的WifiP2pService来管理和控制。
Wi-Fi Multimedia:为了支持Miracast,Android 4.2对MultiMedia系统也进行了修改。
下边我们对Miracast几个重要知识点进行介绍,首先是拓扑结构和视音频格式方面的内容。
Miracast一个重要功能就是支持Wi-Fi Direct。但它也考虑了无线网络环境中存在AP设备的情况下,设备之间的互联问题。读者可参考如图2所示的四种拓扑结构。
图2所示内容比较简单,此处就不再详述。另外,在Wi-Fi Display规范中,还存在着Source将Video和Audio内容分别传送给不同Render Device的情况。感兴趣的读者可参考Wi-Fi Display技术规范。
另外,Miracast对所支持的视音频格式也进行了规定,如表1所示。
表1 Miracast 视音频格式支持
最后,我们简单介绍一下Miracast的大体工作流程。Miracast以session为单位来管理两个设备之间的交互的工作,主要步骤包括(按顺序):
Device Discovery:通过Wi-Fi P2P来查找附近的支持Wi-Fi P2P的设备。
Device Selection:当设备A发现设备B后,A设备需要提示用户。用户可根据需要选择是否和设备B配对。
Connection Setup:Source和Display设备之间通过Wi-Fi P2P建立连接。根据Wi-Fi Direct技术规范,这个步骤包括建立一个Group Owner和一个Client。此后,这两个设备将建立一个TCP连接,同时一个用于RTSP协议的端口将被创建用于后续的Session管理和控制工作。
Capability Negotiation:在正式传输视音频数据前,Source和Display设备需要交换一些Miracast参数信息,例如双方所支持的视音频格式等。二者协商成功后,才能继续后面的流程。
Session Establishment and streaming:上一步工作完成后,Source和Display设备将建立一个Miracast Session。而后就可以开始传输视音频数据。Source端的视音频数据将经由MPEG2TS编码后通过RTP协议传给Display设备。Display设备将解码收到的数据,并最终显示出来。
User Input back channel setup:这是一个可选步骤。主要用于在传输过程中处理用户发起的一些控制操作。这些控制数据将通过TCP在Source和Display设备之间传递。
Payload Control:传输过程中,设备可根据无线信号的强弱,甚至设备的电量状况来动态调整传输数据和格式。可调整的内容包括压缩率,视音频格式,分辨率等内容。
Session teardown:停止整个Session。
通过对上面背景知识的介绍,读者可以发现:
Miracast本质就是一个基于Wi-Fi的网络应用。这个应用包括服务端和客户端。
服务端和客户端必须支持RTP/RTSP等网络协议和相应的编解码技术。
二 Android 4.2 Miracast功能实现介绍
Miracast的Android实现涉及到系统的多个模块,包括:
MediaPlayerService及相关模块:原因很明显,因为Miracast本身就牵扯到RTP/RTSP及相应的编解码技术。
SurfaceFlinger及相关模块:SurfaceFlinger的作用是将各层UI数据混屏并投递到显示设备中去显示。现在,SurfaceFlinger将支持多个显示设备。而支持Miracast的远端设备也做为一个独立的显示设备存在于系统中。
WindowManagerService及相关模块:WindowManagerService用于管理系统中各个UI层的位置和属性。由于并非所有的UI层都会通过Miracast投递到远端设备上。例如手机中的视频可投递到远端设备上去显示,但假如在播放过程中,突然弹出一个密码输入框(可能是某个后台应用程序发起的),则这个密码输入框就不能投递到远端设备上去显示。所以,WindowManagerService也需要修改以适应Miracast的需要。
DisplayManagerService及相关模块:DisplayManagerService服务是Android 4.2新增的,用于管理系统中所有的Display设备。
由于篇幅原因,本文将重点关注SurfaceFlinger和DisplayManagerService以及Miracast的动态工作流程。
2.1 SurfaceFlinger对Miracast的支持
相比前面的版本,Android 4.2中SurfaceFlinger的最大变化就是增加了一个名为DisplayDevice的抽象层。相关结构如图3所示:
图3 SurfaceFlinger家族类图
由图3可知:
Surface系统定义了一个DisplayType的枚举,其中有代表手机屏幕的DISPLAY_PRIMARY和代表HDMI等外接设备的DISPLAY_EXTERNAL。比较有意思的是,作为Wi-Fi Display,它的设备类型是DISPLAY_VIRTUAL。
再来看SurfaceFlinger类,其内部有一个名为mDisplays的变量,它保存了系统中当前所有的显示设备(DisplayDevice)。另外,SurfaceFlinger通过mCurrentState和mDrawingState来控制显示层的状态。其中,mDrawingState用来控制当前正在绘制的显示层的状态,mCurrentState表示当前所有显示层的状态。有这两种State显示层的原因是不论是Miracast还是HDMI设备,其在系统中存在的时间是不确定的。例如用户可以随时选择连接一个Miracast显示设备。为了不破坏当前正在显示的内容,这个新显示设备的一些信息将保存到CurrentState中。等到SurfaceFlinger下次混屏前再集中处理。
mCurrentState和mDrawingState的类型都是SurfaceFlinger的内部类State。由图3可知,State首先通过layerSortedByZ变量保存了一个按Z轴排序的显示层数组(在Android中,显示层的基类是LayerBase),另外还通过displays变量保存了每个显示层对应的DisplayDeviceState。
DisplayDeviceState的作用是保存对应显示层的DisplayDevice的属性以及一个ISurfaceTexure接口。这个接口最终将传递给DisplayDevice。
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变量。
凭着上面这两点不同,我们可以推测出如图5所示的DisplayDevice的作用
三、总结
本文对Miracast的背景知识以及Android系统中Miracast的实现进行了一番简单介绍。从笔者个人角度来看,有以下几个点值得感兴趣的读者注意:
一定要结合Wi-Fi的相关协议去理解Miracast。重点关注的协议包括Wi-Fi P2p和WMM。
Android Miracast的实现中,需要重点理解SurfaceFlinger和RemoteDisplay模块。这部分的实现不仅代码量大,而且类之间,以及线程之间关系复杂。
其他需要注意的点就是DisplayManagerService及相关模块。这部分内容在SDK中有相关API。应用开发者应关注这些新API是否能帮助自己开发出更有新意的应用程序。
另外,Android的进化速度非常快,尤其在几个重要的功能点上。作者在此也希望国内的手机厂商或那些感兴趣的移动互联网厂商能真正投入力量做一些更有深度和价值的研发工作。