工作一年了，好久没来，默默地当颗小螺丝钉。今天借此机会把学习的写一下，记录下。最近工作在交接，正好总结回顾，这一年，主要和三个字母打交道A，P，N。
APN
概述：
APN
的类型分为
web(internet),wap,mms
三种类型，用于手机中上网时数据交换的接入点名称配置与显示。
APN
配置的时候，出现的
type
的值主要有：
default
，
mms,supl,dun
。
D
efault
常用于一般的数据业务，主要有
internet,wap,web.mms
类型用于彩信接收发送的业务；
supl
用于
gprs
上网；
dun
用于
wifi
等上网类型。
配置时注意事项：
1
、在合入完成之后注意检查
authtype
=
”
”
。
authtype
=
“”
这种字串是不允许在
apns-conf.xml
文件中出现的，会导致所有项目
apn
读取失败。
2、
T
ype=
””
这个也不能为空，需求有时会省略它的配置，
apn
的
T
ype=
””
值主要分为default,*,mms,
supl
等，在不确定的情况下，与需求工程师沟通清楚再合入。
3、注释的错误，在xml文件中，注释的格式为如
<!—
V9
Telia
end–>
，注意后面的必须是
–>
，否则会有编译不过的错误。
4、mcc和mnc一般合起来为五位，其中mnc的位数为2，如果出现个位数应该自动补全，如1，补为01。
5、
如果需求中存在
Authentication
：
normal
。
说明
没有用户名和密码的话，这个鉴权是不需要的。
6
、注意检查
wap
和
web
一般不涉及彩信等相关端口的配置，没有
mmsport,mmsproxy..
注意端口写正确。
7
、关于
authtype
,
需求表中没有注明的情况下置为
PAP
or
CHAP
或者空（没有
authtype
这一项）都可以的。
authtype
这一项未填写，不管有无用户名，会自动默认为
PAP
or
CHAP
。
8
、
dun
类型的
apn
就是专门用做
tethering
的。
如果没有
dun
类型的
apn
，默认用
default
的。
dun
后面加上
default
，是为了在
tethering
模式下可以进行下载操作。目前很多需求上明确写明只有
dun
，则按照需求处理。
检查方法：
1、验证其语法的正确性，可以直接双击用浏览器自带的编译xml检查其语法格式的正确性，不正确的会在浏览器末尾报错。
2、验证其读取的正确性：
请将配置文件替换到手机，验证一下配置文件的正确性：
方法：
adb
push
apns-conf.xml
system/etc
然后在
apnsetting
界面
点击
reset
to
default
。
3、
修改手机预设
apn
的方法：
预设的文件在手机的
system/etc
目录
文件名字叫
apns-conf.xml
，可以使用
rm
apns-conf.xml
命令将这个删了
然后到
apn
设置的界面去，恢复下默认设置，这个预设的就没有了，就可以手动设置了。
常见故障：
1
、开发故障，
APN
没有拷贝在手机中
故障描述
：
APN
没有拷贝在手机中，
APN
设置页面列表为空
故障分析
：发现已经有
APN
文件，但是在版本中却没有发现相应的文件合入，检查
在相应的编译文件中分析是否有
APN
配置文件的添加语句。
代码修改
：在项目分支
APN
文件所在目录下
app\ZTE_CUSTOM\
XXX
\android\device\zte\products\
XXX
.mk
中添加语句：
PRODUCT_COPY_FILES
+=
device/zte/products/apns-conf.xml:system/etc/apns-conf.xml
就可保证相应的
APN
文件添加到手机中。
2
、自测，
APN
文件读取失败
故障描述
：自测时，
push
APN
配置文件到
system/etc/
后，执行“重置为默认
APN
”操作。
APN
列表为空，
说明
APN
文件读取失败。
故障分析
：
APN
文件参数配置错误，导致读取失败，可能的原因有
代码修改
：检查
1
、
authtype
若无需求，则不在配置表中列出该项，即不可以出现
authtype
=
“”
（
authtype
参数项中
“”
内不可为空）；
2
、
Type
项也不可为空。常见的
Type
值有
default,mms,supl,*
等。在不确定的情况下，和需求工程师沟通后再合入。
3
、前方故障，
APN
参数错误导致彩信无法发送
故障描述
：彩信无法发送，但可以成功接收
故障分析
：
APN
文件参数配置错误，注意检查彩信涉及的相关端口配置
mmsport,mmsproxy
是否正确
代码修改
：与需求工程师核对
apn
需求，若不确定参数正确与否，可请前方测试人员在局方网络下使用对比机对比，参考其
apn
配置，进行修改。
4
、前方故障，
APN
参数
Authentication
前方实测与需求不符
故障描述
：前方测试，
APN
参数中
authtype
项实际为
PAP
or
CHAP
，而需求为
Authentication:normal
故障分析
：当需求中存在签权项
Authentication:
normal
时，若无用户名和密码参数，该鉴权是不需要的，
APN
配置中可以没有该项；当配置文件中
authype
为空时，代码中默认会将其设置为
PAP
or
CHAP
。
代码修改
：
Authentication
参数值在需求文件中写为
normal
，且无用户名和密码参数，则在
APN
配置文件中不写该项，代码中会默认设置为
PAP
or
CHAP
，不做为故障处理。
5
、定制需求，漫游时，仍使用原卡
MCC/MNC
匹配的
APN
参数
故障描述
：当设备漫游到其它网络时，仍然使用卡中原
MNC/MCC
对应的
APN
设置
故障分析
：
APN
列表中的
APN
参数是根据当前网络提供商的
MCC/MNC
在
APN
配置表
中匹配获得的。
O
perator
numeric
值中前三位为
MCC
（国家码），接着的三位为
MNC
（网
络码）。一般当设备漫游时，
opeartor
numeric
为当前网络提供商的值，而该需求要求使
用原卡的
MCC/MNC
的
APN
配置，则需要在读取
operator
numeric
处做相应的修改（参
考
7x27GB
项目宏
ZTE_RLNC
）。
代码修改
：
SIMRecords.java
文件中，一般情况下，
operator
是由
PROPERTY_ICC_OPERATOR_NUMBERIC
定义；而此处定义为
numeric
=
SystemProperties.get(
“
gsm.operator.numeric.home
”
)
。
createAllApnList()
中，读取
operator
值
根据
numeric.home
进行
APN
匹配，完成
APN
装载。
6
、前方故障，无法自动激活
APN
列表中的默认
APN
选项
故障描述
：首次开机后，
APN
列表正常显示，但无法自动激活默认
APN
；手动激活后，再次开机则可正常激活。
故障分析：该项目
APN
需求中，有两组
MCC/MNC
号相同的
APN
配置，需要通过
spn
参数进行区别。通过匹配卡中读出的
spn
参数和
APN
配置文件中的
spn
进行默认
APN
的选择。而出错项目中，需求
spn
参数与实际不符，导致无法正常匹配，默认
APN
无法激活。
代码修改：请前方测试人员提供日志，确认正确的
spn
参数，修改
APN
配置文件。
目前代码增加了根据
spn
值进行
APN
匹配的功能，类似
APN
，将从卡中读取的
spn
保存在
PREFERSPN_URI.
createAllApnList()
代码中，若
mSelectSpn
=
getPreferredSpn()
，若
spn
不为空，则和
operator
作为
selection
，在
Telephony.Carriers.CONTENT_URI
中定位，选择适当的
Apn
参数加载到
allApns
中。
接着在
buildWaitingApns()
中，将卡中读出的
spn
参数值和
APN
配置表中读出的
spn
参数值进行比较，匹配
spn
相同的
Apn
配置作为
waitingApn
。
7
、定制需求，
APN
子网过滤功能
故障描述：当一张卡有多组
APN
时，除了用
SPN
区分外，需求要求通过子网（
subnet
）来区分，实现
APN
的子网过滤。
故障分析：从卡中读取子网号码：
IMSI
=
MCC
+
MNC
+
子网码
+
用户码，将
APN
配置文件中的
SPN
参数项用子网码来替代。通过匹配卡中的子网码和
APN
配置文件的子网码参数，区分不同的
APN
选项。
代码修改：
SIMRecord.java
中读取
subnet
值，并设置接口
property
名字为
”
gsm.operator.numeric.subnet
”
。
从卡上读取了
subnet
信息了后，在
GsmDataConnectionTracker
.java
中的
buildWaitingApn()
中，进行
subnet
匹配，选取
APN
添加到
APN
列表中。
8
、前方故障，在丢失
pdp
后无法自动恢复，必须手动关闭再打开数据业务后才能恢复。
故障描述
：在
P743VV
项目中，接到外籍投诉，手机上网状态，当转移到信号较弱的地方，会失去数据链接，如果回到信号较强的地方后，无法自动回复数据链接，必须手动关闭再打开才能恢复。
故障分析：该项目在国内虽然没有复现，但是外籍复现此故障的概率较高，分析日志，发现在丢失后没有自动进行重新连接。
代码修改：分析日志，出现这句话：“
onDataSetupComplete:
Not
all
permanent
failures,
retry
”
,
使执行这句话的操作失效，在
if
中添加宏控制
修改代码：
的
GsmDataConnectionTracker
.java
中：
9、
数据连接图标显示有误
故障描述
：
ZTE-C
N766维护项目_印度SSTL
测试使用过程中，启用数据业务，待机不显示数据业务图标
解决方法：
在使能数据连接时，StatusBarPolicy(Context
context)
里面监听器PhoneStateListener.LISTEN_DATA_CONNECTION_STATE会获得这个参数并上传，图标显示。
跟踪了代码，打了LOG，编译了framwork.发现在框架层Phonestatelistener.java里面走到了case
LISTEN_DATA_CONNECTION_STATE，这个函数onDataConnectionStateCha
nged(int
state,
int
networkType)也被调用，LISTEN_DATA_CONNECTION_STATE也被赋值。