这批Android 13设备在4G网络环境和WiFi内网之间来回切换时的表现把人折腾得够呛。现场最常见的情况是设备明明连着WiFi右上角也显示WiFi图标可应用上报数据时偏偏走的还是4G流量反过来4G有信号格但业务App提示无网络。调试过一批Android 13设备之后我对这个系统在网络选路、网络能力评估上的处理逻辑有了更完整的认识。这篇内容就把Android 13在4G蜂窝网络和WiFi内网场景下的链路原理、配置要点、排查思路完整讲一遍适合正在做设备管理、现场集成、Android系统调试以及相关App开发的同事参考理解这套逻辑之后很多玄学问题其实都能定位到具体环节。1. 先搞清楚双网并存的底层机制1.1 为什么手机能同时开着WiFi和4GAndroid的联网架构并不是同一时间只能有一个网络在工作。系统里的核心服务ConnectivityService同时管理着多个NetworkAgentWiFi是一个网络代理蜂窝数据是另一个网络代理它们各自独立注册独立维护链路状态互为备份也互为竞争关系。所以WiFi和4G同时打开这件事在系统层面是常态不是异常。Android 13沿用了这套多网络管理框架并且在新版本里对网络能力的细分更严格了。每个网络都会上报自己的能力集比如是否具备访问公网的能力、是否属于计费网络、当前信号强度、链路带宽估算值等。系统根据这些信息给每个活跃网络打分分数最高的那一个成为默认网络也就是承载默认路由、大多数应用流量实际走向的网络。其他网络依然存在但除非应用显式绑定否则普通流量不会走到它们上面。这里要纠正一个常见误区很多人以为WiFi断开之后4G才会启用实际上两个数据链路一直共存系统只是在路由层面决定默认流量走哪条。Android 13引入的网络逃生舱机制甚至允许某些应用在默认网络无公网能力时自动寻找替代网络这种设计背后的数据走向是做现场联调时需要非常清楚的。1.2 网络评分机制怎么决定默认网络可以把网络评分理解成系统内部的综合体检表。Android框架层有一个专门负责给网络打分的服务其评估维度可以简单概括为下表的几项。评估维度说明对默认网络的影响INTERNET能力网络是否通过了公网连通性验证未通过验证的网络评分大幅降低NOT_METERED能力是否属于不限流量网络计费网络在同等条件下评分偏低信号强度4G的RSRP/RSRQ、WiFi的RSSI信号太差会扣分链路带宽理论上下行速率估算值带宽明显更高时加分验证结果是否成功访问了系统的网络验证服务器验证失败视为无公网能力具体到Android 13系统会维护一个NetworkCapabilities对象里面有CAPABILITY_INTERNET、CAPABILITY_NOT_METERED、CAPABILITY_VALIDATED这些能力位。默认网络的选择就是从当前所有活跃网络里挑出综合条件最好的那个。带公网能力的网络比不带公网能力的网络拥有更高优先级的规则这也是为什么一个验证有效的4G网络往往能压过只提供内网访问、无法通过公网验证的WiFi成为默认网络。现场调试时最让人困惑的明明连着WiFi数据却走4G十有八九就是这个原因WiFi网络所在的内网无法访问公网验证服务器系统判定该WiFi不具备INTERNET能力于是默认网络被评分更高的4G拿走。1.3 不同视角下的链路差异站在不同角色的位置上理解同一套机制的方式不太一样。对终端使用者来说关注的是图标显示什么、流量走了哪条线对开发者或调试人员来说更关心的是系统的网络状态机处于哪个阶段而站在设备管理角度设备同时连着两个网络哪些流量走了哪个接口才是核心问题。Android 13里还有一项需要留意的行为当WiFi内网被判定为无公网能力时系统状态栏上WiFi图标下面可能出现一个感叹号。这个感叹号不代表网络故障它只是告诉你这个网络通不了公网。很多现场人员一看到感叹号就以为是WiFi坏了其实内网访问完全正常数据走4G只是因为系统默认路由策略使然。2. 4G蜂窝数据链路从APN到数据通道2.1 APN参数到底影响什么APN在很多文章里被轻描淡写成接入点名称但它在Android蜂窝网络里承担的任务要复杂得多。APN是一组参数集合决定了终端与运营商核心网之间建立的PDN连接类型。它包含APN名称、MCC/MNC、APN协议IPv4或IPv6、APN漫游协议、鉴权类型、用户名密码等字段。Android 13在开机注册网络时通过TelephonyNetworkFactory发起数据连接请求系统根据当前SIM卡信息去匹配运营商预置的APN配置匹配成功后才发起PDP/PDN上下文激活。这里有个容易踩坑的地方某些设备因为运营商配置更新不及时或者手动改过APN字段导致系统实际激活的PDN连接类型与业务平台预期不一致。实际操作中遇到4G无法拨号上网我的排查习惯是先看当前设备用的是哪个APN。打开设置里的接入点名称检查APN协议是否设成了IPv6而业务服务器只监听IPv4这种错配现场非常常见。直接用adb也可以查询adb shell dumpsys telephony.registry | grep -E mDataRegState|mDataNetworkType|mApnSetting看到mDataNetworkType显示LTE的同时还要确认mDataRegState是否为IN_SERVICE。如果注册状态异常只看APN没有任何意义需要先解决网络注册问题。2.2 信号格与数据通道是两回事信号格显示的其实是射频层面的信号质量比如LTE场景下对应的RSRP、RSRQ、SINR这些指标。而能不能上网取决于网络注册状态、PDN上下文是否激活、数据业务是否被运营商放行。这两个层面的状态并不总是同步。最常见的翻车现场就是信号满格但应用刷不出数据。这时候先别怀疑天线用命令查看数据注册状态adb shell dumpsys telephony.registry | grep -E mDataRegState|mDataNetworkType|mServiceState如果注册状态正常再确认移动数据开关状态adb shell settings get global mobile_data返回1代表开启0代表关闭。Android 13里即使数据开关开启若设备的数据漫游开关没打开在漫游地也一样出现有信号没数据。有些项目设备插的是物联网卡这类卡经常被运营商限制数据业务或限制特定APN排查时要先把卡换到普通手机上做交叉验证这一步能快速判断问题在卡侧还是设备侧。2.3 4G下的DNS与MTU细节蜂窝网络的DNS地址通常由运营商通过DHCP或PCOProtocol Configuration Options下发给终端Android 13默认使用这条链路上的DNS配置不需要手动设置。但很多项目为了统一解析内网域名会去修改私有DNS或者让设备使用固定DNS这里存在一个隐藏风险如果4G和WiFi内网使用不同的DNS策略应用在两个网络之间切换时域名解析行为会跟着改变导致一些依赖内网域名的服务时通时断。MTU同样值得关注。4G链路常见的MTU是1500但在某些专网或运营商核心网配置下实际可用MTU可能只有1400甚至更小。表现为大包传输卡顿、视频加载不了但小流量却正常。验证方法是用ping命令测试大包分片adb shell ping -s 1472 -c 3 8.8.8.8注意这里不是鼓励大家折腾公网地址只是说明排查大包问题时的通用方法。ping不能确认MTU问题时配合抓包看TCP握手后的分段情况会更准确。3. WiFi内网要搞明白的几个关键点3.1 DHCP和静态IP的选择WiFi内网的地址分配无非DHCP和静态IP两种方式。现场设备量大、需要固定身份的时候我一般建议直接配静态IP避免DHCP地址池不够用或者租约过期导致设备掉线。Android 13的WiFi设置入口里可以修改IP设置从DHCP改为静态之后需要手动填写IP地址、子网掩码、网关和DNS。这里有一个很常见的低级错误子网掩码填错。比如设备IP是192.168.10.50掩码却填了255.255.255.0以外的值内网交换机转发就会出问题。另一个低级错误是网关填错指向了不存在的地址结果设备能拿到IP却出不了内网。静态IP场景下DNS配置建议直接指向内网DNS服务器而不是运营商DNS否则可能出现内网域名解析失败。修改完成后可以立即用命令验证连通性adb shell ping -c 3 网关IP adb shell ping -c 3 内网服务器IP如果网关通、服务器不通重点检查交换机端口、VLAN权限和防火墙策略。3.2 内网隔离与多AP场景企业、园区、实验室的WiFi内网通常会做网络隔离。常见做法是同一个SSID下启用客户端隔离终端之间互访被阻断只允许访问网关或特定服务器。另一个做法是按VLAN划分访客网络和办公网络访客网络访问不到核心业务网段。现场排查WiFi能连上但ping不通时先别急着怀疑设备可以按这个顺序验证先ping网关网关通说明二层链路正常问题大概率在路由或防火墙网关不通说明终端压根没进入有效网络。再ping同网段的其他设备如果同网段也不通就要怀疑SSID背后的客户端隔离策略。还有一种情况多个AP部署时手机连到了某个信号最好但归属VLAN不对的AP上表现为某些区域正常、某些区域无法访问内网。这种情况可以引导终端主动切换SSID或关闭再打开WiFi重新触发AP关联问题通常会暴露得更明显。3.3 双网卡并存路由表和策略规则Android 13在路由层面维护着一套策略路由规则。设备同时存在WiFi和蜂窝两个接口时系统会为默认网络对应的网卡生成默认路由同时为其他网络生成按需路由或仅限特定应用访问的路由。查看设备当前网络接口和路由规则最有用的命令是adb shell ip addr adb shell ip route show table all adb shell ip rule showip rule show的输出里能看到不同fwmark对应的路由表编号优先级越高的规则越先匹配。Android默认网络对应的路由表优先级最高这样设计是为了保证默认流量走评分最高的网络。如果想强制某个应用走WiFi内网需要在应用层使用NetworkCallback绑定指定的Network对象或者在有系统权限的情况下调整网络策略单纯改路由表在Android 13里往往不够彻底因为包会被netd的规则拦截。4. 联网模式与开发者选项里的关键配置4.1 移动数据开关和始终开启移动数据开发者选项里有一个开关叫始终开启移动数据对应的系统设置项是Settings.Global.MOBILE_DATA_ALWAYS_ON。这个开关默认关闭时当设备连上WiFi后蜂窝数据链路会进入休眠状态一旦WiFi断开系统需要重新激活蜂窝链路耗时经常在几秒甚至十几秒现场设备如果在移动过程中频繁切换网络业务就会明显卡顿。把这个开关打开之后WiFi存在时蜂窝链路继续保持连接WiFi断开的瞬间数据通道立即接管切换时间大幅缩短。代价是待机功耗会升高因为射频模块一直保持数据连接。对于需要稳定在线的移动设备来说这个取舍通常值得。调试命令如下adb shell settings put global mobile_data_always_on 1修改完成后不需要重启立即生效。除了这个开关还需要留意数据漫游开关。现场设备如果用了非本地归属的物联网卡漫游开关关闭时即使信号正常也无法上网。这个设置位于设置-网络-移动网络-数据漫游修改后建议再执行一次飞行模式切换强制重新注册网络。4.2 私有DNS对两个网络的影响Android 13支持配置私有DNS有三种模式关闭、自动、指定主机名。默认的自动模式使用网络下发的DNS配置关闭模式表示完全禁用私有DNS指定主机名模式会强制所有DNS查询走某个DoT服务器。这个配置在4G和WiFi内网并存场景下非常容易出问题。如果设备配置了某个外部DoT服务器作为私有DNSWiFi内网里那些依赖内网DNS解析的域名就会出现能上内网IP但解析不了内网域名的诡异现象因为DNS查询全被导向了外部服务器内网域名解析自然失败。碰到内网域名解析异常先检查私有DNS模式adb shell settings get global private_dns_mode显示hostname就说明被强制指定了DoT服务器。临时恢复自动模式的方法adb shell settings put global private_dns_mode auto对于纯内网项目最稳妥的做法是把私有DNS设为关闭完全走内网提供的DNS解析。4.3 用命令行摸清真实网络状态设置界面里显示的WiFi连接状态和系统实际网络状态并不总是一致Android 13里最可靠的判断方式是直接看ConnectivityService的实时状态adb shell cmd connectivity monitor这个命令会持续输出网络变化事件包括每个网络的验证结果、默认网络切换、能力变化等。信息量足够大适合现场复现问题时挂机观察。如果只想看当前状态快照adb shell dumpsys connectivity | grep -E NetworkAgentInfo|Default network|NetworkRequest我个人的习惯是先把dumpsys connectivity完整导出保存再触发一次网络切换对比前后的默认网络变化多数流量为什么走了A没走B的问题都能在这个环节看出端倪。5. 场景实操4G与WiFi内网双网并存的排查流程5.1 一套可复用的排查顺序面对Android 13设备的联网问题如果一上来就抓包或者改参数效率很低。建议按物理层-链路层-网络层-应用层的顺序逐级排查避免在错误层面耗费时间。第一步确认物理关联状态设备是否成功连接WiFi SSID、信号强度如何4G是否有信号、是否注册上网络。第二步确认链路层WiFi是否拿到IP、DHCP是否正常4G的APN是否匹配、PDN是否激活。第三步确认网络层路由表是否正常、默认网络是哪条链路、DNS解析是否正常。第四步才是应用层的权限、后台限制、接口地址等。给出一个具体案例。某项目现场设备全部连接WiFi内网但业务端后台看到大量设备上报的IP是4G运营商的IP。排查过程就是先ip route show table all发现默认路由确实指向蜂窝网卡再查dumpsys connectivity确认WiFi被判定为无INTERNET能力最终因为在路由规则里加了针对内网网段的优先级策略业务流量才稳定走WiFi接口。5.2 高频问题速查表现象可能原因排查命令解决建议4G满格但无法上网数据开关关闭、漫游开关关闭、APN错配settings get global mobile_data、dumpsys telephony.registry开启数据开关恢复APN默认配置重新选择运营商WiFi连上但提示无公网内网验证不到公网服务器系统判定无INTERNET能力cmd connectivity monitor确认业务是否只走内网若只走内网则按内网流量配置路由策略内网域名解析失败私有DNS指向外部DoT服务器settings get global private_dns_mode关闭私有DNS或改为自动模式WiFi连上但ping不同网关DHCP异常、VLAN隔离、交换机端口问题ip addr、ping 网关IP检查DHCP地址池、交换机配置必要时指定静态IP默认流量走4G而非WiFiWiFi被判定无INTERNET能力或评分过低dumpsys connectivity调整路由策略或网络请求绑定指定网络耗电异常且WiFi存在时发热MOBILE_DATA_ALWAYS_ON开启确认开关状态关闭始终开启移动数据5.3 日志与抓包定位网络切换问题排查现场问题如果只靠状态快照往往不够。需要日志来还原时间线特别是网络切换相关的瞬时状态。抓取系统网络服务日志的通用命令如下adb logcat -s ConnectivityService:V WifiService:V WifiStateMachine:V TelephonyRegistry:V复现问题的同时挂上logcat观察默认网络切换的日志时间点再配合业务层的错误日志基本能还原出网络切换导致业务连接中断的完整链路。对于更底层的网络报文可以在root权限下使用tcpdump抓包重点看ICMP、DNS、TCP SYN等关键报文。日志级别上ConnectivityService默认打印的信息已经覆盖了网络验证、网络评分、默认网络切换这些关键节点。WifiService的日志覆盖扫描、关联、DHCP过程。TelephonyRegistry则覆盖蜂窝注册和数据状态变化。这三个服务的日志足够覆盖绝大多数4GWiFi内网的排查场景。抓包定位到具体报文层面后再回看系统设置项比如确认是否因为网络评分机制导致路由迁移还是因为目标服务器主动断开了旧连接问题就清晰了。我个人在实际调试过程中最深的体会是Android 13在4G和WiFi内网并存场景下的表现大部分怪问题都不是硬件故障而是系统按规则选择了最合理的网络但这个合理与否需要结合业务场景来判断。调试这类问题先搞清楚设备当前默认网络是谁、为什么是它比盲目改设置有效得多。最后再分享一个小技巧现场调试时用adb shell cmd connectivity airplane-mode enable和disable来切换飞行模式比手动在屏幕上点击稳定可靠尤其在需要反复复现网络切换问题时这个命令可以省下大量等待时间。