Android 4.2 Wifi Display 之 Settings 源碼分析（一）

2015-10-13 20:24

指針空間

閱讀(1359)

評論(0)

編輯

舉報

一、簡單背景

簡單背景：随着無線互聯的深入，不管是藍牙、WIFI或者各種基于此的規範不管是UPNP還是DLNA都随着使用者的需求得到了很大的發展，google 自從android 4.0引入wifi direct後，又在11月份公布的android 4.2中引入了Miracast無線顯示共享，其協定在此可以下載下傳。具體的協定部分内容比較多，本人由于水準有限，就不在這裡羅列協定的内容了，隻附上一份架構圖供大家對其有個大緻的印象。

Android 4.2 Wifi Display 之 Settings 源碼分析（一） - 指針空間

英文縮寫對應如下：

HIDC: Human Interface Device Class

UIBC: User Input Back Channel

PES: Packetized Elementary Stream

HDCP: High-bandwidth Digital Content Protection

MPEG2-TS: Moving Picture Experts Group 2 Transport Stream

RTSP: Real-Time Streaming Protocol

RTP: Real-time Transport Protocol

Wi-Fi P2P: Wi-Fi Direct

TDLS: Tunneled Direct Link Setup

二、應用層簡介

好了，接下來首先來看一看android 4.2 提供了哪些與其相關的應用：

首先，需要注意的自然是API文檔中公布的 http://developer.android.com/about/versions/android-4.2.html#SecondaryDisplays

Presentation應用，在源碼中路徑為：development/samples/ApiDemos/src/com/example/android/apis/app/下面的兩個檔案

PresentationActivity.java

以及 PresentationWithMediaRouterActivity.java 。

這兩個應用所使用的Presentation基類在frameworks/base/core/java/android/app/Presentation.java，可以看到其繼承了dialog類，并複用了如show()以及cancel()函數。

由于官方文檔已經有了關于Presentation以及MediaRouter的簡要介紹，這裡先不再結合framework層詳細介紹，以後有機會一并再結合源碼分析一下。

簡單來說，Display Manager 可以列舉出可以直連顯示的多個裝置，MediaRouter提供了快速獲得系統中用于示範（presentations）預設顯示裝置的方法。可以利用

frameworks/base/media/java/android/media/MediaRouter.java下的getSelectedRoute（int type){ }函數來獲得目前所選擇type類型的Router資訊。對于PresentationWithMediaRouterActivity應用而言，

[java] view plaincopy

MediaRouter mMediaRouter = (MediaRouter) context.getSystemService(Context.MEDIA_ROUTER_SERVICE);
MediaRouter.RouteInfo route = mMediaRouter.getSelectedRoute(MediaRouter.ROUTE_TYPE_LIVE_VIDEO);
Display presentationDisplay = route != null ? route.getPresentationDisplay() : null;

可以看到這裡傳入的是ROUTE_TYPE_LIVE_VIDEO類型，供其擷取已選擇的route資訊。之後，則是判斷route資訊是否為空，如果不為空則傳回被選擇示範（presentation）裝置。值得一提的是，該方法隻對 route資訊類型為ROUTE_TYPE_LIVE_VIDEO有效。

接下來，隻要将該Display對象作為自己重構的示範（Presentation）類構造函數參數傳入，這樣自己重構的示範就會出現在第二個顯示裝置上。

[java] view plaincopy

mPresentation = new DemoPresentation(this, presentationDisplay);
...
try {
mPresentation.show();
} catch (WindowManager.InvalidDisplayException ex) {
Log.w(TAG, "Couldn\'t show presentation! Display was removed in "
+ "the meantime.", ex);
mPresentation = null;
}
}
...

[java] view plaincopy

private final static class DemoPresentation extends Presentation {
...
public DemoPresentation(Context context, Display display) {
super(context, display);
}
...
}

為了進一步優化附加顯示裝置自定義示範UI的顯示效果，你可以在<style>屬性中指定相關應用主題為android:presentationTheme。

為了在運作時檢測外設顯示裝置的連接配接狀态，你需要在自己的實作類中建立一個 MediaRouter.SimpleCallback的一個執行個體，該執行個體中需要自己實作onRoutePresentationDisplayChanged() 等回調函數。當一個新的示範顯示裝置連接配接時，系統就會回調該函數，進一步其就會調用上面提到的MediaRouter.getSelectedRoute()函數。

