前言：
本文介绍了android下网络的评分机制，同时分析wifi连接国内ap时，重新打开wifi后，wifi不回连ap的问题，并提供解决方法。
android下可以有多种网络存在，如：wifi、mobile network、ethernet、bt-pan。而对于上层应用来说，只会看到一个连通的网络，在多个网络同时存在的情况下，android就需要一套评分机制来选择一个当前使用的网络，当那个网络的分值高时，就优先使用那个网络。
Android下各种网络的分值在NetworkAgentInfo.java中管理，保存在currentScore中，各种网络初始化时会设置自己的分值。
Wifi初始分值为60（WifiStateMachine.java）；
Ethernet初始分值为70（EthernetNetworkFactory.java）；
Mobile network初始分值为50（DataConnection.java）；
bt-pan初始分值为69（BluetoothTetheringNetworkFactory.java）：
bt-pan的分值比wifi还高，这比较奇怪，已知的bt-pan网速都比较慢，google出于什么原因设计成这样？就不清楚了。
在实际运行中，还会根据网络的实时状态调整分值。
ethernet根据网卡的up和down状态，把分值设置为70（NETWORK_SCORE）或0。
（EthernetNetworkFactory.java）
mNetworkAgent.sendNetworkScore(mLinkUp? NETWORK_SCORE : 0); 而wifi的分值还跟信号状态、当前数据速率等一系列因素有关：
Wifi的分值计算在WifiStateMachine.java的calculateWifiScore函数中进行，初始计算的基础分值为：int score = 56;根据wifi网络的状态，进行小的加减，最后，如果分值大于60（NetworkAgent.WIFI_BASE_SCORE），就把分值设置为60。
上面设置的分值计算，只考虑网络是否连接好，至于连接的网络是否能连接上internet，还没加入考虑。如wifi已经连接上ap，而该ap是否能连接上internet，就没在这里考虑。
上面设置的网络分值，是最终保存在NetworkAgentInfo类中的分值，而在获取网络分值时，还会根据网络是否连接上internet，是否用户指定使用的网络，返回经过计算后的分值。
NetworkAgentInfo.java
private int getCurrentScore(boolean pretendValidated) {
// TODO: We may want to refactor this into a NetworkScore class that takes a base score from
// the NetworkAgent and signals from the NetworkAgent and uses those signals to modify the
// score. The NetworkScore class would provide a nice place to centralize score constants
// so they are not scattered about the transports.
int score = currentScore;
if (!everValidated && !pretendValidated) score -= UNVALIDATED_SCORE_PENALTY;
if (score < 0) score = 0;
if (networkMisc.explicitlySelected) score = EXPLICITLY_SELECTED_NETWORK_SCORE;
return score;
}如果需要根据网络是否连通internet，就进行if (!everValidated && !pretendValidated) score -= UNVALIDATED_SCORE_PENALTY（40）;处理，当网络与internet不通时，分值减去40。如果是用户指定使用的网络，直接返回分值if (networkMisc.explicitlySelected) score = EXPLICITLY_SELECTED_NETWORK_SCORE;（100）。
pretendValidated参数确定是否认为当前网络就是与internet连通的。everValidated表示当前网络与internet是否连通的标志。networkMisc.explicitlySelected为用户是否指定使用当前网络的标志，在用户手动连接ap的时候，该标志就会被设置，所以这时候的分值比ethernet还高，就会优先选择wifi作为首选网络。但在开关wifi后，自动连接上ap时，该标志就不会设置。
最后，分析一下everValidated标志是由哪里设置的，这里以wifi作为例子分析。
在连接wifi的过程中，当WifiStateMachine进入L2ConnectedState时，就会创建：
mNetworkAgent = new WifiNetworkAgent(getHandler().getLooper(), mContext,
"WifiNetworkAgent", mNetworkInfo, mNetworkCapabilitiesFilter,
mLinkProperties, 60);在WifiNetworkAgent初始化时，把everValidated设置为false，而当网络断开连接时，就会注销WifiNetworkAgent：
if (mNetworkAgent != null) {
mNetworkAgent.sendNetworkInfo(mNetworkInfo);
mNetworkAgent = null;
}所以在每次连接网络后，都会重新设置everValidated，断开网络时就会清除。
创建WifiNetworkAgent时，在WifiNetworkAgent内创建了NetworkMonitor， NetworkMonitor就是一个检测网络的状态机，状态机包含下面状态，初始状态为mDefaultState，检测网络是否与internet连通就是在该状态机中实现。
addState(mDefaultState);
addState(mOfflineState, mDefaultState);
addState(mValidatedState, mDefaultState);
addState(mMaybeNotifyState, mDefaultState);
addState(mEvaluatingState, mMaybeNotifyState);
addState(mCaptivePortalState, mMaybeNotifyState);
addState(mLingeringState, mDefaultState);
setInitialState(mDefaultState);当网络与internet连通时，NetworkMonitor所走的状态机如下图：
当进入mValidatedState时，就会给connectivity发送消息：
mConnectivityServiceHandler.sendMessage(obtainMessage(EVENT_NETWORK_TESTED,
NETWORK_TEST_RESULT_VALID, mNetwork3gTestResultIsFake,
mNetworkAgentInfo))；
connectivity对NETWORK_TEST_RESULT_VALID消息进行处理时，就会设置everValidated为true。
检测网络是否连通的代码如下：
android\frameworks\base\services\core\java\com\android\server\connectivity\ NetworkMonitor.java
public boolean processMessage(Message message) {
if (DBG) log(getName() + message.toString());
switch (message.what) {
case CMD_REEVALUATE:
if (message.arg1 != mReevaluateToken)
return HANDLED;
// Don't bother validating networks that don't satisify the default request.
// This includes:
// - VPNs which can be considered explicitly desired by the user and the
// user's desire trumps whether the network validates.
// - Networks that don't provide internet access. It's unclear how to
// validate such networks.
// - Untrusted networks. It's unsafe to prompt the user to sign-in to
// such networks and the user didn't express interest in connecting to
// such networks (an app did) so the user may be unhappily surprised when
// asked to sign-in to a network they didn't want to connect to in the
// first place. Validation could be done to adjust the network scores
// however these networks are app-requested and may not be intended for
// general usage, in which case general validation may not be an accurate
// measure of the network's quality. Only the app knows how to evaluate
// the network so don't bother validating here. Furthermore sending HTTP
// packets over the network may be undesirable, for example an extremely
// expensive metered network, or unwanted leaking of the User Agent string.
if (!mDefaultRequestworkCapabilities.satisfiedByNetworkCapabilities(
mNetworkAgentInfoworkCapabilities)) {
transitionTo(mValidatedState);
return HANDLED;
}
// Note: This call to isCaptivePortal() could take up to a minute. Resolving the
// server's IP addresses could hit the DNS timeout, and attempting connections
// to each of the server's several IP addresses (currently one IPv4 and one
// IPv6) could each take SOCKET_TIMEOUT_MS. During this time this StateMachine
// will be unresponsive. isCaptivePortal() could be executed on another Thread
// if this is found to cause problems.
int httpResponseCode = isCaptivePortal();
if (httpResponseCode == 204) {
transitionTo(mValidatedState);
} else if (httpResponseCode >= 200 && httpResponseCode <= 399) {
transitionTo(mCaptivePortalState);
} else if (++mAttempt > mMaxAttempts) {
transitionTo(mOfflineState);
} else if (mReevaluateDelayMs >= 0) {
Message msg = obtainMessage(CMD_REEVALUATE, ++mReevaluateToken, 0);
sendMessageDelayed(msg, mReevaluateDelayMs);
}
return HANDLED;
android\frameworks\base\services\core\java\com\android\server\connectivity\ NetworkMonitor.java
/**
* Do a URL fetch on a known server to see if we get the data we expect.
* Returns HTTP response code.
*/
private int isCaptivePortal() {
HttpURLConnection urlConnection = null;
int httpResponseCode = 599;
try {
URL url = new URL("http", mServer, "/generate_204");
// On networks with a PAC instead of fetching a URL that should result in a 204
// reponse, we instead simply fetch the PAC script. This is done for a few reasons:
// 1. At present our PAC code does not yet handle multiple PACs on multiple networks
// until something like https://android-review.googlesource/#/c/115180/ lands.
// Network.openConnection() will ignore network-specific PACs and instead fetch
// using NO_PROXY. If a PAC is in place, the only fetch we know will succeed with
// NO_PROXY is the fetch of the PAC itself.
// 2. To proxy the generate_204 fetch through a PAC would require a number of things
// happen before the fetch can commence, namely:
// a) the PAC script be fetched
// b) a PAC script resolver service be fired up and resolve mServer
// Network validation could be delayed until these prerequisities are satisifed or
// could simply be left to race them. Neither is an optimal solution.
// 3. PAC scripts are sometimes used to block or restrict Internet access and may in
// fact block fetching of the generate_204 URL which would lead to false negative
// results for network validation.
boolean fetchPac = false;
{
final ProxyInfo proxyInfo = mNetworkAgentInfo.linkProperties.getHttpProxy();
if (proxyInfo != null && !Uri.EMPTY.equals(proxyInfo.getPacFileUrl())) {
url = new URL(proxyInfo.getPacFileUrl().toString());
fetchPac = true;
}
}
if (DBG) {
log("Checking " + url.toString() + " on " +
mNetworkAgentInfoworkInfo.getExtraInfo());
}
urlConnection = (HttpURLConnection) mNetworkAgentInfowork.openConnection(url);
urlConnection.setInstanceFollowRedirects(fetchPac);
urlConnection.setConnectTimeout(SOCKET_TIMEOUT_MS);
urlConnection.setReadTimeout(SOCKET_TIMEOUT_MS);
urlConnection.setUseCaches(false);
// Time how long it takes to get a response to our request
long requestTimestamp = SystemClock.elapsedRealtime();
urlConnection.getInputStream();
// Time how long it takes to get a response to our request
long responseTimestamp = SystemClock.elapsedRealtime();
httpResponseCode = urlConnection.getResponseCode();
if (DBG) {
log("isCaptivePortal: ret=" + httpResponseCode +
" headers=" + urlConnection.getHeaderFields());
}
// NOTE: We may want to consider an "HTTP/1.0 204" response to be a captive
// portal. The only example of this seen so far was a captive portal. For
// the time being go with prior behavior of assuming it's not a captive
// portal. If it is considered a captive portal, a different sign-in URL
// is needed (i.e. can't browse a 204). This could be the result of an HTTP
// proxy server.
// Consider 200 response with "Content-length=0" to not be a captive portal.
// There's no point in considering this a captive portal as the user cannot
// sign-in to an empty page. Probably the result of a broken transparent proxy.
// See http://b/9972012.
if (httpResponseCode == 200 && urlConnection.getContentLength() == 0) {
if (DBG) log("Empty 200 response interpreted as 204 response.");
httpResponseCode = 204;
}
if (httpResponseCode == 200 && fetchPac) {
if (DBG) log("PAC fetch 200 response interpreted as 204 response.");
httpResponseCode = 204;
}
sendNetworkConditionsBroadcast(true /* response received */,
httpResponseCode != 204 /* isCaptivePortal */,
requestTimestamp, responseTimestamp);
} catch (IOException e) {
if (DBG) log("Probably not a portal: exception " + e);
if (httpResponseCode == 599) {
// TODO: Ping gateway and DNS server and log results.
}
} finally {
if (urlConnection != null) {
urlConnection.disconnect();
}
}
return httpResponseCode;
}当网络与internet不连通时，NetworkMonitor所走状态机如下：
当与internet不通时，开始进行间隔5秒（每次检测超时为10(SOCKET_TIMEOUT_MS)秒，总的来说就是15秒检测一次）的检测，当大于3（INITIAL_ATTEMPTS）次检测都不通时，就会转到mOfflineState状态，并发送一个10分钟后的CMD_FORCE_REEVALUATION消息，10分钟后再进入mEvaluatingState状态进行检测，这次检测如果失败，就会再次进入mOfflineState状态，不停的循环检测。但有时上层会发送一个CMD_FORCE_REEVALUATIO消息过来，这时马上就进入mEvaluatingState状态进行检测，如果失败就继续进入mOfflineState状态并发送一个10分钟的CMD_FORCE_REEVALUATION消息。
从android代码看，在进入mOfflineState状态时，会给connectivity发送NETWORK_TEST_RESULT_INVALID消息，但connectivity中没有对该消息进行处理，也就是说，只要有一次检测到网络与internet连通后，everValidated设置为true，即使后面因为其他原因与internet不通了（与ap连接还是正常的），即使用户发送CMD_FORCE_REEVALUATIO消息进行网络检测，everValidated也不会被设置为false。
在android中，判断网络是否连接，是通过连接google服务器是否有回应判断的，在isCaptivePortal函数中实现，所以在大陆连接wifi的时候，由于无法与google服务器通信，所以在机子看来网络也是不通的。一个明显的标志是连接大陆wifi，在状态栏的wifi图标旁边有一个“感叹号”，如果连接的wifi能与google服务器通信，wifi图标旁就不会有“感叹号”。Wifi在检测到多次不能连接google服务器后，会在/data/misc/wifi/ networkHistory.txt 中记录：
!NO_INTERNET_ACCESS_REPORTS : 1
“VALIDATED_INTERNET_ACCESS: false
当VALIDATED_INTERNET_ACCESS为false，numNoInternetAccessReports大于0时，wifi AP名的下面就会出现提示“未检测到任何互联网连接，因此不会自动重新连接”，这就是连接大陆wifi时，会遇到的不会回连ap的情况。
这个问题，可以通过修改代码来规避：
如修改下面代码：
private int isCaptivePortal() {
/* 增加代码，不配置该属性，默认为1，直接返回检测网络成功 */
if (SystemProperties.get("ro.isCaptivePortal", ”1”).equals("1")) return 204;上面的修改，对于原生的检查代码，还缺少一个发送网络检测时间的广播，下面的修改，增加上广播网络回应时间。
protected int isCaptivePortal() {
if (SystemProperties.get("ro.isCaptivePortal", ”1”).equals("1")) {
/* make fake return */
int fakehttpResponseCode = 204;
// Time how long it takes to get a response to our request
long fakerequestTimestamp = SystemClock.elapsedRealtime();
try
{
Thread.currentThread().sleep(200);
}
catch(Exception e){}
// Time how long it takes to get a response to our request
long fakeresponseTimestamp = SystemClock.elapsedRealtime();
sendNetworkConditionsBroadcast(true /* response received */,
fakehttpResponseCode != 204 /* isCaptivePortal */,
fakerequestTimestamp, fakeresponseTimestamp);
return fakehttpResponseCode;
}甚至我们可以重定向检测网络的地址。
private int isCaptivePortal() {
HttpURLConnection urlConnection = null;
int httpResponseCode = 599;
try {
URL url = new URL("http", "www.baidu", "/more/index.html"); /* 确保能成功获取该内容 */
//URL url = new URL("http", "www.baidu", "/img/baidu_jgylogo3.gif"); /* 确保能成功获取该内容 */
// On networks with a PAC instead of fetching a URL that should result in a 204
// reponse, we instead simply fetch the PAC script. This is done for a few reasons:
// 1. At present our PAC code does not yet handle multiple PACs on multiple networks
// until something like https://android-review.googlesource/#/c/115180/ lands.
// Network.openConnection() will ignore network-specific PACs and instead fetch
// using NO_PROXY. If a PAC is in place, the only fetch we know will succeed with
// NO_PROXY is the fetch of the PAC itself.
// 2. To proxy the generate_204 fetch through a PAC would require a number of things
// happen before the fetch can commence, namely:
// a) the PAC script be fetched
// b) a PAC script resolver service be fired up and resolve mServer
// Network validation could be delayed until these prerequisities are satisifed or
// could simply be left to race them. Neither is an optimal solution.
// 3. PAC scripts are sometimes used to block or restrict Internet access and may in
// fact block fetching of the generate_204 URL which would lead to false negative
// results for network validation.
boolean fetchPac = false;
{
final ProxyInfo proxyInfo = mNetworkAgentInfo.linkProperties.getHttpProxy();
if (proxyInfo != null && !Uri.EMPTY.equals(proxyInfo.getPacFileUrl())) {
url = new URL(proxyInfo.getPacFileUrl().toString());
fetchPac = true;
}
}
if (DBG) {
log("Checking " + url.toString() + " on " +
mNetworkAgentInfoworkInfo.getExtraInfo());
}
urlConnection = (HttpURLConnection) mNetworkAgentInfowork.openConnection(url);
urlConnection.setInstanceFollowRedirects(fetchPac);
urlConnection.setConnectTimeout(SOCKET_TIMEOUT_MS);
urlConnection.setReadTimeout(SOCKET_TIMEOUT_MS);
urlConnection.setUseCaches(false);
// Time how long it takes to get a response to our request
long requestTimestamp = SystemClock.elapsedRealtime();
urlConnection.getInputStream();
// Time how long it takes to get a response to our request
long responseTimestamp = SystemClock.elapsedRealtime();
httpResponseCode = urlConnection.getResponseCode();
if (DBG) {
log("isCaptivePortal: ret=" + httpResponseCode +
" headers=" + urlConnection.getHeaderFields());
}
// NOTE: We may want to consider an "HTTP/1.0 204" response to be a captive
// portal. The only example of this seen so far was a captive portal. For
// the time being go with prior behavior of assuming it's not a captive
// portal. If it is considered a captive portal, a different sign-in URL
// is needed (i.e. can't browse a 204). This could be the result of an HTTP
// proxy server.
// Consider 200 response with "Content-length=0" to not be a captive portal.
// There's no point in considering this a captive portal as the user cannot
// sign-in to an empty page. Probably the result of a broken transparent proxy.
// See http://b/9972012.
if (httpResponseCode == 200) {
if (DBG) log("www.baidu 200 response interpreted as 204 response.");
httpResponseCode = 204;
}更多推荐
android网络的评分机制、连接国内ap wifi不回连问题
发布评论