Android 13 网络策略调优：实现以太网与WIFI的智能协同

1. 为什么需要以太网与WIFI智能协同在智能家居控制面板、工业手持终端这类设备上我们经常遇到一个头疼的问题插着网线时WIFI自动断连。Android系统默认的以太网优先策略就像个非黑即白的直男——只要检测到网线插入就会立即切断WIFI连接。这种设计在手机上是合理的但对于需要双网保障的设备简直就是灾难。我去年参与开发的智能售货机项目就踩过这个坑。现场工程师反馈设备联网不稳定排查后发现是商场的网络端口时好时坏。理想状态应该是有线网络正常时走以太网保障稳定性一旦网线异常就自动切换WIFI就像手机的双卡智能切换。但原生Android 13的粗暴策略直接导致设备断网只能手动拔网线才能恢复WIFI。2. 破解系统默认策略的关键点2.1 理解网络选择的三层机制Android的网络管理就像个精密运转的齿轮组核心部件是这三个ConnectivityService网络连接的大脑负责判断哪个网络该激活NetworkRanker网络评分的裁判给不同网络类型打分netd路由规则实际控制数据流向的交通警察原生系统的处理流程是这样的当同时连接以太网和WIFI时NetworkRanker会给以太网打90分WIFI只有60分。ConnectivityService拿到评分后就会像班主任选班干部一样直接让分数高的以太网上岗把WIFI踢出局。2.2 需要修改的核心逻辑要实现智能协同我们需要在三处动手术欺骗评分系统让系统认为WIFI和以太网同样优秀修改路由表允许数据包同时在两个网络间流动增加回退机制当主网络异常时自动切换备选线路这就像改造交通系统——不仅要允许汽车和地铁同时运营还要在某个交通工具停运时自动把乘客引导到另一个系统。3. 实战修改ConnectivityService3.1 解除网络互斥限制找到packages/modules/Connectivity/service/src/com/android/server/ConnectivityService.java关键修改点在unneeded()方法。这个方法的原始逻辑就像个严格的保安会强制关闭不必要的网络连接。我们需要增加特殊判断// 在unneeded方法开头添加 if (nai.isWIFI() || nai.isETHERNET()) { Log.d(TAG, Always keep WIFI/ETHERNET alive); return false; // 返回false表示网络始终需要保持 }这个改动相当于给保安发了新指令WIFI和以太网是VIP永远不能赶走。我测试时发现个细节——修改后需要重启netd服务才能生效命令是adb shell stop netd adb shell start netd3.2 扩展网络类型判断在NetworkAgentInfo.java中添加两个关键方法就像给系统装上新的传感器public boolean isWIFI() { return networkCapabilities.hasTransport(NetworkCapabilities.TRANSPORT_WIFI); } public boolean isETHERNET() { return networkCapabilities.hasTransport(NetworkCapabilities.TRANSPORT_ETHERNET); }这步操作看似简单但就像给机器人安装新的触觉传感器。没有这两个方法系统就无法准确识别网络类型。实测发现有些厂商定制的ROM会修改这些基础定义所以最好在代码里加上版本判断。4. 重构NetworkRanker评分逻辑4.1 调整网络优先级原始代码中写死了以太网优先的顺序private static final int[] PREFERRED_TRANSPORTS_ORDER { TRANSPORT_ETHERNET, TRANSPORT_WIFI, TRANSPORT_BLUETOOTH, TRANSPORT_CELLULAR };我们需要创建新的优先级规则就像重新制定比赛评分标准private static int[] PREFERRED_TRANSPORTS_ORDER_COEXIST { TRANSPORT_WIFI, // 让WIFI当班长 TRANSPORT_ETHERNET, // 以太网当副班长 TRANSPORT_BLUETOOTH, TRANSPORT_CELLULAR }; static { PREFERRED_TRANSPORTS_ORDER PREFERRED_TRANSPORTS_ORDER_COEXIST; }这个改动就像把体育特长生加分政策改为文体平等。但要注意不能简单调换顺序我在项目中就遇到过蓝牙设备连接异常的问题最后发现是没处理好TRANSPORT_BLUETOOTH的优先级。4.2 动态评分策略进阶版更智能的做法是根据网络质量动态调整。在mightBeat()方法中加入实时评估// 获取当前网络延迟和带宽 int contestantLatency getNetworkLatency(contestant); int championLatency getNetworkLatency(champion); // WIFI延迟低于50ms时优先使用 if (contestant.isWIFI() contestantLatency 50) { return true; } // 以太网带宽大于100Mbps时优先使用 else if (contestant.isETHERNET() getBandwidthMbps(contestant) 100) { return true; }这种策略下设备会像老司机一样实时选择更畅通的车道。测试时需要模拟各种网络环境推荐使用Android Studio的Network Profiler工具。5. 深度改造netd路由规则5.1 新增直连路由规则在system/netd/server/RouteController.cpp中我们需要增加新的交通管制规则[[nodiscard]] static int addDirectlyConnectedRule() { return modifyIpRule(RTM_NEWRULE, RULE_PRIORITY_DIRECTLY_CONNECTED, RT_TABLE_MAIN, MARK_UNSET, MARK_UNSET, IIF_NONE, OIF_NONE, INVALID_UID, INVALID_UID); }这个规则相当于在城市中新开辟了一条BRT快速公交专用道。关键参数RULE_PRIORITY_DIRECTLY_CONNECTED需要与头文件中定义的值一致// 在RouteController.h中添加 constexpr int32_t RULE_PRIORITY_DIRECTLY_CONNECTED 9999;5.2 路由初始化流程改造在Init()方法中插入我们的新规则if (int ret addDirectlyConnectedRule()) { ALOGE(Failed to add directly connected rule); return ret; }这步操作就像在交通枢纽安装新的信号灯系统。测试时发现个坑某些内核版本对RT_TABLE_MAIN的处理有差异建议先用ip rule list命令验证规则是否生效。6. 调试技巧与常见问题6.1 验证路由规则是否生效连接双网络后在adb shell中运行ip rule list ip route show table main正常应该看到类似这样的输出9999: from all lookup main如果没生效可以尝试手动刷新ndc network destroy ndc network create 1006.2 典型问题排查指南WIFI频繁切换通常是评分策略太敏感可以增加 hysteresis 阈值DNS解析失败检查resolv.conf是否包含两个网络的DNSSocket绑定错误需要设置SO_BINDTODEVICE选项有个隐蔽的坑是MTU值差异。以太网默认1500而某些WIFI可能只有1400会导致大包丢弃。解决方法ifconfig eth0 mtu 14007. 高级应用场景拓展7.1 智能负载均衡方案通过eBPF实现更精细的流量分配// 示例根据目标端口分流 SEC(classifier/port_based) int handle_ingress(struct __sk_buff *skb) { __u16 dest_port load_half(skb, offsetof(struct tcphdr, dest)); if (dest_port 80 || dest_port 443) { bpf_redirect(eth0_ifindex, 0); } else { bpf_redirect(wlan0_ifindex, 0); } return TC_ACT_OK; }这种方案适合视频监控设备——关键数据走稳定的以太网普通管理流量走WIFI。7.2 双网热备方案使用NetworkMonitor检测网络质量registerDefaultNetworkCallback(new ConnectivityManager.NetworkCallback() { Override public void onLost(Network network) { // 自动切换到备用网络 } });在工业现场我们给这个机制加了心跳检测功能每秒发送探测包确保切换延迟小于200ms。