[java] view plaincopy

private final MediaRouter.SimpleCallback mMediaRouterCallback =
new MediaRouter.SimpleCallback() {
public void onRouteSelected(MediaRouter router, int type, RouteInfo info) {
updatePresentation();
}
public void onRouteUnselected(MediaRouter router, int type, RouteInfo info) {
updatePresentation();
}
public void onRoutePresentationDisplayChanged(MediaRouter router, RouteInfo info) {
updatePresentation();
}
};

當然，使用者需要使用MediaRouter.addCallback()函數完成注冊，如同在PresentationWithMediaRouterActivity應用中，

[java] view plaincopy

mMediaRouter.addCallback(MediaRouter.ROUTE_TYPE_LIVE_VIDEO, mMediaRouterCallback);

這裡可以簡單看看調用流程，首先可以看到onRoutePresentationDisplayChanged()回調函數在MediaRouter.java會先觸發dispatchRoutePresentationDisplayChanged()函數，

frameworks/base/media/java/android/media/MediaRouter.java

[java] view plaincopy

static void dispatchRoutePresentationDisplayChanged(RouteInfo info) {
for (CallbackInfo cbi : sStatic.mCallbacks) {
if ((cbi.type & info.mSupportedTypes) != 0) {
cbi.cb.onRoutePresentationDisplayChanged(cbi.router, info);
}
}
}

進一步可以看到該分發函數被用于更新示範裝置的狀态，并将其提供給frameworks/base/core/java/android/app/Presentation.java中注冊的監聽函數，

frameworks/base/media/java/android/media/MediaRouter.java

[java] view plaincopy

private void updatePresentationDisplays(int changedDisplayId) {
final Display[] displays = getAllPresentationDisplays();
final int count = mRoutes.size();
for (int i = 0; i < count; i++) {
final RouteInfo info = mRoutes.get(i);
Display display = choosePresentationDisplayForRoute(info, displays); //根據displays的位址資訊從所有顯示類型為Presentation displays的裝置中選擇對應的顯示裝置
if (display != info.mPresentationDisplay
|| (display != null && display.getDisplayId() == changedDisplayId)) {
info.mPresentationDisplay = display;
dispatchRoutePresentationDisplayChanged(info);
}
}
}

[java] view plaincopy

@Override
public void onDisplayAdded(int displayId) {
updatePresentationDisplays(displayId);
}
@Override
public void onDisplayChanged(int displayId) {
updatePresentationDisplays(displayId);
}
@Override
public void onDisplayRemoved(int displayId) {
updatePresentationDisplays(displayId);
}

frameworks/base/core/java/android/app/Presentation.java

[java] view plaincopy

@Override
protected void onStart() {
super.onStart();
mDisplayManager.registerDisplayListener(mDisplayListener, mHandler);// Presentation線程一啟動就會注冊Display Manager中負責監聽示範裝置變化的三個監聽器
...
}

[java] view plaincopy

private final DisplayListener mDisplayListener = new DisplayListener() {
@Override
public void onDisplayAdded(int displayId) {
}
@Override
public void onDisplayRemoved(int displayId) {
if (displayId == mDisplay.getDisplayId()) {
handleDisplayRemoved();
}
}
@Override
public void onDisplayChanged(int displayId) {
if (displayId == mDisplay.getDisplayId()) {
handleDisplayChanged();
}
}
};

該注冊函數的實作實際是在DisplayManagerGlobal類中，該類主要負責管理顯示管理器(Display Manager)與顯示管理服務(Display Manager Service)之間的通信。

frameworks/base/core/java/android/hardware/display/DisplayManagerGlobal.java

[java] view plaincopy

public void registerDisplayListener(DisplayListener listener, Handler handler) {
if (listener == null) {
throw new IllegalArgumentException("listener must not be null");
}
synchronized (mLock) {
int index = findDisplayListenerLocked(listener);
if (index < 0) {
mDisplayListeners.add(new DisplayListenerDelegate(listener, handler)); //給動态數組中增添顯示監聽處理代理
registerCallbackIfNeededLocked(); //實際負責注冊回調函數的方法
}
}
}

[java] view plaincopy

