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的支撐體系結構
由圖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 Miracast的四種拓撲結構
圖2所示內容比較簡單,此處就不再詳述。另外,在Wi-Fi Display規範中,還存在著Source將Video和Audio內容分別傳送給不同Render Device的情況。感興趣的讀者可參考Wi-Fi Display技術規範。
另外,Miracast對所支持的視音頻格式也進行了規定,如表1所示。
表1 Miracast 視音頻格式支持
解析度 | 17種 CEA格式,解析度從640*480到1920*1080,幀率從24到60 29種VESA格式,解析度從800*600到1920*1200,幀率從30到60 12種手持設備格式,解析度從640*360到960*540,幀率從30到60 |
視頻 | H.264高清 |
音頻 | 必選:LPCM 16bits,48kHz採樣率,雙聲道 可選: LPCM 16bits,44.1kHz採樣率,雙聲道 Advanced Audio coding Dolby Advanced Codec 3 |
最後,我們簡單介紹一下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 SurfaceFlinger代碼片段
由圖4代碼可知:
- 對於非Virtual設備,DisplayDevice的FrameBufferSurface不為空。而且SurfaceTextureClient的構造參數來自於FrameBufferSurface的getBufferQueue函數。
- 如果是Virtual設備,SurfaceTextureClient直接使用了State信息中攜帶的surface變數。
憑著上面這兩點不同,我們可以推測出如圖5所示的DisplayDevice的作用
圖5 DisplayDevice的隔離示意圖
最後再來看一下SurfaceFlinger中混屏操作的實現,代碼如圖6所示:
圖6 SurfaceFilnger的混屏操作
由圖5可知,SurfaceFlinger將遍歷系統中所有的DisplayDevice來完成各自的混屏工作。
2.2 Framework對Miracast的支持
為了徹底解決多顯示設備的問題,Android 4.2乾脆在Framework中新增了一個名為DisplayManagerService的服務,用來統一管理系統中的顯示設備。DisplayManagerService和系統其它幾個服務都有交互。整體結構如圖7所示。
圖7 DisplayManagerService及相關類圖
由圖7可知:
- DisplayManagerService主要實現了IDisplayManager介面。這個介面的大部分函數都和Wi-Fi Display操作相關。
- 另外,DisplayManagerService和WindowManagerService交互緊密。因為WindowManagerService管理系統所有UI顯示,包括屬性,Z軸位置等等。而且,WindowManagerService是系統內部和SurfaceFlinger交互的重要通道。
- DisplayManagerService通過mDisplayAdapters來和DisplayDevice交互。每一個DisplayDevice都對應有一個DisplayAdapter。
- 系統定義了四種DisplayAdapter。HeadlessDisplayAdapter和OverlayDisplayAdapter針對的都是Fake設備。其中OverlayDisplay用於幫助開發者模擬多屏幕之用。LocalDisplayAdapter代表主屏幕,而WifiDisplayAdapter代表Wi-Fi Display。
2.3 Android中Miracast動態工作流程介紹
當用戶從Settings程序中選擇開啟Miracast並找到匹配的Device后,系統將通過WifiDisplayController的