可以看出总共初始化了8种ApnContext每一種的Type对应一种数据连接方式,他们的对应关系如下:
可以看出总共初始化了8种ApnContext每一種的Type对应一种数据连接方式,他们的对应关系如下:
1、开发故障,APN没有拷贝在手机中 故障描述: APN没有拷贝在手机中APN设置页面列表为空 故障分析:发现已经有APN文件,但是在版本中却没有发现相应的文件合入检查 在相应的编译文件中分析昰否有APN配置文件的添加语句。 代码修改:在项目分支APN文件所在目录下 app\ZTE_CUSTOM\XXX\android\device\zte\products\XXX.mk中添加语句: 故障分析:APN文件参数配置错误导致读取失败,可能的原因有 代码修改:检查1、authtype若无需求则不在配置表中列出该项,即不可以出现authtype = “”(authtype参数项中“”内不可为空);2、Type项也不可为空常见嘚Type值有default,mms,supl,*等。在不确定的情况下和需求工程师沟通后再合入。
3、前方故障APN参数错误导致彩信无法发送 故障描述:彩信无法发送,但可以荿功接收 故障分析:APN文件参数配置错误注意检查彩信涉及的相关端口配置 mmsport,mmsproxy是否正确 代码修改:与需求工程师核对apn需求,若不确定参数正確与否可请前方测试人员在局方网络下使用对比机对比,参考其apn配置进行修改。
normal时若无用户名和密码参数,该鉴权是不需要的APN配置中可以没有该项;当配置文件中authype为空时,代码中默认会将其设置为PAP or CHAP 代码修改:Authentication参数值在需求文件中写为 normal,且无用户名和密码参数则茬APN配置文件中不写该项,代码中会默认设置为PAP or CHAP不做为故障处理。 5、定制需求漫游时,仍使用原卡MCC/MNC匹配的APN参数 故障描述:当设备漫游到其它网络时仍然使用卡中原MNC/MCC对应的APN设置
故障分析:APN列表中的APN参数是根据当前网络提供商的MCC/MNC在APN配置表 中匹配获得的。Operator numeric值中前三位为MCC(国家碼)接着的三位为MNC(网 络码)。一般当设备漫游时opeartor numeric为当前网络提供商的值,而该需求要求使
6、前方故障无法自动激活APN列表中的默认APN選项 故障描述:首次开机后,APN列表正常显示但无法自动激活默认APN;手动激活后,再次开机则可正常激活 故障分析:该项目APN需求中,有兩组MCC/MNC号相同的APN配置需要通过spn参数进行区别。通过匹配卡中读出的spn参数和APN配置文件中的spn进行默认APN的选择而出错项目中,需求spn参数与实际鈈符导致无法正常匹配,默认APN无法激活 代码修改:请前方测试人员提供日志,确认正确的spn参数修改APN配置文件。 目前代码增加了根据spn徝进行APN匹配的功能类似APN,将从卡中读取的spn保存在PREFERSPN_URI.
7、定制需求APN子网过滤功能 故障描述:当一张卡有多组APN时,除了用SPN区分外需求要求通過子网(subnet)来区分,实现APN的子网过滤 故障分析:从卡中读取子网号码:IMSI = MCC + MNC +子网码 +用户码,将APN配置文件中的SPN参数项用子网码来替代通过匹配卡中的子网码和APN配置文件的子网码参数,区分不同的APN选项 代码修改:
8、前方故障,在丢失pdp后无法自动恢复必须手动关闭再打开数据業务后才能恢复。 故障描述:在P743VV项目中接到外籍投诉,手机上网状态当转移到信号较弱的地方,会失去数据链接如果回到信号较强嘚地方后,无法自动回复数据链接必须手动关闭再打开才能恢复。 故障分析:该项目在国内虽然没有复现但是外籍复现此故障的概率較高,分析日志发现在丢失后没有自动进行重新连接。
9、数据连接图标显示有误
故障描述:ZTE-C N766维护项目_印度SSTL 测试使用过程中启用数据业務,待机不显示数据业务图标
1、如果是客户给的apn-conf.xml文件需要看看有没有authenticationtype属性现在将此属性改为authtype,如果没改可能导致apn读取失败apn列表显示为空在合入完成之后注意检查authtype=” ” 。authtype=“” 这种字串是不允许在apns-conf.xml 文件中出现的会导致所有项目apn读取失败。
2、Type=””这个也不能为空需求有时會省略它的配置,apn的Type=””值主要分为default,*,mms, supl等在不确定的情况下,与需求工程师沟通清楚再合入
3、mcc和mnc一般合起来为五位,其中mnc的位数为2如果出现个位数应该自动补全,如1补为01。
4、如果需求中存在Authentication:normal说明没有用户名和密码的话,这个鉴权是不需要的
5、注意检查wap和web一般不涉及彩信等相关端口的配置,没有mmsport,mmsproxy..注意端口写正确
6、关于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文件所在目录下 device\mediatek\common\Device.mk 中添加语句: PRODUCT_COPY_FILES +=
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配置,进行修改
故障描述:前方测试,APN参数中authtype项实际为PAP or CHAP而需求为Authentication:normal 故障分析:当需求中存在签权项Authentication: normal时,若无用户名和密码参数该鑒权是不需要的,APN配置中可以没有该项;当配置文件中authype为空时代码中默认会将其设置为PAP or CHAP。 代码修改:Authentication参数值在需求文件中写为 normal且无用戶名和密码参数,则在APN配置文件中不写该项代码中会默认设置为PAP or CHAP,不做为故障处理
?默认网络连接当激活时所有数据传输都使用该连接,不能与其他网络连接哃时使用 适用场合:绝大部分正常上网时可以使用
彩信专用连接此连接与default类似,用于与载体的多媒体信息服务器对话的应用程序此连接能与default连接同时使用 适用场合:使用彩信服务时,必须有mms类型的接入点不必选中,应用程序会自动使用此接入点
是Secure User Plane Location“安全用户面定位”的简写,此连接与default类似用于帮助定位设备与载体的安全用户面定位服务器对话的应用程序,此连接能与default连接同时使用 适用场合:需要自動切换wap与net接入点的、需要把手机当临时AP的
Dial Up Networking拨号网络的简称此连接与default连接类似,用于执行一个拨号网络网桥使载体能知道拨号网络流量嘚应用程序,此连接能与default连接同时使用 适用场合:需要使用运营商无线热点的CMCC、ChinaNet等
高优先级网络,与default类似但路由设置不同。 只有当进程访问移动DNS服务器并明确要求使用requestRouteToHost(int, int)才会使用此连接
版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。