private void registerCallbackIfNeededLocked() {
if (mCallback == null) {
mCallback = new DisplayManagerCallback();
try {
mDm.registerCallback(mCallback);
} catch (RemoteException ex) {
Log.e(TAG, "Failed to register callback with display manager service.", ex);
mCallback = null;
}
}
}

可以看到，registerCallbackIfNeededLocked()函數中建立的回調函數實際上是IDisplayManagerCallback的AIDL接口實作，

[java] view plaincopy

private final class DisplayManagerCallback extends IDisplayManagerCallback.Stub {
@Override
public void onDisplayEvent(int displayId, int event) {
if (DEBUG) {
Log.d(TAG, "onDisplayEvent: displayId=" + displayId + ", event=" + event);
}
handleDisplayEvent(displayId, event);
}
}

frameworks/base/core/java/android/hardware/display/IDisplayManagerCallback.aidl

[java] view plaincopy

package android.hardware.display;
/** @hide */
interface IDisplayManagerCallback {
oneway void onDisplayEvent(int displayId, int event);
}

之後則是将建立的mCallback作為參數傳入IDisplayManager中的registerCallback(in IDisplayManagerCallback callback)；接口函數中。

最後，來看看與IDisplayManager AIDL接口對應的Service實作。

frameworks/base/services/java/com/android/server/display/DisplayManagerService.java

[java] view plaincopy

@Override // Binder call
public void registerCallback(IDisplayManagerCallback callback) {
if (callback == null) {
throw new IllegalArgumentException("listener must not be null");
}
synchronized (mSyncRoot) {
int callingPid = Binder.getCallingPid();
if (mCallbacks.get(callingPid) != null) {
throw new SecurityException("The calling process has already "
+ "registered an IDisplayManagerCallback.");
}
CallbackRecord record = new CallbackRecord(callingPid, callback);
try {
IBinder binder = callback.asBinder();
binder.linkToDeath(record, 0);
} catch (RemoteException ex) {
// give up
throw new RuntimeException(ex);
}
mCallbacks.put(callingPid, record);
}
}

可以看到該服務采取同步機制，這是因為display manager可能同時被多個線程通路，這裡所有屬于display manager的對象都會使用同一把鎖。本服務将該鎖稱為同步root，其有唯一的類型DisplayManagerService.SyncRoot，所有需要該鎖的方法都會以“Locked"作為字尾。另外，CallbackRecord函數會綁定IDisplayManagerCallback接口。并且通過函數notifyDisplayEventAsync( )向回調函數提供顯示事件通知，事件類型分為三類EVENT_DISPLAY_ADDED，EVENT_DISPLAY_CHANGED以及EVENT_DISPLAY_REMOVED等。

函數notifyDisplayEventAsync( )會在DisplayManager處理線程DisplayManagerHandler中，當msg類型為MSG_DELIVER_DISPLAY_EVENT時被函數deliverDisplayEvent( )調用。進一步而言，類型為MSG_DELIVER_DISPLAY_EVENT的消息，是由函數void sendDisplayEventLocked(int displayId, int event)發送的。該函數的使用者addLogicalDisplayLocked（）以及 updateLogicalDisplaysLocked( )正好通過sendDisplayEventLocked( )将顯示裝置ID displayid 與三種顯示事件類型聯系在了一起。最後正是函數handleDisplayDeviceAdded( )、handleDisplayDeviceChanged()以及handleDisplayDeviceRemoved()将顯示裝置的變化狀态通過注冊在顯示管理服務中的監聽器DisplayAdapter.Listener以異步方式傳遞給Display adapter。

[java] view plaincopy

private final class DisplayAdapterListener implements DisplayAdapter.Listener {
@Override
public void onDisplayDeviceEvent(DisplayDevice device, int event) {
switch (event) {
case DisplayAdapter.DISPLAY_DEVICE_EVENT_ADDED:
handleDisplayDeviceAdded(device);
break;
case DisplayAdapter.DISPLAY_DEVICE_EVENT_CHANGED:
handleDisplayDeviceChanged(device);
break;
case DisplayAdapter.DISPLAY_DEVICE_EVENT_REMOVED:
handleDisplayDeviceRemoved(device);
break;
}
}
...
}

