多应用+插件架构,代码干净,二开方便,首家独创一键云编译技术,文档视频完善,免费商用码云13.8K 广告
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所示: :-: ![](http://img.blog.csdn.net/20140309211006531?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvSW5ub3N0/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast) 图5-8 Captive Portal Check示意图 测试时,笔者禁用了无线网络安全,所以AirPcap可以解析这些没有加密的数据包。由图5-8可知,当笔者的Note 2发起HTTP GET请求后,小区宽带服务器回复了HTTP 302,所以笔者手机状态栏才会显然如图5-9所示的提示项以提醒笔者该无线网络需要登录。 :-: ![](http://img.blog.csdn.net/20140309211102218?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvSW5ub3N0/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast) 图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。