背景
在介绍PhoneApp的创建过程时,我们知道为了支持双卡手机,PhoneFactory创建了两个Phone对象。
然而由于通信制式、功耗等的限制,目前底层的芯片厂商规定modem工作于DSDS模式下,于是同一时间内只有一个Phone具有上网的能力。
本文旨在揭示激活Phone拨号能力的过程,即讲述数据拨号前的准备工作。
版本
android 7.0
1 TelephonyProvider的启动
数据业务在建立之前,必须有可用的APN,因此我们首先看看Android 7.0中APN加载的过程。
之前分析PhoneApp启动过程时,我们知道PhoneApp的onCreate函数是靠ActivityThread.java中的handleBindApplication函数调用的。
private void handleBindApplication(AppBindData data) {
........
try {
Application app = data.info.makeApplication(data.restrictedBackupMode, null);
mInitialApplication = app;
if (!data.restrictedBackupMode) {
if (!ArrayUtils.isEmpty(data.providers)) {
//加载App中的provider
installContentProviders(app, data.providers);
...........
}
}
try {
mInstrumentation.onCreate(data.instrumentationArgs);
} catch (Exception e) {
.........
}
try {
//调用App的onCreate函数
mInstrumentation.callApplicationOnCreate(app);
} catch (Exception e) {
..............
}
} finally {
.............
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
从上面的代码,我们知道在PhoneApp的onCreate被调用前,先加载了PhoneApp中的ContentProvider(PM解析xml得到这种包含关系)。
private void installContentProviders(Context context, List<ProviderInfo> providers) {
........
for (ProviderInfo cpi : providers) {
..........
//依次安装provider
IActivityManager.ContentProviderHolder cph = installProvider(context, null, cpi,
false /*noisy*/, true /*noReleaseNeeded*/, true /*stable*/);
............
}
try {
//发布provider
ActivityManagerNative.getDefault().publishContentProviders(
getApplicationThread(), results);
} catch (RemoteException ex) {
throw ex.rethrowFromSystemServer();
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
从TelephonyProvider的AndroidManifest.xml,我们知道TelephonyProvider就是运行在Phone进程中的,因此结合上面的代码,可以得出结论:
TelephonyProvider将在PhoneApp的onCreate被调用前被加载。
Android7.0 TelephonyProvider启动后的过程,与Android6.0中一致。
之前的blog分析Android6.0中APN加载过程时,已经做过描述了,其实就是创建数据库、解析xml文件并存入数据库的过程,此处不再赘述。
2 设定具有拨号能力的Phone
我们回忆一下PhoneApp启动后,利用PhoneFactory的makeDefaultPhone创建对象的代码,其中:
.........
//创建了一个PhoneSwitcher
sPhoneSwitcher = new PhoneSwitcher(MAX_ACTIVE_PHONES, numPhones,
sContext, sc, Looper.myLooper(), tr, sCommandsInterfaces,
sPhones);
.........
sTelephonyNetworkFactories = new TelephonyNetworkFactory[numPhones];
for (int i = 0; i < numPhones; i++) {
//创建了两个TelephonyNetworkFactory,分别与每个Phone关联起来
sTelephonyNetworkFactories[i] = new TelephonyNetworkFactory(
sPhoneSwitcher, sc, sSubscriptionMonitor, Looper.myLooper(),
sContext, i, sPhones[i].mDcTracker);
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
在刚开机时,不插卡的情况下,上面代码提及的PhoneSwitcher和TelephonyNetworkFactory将决定具有拨号能力的Phone。
我们在这里先分析不插卡情况下的流程,主要原因是:
框架对卡信息有记录,将会根据记录信息改变具有拨号能力的Phone。这个过程是通过调用Phone进程提供的接口完成的,我们以后再做分析。
2.1 PhoneSwitcher
我们先来看看PhoneSwitcher:
//PhoneSwitcher继承自Handler
public class PhoneSwitcher extends Handler {
......
public PhoneSwitcher(......) {
........
//创建NetworkCapabilities,为创建NetworkFactory作准备
//NetworkCapabilities决定了NetworkFactory可以处理的Network Request种类
NetworkCapabilities netCap = new NetworkCapabilities();
netCap.addTransportType(NetworkCapabilities.TRANSPORT_CELLULAR);
netCap.addCapability(NetworkCapabilities.NET_CAPABILITY_MMS);
netCap.addCapability(NetworkCapabilities.NET_CAPABILITY_SUPL);
netCap.addCapability(NetworkCapabilities.NET_CAPABILITY_DUN);
netCap.addCapability(NetworkCapabilities.NET_CAPABILITY_FOTA);
netCap.addCapability(NetworkCapabilities.NET_CAPABILITY_IMS);
netCap.addCapability(NetworkCapabilities.NET_CAPABILITY_CBS);
netCap.addCapability(NetworkCapabilities.NET_CAPABILITY_IA);
netCap.addCapability(NetworkCapabilities.NET_CAPABILITY_RCS);
netCap.addCapability(NetworkCapabilities.NET_CAPABILITY_XCAP);
netCap.addCapability(NetworkCapabilities.NET_CAPABILITY_EIMS);
netCap.addCapability(NetworkCapabilities.NET_CAPABILITY_NOT_RESTRICTED);
netCap.addCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET);
netCap.setNetworkSpecifier(NetworkCapabilities.MATCH_ALL_REQUESTS_NETWORK_SPECIFIER);
//创建了一个NetworkFactory对象
NetworkFactory networkFactory = new PhoneSwitcherNetworkRequestListener(looper, context,
netCap, this);
//每个NetworkFactory仅能处理分数比自己低的NetworkRequest
//这里设置分数为101,将能够处理所有的request
networkFactory.setScoreFilter(101);
//注册该NetworkFactory对象
networkFactory.register();
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
上面的代码涉及到了很多内容,以后有机会再分析,此时我们仅需要有一个映像就是:
PhoneSwitcher创建了一个能够处理所有Network Request的NetworkFactory(实际上是子类),并调用了register方法。
我们来看看NetworkFactory的register方法:
//NetworkFactory继承Handler
public class NetworkFactory extends Handler {
........
public void register() {
if (DBG) log("Registering NetworkFactory");
if (mMessenger == null) {
//构造Messenger对象,其中包含Handler
mMessenger = new Messenger(this);
//调用ConnectivityManager的registerNetworkFactory方法
ConnectivityManager.from(mContext).registerNetworkFactory(mMessenger, LOG_TAG);
}
}
..........
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
继续跟进ConnectivityManager中的函数:
public static ConnectivityManager from(Context context) {
return (ConnectivityManager) context.getSystemService(Context.CONNECTIVITY_SERVICE);
}
public void registerNetworkFactory(Messenger messenger, String name) {
try {
//可以看到将调用用mService的registerNetworkFactory函数
mService.registerNetworkFactory(messenger, name);
} catch (RemoteException e) {
throw e.rethrowFromSystemServer();
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
mService的类型为IConnectivityManager,其实是ConnectivityService的Binder通信的服务端代理,因此上述代码最终将调用到ConnectivityService的registerNetworkFactory函数。
ConnectivityService是开机时,由SystemServer加载的,这里我们不分析ConnectivityService启动的过程,以后有机会单独介绍ConnectivityService。这里我们只需要知道ConnectivityService主要负责管理Android中的各种网络。
我们看看ConnectivityService的registerNetworkFactory函数:
@Override
public void registerNetworkFactory(Messenger messenger, String name) {
//权限检查
enforceConnectivityInternalPermission();
//构造NetworkFactoryInfo, 该变量用于在ConnectivityService中代表注册的NetworkFactory
//注意Messager中,包含注册NetworkFactory内部的Handler
NetworkFactoryInfo nfi = new NetworkFactoryInfo(name, messenger, new AsyncChannel());
//发送消息给给内部的Handler处理,将并行的接口调用变为串行的消息处理
mHandler.sendMessage(mHandler.obtainMessage(EVENT_REGISTER_NETWORK_FACTORY, nfi));
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
ConnectivityService内部的handler将调用handleRegisterNetworkFactory处理EVENT_REGISTER_NETWORK_FACTORY消息:
............
case EVENT_REGISTER_NETWORK_FACTORY: {
handleRegisterNetworkFactory((NetworkFactoryInfo)msg.obj);
break;
}
...........
- 1
- 2
- 3
- 4
- 5
- 6
private void handleRegisterNetworkFactory(NetworkFactoryInfo nfi) {
if (DBG) log("Got NetworkFactory Messenger for " + nfi.name);
//以键值对的方式,存储NetworkFactory的messenger和对应的NetworkFactoryInfo
mNetworkFactoryInfos.put(nfi.messenger, nfi);
//调用AsyncChannel的connect方法,将ConnectivityService的TrackerHandler与NetworkFactory的Messenger联系起来
nfi.asyncChannel.connect(mContext, mTrackerHandler, nfi.messenger);
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
我们看看AsyncChannel的connect方法:
//此处传递的srcHandler是ConnectivityService的mTrackerHandler
//dstMessenger为NetworkFactory内部的Messenger
public void connect(Context srcContext, Handler srcHandler, Messenger dstMessenger) {
if (DBG) log("connect srcHandler to the dstMessenger E");
// We are connected
connected(srcContext, srcHandler, dstMessenger);
// Tell source we are half connected
replyHalfConnected(STATUS_SUCCESSFUL);
if (DBG) log("connect srcHandler to the dstMessenger X");
}
public void connected(Context srcContext, Handler srcHandler, Messenger dstMessenger) {
if (DBG) log("connected srcHandler to the dstMessenger E");
// Initialize source fields
mSrcContext = srcContext;
mSrcHandler = srcHandler;
mSrcMessenger = new Messenger(mSrcHandler);
// Initialize destination fields
mDstMessenger = dstMessenger;
//监听目的端断开
linkToDeathMonitor();
if (DBG) log("connected srcHandler to the dstMessenger X");
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
看到connnected函数,我们知道每个NetworkFactory注册后,ConnectivityService将维护对应的NetworkFactoryInfo,对应的键值为NetworkFactory中的Messenger对象。
每个NetworkFactoryInfo中有一个AsyncChannel对象,该对象的源端Messenger包裹着ConnectivityService的mTrackerHandler,目的端Messenger为注册NetworkFactory的Messenger。
ConnectivityService这么做的目的是:简化ConnectivityService与每个NetworkFactory通信时的函数调用。
//这里发送CMD_CHANNEL_HALF_CONNECTED给ConnectivityService的mTrackerHandler
//replyTo NetworkFactory中的Messenger
private void replyHalfConnected(int status) {
Message msg = mSrcHandler.obtainMessage(CMD_CHANNEL_HALF_CONNECTED);
msg.arg1 = status;
msg.obj = this;
msg.replyTo = mDstMessenger;
if (!linkToDeathMonitor()) {
// Override status to indicate failure
msg.arg1 = STATUS_BINDING_UNSUCCESSFUL;
}
mSrcHandler.sendMessage(msg);
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
根据上面的代码,我们知道接下来应该是ConnectivityService的mTrackerHandler处理CMD_CHANNEL_HALF_CONNECTED事件。
mTrackerHandler的类型为ConnectivityService的内部类NetworkStateTrackerHandler:
private class NetworkStateTrackerHandler extends Handler {
...........
@Override
public void handleMessage(Message msg) {
//这里的代码写法还是很赞的,特意看了Android6.0之前的代码
//在Android6.0之前,是在一个handleMessage中,根据msg.what使用大量的switch-case语句
//现在这样写,虽然本质上仍是大量的switch-case,但至少作了个分类
if (!maybeHandleAsyncChannelMessage(msg) && !maybeHandleNetworkMonitorMessage(msg)) {
maybeHandleNetworkAgentMessage(msg);
}
}
.......
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
在这里我们看看maybeHandleAsyncChannelMessage:
private boolean maybeHandleAsyncChannelMessage(Message msg) {
switch (msg.what) {
//说实话这个代码写的辣眼睛
//自己写switch-case,一直将default写在最后,导致自己认为default是可以匹配所有的case
//实际上,当剩余的case匹配不上时,default才会去匹配,default写在之前之后,没有关系
default:
return false;
case AsyncChannel.CMD_CHANNEL_HALF_CONNECTED: {
//这里我们调用这个函数
handleAsyncChannelHalfConnect(msg);
break;
}
case AsyncChannel.CMD_CHANNEL_DISCONNECT: {
NetworkAgentInfo nai = mNetworkAgentInfos.get(msg.replyTo);
if (nai != null) nai.asyncChannel.disconnect();
break;
}
case AsyncChannel.CMD_CHANNEL_DISCONNECTED: {
handleAsyncChannelDisconnected(msg);
break;
}
}
return true;
}
private void handleAsyncChannelHalfConnect(Message msg) {
AsyncChannel ac = (AsyncChannel) msg.obj;
//从前面的代码,我们知道msg.replyTo为NetworkFactory对应的Messenger
if (mNetworkFactoryInfos.containsKey(msg.replyTo)) {
if (msg.arg1 == AsyncChannel.STATUS_SUCCESSFUL) {
if (VDBG) log("NetworkFactory connected");
// A network factory has connected. Send it all current NetworkRequests.
//这里的NetworkRequest等下说明
for (NetworkRequestInfo nri : mNetworkRequests.values()) {
//NetworkRequest分为监听网络用的,和申请网络用的
//仅处理申请网络用的
if (!nri.isRequest()) continue;
//判断NetworkRequest是否有对应的NetworkAgentInfo
//当一个网络建立后,将会生成对应的NetworkAgent注册到ConnectivityService
//这里是取出NetworkRequest对应的NetworkAgentInfo
NetworkAgentInfo nai = mNetworkForRequestId.get(nri.request.requestId);
//将CMD_REQUEST_NETWORK的消息发送给NetworkFactory,同时指定该request的分数
ac.sendMessage(android.net.NetworkFactory.CMD_REQUEST_NETWORK,
(nai != null ? nai.getCurrentScore() : 0), 0, nri.request);
}
} else {
loge("Error connecting NetworkFactory");
mNetworkFactoryInfos.remove(msg.obj);
}
} else if (mNetworkAgentInfos.containsKey(msg.replyTo)) {
//这里是发送给NetworkAgent的消息,我们暂时不关注
.........
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
上面的代码其实就是发消息给NetworkFactory。这里存在的疑点是:
1、开机时是否有NetworkRequest?
2、发送CMD_REQUEST_NETWORK时为什么要携带分数?
我们先来分析第一个问题:
//构造函数
public ConnectivityService(.......) {
if (DBG) log("ConnectivityService starting up");
//初始时创建了DefaultRequest
mDefaultRequest = createInternetRequestForTransport(-1);
//创建对应的NetworkRequestInfo
NetworkRequestInfo defaultNRI = new NetworkRequestInfo(null, mDefaultRequest, new Binder(), NetworkRequestType.REQUEST);
//按键值对存储
mNetworkRequests.put(mDefaultRequest, defaultNRI);
mNetworkRequestInfoLogs.log("REGISTER " + defaultNRI);
............
}
//初始时,ConnectivityService创建NetworkRequest传入的参数为-1
private NetworkRequest createInternetRequestForTransport(int transportType) {
NetworkCapabilities netCap = new NetworkCapabilities();
netCap.addCapability(NET_CAPABILITY_INTERNET);
netCap.addCapability(NET_CAPABILITY_NOT_RESTRICTED);
if (transportType > -1) {
netCap.addTransportType(transportType);
}
return new NetworkRequest(netCap, TYPE_NONE, nextNetworkRequestId());
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
从上面的代码,我们知道了开机后,ConnectivityService中默认就会存在一个NetworkRequest,于是每当一个新的NetworkFactory注册到ConnectivityService后,都会处理这个默认的NetworkRequest。
现在我们再来回答第二个问题,为什么发送CMD_REQUEST_NETWORK时,需要携带分数。
这个问题其实涉及了Android框架,管理整个网络的架构。具体的情况,今后介绍ConnectivityService时,会详细介绍。
在这里直接抛出近似的答案:Android通过ConnectivityService管理所有的网络,每一种网络都有各自的NetworkFactory。当NetworkFactory收到NetworkRequest后,将创建实际的网络对象。ConnectivityService用NetworkAgent和NetworkAgentInfo来抽象实际的网络对象的一些特性(还有其它的对象,例如Network,LinkProperties等共同抽象网络)。
然而,同一个设备在同一时间内不需要连接多个网络。比如说,用户的目的就是上网,但WiFi和移动网络均能满足用户上网的需求,因此设备没有必要同时连接WiFi和移动网络。因此,Android需要一种机制来权衡各种网络的是否应该保留。
为此android引入了分数的概念,当两个网络能同时满足一个NetworkRequest时,分数高者就留下。根据这个规则,我们其实也知道如果两个网络分别满足不同的NetworkRequest时,是可以共存的。
以上是基本的结论,今后分析ConnectivityService时,会分析对应的源码。
知道原理后,
现在回过头来看看发送CMD_REQUEST_NETWORK时,为什么要携带分数。
当消息发送给NetworkFactory后,NetworkFactory如果能满足NetworkRequest的需求,需要生成对应当NetworkAgent注册到ConnectivityService。如果这个新生成的NetworkAgent的分数,比之前满足NetworkRequest的已存在的NetworkAgent分数低,那么这个NetworkAgent将被处理掉。
因此,与其浪费资源生成一个无用的NetworkAgent,不如一开始就让NetworkFactory通过比较分数,不处理高分NetworkRequest。
这种设计类似于从声源阻止噪声吧!
回答完问题后,让我们继续回到之前ConnectivityService的流程,接下来看看AsyncChannel如何发送消息:
//一层层的sendMessage调用,最后会调用到这个sendMessage
public void sendMessage(Message msg) {
//根据前面的分析,我们知道ConnectivityService中NetworkFactoryInfo的AsyncChannel中
//mSrcMessenger中包裹的是mTrackerHandler
msg.replyTo = mSrcMessenger;
try {
//DstMessenger中包裹的是NetworkFactory中的handler
//binder通信,发往了NetworkFactory
mDstMessenger.send(msg);
} catch (RemoteException e) {
replyDisconnected(STATUS_SEND_UNSUCCESSFUL);
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
至此,消息终于又发回了PhoneSwitcher中创建的NetworkFactory,消息的处理由父类NetworkFactory处理:
@Override
public void handleMessage(Message msg) {
switch (msg.what) {
case CMD_REQUEST_NETWORK: {
//调用该函数处理
handleAddRequest((NetworkRequest)msg.obj, msg.arg1);
break;
}
case CMD_CANCEL_REQUEST: {
handleRemoveRequest((NetworkRequest) msg.obj);
break;
}
case CMD_SET_SCORE: {
handleSetScore(msg.arg1);
break;
}
case CMD_SET_FILTER: {
handleSetFilter((NetworkCapabilities) msg.obj);
break;
}
}
}
@VisibleForTesting
protected void handleAddRequest(NetworkRequest request, int score) {
//判断之前是否处理过该NetworkRequest
NetworkRequestInfo n = mNetworkRequests.get(request.requestId);
if (n == null) {
if (DBG) log("got request " + request + " with score " + score);
n = new NetworkRequestInfo(request, score);
mNetworkRequests.put(n.request.requestId, n);
} else {
if (VDBG) log("new score " + score + " for exisiting request " + request);
//对于处理过的NetworkRequest,仅更新器分数
//原因是:ConnectivityService中匹配该NetworkRequest的NetworkAgent可能变化,所以需要更新分数
n.score = score;
}
if (VDBG) log(" my score=" + mScore + ", my filter=" + mCapabilityFilter);
//评估NetworkRequest
evalRequest(n);
}
private void evalRequest(NetworkRequestInfo n) {
if (VDBG) log("evalRequest");
//n.requested == false表示该request未被处理过
//n.score < mScore表示request的分数小于NetworkFactory的分数(子类定义)
//satisfiedByNetworkCapabilities是为了判断NetworkFactory(子类)的网络能力能满足NetworkRequest
//acceptRequest函数衡返回true,这是留给子类覆盖用的吧,一般没有覆盖
if (n.requested == false && n.score < mScore &&
n.request.networkCapabilities.satisfiedByNetworkCapabilities(
mCapabilityFilter) && acceptRequest(n.request, n.score)) {
if (VDBG) log(" needNetworkFor");
//进入子类的实现
needNetworkFor(n.request, n.score);
n.requested = true;
} else if (n.requested == true &&
(n.score > mScore || n.request.networkCapabilities.satisfiedByNetworkCapabilities(
mCapabilityFilter) == false || acceptRequest(n.request, n.score) == false)) {
if (VDBG) log(" releaseNetworkFor");
releaseNetworkFor(n.request);
n.requested = false;
} else {
if (VDBG) log(" done");
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
绕了一圈,我们现在可以看看PhoneSwitcher中创建的NetworkFactory的needNetworkFor函数:
@Override
protected void needNetworkFor(NetworkRequest networkRequest, int score) {
if (VDBG) log("needNetworkFor " + networkRequest + ", " + score);
Message msg = mPhoneSwitcher.obtainMessage(EVENT_REQUEST_NETWORK);
msg.obj = networkRequest;
//发送消息给自己的handler处理,将调用PhoneSwitcher中的onRequestNetwork处理
msg.sendToTarget();
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
private void onRequestNetwork(NetworkRequest networkRequest) {
//利用NetworkRequest构造DcRequest
final DcRequest dcRequest = new DcRequest(networkRequest, mContext);
//之前没有处理过的dcRequest,才会进行处理
if (mPrioritizedDcRequests.contains(dcRequest) == false) {
mPrioritizedDcRequests.add(dcRequest);
//根据优先级进行排序
Collections.sort(mPrioritizedDcRequests);
//评估,REQUESTS_CHANGED的值为true
onEvaluate(REQUESTS_CHANGED, "netRequest");
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
这里的唯一的问题就是“根据优先级排序”的概念。
我们花点时间来看看DcRequest这个类:
public class DcRequest implements Comparable<DcRequest> {
..........
public DcRequest(NetworkRequest nr, Context context) {
//初始化优先级排序规则
initApnPriorities(context);
networkRequest = nr;
//从NetworkReqeust得出对应的匹配APN id
apnId = apnIdForNetworkRequest(networkRequest);
//得到这个NetworkReqeust的优先级
priority = priorityForApnId(apnId);
}
.........
private void initApnPriorities(Context context) {
synchronized (sApnPriorityMap) {
//初始化优先级配置仅用执行一次
if (sApnPriorityMap.isEmpty()) {
//解析xml文件,得到配置信息
String[] networkConfigStrings = context.getResources().getStringArray(
com.android.internal.R.array.networkAttributes);
for (String networkConfigString : networkConfigStrings) {
NetworkConfig networkConfig = new NetworkConfig(networkConfigString);
//从配置信息中,得到apnId
final int apnId = ApnContext.apnIdForType(networkConfig.type);
//以键值对的方式,将apnId和优先级信息放入到sApnPriorityMap中
sApnPriorityMap.put(apnId, networkConfig.priority);
}
}
}
}
.........
private int apnIdForNetworkRequest(NetworkRequest nr) {
NetworkCapabilities nc = nr.networkCapabilities;
// For now, ignore the bandwidth stuff
if (nc.getTransportTypes().length > 0 &&
nc.hasTransport(NetworkCapabilities.TRANSPORT_CELLULAR) == false) {
return APN_INVALID_ID;
}
int apnId = APN_INVALID_ID;
boolean error = false;
//其实就是根据NetworkRequest申请的NetworkCapbility,来决定对应的apnId
if (nc.hasCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET)) {
if (apnId != APN_INVALID_ID) error = true;
apnId = APN_DEFAULT_ID;
}
if (nc.hasCapability(NetworkCapabilities.NET_CAPABILITY_MMS)) {
if (apnId != APN_INVALID_ID) error = true;
apnId = APN_MMS_ID;
}
......
return apnId;
}
..........
public int compareTo(DcRequest o) {
return o.priority - priority;
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
从上面的代码,我们知道DcRequest其实就是根据xml中的配置文件得到每个Apn对应的优先级;然后,根据每个NetworkRequest需要的NetworkCapabilities得到对应的apnId;最终,根据apnId的优先级,完成对NetworkRequest的优先级排序。
其中,networkAttributes定义于frameworks/base/core/res/res/values/config.xml中:
<string-array translatable="false" name="networkAttributes">
<item>"wifi,1,1,1,-1,true"</item>
<item>"mobile,0,0,0,-1,true"</item>
<item>"mobile_mms,2,0,2,60000,true"</item>
<item>"mobile_supl,3,0,2,60000,true"</item>
<item>"mobile_hipri,5,0,3,60000,true"</item>
<item>"mobile_fota,10,0,2,60000,true"</item>
<item>"mobile_ims,11,0,2,60000,true"</item>
<item>"mobile_cbs,12,0,2,60000,true"</item>
<item>"wifi_p2p,13,1,0,-1,true"</item>
<item>"mobile_ia,14,0,2,-1,true"</item>
<item>"mobile_emergency,15,0,2,-1,true"</item>
</string-array>
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
根据NetworkConfig的构造函数,我们看出每一行的第4位表示优先级。结合DcReqeust中的compareTo函数,我们知道数字越大,优先级越高,例如mobile_mms的优先级要高于mobile:
public NetworkConfig(String init) {
String fragments[] = init.split(",");
name = fragments[0].trim().toLowerCase(Locale.ROOT);
type = Integer.parseInt(fragments[1]);
radio = Integer.parseInt(fragments[2]);
priority = Integer.parseInt(fragments[3]);
restoreTime = Integer.parseInt(fragments[4]);
dependencyMet = Boolean.parseBoolean(fragments[5]);
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
现在继续回到PhoneSwitcher处理NetworkRequest的流程中来,PhoneSwitcher根据优先级对NetworkRequest排序后,将调用onEvaluate方法:
private void onEvaluate(boolean requestsChanged, String reason) {
........
//此时,传入的参数为true
boolean diffDetected = requestsChanged;
//检测卡信息是否发生变化,我们此时分析不插卡的流程,暂不关注这个
//即使插了卡,也不影响当前流程
........
if (diffDetected) {
List<Integer> newActivePhones = new ArrayList<Integer>();
//按优先级依次处理DcRequest
for (DcRequest dcRequest : mPrioritizedDcRequests) {
//根据networkRequest中NetworkCapabilities携带的Specifier参数,决定phoneId
int phoneIdForRequest = phoneIdForRequest(dcRequest.networkRequest);
if (phoneIdForRequest == INVALID_PHONE_INDEX) continue;
if (newActivePhones.contains(phoneIdForRequest)) continue;
newActivePhones.add(phoneIdForRequest);
//目前mMaxActivePhones的值为1,意味者找到优先级最高的DcRequest对应phone后,结束循环
if (newActivePhones.size() >= mMaxActivePhones) break;
}
..........
for (int phoneId = 0; phoneId < mNumPhones; phoneId++) {
if (newActivePhones.contains(phoneId) == false) {
//去激活 无法处理最高优先级DcRequest的phone 的数据拨号能力
deactivate(phoneId);
}
}
// only activate phones up to the limit
for (int phoneId : newActivePhones) {
//激活 能处理最高优先级DcRequest的phone 的数据拨号能力
activate(phoneId);
}
}
}
private int phoneIdForRequest(NetworkRequest netRequest) {
//在此流程中,specifier的值为空
//一般发送彩信,建立彩信网络时,才会指定specifier为对应卡的subId
String specifier = netRequest.networkCapabilities.getNetworkSpecifier();
int subId;
if (TextUtils.isEmpty(specifier)) {
//为空时,取subId为默认数据卡的subId
//我们分析不插卡的流程时,mDefaultDataSubscription为初始值0
subId = mDefaultDataSubscription;
} else {
subId = Integer.parseInt(specifier);
}
int phoneId = INVALID_PHONE_INDEX;
if (subId == INVALID_SUBSCRIPTION_ID) return phoneId;
for (int i = 0 ; i < mNumPhones; i++) {
if (mPhoneSubscriptions[i] == subId) {
//我们分析不插卡的流程时,phoneId最后取0
//实际插卡情况,将有specifier来具体决定
phoneId = i;
break;
}
}
return phoneId;
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
最后,我们来看看deactivate和activate函数:
private void deactivate(int phoneId) {
PhoneState state = mPhoneStates[phoneId];
if (state.active == false) return;
//记录对应phone的激活状态
state.active = false;
log("deactivate " + phoneId);
state.lastRequested = System.currentTimeMillis();
//mCommandsInterfaces[phoneId]其实就是RIL对象
//这里其实就是通过RIL发送消息给modem,取消对应phone的数据拨号能力
mCommandsInterfaces[phoneId].setDataAllowed(false, null);
//通知观察者
mActivePhoneRegistrants[phoneId].notifyRegistrants();
}
private void activate(int phoneId) {
PhoneState state = mPhoneStates[phoneId];
if (state.active == true) return;
state.active = true;
log("activate " + phoneId);
state.lastRequested = System.currentTimeMillis();
//同样,通过RIL发送消息
mCommandsInterfaces[phoneId].setDataAllowed(true, null);
//通知观察者
mActivePhoneRegistrants[phoneId].notifyRegistrants();
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
PhoneSwitcher的上述流程,最终激活了一个Phone的数据拨号能力,完成拨号前的第一部分准备工作。
2.2 TelephonyNetworkFactory
PhoneSwitcher只是决定了那一个Phone具有拨号能力,在实际拨号前还需要激活可用的APN。这一部分工作需要TelephonyNetworkFactory来主动承担。
public class TelephonyNetworkFactory extends NetworkFactory {
..........
public TelephonyNetworkFactory(.....) {
super(looper, context, "TelephonyNetworkFactory[" + phoneId + "]", null);
//创建内部的handler
mInternalHandler = new InternalHandler(looper);
//设定TelephonyNetworkFactory的网络能力,决定了它能处理的NetworkReqeust
setCapabilityFilter(makeNetworkFilter(subscriptionController, phoneId));
//NetworkFactory的分数为50
setScoreFilter(TELEPHONY_NETWORK_SCORE);
............
//创建时,TelephonyNetworkFactory是非激活的
mIsActive = false;
//是PhoneSwitcher的观察者
mPhoneSwitcher.registerForActivePhoneSwitch(mPhoneId, mInternalHandler,
EVENT_ACTIVE_PHONE_SWITCH, null);
//监听卡变化的情况
............
//同样注册到ConnectivityService
register();
}
private NetworkCapabilities makeNetworkFilter(SubscriptionController subscriptionController,
int phoneId) {
final int subscriptionId = subscriptionController.getSubIdUsingPhoneId(phoneId);
return makeNetworkFilter(subscriptionId);
}
//指定了TelephonyNetworkFactory的NetworkCapabilities
private NetworkCapabilities makeNetworkFilter(int subscriptionId) {
NetworkCapabilities nc = new NetworkCapabilities();
nc.addTransportType(NetworkCapabilities.TRANSPORT_CELLULAR);
nc.addCapability(NetworkCapabilities.NET_CAPABILITY_MMS);
nc.addCapability(NetworkCapabilities.NET_CAPABILITY_SUPL);
nc.addCapability(NetworkCapabilities.NET_CAPABILITY_DUN);
nc.addCapability(NetworkCapabilities.NET_CAPABILITY_FOTA);
nc.addCapability(NetworkCapabilities.NET_CAPABILITY_IMS);
nc.addCapability(NetworkCapabilities.NET_CAPABILITY_CBS);
nc.addCapability(NetworkCapabilities.NET_CAPABILITY_IA);
nc.addCapability(NetworkCapabilities.NET_CAPABILITY_RCS);
nc.addCapability(NetworkCapabilities.NET_CAPABILITY_XCAP);
nc.addCapability(NetworkCapabilities.NET_CAPABILITY_EIMS);
nc.addCapability(NetworkCapabilities.NET_CAPABILITY_NOT_RESTRICTED);
nc.addCapability(NetworkCapabilities.NET_CAPABILITY_INTERNET);
nc.setNetworkSpecifier(String.valueOf(subscriptionId));
return nc;
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
从上面的代码我们知道,在初始时每个Phone对应的TelephonyNetworkFactory的激活态均是false,并且均注册到了ConnectivityService。于是,与PhoneSwitcher一样,TelephonyNetworkFactory也会收到ConnectivityService发送的NetworkReqeust请求。
由于ConnectivityService创建的DefaultRequest只要求Internet能力,并且在没有建立其它网络的条件下(没有连接WiFi等网络),DefaultRequest的分数为0,因此两个Phone对应的TelephonyNetworkFactory均会处理ConnectivityService发送的NetworkReqeust请求。
与PhoneSwitcher一样,我们看看TelephonyNetworkFactory的needNetworkFor函数:
@Override
public void needNetworkFor(NetworkRequest networkRequest, int score) {
//发送消息,由onNeedNetworkFor函数处理
Message msg = mInternalHandler.obtainMessage(EVENT_NETWORK_REQUEST);
msg.obj = networkRequest;
msg.sendToTarget();
}
private void onNeedNetworkFor(Message msg) {
NetworkRequest networkRequest = (NetworkRequest)msg.obj;
boolean isApplicable = false;
LocalLog localLog = null;
//当NetworkReqeust的specifier为空时
if (TextUtils.isEmpty(networkRequest.networkCapabilities.getNetworkSpecifier())) {
// request only for the default network
localLog = mDefaultRequests.get(networkRequest);
if (localLog == null) {
localLog = new LocalLog(REQUEST_LOG_SIZE);
localLog.log("created for " + networkRequest);
mDefaultRequests.put(networkRequest, localLog);
//只有default phone才能处理这个NetworkReqeust
isApplicable = mIsDefault;
}
} else {
//当NetworkReqeust的specifier不为空时,只要之前没有处理过,就可以处理
//因为在收到NetworkRequest时,父类的evalRequest中,已经通过NetworkCapabilities匹配过了
localLog = mSpecificRequests.get(networkRequest);
if (localLog == null) {
localLog = new LocalLog(REQUEST_LOG_SIZE);
mSpecificRequests.put(networkRequest, localLog);
isApplicable = true;
}
}
//只有TelephonyNetworkFactory处于激活态,并且能够处理时,才进入该分支
if (mIsActive && isApplicable) {
String s = "onNeedNetworkFor";
localLog.log(s);
log(s + " " + networkRequest);
mDcTracker.requestNetwork(networkRequest, localLog);
} else {
String s = "not acting - isApp=" + isApplicable + ", isAct=" + mIsActive;
localLog.log(s);
log(s + " " + networkRequest);
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
从上面的代码我们知道,在TelephonyNetworkFactory被激活前,它收到NetworkRequest的请求,但不会进行实际操作,直到PhoneSwitcher完成了激活Phone拨号能力的操作。
在TelephonyNetworkFactory的构造函数中,向PhoneSwitcher注册了观察对象,当发现Phone的激活态改变后,将向内部handler发送EVENT_ACTIVE_PHONE_SWITCH消息。内部handler收到消息后,将调用onActivePhoneSwitch进行处理。
private void onActivePhoneSwitch() {
//根据PhoneSwitcher中记录的phoneState决定自己是否active
final boolean newIsActive = mPhoneSwitcher.isPhoneActive(mPhoneId);
//自己的active状态改变后,处理request
if (mIsActive != newIsActive) {
mIsActive = newIsActive;
String logString = "onActivePhoneSwitch(" + mIsActive + ", " + mIsDefault + ")";
if (DBG) log(logString);
//mIsActive的值,决定了requestNetwork,还是releaseNetwork
//android7.0中,defaultRequest与specificRequest分别装在了不同的map中
if (mIsDefault) {
applyRequests(mDefaultRequests, (mIsActive ? REQUEST : RELEASE), logString);
}
applyRequests(mSpecificRequests, (mIsActive ? REQUEST : RELEASE), logString);
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
从上面的代码,可以看出当PhoneSwitcher改变TelephonyNetworkFactory的激活状态后,TelephonyNetworkFactory将根据各自的状态,调用applyRequests函数:
private void applyRequests(HashMap<NetworkRequest, LocalLog> requestMap, boolean action,
String logStr) {
for (NetworkRequest networkRequest : requestMap.keySet()) {
LocalLog localLog = requestMap.get(networkRequest);
localLog.log(logStr);
if (action == REQUEST) {
//我们关注active phone的操作
mDcTracker.requestNetwork(networkRequest, localLog);
} else {
mDcTracker.releaseNetwork(networkRequest, localLog);
}
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
根据上面的代码,我们知道了流程走到了DcTracker。
DcTracker是PhoneFactory创建GsmCdmaPhone时,在GsmCdmaPhone内部创建的,与TelephonyNetworkFactory一样,每个phone对象持有一个。
public GsmCdmaPhone(.....) {
........
mDcTracker = mTelephonyComponentFactory.makeDcTracker(this);
........
}
- 1
- 2
- 3
- 4
- 5
TelephonyComponentFactory是一个单例对象:
public static TelephonyComponentFactory getInstance() {
if (sInstance == null) {
sInstance = new TelephonyComponentFactory();
}
return sInstance;
}
public DcTracker makeDcTracker(Phone phone) {
return new DcTracker(phone);
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
我们回到拨号前的准备流程,看看DcTracker的requestNetwork函数:
public void requestNetwork(NetworkRequest networkRequest, LocalLog log) {
//与上文中定义APN优先级一样,根据NetworkRequest的NetworkCapabilities得到对应的ApnId
final int apnId = ApnContext.apnIdForNetworkRequest(networkRequest);
//判断DcTracker能否处理该APN
final ApnContext apnContext = mApnContextsById.get(apnId);
log.log("DcTracker.requestNetwork for " + networkRequest + " found " + apnContext);
//能够处理时,就调用ApnContext的incRefCount方法
if (apnContext != null) apnContext.incRefCount(log);
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
上面的代码中唯一的疑点是mApnContextsById是如何定义的?这就必须提及DcTracker的构造函数了。
public DcTracker(Phone phone) {
.......
//初始化APN Context
initApnContexts();
.......
}
private void initApnContexts() {
String[] networkConfigStrings = mPhone.getContext().getResources().getStringArray(
com.android.internal.R.array.networkAttributes);
for (String networkConfigString : networkConfigStrings) {
NetworkConfig networkConfig = new NetworkConfig(networkConfigString);
ApnContext apnContext = null;
switch (networkConfig.type) {
case ConnectivityManager.TYPE_MOBILE:
apnContext = addApnContext(PhoneConstants.APN_TYPE_DEFAULT, networkConfig);
break;
case ConnectivityManager.TYPE_MOBILE_MMS:
apnContext = addApnContext(PhoneConstants.APN_TYPE_MMS, networkConfig);
break;
......
}
..........
}
private ApnContext addApnContext(String type, NetworkConfig networkConfig) {
ApnContext apnContext = new ApnContext(mPhone, type, LOG_TAG, networkConfig, this);
mApnContexts.put(type, apnContext);
mApnContextsById.put(ApnContext.apnIdForApnName(type), apnContext);
mPrioritySortedApnContexts.add(apnContext);
return apnContext;
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
从上面的代码可以看出,mApnContextsById中的Apn记录也是从config.xml中读取出来的,因此ApnContext的incRefCount方法可以得到执行:
public void incRefCount(LocalLog log) {
synchronized (mRefCountLock) {
if (mLocalLogs.contains(log)) {
log.log("ApnContext.incRefCount has duplicate add - " + mRefCount);
} else {
mLocalLogs.add(log);
log.log("ApnContext.incRefCount - " + mRefCount);
}
//每种APN类型只激活一次
if (mRefCount++ == 0) {
//这里重新调用DcTracker的setEnabled函数,传入的参数之一是可用的ApnId
//也就是说这一类APN是可以使用的,例如如果激活的ApnId为DctConstants.APN_DEFAULT_ID
//那么所有具有default属性的APN均可以使用了
mDcTracker.setEnabled(apnIdForApnName(mApnType), true);
}
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
最后我们来看看DcTracker的setEnabled函数。
public void setEnabled(int id, boolean enable) {
//发送消息给内部handler处理,将调用onEnableApn进行处理
Message msg = obtainMessage(DctConstants.EVENT_ENABLE_NEW_APN);
msg.arg1 = id;
msg.arg2 = (enable ? DctConstants.ENABLED : DctConstants.DISABLED);
sendMessage(msg);
}
private void onEnableApn(int apnId, int enabled) {
ApnContext apnContext = mApnContextsById.get(apnId);
if (apnContext == null) {
loge("onEnableApn(" + apnId + ", " + enabled + "): NO ApnContext");
return;
}
// TODO change our retry manager to use the appropriate numbers for the new APN
if (DBG) log("onEnableApn: apnContext=" + apnContext + " call applyNewState");
//更新apnContext的state
//DependencyMet由config.xml得到,均为true
applyNewState(apnContext, enabled == DctConstants.ENABLED, apnContext.getDependencyMet());
}
private void applyNewState(ApnContext apnContext, boolean enabled, boolean met) {
boolean cleanup = false;
boolean trySetup = false;
........
//初始时,apnContext not ready
if (apnContext.isReady()) {
......
} else {
//传入参数中,enabled与met均为true
if (enabled && met) {
if (apnContext.isEnabled()) {
apnContext.setReason(Phone.REASON_DATA_DEPENDENCY_MET);
} else {
apnContext.setReason(Phone.REASON_DATA_ENABLED);
}
if (apnContext.getState() == DctConstants.State.FAILED) {
apnContext.setState(DctConstants.State.IDLE);
}
trySetup = true;
}
}
//完成准备工作!!!拨号依赖于此条件
apnContext.setEnabled(enabled);
apnContext.setDependencyMet(met);
if (cleanup) cleanUpConnection(true, apnContext);
if (trySetup) {
apnContext.resetErrorCodeRetries();
//会触发拨号操作,当然此时没插卡,数据业务开关也没打开,不会通过RIL发送消息给modem
trySetupData(apnContext);
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
至此,TelephonyNetworkFactory再次完成了一部分数据拨号前的准备工作,激活了一个类型的APN。
3 DcTracker装载卡对应的APN信息
从这一节的标题就知道,我们要开始分析插入卡后的流程了,毕竟拨号是离不开SIM卡的(网络运营商提供的虚拟卡暂不考虑)。
我们先看看框架是如何知道手机中插入了卡。
卡实际上可以看做一种硬件设备,当卡插入手机后,会产生相应的电信号,触发相应的驱动工作。当然,这不是我们关注的重点,我们只需要知道的是,当检测到卡后,modem将主动上报RIL_UNSOL_RESPONSE_SIM_STATUS_CHANGED事件。
RIL收到该事件后,将通知其观察者:
case RIL_UNSOL_RESPONSE_SIM_STATUS_CHANGED:
if (RILJ_LOGD) unsljLog(response);
if (mIccStatusChangedRegistrants != null) {
mIccStatusChangedRegistrants.notifyRegistrants();
}
break;
- 1
- 2
- 3
- 4
- 5
- 6
- 7
那么谁是该事件的观察者呢?
我们知道在PhoneFactory的makeDefaultPhone中,创建过UiccController,看看UiccController构造函数的片段:
private UiccController(Context c, CommandsInterface []ci) {
..........
for (int i = 0; i < mCis.length; i++) {
Integer index = new Integer(i);
//从这里可以看出UiccController将监听IccStatusChanged事件
//监听到IccStatusChanged发送EVENT_ICC_STATUS_CHANGED消息给自己处理
mCis[i].registerForIccStatusChanged(this, EVENT_ICC_STATUS_CHANGED, index);
.............
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
@Override
public void handleMessage (Message msg) {
.......
switch (msg.what) {
case EVENT_ICC_STATUS_CHANGED:
if (DBG) log("Received EVENT_ICC_STATUS_CHANGED, calling getIccCardStatus");
//利用RIL从modem获取卡信息,获取到卡信息后,发送EVENT_GET_ICC_STATUS_DONE给自己处理
mCis[index].getIccCardStatus(obtainMessage(EVENT_GET_ICC_STATUS_DONE, index));
break;
case EVENT_GET_ICC_STATUS_DONE:
if (DBG) log("Received EVENT_GET_ICC_STATUS_DONE");
//获取到卡信息后,进行处理
onGetIccCardStatusDone(ar, index);
break;
......
}
.......
}
private synchronized void onGetIccCardStatusDone(AsyncResult ar, Integer index) {
........
IccCardStatus status = (IccCardStatus)ar.result;
//利用获取的卡信息,形成抽象的卡对象
if (mUiccCards[index] == null) {
//Create new card
mUiccCards[index] = new UiccCard(mContext, mCis[index], status, index);
} else {
//Update already existing card
mUiccCards[index].update(mContext, mCis[index] , status);
}
if (DBG) log("Notifying IccChangedRegistrants");
//通知自己的观察者
mIccChangedRegistrants.notifyRegistrants(new AsyncResult(null, index, null));
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
UiccController的观察者比较多,其中就有我们关注的DcTracker,在DcTracker的构造函数中,就有如下片段:
public DcTracker(Phone phone) {
.......
mUiccController = UiccController.getInstance();
//收到UiccController的通知后,将发送EVENT_ICC_CHANGED给自己处理,调用函数为onUpdateIcc
mUiccController.registerForIccChanged(this, DctConstants.EVENT_ICC_CHANGED, null);
.......
}
private void onUpdateIcc() {
if (mUiccController == null ) {
return;
}
//利用UiccController获取卡信息
IccRecords newIccRecords = getUiccRecords(UiccController.APP_FAM_3GPP);
IccRecords r = mIccRecords.get();
if (r != newIccRecords) {
if (r != null) {
log("Removing stale icc objects.");
r.unregisterForRecordsLoaded(this);
mIccRecords.set(null);
}
if (newIccRecords != null) {
if (SubscriptionManager.isValidSubscriptionId(mPhone.getSubId())) {
log("New records found.");
mIccRecords.set(newIccRecords);
//监听卡信息是否载入完成,IccRecords的子类负责通知
newIccRecords.registerForRecordsLoaded(
this, DctConstants.EVENT_RECORDS_LOADED, null);
SubscriptionController.getInstance().setSimProvisioningStatus(
SubscriptionManager.SIM_PROVISIONED, mPhone.getSubId());
}
} else {
onSimNotReady();
}
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
当DcTracker监听到卡信息载入完成后,处理EVENT_RECORDS_LOADED事件:
..........
case DctConstants.EVENT_RECORDS_LOADED:
// If onRecordsLoadedOrSubIdChanged() is not called here, it should be called on
// onSubscriptionsChanged() when a valid subId is available.
int subId = mPhone.getSubId();
//卡载入完成,应该已经有了有效的subId
if (SubscriptionManager.isValidSubscriptionId(subId)) {
//调用该函数
onRecordsLoadedOrSubIdChanged();
} else {
log("Ignoring EVENT_RECORDS_LOADED as subId is not valid: " + subId);
}
break;
........
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
private void onRecordsLoadedOrSubIdChanged() {
............
//创建APN list
createAllApnList();
//从所有可用APN中,选择一个APN通过RIL发送给modem
//选择顺序是IA(支持IA类型的APN)、prefer(用户选择的)、 default(支持default类型的)、 first(mApnSettings中的第一个)
setInitialAttachApn();
//判断modem的radio是否处于开启状态
if (mPhone.mCi.getRadioState().isOn()) {
if (DBG) log("onRecordsLoadedOrSubIdChanged: notifying data availability");
//发送一个通知而已
notifyOffApnsOfAvailability(Phone.REASON_SIM_LOADED);
}
//进行数据拨号,注意此时数据业务开关如果是开的,才能利用RIL发送信息给modem
setupDataOnConnectableApns(Phone.REASON_SIM_LOADED);
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
我们看看createAllApnList函数:
private void createAllApnList() {
.......
mAllApnSettings = new ArrayList<ApnSetting>();
IccRecords r = mIccRecords.get();
String operator = (r != null) ? r.getOperatorNumeric() : "";
String operator = (r != null) ? r.getOperatorNumeric() : "";
if (operator != null) {
//根据运营商构造selection语句
String selection = "numeric = '" + operator + "'";
String orderBy = "_id";
//查询数据库
Cursor cursor = mPhone.getContext().getContentResolver().query( Telephony.Carriers.CONTENT_URI, null, selection, null, orderBy);
if (cursor != null) {
if (cursor.getCount() > 0) {
//该函数内部利用makeApnSettings函数,根据数据库字段,构造当前卡可以使用的Apn
mAllApnSettings = createApnList(cursor);
}
cursor.close();
}
//增加紧急拨号类型的APN
addEmergencyApnSetting();
//删除重复的APN
dedupeApnSettings();
if (mAllApnSettings.isEmpty()) {
mPreferredApn = null;
} else {
//获取prefer APN(即优先使用的APN)
//根据subId匹配,将数据库中对应的APN按名称ASC(升序)排列后,取出数据库中第一个APN的id
//轮询当前卡的AllApnSettings,匹配id并且能满足NetworkRequest要求的APN就是prefer APN
//用户不设置的话,初始时应该是没有的
mPreferredApn = getPreferredApn();
//优选APN不适用于当期运营商的话,则不设定优选APN
if (mPreferredApn != null && !mPreferredApn.numeric.equals(operator)) {
mPreferredApn = null;
setPreferredApn(-1);
}
}
}
//调用RIL的接口setDataProfile,向modem发送dataProfie,即发送当期卡可用的APN信息给modem
setDataProfilesAsNeeded();
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
至此,我们做好了数据拨号前的所有工作,用户点击数据业务开关后,就可以开始拨号流程了。
当然上述过程过于繁杂,涉及的细节比较多,因此还是需要整理一下流程图和类图:
流程图对应链接
结束语
以上的流程图和类图都是比较简易的。
实际终端的开机过程,可能和流程图存在一定时序上的偏差,但大致流程应该一致;类图并没有严格分析每个类之间的关系,仅仅描述了主要类的关系。
最后需要说明的是,目前的逻辑都是按照Android 7.0原生流程来分析的,实际终端的软件版本应该与此有些差异。不论MTK还是Qualcomm应该都会根据自己的芯片能力,对原生流程进行修改。
举例来说,原生流程中,PhoneSwitcher直接通过setDataAllowed激活Phone的数据拨号能力,然后立马就通知TelephonyNetworkFactory。
这实在是高估了底层芯片的能力,自己目前还没有拿到Qualcomm和MTK的代码,但觉得这里应该会像Android6.0一样,必须等底层芯片返回数据能力设置成功的信息后,才会通知TelephonyNetworkFactory。甚至考虑到底层的异常,厂商应该还是会引入状态机进行控制。
原文地址:http://blog.csdn.net/gaugamela/article/details/52325196