這樣将服務與顯示裝置擴充卡分離的做法有兩方面優點，其一方面簡潔的封裝了兩個類的不同職責：顯示擴充卡負責處理各個顯示裝置而顯示管理服務則負責處理全局的狀态變化；另一方面，其将會避免在異步搜尋顯示裝置時導緻的死鎖問題。

接下來，讓我們進入正題，來通過WiFi Display Setting應用來大緻分析一下Wifidisplay具體的流程，其在源碼目錄下

packages/apps/Settings/src/com/android/settings/wfd/WifiDisplaySettings.java

關于此應用的細節這裡就不再詳述，我們首先來看Wifi Display 的裝置發現，這裡首先需要檢視Wifi Display的裝置狀态，通過調用getFeatureState()可以獲得進行該操作的裝置是否可以支援Wifi Display，以及該功能是否被使用者使能等資訊。如果此時的裝置狀态表示Widfi display功能已經開啟，那麼就開始進行裝置發現

[java] view plaincopy

if (mWifiDisplayStatus.getFeatureState() == WifiDisplayStatus.FEATURE_STATE_ON) {
mDisplayManager.scanWifiDisplays();
}

在搜尋完裝置後，使用者可以選擇裝置進行連接配接，當然正在進行連接配接或已經連接配接配對的裝置，再次點選配置後，會彈出對話框供使用者選擇斷開連接配接。

[java] view plaincopy

public boolean onPreferenceTreeClick(PreferenceScreen preferenceScreen,
Preference preference) {
if (preference instanceof WifiDisplayPreference) {
WifiDisplayPreference p = (WifiDisplayPreference)preference;
WifiDisplay display = p.getDisplay();
if (display.equals(mWifiDisplayStatus.getActiveDisplay())) {
showDisconnectDialog(display);
} else {
mDisplayManager.connectWifiDisplay(display.getDeviceAddress());
}
}
return super.onPreferenceTreeClick(preferenceScreen, preference);
}

最後，該應用還提供對裝置重命名以及剔除Wifi Display 裝置連接配接曆史資訊的方法。

三、Frameworks層分析

首先，從應用層的裝置發現來往下分析，我們容易看到，如同對上面PresentationWithMediaRouterActivity應用的分析，這裡采取的也是AIDL程序間通信方式。來看一看接口定義檔案，

frameworks/base/core/java/android/hardware/display/IDisplayManager.aidl

[java] view plaincopy

package android.hardware.display;
import android.hardware.display.IDisplayManagerCallback;
import android.hardware.display.WifiDisplay;
import android.hardware.display.WifiDisplayStatus;
import android.view.DisplayInfo;
/** @hide */
interface IDisplayManager {
DisplayInfo getDisplayInfo(int displayId);
int[] getDisplayIds();
void registerCallback(in IDisplayManagerCallback callback);
// No permissions required.
void scanWifiDisplays();
// Requires CONFIGURE_WIFI_DISPLAY permission to connect to an unknown device.
// No permissions required to connect to a known device.
void connectWifiDisplay(String address);
// No permissions required.
void disconnectWifiDisplay();
// Requires CONFIGURE_WIFI_DISPLAY permission.
void renameWifiDisplay(String address, String alias);
// Requires CONFIGURE_WIFI_DISPLAY permission.
void forgetWifiDisplay(String address);
// No permissions required.
WifiDisplayStatus getWifiDisplayStatus();
}

可以看到，該接口中定義了DisplayManger所需要互動的全部函數，包括裝置發現和裝置連接配接等函數。DisplayManager是根據DisplayManagerGlobal提供的單執行個體來通路相應的接口函數，并與Display manager service建立起聯系。以下是DisplayManagerGlobal提供的擷取其單例模式的函數，

frameworks/base/core/java/android/hardware/display/DisplayManagerGlobal.java

[java] view plaincopy

public static DisplayManagerGlobal getInstance() {
synchronized (DisplayManagerGlobal.class) {
if (sInstance == null) {
IBinder b = ServiceManager.getService(Context.DISPLAY_SERVICE);
if (b != null) {
sInstance = new DisplayManagerGlobal(IDisplayManager.Stub.asInterface(b));
//擷取DISPLAY_SERVICE服務代理并用于填充構造函數
}
}
return sInstance;
}
}
private final IDisplayManager mDm;
// AIDL接口對象
private DisplayManagerGlobal(IDisplayManager dm)
{
mDm = dm;
}
public void scanWifiDisplays() {
try {
mDm.scanWifiDisplays();
} catch (RemoteException ex) {
Log.e(TAG, "Failed to scan for Wifi displays.", ex);
}
}

