《Android下WiFiDisplay功能探究.docx》由会员分享，可在线阅读，更多相关《Android下WiFiDisplay功能探究.docx（23页珍藏版）》请在金锄头文库上搜索。
1、版权声明：本文为博主原创文章，未经博主允许不得转载。目录(?)-1. 1WiFiDisplay简介1. 2 WiFiDisplay重要规范及标准2. WiFi联盟定义了Miracast支持的视音频格式标准2. 主要模块介绍1. 1 WiFiP2P1. 11 WiFiP2P简介2. 12 Android中WiFiP2P2. Android下实现详述1. 32 DisplayManagerService及相关1. WiFiDisplay应用场景及相关产品1. 2 相关应用产品1. DLNA技术和AirPlay技术1. 2 AirPlay技术1WiFiDisplay简介1.1WiFiDisplay概
2、述 WiFiDisplay(WFD)是WiFi联盟在已有技术的基础上，为了加速视/音频的传输分享而提出来的一个新概念。WiFi联盟对此成立了一个认证项目：Miracast- 用来认证一个设备是否支持WiFiDisplay功能。 下图是WiFiDisplay功能的技术支撑体系，实际上最重要的部分就是WiFi Direct：也就是两个设备无需AP(AccessPoint)的情况下直接相连，这就奠定了两个带WiFi功能的设备能够随时传递高质/高清视频的前提。另外，其他深蓝色的技术是必须支持的：11n：即802.11n协议，支持最高传输速度540Mbit/s；WMM：即WiFi Multimedia的
3、简称，主要针对不同的数据内容保证其传输的稳定和质量；WPA2：是WiFi联盟对于采用802.11i协议并采用更为复杂加密算法的认证项目；WiFi ProtectedSteup：也是一个WiFi联盟的一个认证项目：简化用户安装无线局域网和对安全性能的配置工作；WiFi Direct：表示设备可以实现直接互联，无需AP的参与；WiFi Miracast：即为是否可以实现wifi-display功能的认证项目。图 1 WiFiDisplay技术支撑架构另外，WiFi联盟还描述了WiFiDisplay的简化工作模型(图2)。在这个工作模型中，Miracast定义传输视/音频数据的一方为source端；
4、接受数据并重新呈现的为sink端。从图中可以看到，source端要有数据内容的存储和下载/生成能力；对数据进行编码能力。而sink端则需要对数据的解码能力；对视/音频进行再度呈现的能力。而Miracast则是定义了这两个设备之间，怎样保持会话；可以传输数据的格式标准；会话控制等内容。图 2 WiFiDisplay的工作模型1.2 WiFiDisplay重要规范及标准 WiFi联盟定义了Miracast支持的视/音频格式标准：图 3 Miracast支持的显示、视频、音频格式标准同时，Miracast也规范了设备连接后进行协商(图4)、建立会话的流程(图5)。详细描述了设备在建立物理连接后，通过
5、标准步骤来完成WiFi Display的会话建立，然后开始数据传输。关于各个标准步骤的详细信息，请见Miracast官方解释。图 4 Miracast定义的设备协商标准过程图5 Miracast定义的显示会话建立过程标准2 主要模块介绍 由于WFD功能主要涉及wifiP2P功能和display功能，现对Android中涉及的两个模块wifiP2pService和SurfaceFlinger做一些介绍。2.1 WiFiP2P2.1.1 WiFiP2P简介 WiFiP2P是WiFi联盟提出的一项重要技术规范，它定义了两个wifi设备如何在没有路由的情形下连接并通信。根据定义，支持WiFiP2P的设
6、备需要扮演P2P GroupOwner或P2P Client角色来形成一个P2P Group：图6 WiFiP2P工作组模型其中P2P Group Owner的设备需要发挥传统路由的功能：控制WiFiP2P工作组，使能设备通信等；P2PClient设备则需要连接上P2P Group Owner设备来形成一个工作组来通信。 在以上的工作模型基础上，WiFiP2P细化了以下技术项：图7 WiFiP2P定义的P2PDiscovery规范在P2P Discovery规范中，定义了发现设备(Device Discovery )并构建工作组(GroupFormation )的细节。其中发现设备规定设备首先
7、进入扫描阶段(ScanPhase)，去发送Probe Request帧；然后进入寻找阶段(Find Phase)，在这个阶段中设备会在SearchState和Listen State中切换：两个阶段分别是发送Probe Request帧、监听ProbeRequest帧并发送Probe Response帧。当找到附近的P2P设备后，就可以来构建一个工作组：包括决定谁是Group Owner的协商(GONegotiation )和设备交换安全配置信息(Provisioning)，用于Client设备利用安全配置信息连接GO。 另外，WiFiP2P还定义了GroupOperation技术项，具体描述
8、了和工作组交互的场景和流程：P2P Device Join GO(Group Owner)P2P Device Join GC(Group Client)GC invite P2P DeviceGO invite P2P Device 2.12 Android中WiFiP2P Android中关于WiFiP2P模块主要涉及以下几个部分：图8 Android中WiFiP2P涉及模块WiFiP2PSettings 是用来和用户交互的部分，主要是提供UI给用户选择打开/开闭WiFiP2P功能、呈现搜寻到的P2P设备给用户等；WiFiP2PSettings实现的功能调用的是WiFiP2PManager
9、中的接口；WiFiP2PManager最终会与WiFiP2PService交互，它们依靠Android的Binder机制来实现进程间的通信，WiFiP2PService则是用来管理Android中WiFiP2P功能的核心模块：图9 Android中WiFiP2P涉及模块在WiFiP2PService类中有一个内部类P2pStateMachine(状态机)用来管理WiFiP2P的不同状态然后执行不同的操作；另外WiFiP2PService还会创建一个WifiMonitor对象用于接收来自wpa_supplicant的消息并根据接收到的消息给P2pStateMachine传值来推动状态机的工作。从
10、图中可以看到，WiFiP2PService或WifiMonitor交互的是WiFiNative.Java中的接口，这里面的都是一些native函数；这是因为wap_supplicant进程是C语言实现，Android是通过JNI机制调用android_net_wifi_Wifi.cpp 里面的本地接口，这些本地接口来最终和wpa_supplicant交互(wifi.c里面是对发送到wpa_supplicant里面消息的封装)。 wpa_supplicant是一个开源项目，实现了WiFi联盟规范中的众多功能，详见官方文档。下图是wpa_supplicant及与下层部件的一个草图：图10 wpa_
11、supplicant及底层部件草图2.2 SurfaceFlinger 总所周知，SurfaceFlinger是Android中对图形画面进行管理并交由FrameBuffer实际显示的重要模块，它需要收集系统中所有应用程序绘制的图像数据，然后集中处理后显示到物理屏幕上。下图是Android下图形显示的一个简略框图：图11 Android显示系统简略框图上图描述的是使用OpenGL ES图形开发规范下的情况。首先，每个应用程序在自己的窗口上进行绘图，这里的窗口(Window-2)实际上对应的是一些缓冲区；然后SurfaceFlinger则会对这些缓冲区进行统一管理；最后每一帧的图形数据会被送到F
12、rameBuffer上并实际显示在设备上。 对于上层应用来说，Window-2在Android中的实现为SurfaceTextureClient类。由于是在OpenGL ES的开发框架下，SurfaceTextureClient实际上是继承自ANativeWindow同时在本地实现了一些接口(参见EGL知识)：图12 上层应用的window实现hook_dequeueBuffer()和hook_queueBuffer()是框架定义中需要实现的本地函数，上层应用作图时需要从缓冲队列得到缓冲区；作图完成后需要把缓冲区送还给缓冲队列。具体情形如下：图13 本地窗口和缓冲队列交互图如上图，本地窗口实际
13、上是从BufferQueue来得到缓冲区；画图后再将缓冲区入列到缓冲队列。而BufferQueue是在应用程序创建Surface(在SurfaceFlinger端对应Layer)的时候生成的，本地窗口通过返回的ISurface对象得到ISurfaceTexture对象来最终和BufferQueue交互。 对于SurfaceFlinger侧的本地窗口Window-1(图11)来说，SurfaceTextureClient也是作为本地窗口的功能。不过在SurfaceFlinger端通过标准的OpenGL ES接口进行请求缓冲区操作和入列缓冲区操作的对象就不一样了；而且在入列缓冲区后所进行的操作也不
14、一样：图14 SurfaceFlinger的本地窗口如上图，在SurfaceFlinger端的本地窗口Window-1，会有自己的BufferQueue对象，而最终和HAL层的Gralloc模块交互实际分配缓冲区的时候，会根据功用不同来分配不同类型的缓冲区：上层应用分配的缓冲区是给OpenGL绘图用的；SurfaceFlinger这边分配的缓冲区是要送显FrameBuffer的(详见gralloc.h中定义)。 对于上层应用来说，填充好缓冲区后处理端(consumer&producter模型)会调用到Layer文件的onFrameQueued()函数，如果需要渲染图形这时候需要等待一个VSYN
15、C信号(详见Android的Project Butter)，收到VSYNC信号后会对需要渲染的Buffer按照Z轴计算可见区域并进行图像混合；而对于SurfaceFlinger端来说，缓冲区入列后consumer会最终调用fb的HAL层接口完成实际显示。3 Android下实现详述 Android自从4.2后就支持WiFiDisplay功能了。以下是Miracast官方公布的WFD工作模块框图：图15WiFiDisplay的工作模块框图在以上工作模型的基础上，Android主要做了以下工作：新加了WiFiDisplay的setting部分，用来为用户提供操作选项；新加DisplayDevice类用来描述不同的显示设备，WiFiDisplay作为一个虚拟显示设备；修改了SurfaceFlinger模块来支持WiFiDisplay，通过SF把显示内容投放到不同的设备上；新加了DisplayManagerService来对系统的显示设备进行统一管理根据Miracast规定的会话建立管理流程，实现了source端和sink端的程序3.1 应用程序端 对于WiFiDisplay功能，Android提供
