Android 4.2中,Captive Portal Check功能集中在CaptivePortalTracker類中,而且它也是一個HSM。CaptivePortalTracker的創建位于ConnectivityService構造函數中。在那里,它的makeCaptivePortalTracker函數被調用。相關代碼如下所示:
**CaptivePortalTracker.java::makeCaptivePortalTracker**
~~~
public static CaptivePortalTracker makeCaptivePortalTracker(Context context,
IConnectivityManager cs) {
CaptivePortalTracker captivePortal = new CaptivePortalTracker(context, cs);
captivePortal.start();//啟動HSM
return captivePortal;
}
~~~
馬上來看CaptivePortalTracker的構造函數
**1、CaptivePortalTracker構造函數分析**
**CaptivePortalTracker.java::CaptivePortalTracker**
~~~
private CaptivePortalTracker(Context context, IConnectivityManager cs) {
super(TAG);
mContext = context;mConnService = cs;
mTelephonyManager = (TelephonyManager) context.getSystemService(
Context.TELEPHONY_SERVICE);
//注冊一個廣播接收對象,用于處理CONNECTIVITY_ACTION消息
IntentFilter filter = new IntentFilter();
filter.addAction(ConnectivityManager.CONNECTIVITY_ACTION);
mContext.registerReceiver(mReceiver, filter);
//CAPTIVE_PORTAL_SERVER用于設置進行Captive Portal Check測試的服務器地址
mServer = Settings.Global.getString(mContext.getContentResolver(),
Settings.Global.CAPTIVE_PORTAL_SERVER);
//如果沒有指明服務器地址的,則采用DEFAULT_SERVER,其地址是“clients3.google.com”
if (mServer == null) mServer = DEFAULT_SERVER;
//是否開啟Captive Portal Check功能,默認是開始
mIsCaptivePortalCheckEnabled = Settings.Global.getInt(mContext.getContentResolver(),
Settings.Global.CAPTIVE_PORTAL_DETECTION_ENABLED, 1) == 1;
addState(mDefaultState);//CaptivePortalTracker只有4個狀態
addState(mNoActiveNetworkState, mDefaultState);
addState(mActiveNetworkState, mDefaultState);
addState(mDelayedCaptiveCheckState, mActiveNetworkState);
setInitialState(mNoActiveNetworkState);
}
~~~
CaptivePortalTracker只監聽CONNECTIVITY_ACTION廣播,而WifiService相關模塊并不會發送這個廣播。那么,在前面介紹的流程中,哪一步會觸發CaptivePortalTracker進行工作呢?來看下節。
**2、CMD_CONNECTIVITY_CHANGE處理流程分析**
當Wifi網絡連接成功時,ConnectivityService的handleConnect將被觸發,該函數內部將發送一個CONNECTIVITY_ACTION消息。這個消息將被CaptivePortalTracker注冊的廣播接收對象處理。相關代碼如下所示:
**CaptivePortalTracker.java::onReceive**
~~~
private final BroadcastReceiver mReceiver = new BroadcastReceiver() {
public void onReceive(Context context, Intent intent) {
String action = intent.getAction();
if (action.equals(ConnectivityManager.CONNECTIVITY_ACTION)) {
NetworkInfo info = intent.getParcelableExtra(
ConnectivityManager.EXTRA_NETWORK_INFO);
//向狀態機發送CMD_CONNECTIVITY_CHANGE消息
sendMessage(obtainMessage(CMD_CONNECTIVITY_CHANGE, info));
}
}
};
~~~
CaptivePortalTracker的NoActiveNetworkState將處理該消息。相關代碼如下所示:
**CaptivePortalTracker.java::NoActiveNetworkState:processMessage**
~~~
public boolean processMessage(Message message) {
InetAddress server; NetworkInfo info;
switch (message.what) {
case CMD_CONNECTIVITY_CHANGE:
info = (NetworkInfo) message.obj;
//無線網絡已經連接成功,并且手機當前使用的就是Wifi。isActiveNetwork將查詢
//ConnectivityService以獲取當前活躍的數據鏈接類型
if (info.isConnected() && isActiveNetwork(info)) {
mNetworkInfo = info;
transitionTo(mDelayedCaptiveCheckState);//轉移到DelayedCaptiveCheckState
}
......
}
return HANDLED;
}
~~~
來看DelayedCaptiveCheckState。
**3、CMD_DELAYED_CAPTIVE_CHECK處理流程分析**
代碼如下所示:
**CaptivePortalTracker.java::DelayedCaptiveCheckState**
~~~
private class DelayedCaptiveCheckState extends State {
public void enter() {
//發送一個延遲消息,延遲時間為10秒
sendMessageDelayed(obtainMessage(CMD_DELAYED_CAPTIVE_CHECK,
++mDelayedCheckToken, 0), DELAYED_CHECK_INTERVAL_MS);
}
public boolean processMessage(Message message) {
switch (message.what) {
case CMD_DELAYED_CAPTIVE_CHECK:
if (message.arg1 == mDelayedCheckToken) {
InetAddress server = lookupHost(mServer);//獲取Server的ip地址
if (server != null) {
//AP是否需要Captive Portal Check。如果是的話,setNotificiationVisible
//將在狀態欄中添加一個提醒信息
if (isCaptivePortal(server)) setNotificationVisible(true);
}
transitionTo(mActiveNetworkState);//轉到ActiveNetworkState
}
break;
default:
return NOT_HANDLED;
}
return HANDLED;
}
}
~~~
上述代碼中,isCaptivePortal用于判斷server是否需要Captive Portal Check。其代碼如下所示:
**CaptivePortalTracker.java::isCaptivePortal**
~~~
private boolean isCaptivePortal(InetAddress server) {
HttpURLConnection urlConnection = null;
if (!mIsCaptivePortalCheckEnabled) return false;
//mUrl實際訪問的地址是:http://clients3.google.com/generate_204
mUrl = "http://" + server.getHostAddress() + "/generate_204";
/*
Captive Portal的測試非常簡單,就是向mUrl發送一個HTTP GET請求。如果無線網絡提供商沒有設置Portal
Check,則HTTP GET請求將返回204。204表示請求處理成功,但沒有數據返回。如果無線網絡提供商設置了
Portal Check,則它一定會重定向到某個特定網頁。這樣,HTTP GET的返回值就不是204
*/
try {
URL url = new URL(mUrl);
urlConnection = (HttpURLConnection) url.openConnection();
urlConnection.setInstanceFollowRedirects(false);
urlConnection.setConnectTimeout(SOCKET_TIMEOUT_MS);
urlConnection.setReadTimeout(SOCKET_TIMEOUT_MS);
urlConnection.setUseCaches(false);
urlConnection.getInputStream();
return urlConnection.getResponseCode() != 204;
}......
}
~~~
處理完畢后,CaptivePortalTracker將轉入ActiveNetworkState狀態。該狀態的內容非常簡單,讀者可自行閱讀它。由于筆者家中所在小區寬帶提供商使用了Capive Portal Check,所以筆者利用AirPcap截獲了相關網絡交換數據,如圖5-8所示:
:-: 
圖5-8 Captive Portal Check示意圖
測試時,筆者禁用了無線網絡安全,所以AirPcap可以解析這些沒有加密的數據包。由圖5-8可知,當筆者的Note 2發起HTTP GET請求后,小區寬帶服務器回復了HTTP 302,所以筆者手機狀態欄才會顯然如圖5-9所示的提示項以提醒筆者該無線網絡需要登錄。
:-: 
圖5-9 Captive Portal Check提示示意圖
**4、CaptivePortalTracker總結和討論**
和WifiWatchdogStateMachine一樣,CaptivePortalTracker也比較有意思。CaptivePortalTracker類出現于4.2中。而4.1中的Captive Portacl Check功能則是由WifiWatchdogStateMachin來完成的。在4.1中,WifiWatchdogStateMachine定義了一個名為WalledGardenCheckState的類用于處理Captive Portal Check。
不過,筆者在研究4.1和4.2相關模塊的代碼后,發現4.2中的處理似乎有一些問題。此處先記下此問題,希望有興趣的讀者參與討論。該問題如下:
* * * * *
4.2中,WifiStateMachine在ConnectedState前增加了一個CaptivePortalCheckState。很明顯,CaptivePortalCheckState的目的是在WifiStateMachine轉入ConnectedState之前完成Captive Portal Check。但根據本節對CaptivePortalTracker的介紹,只有WifiStateMachine進入ConnectedState后,ConnectivityService才會發送CONNECTIVITY_ACTION廣播。而在4.1中,WifiWatchdogStateMachine也是在WifiStateMachine轉入ConnectedState后進入WalledGardenCheckState的。
* * * * *
>[info] 提示:那么,WifiStateMachine如何從CaptivePortalCheckState轉為ConnectedState呢?
>
> 答案在ConnectivityService的handleCaptivePortalTrackerCheck函數中。在那里,WifiStateMachine的captivePortalCheckComplete函數最終會被調用。在那個函數中,CMD_CAPTIVE_CHECK_COMPLETE將被發送,故CaptivePortalCheckState才會轉入ConnectedState狀態。但是,在這個流程中,CaptivePortalTracker并未被真正觸發以進行Captive Portal Check。
- 前言
- 第1章 準備工作
- 1.1 Android系統架構
- 1.2 工具使用
- 1.2.1 Source Insight的使用
- 1.2.2 Eclipse的使用
- 1.2.3 BusyBox的使用
- 1.3 本書資源下載說明
- 第2章 深入理解Netd
- 2.1 概述
- 2.2 Netd工作流程
- 2.2.1 main函數分析
- 2.2.2 NetlinkManager分析
- 2.2.3 CommandListener分析
- 2.2.4 DnsProxyListener分析
- 2.2.5 MDnsSdListener分析
- 2.3 CommandListener中的命令
- 2.3.1 iptables、tc和ip命令
- 2.3.2 CommandListener構造函數和測試工具ndc
- 2.3.3 InterfaceCmd命令
- 2.3.4 IpFwd和FirewallCmd命令
- 2.3.5 ListTtysCmd和PppdCmd命令
- 2.3.6 BandwidthControlCmd和IdletimerControlCmd命令
- 2.3.7 NatCmd命令
- 2.3.8 TetherCmd和SoftapCmd命令
- 2.3.9 ResolverCmd命令
- 2.4 NetworkManagementService介紹
- 2.4.1 create函數詳解
- 2.4.2 systemReady函數詳解
- 2.5 本章總結和參考資料說明
- 2.5.1 本章總結
- 2.5.2 參考資料說明
- 第3章 Wi-Fi基礎知識
- 3.1 概述
- 3.2 無線電頻譜和802.11協議的發展歷程
- 3.2.1 無線電頻譜知識
- 3.2.2 IEEE 802.11發展歷程
- 3.3 802.11無線網絡技術
- 3.3.1 OSI基本參考模型及相關基本概念
- 3.3.2 802.11知識點導讀
- 3.3.3 802.11組件
- 3.3.4 802.11 Service介紹
- 3.3.5 802.11 MAC服務和幀
- 3.3.6 802.11 MAC管理實體
- 3.3.7 無線網絡安全技術知識點
- 3.4 Linux Wi-Fi編程API介紹
- 3.4.1 Linux Wireless Extensions介紹
- 3.4.2 nl80211介紹
- 3.5 本章總結和參考資料說明
- 3.5.1 本章總結
- 3.5.2 參考資料說明
- 第4章 深入理解wpa_supplicant
- 4.1 概述
- 4.2 初識wpa_supplicant
- 4.2.1 wpa_supplicant架構
- 4.2.2 wpa_supplicant編譯配置
- 4.2.3 wpa_supplicant命令和控制API
- 4.2.4 git的使用
- 4.3 wpa_supplicant初始化流程
- 4.3.1 main函數分析
- 4.3.2 wpa_supplicant_init函數分析
- 4.3.3 wpa_supplicant_add_iface函數分析
- 4.3.4 wpa_supplicant_init_iface函數分析
- 4.4 EAP和EAPOL模塊
- 4.4.1 EAP模塊分析
- 4.4.2 EAPOL模塊分析
- 4.5 wpa_supplicant連接無線網絡分析
- 4.5.1 ADD_NETWORK命令處理
- 4.5.2 SET_NETWORK命令處理
- 4.5.3 ENABLE_NETWORK命令處理
- 4.6 本章總結和參考資料說明
- 4.6.1 本章總結
- 4.6.2 參考資料說明
- 第5章 深入理解WifiService
- 5.1 概述
- 5.2 WifiService的創建及初始化
- 5.2.1 HSM和AsyncChannel介紹
- 5.2.2 WifiService構造函數分析
- 5.2.3 WifiStateMachine介紹
- 5.3 加入無線網絡分析
- 5.3.1 Settings操作Wi-Fi分析
- 5.3.2 WifiService操作Wi-Fi分析
- 5.4 WifiWatchdogStateMachine介紹
- 5.5 Captive Portal Check介紹
- 5.6 本章總結和參考資料說明
- 5.6.1 本章總結
- 5.6.2 參考資料說明
- 第6章 深入理解Wi-Fi Simple Configuration
- 6.1 概述
- 6.2 WSC基礎知識
- 6.2.1 WSC應用場景
- 6.2.2 WSC核心組件及接口
- 6.3 Registration Protocol詳解
- 6.3.1 WSC IE和Attribute介紹
- 6.3.2 802.11管理幀WSC IE設置
- 6.3.3 EAP-WSC介紹
- 6.4 WSC代碼分析
- 6.4.1 Settings中的WSC處理
- 6.4.2 WifiStateMachine的處理
- 6.4.3 wpa_supplicant中的WSC處理
- 6.4.4 EAP-WSC處理流程分析
- 6.5 本章總結和參考資料說明
- 6.5.1 本章總結
- 6.5.2 參考資料說明
- 第7章 深入理解Wi-Fi P2P
- 7.1 概述
- 7.2 P2P基礎知識
- 7.2.1 P2P架構
- 7.2.2 P2P Discovery技術
- 7.2.3 P2P工作流程
- 7.3 WifiP2pSettings和WifiP2pService介紹
- 7.3.1 WifiP2pSettings工作流程
- 7.3.2 WifiP2pService工作流程
- 7.4 wpa_supplicant中的P2P
- 7.4.1 P2P模塊初始化
- 7.4.2 P2P Device Discovery流程分析
- 7.4.3 Provision Discovery流程分析
- 7.4.4 GO Negotiation流程分析
- 7.5 本章總結和參考資料說明
- 7.5.1 本章總結
- 7.5.2 參考資料說明
- 第8章 深入理解NFC
- 8.1 概述
- 8.2 NFC基礎知識
- 8.2.1 NFC概述
- 8.2.2 NFC R/W運行模式
- 8.2.3 NFC P2P運行模式
- 8.2.4 NFC CE運行模式
- 8.2.5 NCI原理
- 8.2.6 NFC相關規范
- 8.3 Android中的NFC
- 8.3.1 NFC應用示例
- 8.3.2 NFC系統模塊
- 8.4 NFC HAL層討論
- 8.5 本章總結和參考資料說明
- 8.5.1 本章總結
- 8.5.2 參考資料說明
- 第9章 深入理解GPS
- 9.1 概述
- 9.2 GPS基礎知識
- 9.2.1 衛星導航基本原理
- 9.2.2 GPS系統組成及原理
- 9.2.3 OMA-SUPL協議
- 9.3 Android中的位置管理
- 9.3.1 LocationManager架構
- 9.3.2 LocationManager應用示例
- 9.3.3 LocationManager系統模塊
- 9.4 本章總結和參考資料說明
- 9.4.1 本章總結
- 9.4.2 參考資料說明
- 附錄