frameworks/base/core/java/android/hardware/display/DisplayManager.java

[java] view plaincopy

public DisplayManager(Context context) {
mContext = context;
mGlobal = DisplayManagerGlobal.getInstance();
}
public void scanWifiDisplays() {
mGlobal.scanWifiDisplays();
}

接下來，再看一看scanWifiDisplays()在Display Manager Service中的實作，也就是AIDL接口的實際實作，

frameworks/base/services/java/com/android/server/display/DisplayManagerService.java

[java] view plaincopy

public final class DisplayManagerService extends IDisplayManager.Stub {
...
@Override // Binder call
public void scanWifiDisplays() {
final long token = Binder.clearCallingIdentity();
try {
synchronized (mSyncRoot) {
if (mWifiDisplayAdapter != null) {
mWifiDisplayAdapter.requestScanLocked();
}
}
} finally {
Binder.restoreCallingIdentity(token);
}
}
...
}

以上程式使用了mWifiDisplayAdapter對象，WifiDisplayAdapter類繼承于顯示擴充卡（DisplayAdapter），該類負責處理完成在連接配接到Wifi display裝置時與媒體服務、Surface Flinger以及顯示管理服務之間的各種互動及操作。在繼續分析WifiDisplayAdapter中的流程前，我們先來看看系統是啟動該服務的大緻流程，

首先在ServerThread.run中通過addService(Context.DISPLAY_SERVICE，…)來注冊該服務

frameworks/base/services/java/com/android/server/SystemServer.java

[java] view plaincopy

display = new DisplayManagerService(context, wmHandler, uiHandler);
ServiceManager.addService(Context.DISPLAY_SERVICE, display, true);

通過display.systemReady(safeMode,onlyCore)來初始化。

當系統屬性persist.debug.wfd.enable為1或config_enableWifiDisplay為1，并且不是核心模式和安全模式才進行初始化。該服務是displays的全局管理者，決定如何根據目前連結的實體顯示裝置來配置邏輯顯示器。當狀态發生變化時發送通知給系統和應用程式，等等。包括的擴充卡有OverlayDisplayAdapter，WifiDisplayAdapter，HeadlessDisplayAdapter，LocalDisplayAdapter。對于WifiDisplayAdapter而言，流程大緻如下圖所示，

接下來讓我們接着之前的流程繼續分析WifiDisplayAdapter中的發現裝置額的調用流程

frameworks/base/services/java/com/android/server/display/WifiDisplayAdapter.java

[java] view plaincopy

public void requestScanLocked() {
if (DEBUG) {
Slog.d(TAG, "requestScanLocked");
}
getHandler().post(new Runnable() {
@Override
public void run() {
if (mDisplayController != null) {
mDisplayController.requestScan();
}
}
});
}

可以看到此函數又調用了WifiDisplayController類中的requestScan()方法，值得注意的是WifiDisplayController對象必須在handler線程中執行個體化，該類負責處理控制在WifiDisplayAdapter與WifiP2pManager之間的各種異步操作。

frameworks/base/services/java/com/android/server/display/WifiDisplayController.java

[java] view plaincopy

public void requestScan() {
discoverPeers();
}
private void discoverPeers() {
if (!mDiscoverPeersInProgress) {
mDiscoverPeersInProgress = true;
mDiscoverPeersRetriesLeft = DISCOVER_PEERS_MAX_RETRIES; //嘗試發現配對裝置次數，預設值為10
handleScanStarted();
tryDiscoverPeers();
}
private void handleScanStarted() {
mHandler.post(new Runnable() {
@Override
public void run() {
mListener.onScanStarted(); //供WifiDisplayAdapter使用的監聽器接口函數
}
});
}
private void tryDiscoverPeers() {
mWifiP2pManager.discoverPeers(mWifiP2pChannel, new ActionListener() { //直接調用
WifiP2pManager接口
@Override
public void onSuccess() {
...
mDiscoverPeersInProgress = false;
requestPeers(); //獲得P2P已經配對的裝置在判斷是否是Wifidisplay裝置，如果是加入WifiP2pDevice動态數組中
}
@Override
public void onFailure(int reason) {
...
if (mDiscoverPeersInProgress)
{
if (reason == 0 && mDiscoverPeersRetriesLeft > 0 && mWfdEnabled)
{
mHandler.postDelayed(new Runnable()
{ @Override
public void run()
{
if (mDiscoverPeersInProgress)
{
if (mDiscoverPeersRetriesLeft > 0 && mWfdEnabled)
{
mDiscoverPeersRetriesLeft -= 1;
...
tryDiscoverPeers();
}
else {
handleScanFinished();
mDiscoverPeersInProgress = false;
}
}
}
}, DISCOVER_PEERS_RETRY_DELAY_MILLIS); //一次發現不成功後延時定長時間後繼續嘗試連接配接，遞歸函數
} else {
handleScanFinished();
mDiscoverPeersInProgress = false;
}
}
}
});
}

可以看到，這裡直接調用了void discoverPeers(Channel c, ActionListener listener){}函數，該函數發起WIFI對等點發現，該函數會收到發現成功或失敗的監聽回調。發現過程會一直保持到連接配接初始化完成或者一個P2P組建立完成。另外，在WifiDisplayController.java中可以看到還注冊了WifiP2pManager.WIFI_P2P_PEERS_CHANGED_ACTION這一intent，以确定當p2p peers更改時(即收到WIFI_P2P_PEERS_CHANGED_ACTION廣播後)，重新擷取Wifi Display配對清單，并結束裝置發現任務完成相應工作，該流程由函數requestPeers()完成

[java] view plaincopy

private void requestPeers() {
mWifiP2pManager.requestPeers(mWifiP2pChannel, new PeerListListener() {
@Override
public void onPeersAvailable(WifiP2pDeviceList peers) {
if (DEBUG) {
Slog.d(TAG, "Received list of peers.");
}
mAvailableWifiDisplayPeers.clear();
for (WifiP2pDevice device : peers.getDeviceList()) {
if (DEBUG) {
Slog.d(TAG, " " + describeWifiP2pDevice(device));
}
if (isWifiDisplay(device)) { //根據裝置wfdInfo來判斷其是否支援wifi display;并且判斷其裝置類型是否是主sink裝置
mAvailableWifiDisplayPeers.add(device);
}
}
handleScanFinished(); //結束裝置發現，對所有符合要求的wifidisplay裝置建立Parcelable對象
}
});
}

類似與handleScanStarted()函數，這裡結束裝置發現任務并且完成相應處理工作的函數handleScanFinished()，也開啟監聽線程。這些監聽線程将在WifiDisplayAdapter被注冊使用，

frameworks/base/services/java/com/android/server/display/WifiDisplayAdapter.java

[java] view plaincopy

private final WifiDisplayController.Listener mWifiDisplayListener =
new WifiDisplayController.Listener() {
@Override
public void onFeatureStateChanged(int featureState) {
synchronized (getSyncRoot()) {
if (mFeatureState != featureState) {
mFeatureState = featureState;
scheduleStatusChangedBroadcastLocked();
}
}
}
@Override
public void onScanStarted() {
synchronized (getSyncRoot()) {
if (mScanState != WifiDisplayStatus.SCAN_STATE_SCANNING) {
mScanState = WifiDisplayStatus.SCAN_STATE_SCANNING;
scheduleStatusChangedBroadcastLocked();
}
}
}
@Override
public void onScanFinished(WifiDisplay[] availableDisplays) {
synchronized (getSyncRoot()) {
availableDisplays = mPersistentDataStore.applyWifiDisplayAliases(
availableDisplays);
if (mScanState != WifiDisplayStatus.SCAN_STATE_NOT_SCANNING
|| !Arrays.equals(mAvailableDisplays, availableDisplays)) {
mScanState = WifiDisplayStatus.SCAN_STATE_NOT_SCANNING;
mAvailableDisplays = availableDisplays;
scheduleStatusChangedBroadcastLocked();
}
}
}
...
};

可以看到，這些監聽接口函數在觸發時，都會調用同一個函數scheduleStatusChangedBroadcastLocked()，

[java] view plaincopy

private final WifiDisplayHandler mHandler;
private void scheduleStatusChangedBroadcastLocked() {
mCurrentStatus = null;
if (!mPendingStatusChangeBroadcast) {
mPendingStatusChangeBroadcast = true;
mHandler.sendEmptyMessage(MSG_SEND_STATUS_CHANGE_BROADCAST);
}
}
private final class WifiDisplayHandler extends Handler {
public WifiDisplayHandler(Looper looper) {
super(looper, null, true /*async*/);
}
@Override
public void handleMessage(Message msg) {
switch (msg.what) {
case MSG_SEND_STATUS_CHANGE_BROADCAST:
handleSendStatusChangeBroadcast();
break;
...
}
}
}
}

函數scheduleStatusChangedBroadcastLocked()會向内類注冊的Handler處理函數發送MSG_SEND_STATUS_CHANGE_BROADCAST消息，處理函數接收到該消息後由handleSendStatusChangeBroadcast()向裝置上所有注冊過ACTION_WIFI_DISPLAY_STATUS_CHANGED這一intent的接受者發送WifiDisplayStatus廣播，

[java] view plaincopy

private void handleSendStatusChangeBroadcast() {
final Intent intent;
synchronized (getSyncRoot()) {
if (!mPendingStatusChangeBroadcast) {
return;
}
mPendingStatusChangeBroadcast = false;
intent = new Intent(DisplayManager.ACTION_WIFI_DISPLAY_STATUS_CHANGED);
intent.addFlags(Intent.FLAG_RECEIVER_REGISTERED_ONLY);
intent.putExtra(DisplayManager.EXTRA_WIFI_DISPLAY_STATUS,
getWifiDisplayStatusLocked());
}
// Send protected broadcast about wifi display status to registered receivers.
getContext().sendBroadcastAsUser(intent, UserHandle.ALL);
}

最後，我們來看看對于Wifi Display 裝置發現最後需要注意的一個部分，即在WifidisplayController中調用的WifiP2pManager中的discoverPeers()接口函數，

frameworks/base/wifi/java/android/net/wifi/p2p/WifiP2pManager.java

[java] view plaincopy

public void discoverPeers(Channel c, ActionListener listener) {
checkChannel(c);
c.mAsyncChannel.sendMessage(DISCOVER_PEERS, 0, c.putListener(listener));
}

當使用者在搜尋裝置時，該函數會向Channel中發送DISCOVER_PEERS信号，并注冊監聽器監聽響應結果。Channel的初始化在WifiDisplayController的構造函數中由函數Channel initialize(Context srcContext, Looper srcLooper, ChannelListener listener){}完成，該函數将P2phandler連接配接到P2p處理函數架構中。當裝置進入P2pEnabledState狀态中，并且處理函數接受到DISCOVER_PEERS信号後，真正調用WifiNative的接口函數p2pFind()，并且執行wifi_command()函數調用Wifi裝置底層的指令，

frameworks/base/wifi/java/android/net/wifi/p2p/WifiP2pService.java

[java] view plaincopy

clearSupplicantServiceRequest();
if (mWifiNative.p2pFind(DISCOVER_TIMEOUT_S)) {
replyToMessage(message, WifiP2pManager.DISCOVER_PEERS_SUCCEEDED);
sendP2pDiscoveryChangedBroadcast(true);
} else {
replyToMessage(message, WifiP2pManager.DISCOVER_PEERS_FAILED,
WifiP2pManager.ERROR);
}

如果p2pFind(int timeout)調用doBooleanCommand("P2P_FIND " + timeout)并且執行成功，則向先前連接配接的P2pHandler處理函數回複DISCOVER_PEERS_SUCCEEDED信号，并且調用監聽函數回調接口((ActionListener) listener).onSuccess()，回調WifidisplayController中的discoverPeers()函數做發現裝置成功後的獲得裝置清單工作即執行函數requestPeers()。最後，還會給在boot之前注冊的接收者發送WIFI_P2P_DISCOVERY_CHANGED_ACTION廣播。

至此，本文已經基本講清楚了Wifi Display在裝置發現時的基本調用流程，關于連接配接和開始傳送資料流等内容将會再下一回的内容讨論，謝謝關注！