RK3399 Android 7.1 实现 WiFi STA+AP 并发全栈解析

1. 双WiFi并发不是“开个热点”那么简单：RK3399 Android 7.1 上 STA+AP 同时工作的底层真相

你手头有一块 RK3399 开发板，跑着 Android 7.1 系统，现在想让它一边连上公司内网（STA 模式），一边给手机开个热点（AP 模式），实现真正的“双 WiFi 并发”。网上搜一圈，很多人说“改个配置就行”“驱动支持就OK”，结果一试——要么 AP 起不来，要么 STA 断连，要么系统卡死重启。我去年在给某工业网关做定制固件时，就在这个需求上卡了整整三周。不是代码写错了，而是根本没搞清 RK3399 这颗 SoC 的 WiFi 子系统到底怎么调度、Android 7.1 的 HAL 层如何接管、以及 Realtek RTL8723BS（或博通 BCM43438）这类常见模组在并发场景下的真实行为边界。这不是一个“功能开关”问题，而是一场对硬件资源、驱动状态机、HAL 接口协议和 Android 框架调度逻辑的全栈穿透。核心关键词 RK3399、android7.1、wifi、STA、AP，每一个都指向一个必须亲手验证的断点：RK3399 的 PCIe 总线带宽是否够用？Android 7.1 的 wpa_supplicant 配置是否兼容双 interface？WiFi 模组固件是否真支持 concurrent mode？驱动里那个叫wlan0和wlan1的设备名，到底是两个物理接口，还是同一个 MAC 地址在不同上下文里的虚拟映射？这篇文章不讲“复制粘贴就能跑”的速成教程，而是带你一层层剥开这层皮——从芯片手册的寄存器定义开始，到 dmesg 里一行行报错日志的含义，再到 system_server 里 WifiService 的状态流转。如果你正被“笔记本已连接热点也可以上网但是不能正常显示wifi连接符号”这类现象困扰，或者调试时看到unexpected status 401 unauthorized却查不到源头，那说明你已经踩进了并发模式的深水区。本文所有结论，全部来自我在 RK3399 + Android 7.1 + RTL8723BS 模组上的实测记录，包括 17 个失败的编译版本、43 次 kernel panic 日志分析，以及最终稳定运行超过 6 个月的生产环境配置。下面，我们从最硬的那块骨头开始啃。

1.1 RK3399 的 WiFi 架构：PCIe 通道、SDIO 接口与“伪双频”的物理真相

RK3399 的 WiFi 并发能力，首先取决于它怎么把无线芯片接到 SoC 上。这里必须打破一个普遍误解：RK3399 并没有内置 WiFi，它靠外部模组——最常见的就是通过 SDIO 接口挂载 RTL8723BS（低成本方案）或通过 PCIe 接口挂载 BCM43438（高性能方案）。这两种路径，直接决定了你能否实现 STA+AP 并发。RTL8723BS 是单 SDIO 接口、单 MAC 地址的芯片，它的“双模式”本质是时间分片：驱动在 STA 和 AP 两种状态间快速切换，共用同一套射频和基带资源。而 BCM43438 是 PCIe 接口，拥有独立的 DMA 引擎和更复杂的固件架构，原生支持 concurrent mode，即 STA 和 AP 可以真正并行工作，互不抢占信道。我在项目初期就栽在这一步：拿到一块标称“RK3399+RTL8723BS”的板子，以为只要刷对固件就行，结果无论怎么调 wpa_supplicant 配置，AP 模式一启，STA 就掉线。抓取dmesg | grep wlan发现关键线索：

[ 12.345678] rtl8723bs: chip version 0x11 [ 12.345789] rtl8723bs: firmware ver 0x22.12, h2c cmd count 0x1f [ 12.345890] rtl8723bs: concurrent mode NOT supported in this firmware

注意最后一行——concurrent mode NOT supported。这不是驱动报错，而是固件（firmware）自己声明不支持。RTL8723BS 的固件分好几种：rtl8723bs_nic.bin（仅 STA）、rtl8723bs_ap.bin（仅 AP）、rtl8723bs_concurrent.bin（STA+AP）。但很多厂商出货时只烧录了前两种，因为并发固件体积更大、功耗更高、测试成本高。你得先确认你的模组里烧的是哪个固件。方法很简单：进/lib/firmware/rtlwifi/目录，看有没有rtl8723bs_concurrent.bin；如果没有，就得去 Realtek 官网找对应芯片 ID 的 SDK，自己编译固件。我花了两天时间，在 Realtek 的 Linux SDK 里找到rtl8723bs/rtl8723bs_concurrent.c，修改了CONFIG_CONCURRENT_MODE=y，重新生成 bin 文件，再用dd写入 eMMC 的 firmware 分区。这一步做完，dmesg里的提示才变成concurrent mode enabled。但别高兴太早——这只是硬件层开了门，上层软件栈还没准备好接招。

1.2 Android 7.1 的 WiFi 框架：HALv1.2 与 wpa_supplicant 的“双 interface”幻觉

Android 7.1 使用的是 HALv1.2（Hardware Abstraction Layer），它把 WiFi 控制权交给了wpa_supplicant这个用户态守护进程。关键点在于：Android 并不直接管理wlan0这个设备节点，而是通过WifiHAL与wpa_supplicant通信，再由wpa_supplicant去操作内核驱动。所以，当你在 Settings 里点“开启热点”，系统实际是发了一条SET_AP命令给wpa_supplicant，后者再去调用驱动的ioctl接口。问题来了：标准的wpa_supplicant.conf默认只配一个 interface（通常是wlan0），它怎么同时管 STA 和 AP？答案是——它不直接管，而是靠wpa_supplicant的 multi-interface 支持。Android 7.1 的wpa_supplicant编译时必须启用CONFIG_AP和CONFIG_P2P，并且要配置两个独立的 interface：一个叫wlan0（用于 STA），另一个叫ap0或wlan1（用于 AP）。但这里有个致命陷阱：很多移植者以为只要在BoardConfig.mk里加-DCONFIG_AP就完事了，却忽略了wpa_supplicant的启动脚本init.wifi.rc。默认的init.wifi.rc只会启动一个wpa_supplicant实例：

service wpa_supplicant /system/bin/wpa_supplicant \ -imulti -Dnl80211 -c/data/misc/wifi/wpa_supplicant.conf -Iwlan0 -O/data/system/wpa_supplicant

这个-Iwlan0参数锁死了它只监听wlan0。要支持双 interface，你必须启动两个实例，或者——更稳妥的做法——启动一个支持 multi-interface 的实例，并指定两个 interface 名字。正确写法是：

service wpa_supplicant /system/bin/wpa_supplicant \ -imulti -Dnl80211 -c/data/misc/wifi/wpa_supplicant.conf -Iwlan0 -Iap0 -O/data/system/wpa_supplicant

注意-Iwlan0 -Iap0这两个参数。这意味着wpa_supplicant会同时监控wlan0和ap0两个 netdev。但ap0设备从哪来？它不是内核自动创建的，而是由wpa_supplicant在收到SET_AP命令后，调用nl80211接口动态创建的 virtual interface。这就引出了下一个关键点：nl80211驱动是否支持NL80211_CMD_ADD_INTERFACE？我第一次编译时，wpa_supplicant启动报错：

Failed to initialize driver 'nl80211' Could not read interface wlan0 flags: No such device

查源码发现，external/wpa_supplicant_8/src/drivers/driver_nl80211.c里有个函数nl80211_get_ifindex()，它依赖内核的CONFIG_CFG80211_WEXT和CONFIG_NL80211。而 RK3399 的 kernel config 里，CONFIG_CFG80211_WEXT默认是n（不编译），因为 Android 已经弃用 WEXT 接口。必须手动改成y，否则nl80211驱动无法获取 interface 状态。这个细节，90% 的公开教程都没提，但它直接决定wpa_supplicant能不能“看见”你的 WiFi 设备。

1.3 STA+AP 并发的三大死锁场景：信道冲突、IP 地址池与 DHCP 服务争抢

即使硬件固件 OK、wpa_supplicant多 interface 启动成功，你还会遇到三种典型的“看似能连、实则不通”的死锁。它们不是 bug，而是并发模式下资源调度的必然结果，必须手动干预。

第一种死锁：信道冲突（Channel Conflict）
WiFi 的 2.4GHz 频段只有 13 个非重叠信道（CH1/6/11 最常用）。STA 连接路由器时，会自动选择一个信道（比如 CH6）；AP 模式启动时，hostapd默认也选 CH6。两个模式在同一信道上“打架”，导致 STA 接收灵敏度暴跌，ping 包丢一半。解决方案不是随便换信道，而是强制 STA 和 AP 使用不同信道。在wpa_supplicant.conf里，为 STA 添加scan_freq=2412（CH1），为 AP 添加channel=11。但要注意：某些路由器禁止 STA 连接非主信道，所以得先确认你的上级 AP 是否允许 CH1 连接。

第二种死锁：IP 地址池重叠（IP Pool Collision）
Android 热点默认用192.168.43.0/24网段，DHCP 分配192.168.43.2~192.168.43.254。如果你的 STA 连接的内网也是192.168.43.x，那么手机连上热点后，路由表会混乱：去192.168.43.100的包，不知道该走wlan0（内网）还是ap0（热点）。ip route show输出会看到两条冲突路由。解决办法是修改热点网段，比如改成172.16.100.0/24。这需要改两处：一是frameworks/base/services/core/java/com/android/server/connectivity/Tethering.java里DEFAULT_TETHERING_IP_RANGE，二是system/netd/NetworkController.cpp里TetherController::setIpForwardingEnabled()的 iptables 规则。

第三种死锁：DHCP 服务争抢（DHCP Daemon Race）
Android 7.1 有两个 DHCP 服务：dnsmasq（负责热点 DHCP）和dhcpclient（负责 STA 获取 IP）。当dnsmasq启动时，它会绑定0.0.0.0:67端口；如果dhcpclient正在用这个端口，就会失败。logcat -s DhcpServer会看到bind failed: Address already in use。这不是代码问题，而是启动顺序竞争。我的解法是：在init.wifi.rc里，给dnsmasq加start on property:net.dns1=*，确保它等 DNS 设置好再起；同时在system/core/rootdir/init.rc里，把dhcpclient的start on条件改成start on property:sys.boot_completed=1，错开启动时间。实测下来，这个 200ms 的时间差，能避免 99% 的 DHCP 冲突。

2. 从零构建可复现的 RK3399 Android 7.1 双 WiFi 环境：Yocto 与 Kernel 的精准手术

网上很多教程让你“下载官方 SDK，改几个配置，编译烧录”，结果编译失败、烧录后 WiFi 不识别、或者 logcat 里全是E/WifiHAL: wifi_set_country_code: Failed。这是因为 RK3399 的 Android 7.1 移植，本质上是一场对 Yocto 构建系统、Linux kernel 和 Android HAL 的协同手术。任何环节的版本错配，都会导致并发功能失效。我用的是 Rockchip 官方的rockchip-7.1分支（commita1b2c3d），搭配 Yoctomorty版本（2.2.2），kernel 用4.4.194。下面是我验证过的、可 100% 复现的完整步骤链，每一步都有其不可替代的理由。

2.1 Yocto 层级的关键补丁：meta-rockchip里的 concurrency enable flag

Rockchip 的meta-rockchiplayer 里，recipes-kernel/linux/linux-rockchip_4.4.bbappend文件控制 kernel 配置。很多人直接bitbake linux-rockchip，结果 kernel config 里CONFIG_CFG80211_WEXT是n。必须在这个 bbappend 里添加：

do_configure_prepend() { sed -i 's/CONFIG_CFG80211_WEXT=n/CONFIG_CFG80211_WEXT=y/g' ${B}/.config sed -i 's/CONFIG_NL80211=y/# CONFIG_NL80211 is not set/g' ${B}/.config }

为什么要把CONFIG_NL80211注释掉？因为 Android 7.1 的wpa_supplicant用的是旧版nl80211接口，而 kernel 4.4 的CONFIG_NL80211是新版，两者 ABI 不兼容。注释掉它，强制wpa_supplicant回退到wext模式，反而更稳。这个反直觉的操作，是我在对比wpa_supplicant源码src/drivers/driver_nl80211.c和 kernelnet/wireless/nl80211.c的函数签名后确认的。wpa_supplicant里调用的NL80211_CMD_GET_SCAN在 kernel 新版里参数变了，老版wext则完全兼容。

2.2 Kernel 驱动的深度定制：rtl8723bs 的 concurrent mode 初始化序列

RTL8723BS 的驱动代码在drivers/staging/rtl8723bs/。标准驱动只初始化 STA 模式，要支持并发，必须修改core/rtw_wlan_util.c里的rtw_init_drv_sw()函数。关键改动有三处：

1. 在rtw_init_drv_sw()开头，添加固件加载判断：

   if (rtw_is_concurrent_mode(padapter)) { rtw_load_fw(padapter, "rtl8723bs_concurrent.bin"); } else { rtw_load_fw(padapter, "rtl8723bs_nic.bin"); }

   这里rtw_is_concurrent_mode()是我新加的函数，读取padapter->registrypriv.concurrency_mode，这个值从哪里来？来自BoardConfig.mk里定义的BOARD_WLAN_CONCURRENT_MODE := true，然后在hardware/rockchip/wifi/rtl8723bs/wifi_hal.cpp里传给驱动。

2. 在hal/rtl8723b_hal_init.c的rtl8723b_hw_init()里，关闭 PHY 休眠：

   // 并发模式下，PHY 必须常驻工作，否则 STA/AP 切换时 PHY 重置导致丢包 rtw_write32(padapter, REG_SYS_PW_CTRL, 0x00000000);

3. 在core/rtw_mlme.c的rtw_joinbss_event_prehandle()里，添加信道同步逻辑：

   if (rtw_is_concurrent_mode(padapter)) { // STA 连上后，立刻通知 AP 模块切换到相同信道的邻频，避免干扰 rtw_set_channel(padapter, ap_channel_sync(padapter->mlmeextpriv.cur_channel)); }

   ap_channel_sync()是个简单函数：如果 STA 在 CH6，AP 就设 CH1 或 CH11；如果 STA 在 CH1，AP 就设 CH6。这个逻辑让两个模式在物理层上“错峰”，比单纯换信道更有效。

2.3 Android HAL 的胶水层：hardware/rockchip/wifi/下的 concurrency bridge

Rockchip 的 WiFi HAL 在hardware/rockchip/wifi/，它负责把 Android 的WifiManager请求翻译成wpa_supplicant命令。标准 HAL 只处理单 interface，要支持双 mode，必须重写wifi_hal.cpp里的wifi_start_ap()函数。原版代码是：

int wifi_start_ap(wifi_interface_handle handle, wifi_ap_params *params) { return wifi_send_command(handle, "AP_START"); }

新版本要改成：

int wifi_start_ap(wifi_interface_handle handle, wifi_ap_params *params) { // 1. 先检查 STA 是否已连接 if (!is_sta_connected()) { ALOGE("STA not connected, cannot start AP"); return -1; } // 2. 动态创建 ap0 interface if (system("iw dev wlan0 interface add ap0 type __ap") != 0) { ALOGE("Failed to add ap0 interface"); return -1; } // 3. 启动 hostapd，指定 ap0 if (system("hostapd -B /data/misc/wifi/hostapd.conf -i ap0") != 0) { ALOGE("Failed to start hostapd on ap0"); return -1; } return 0; }

这里iw dev wlan0 interface add ap0 type __ap是关键命令，它利用 kernel 的mac80211框架，为wlan0这个 phy 创建一个名为ap0的 virtual interface。type __ap表示这是一个 AP 类型的 interface。这个命令必须在wpa_supplicant启动前执行，否则wpa_supplicant会忽略ap0。我在init.wifi.rc里把它做成一个 service：

service wifi_ap_init /system/bin/sh -c "iw dev wlan0 interface add ap0 type __ap && chmod 600 /sys/class/net/ap0/phy80211/name" class main user root group root oneshot

这样，系统启动时，ap0设备就已存在，wpa_supplicant启动时-Iap0才能生效。

3. 实战调试：从dmesg到logcat的全链路日志追踪法

当你按上述步骤编译烧录后，发现“热点图标亮了，但手机连不上”或者“连上了但 ping 不通”，别急着重刷固件。RK3399 Android 7.1 的双 WiFi 调试，是一场对日志信号的精密解码。我总结了一套四层日志追踪法，覆盖从硬件到应用的全栈，每层都有明确的判断依据和修复动作。

3.1 第一层：dmesg—— 硬件与驱动的“心跳图”

dmesg是内核环形缓冲区，记录驱动加载、中断触发、错误告警。过滤 WiFi 相关日志：

dmesg | grep -i "wlan\|rtl\|sdio\|pcie"

重点关注以下几类输出：

• 固件加载成功：rtl8723bs: firmware ver 0x22.12, concurrent mode enabled。如果看到concurrent mode NOT supported，说明固件没换对，回退到 1.1 节重刷。
• interface 创建失败：rtl8723bs: can't create ap0 interface: -ENODEV。这表示iw dev wlan0 interface add ap0命令失败，原因可能是wlan0设备没起来，或者 kernel 没编译CONFIG_MAC80211。检查ls /sys/class/net/是否有wlan0。
• 信道设置异常：rtl8723bs: set channel 6 failed, ret=-110。-110是ETIMEDOUT，说明 PHY 层忙，可能因为 STA 正在扫描，或者rtw_set_channel()调用时机不对。这时要检查rtw_mlme.c里的信道同步逻辑是否在 STA 关联完成后才执行。

我曾遇到一个诡异 case：dmesg显示ap0创建成功，但ifconfig ap0报Device not found。抓取cat /proc/net/dev，发现ap0根本不在列表里。最后发现是init.wifi.rc里wifi_ap_initservice 的oneshot属性没生效，ap0创建后被系统清理了。解决方案是去掉oneshot，改成restart，并加disabled，在wpa_supplicant启动后再start wifi_ap_init。

3.2 第二层：logcat -s wpa_supplicant—— HAL 与用户态的“对话记录”

wpa_supplicant是整个 WiFi 的大脑，它的日志告诉你“命令发没发出去”、“对方接没接住”。

logcat -s wpa_supplicant

典型成功流程日志：

wpa_supplicant: wlan0: CTRL-EVENT-CONNECTED - Connection to 00:11:22:33:44:55 completed [id=0 id_str=] wpa_supplicant: ap0: AP-ENABLED wpa_supplicant: ap0: CTRL-Event-AP-STA-CONNECTED xx:xx:xx:xx:xx:xx

如果卡在CTRL-EVENT-CONNECTED后没AP-ENABLED，说明SET_AP命令没发给wpa_supplicant，或者wpa_supplicant拒绝了。检查WifiService的 log：

logcat -s WifiService

看是否有WifiService: startSoftAp()调用，以及WifiStateMachine: Entering SoftApState。如果WifiStateMachine没进SoftApState，说明 Android 框架层认为条件不满足，比如mWifiController.isApEnabled()返回 false。这通常是因为WifiController的状态机没同步，需要检查WifiController.java里handleMessage()对CMD_START_AP的处理逻辑。

3.3 第三层：logcat -s DhcpServer与logcat -s ConnectivityService—— 网络层的“血液流动”

DHCP 和 Connectivity 是网络通不通的最终判官。

• logcat -s DhcpServer：看 DHCP 是否分配 IP。成功日志：

  DhcpServer: Sending ACK to 172.16.100.100

  如果看到DhcpServer: no lease available，说明 IP 池满了，或者dnsmasq没起来。用ps | grep dnsmasq确认进程是否存在。

• logcat -s ConnectivityService：看路由是否建立。成功日志：

  ConnectivityService: Setting iface wlan0 as default ConnectivityService: Setting iface ap0 as tethered

  如果只有wlan0的日志，没有ap0，说明Tethering模块没触发。检查Settings -> Hotspot & tethering里是否开启了USB tethering或Bluetooth tethering，它们会抢占Tethering的控制权。必须全部关闭，只留 WiFi hotspot。

3.4 第四层：adb shell网络诊断 —— 终极验证的“外科手术刀”

当所有日志都看似正常，但网络还是不通，就该上adb shell了。这不是猜，而是用命令逐层验证。

1. 确认 interface 状态：

   adb shell # su ip link show wlan0 # 应该是 UP ip link show ap0 # 应该是 UP ip addr show ap0 # 应该有 172.16.100.1/24

2. 检查 iptables 规则：

   iptables -t nat -L -n | grep 172.16.100 # 应该有 POSTROUTING 链，MASQUERADE 172.16.100.0/24 到 wlan0

3. 抓包验证数据流：

   tcpdump -i ap0 -w /data/local/tmp/ap0.pcap & tcpdump -i wlan0 -w /data/local/tmp/wlan0.pcap & # 让手机 ping 8.8.8.8，然后 pull pcap 文件用 Wireshark 分析

   我曾发现ap0.pcap里有 ARP 请求，但wlan0.pcap里没有对应的 ARP 回复，说明 NAT 规则没生效。原因是iptables的POSTROUTING链里，MASQUERADE规则的-o参数写成了wlan1（不存在的 interface），应该写wlan0。

4. 生产环境稳定性加固：内存泄漏、热插拔与长期运行的 7 个硬核技巧

实验室里能跑通，不等于能放进产品里。我在工业网关上部署双 WiFi 后，连续运行 3 天，发现内存占用每天涨 2MB，第 7 天wpa_supplicantOOM 被 kill。这不是偶然，而是 Android 7.1 的wpa_supplicant在并发模式下，nl80211事件监听器有内存泄漏。下面是我总结的 7 个生产环境必备加固技巧，每个都来自真实故障复盘。

4.1 技巧一：wpa_supplicant的内存泄漏修补（patch 级别）

external/wpa_supplicant_8/src/drivers/driver_nl80211.c里，process_drv_event()函数处理NL80211_CMD_NEW_STATION事件时，会 malloc 一个struct station_info，但在nl80211_process_beacon()里没 free。补丁如下：

--- a/src/drivers/driver_nl80211.c +++ b/src/drivers/driver_nl80211.c @@ -1234,6 +1234,7 @@ static void nl80211_process_beacon(struct wpa_driver_nl80211_data *drv, os_free(sta); + os_free(sinfo); }

这个补丁让每次 beacon 处理后释放sinfo，内存增长从每天 2MB 降到 0。实测 30 天无增长。

4.2 技巧二：dnsmasq的守护进程化（防止 DHCP 服务意外退出）

dnsmasq默认是前台进程，一旦被 signal 杀掉，热点就断 DHCP。必须把它变成 daemon，并加 watchdog：

# /system/etc/init.d/50dnsmasq #!/system/bin/sh while true; do if ! pgrep dnsmasq > /dev/null; then /system/bin/dnsmasq --no-daemon --port=0 --interface=ap0 --bind-interfaces --dhcp-range=172.16.100.2,172.16.100.254,12h --dhcp-option=option:router,172.16.100.1 & fi sleep 10 done

--no-daemon让它前台运行，便于pgrep检测；sleep 10避免高频轮询。

4.3 技巧三：wlan0的热插拔保护（应对模组意外断电）

RTL8723BS 模组在高温下可能 SDIO 通信中断，wlan0设备消失。wpa_supplicant不会自动重建。解决方案是在init.wifi.rc里加一个 monitor service：

service wifi_monitor /system/bin/sh -c "while true; do if ! ip link show wlan0 > /dev/null 2>&1; then echo 'wlan0 down, reloading driver'; insmod /system/lib/modules/rtl8723bs.ko; fi; sleep 5; done" class main user root group root disabled on property:sys.boot_completed=1 start wifi_monitor

insmod会重新加载驱动，wlan0自动恢复。

4.4 技巧四：AP 模式的低功耗优化（降低发热与耗电）

并发模式下，AP 的 beacon 帧发射是主要功耗源。hostapd.conf里调整：

beacon_int=200 # 默认 100ms，改成 200ms，降低 beacon 频率 dtim_period=3 # 默认 2，改成 3，延长 client 唤醒间隔 ignore_broadcast_ssid=0 # 必须为 0，否则手机看不到热点

实测 CPU 温度降 8°C，待机功耗降 15%。

4.5 技巧五：STA 的智能重连策略（避免“连不上就死等”）

默认wpa_supplicant在 STA 断连后，会无限重试。生产环境需要超时退出，触发 AP 模式降级：

# wpa_supplicant.conf network={ ssid="MyRouter" key_mgmt=WPA-PSK psk="12345678" disconnect_low_rssi=30 # RSSI < 30 时主动断连 reconnect_timeout=30 # 30 秒内重连失败，发广播通知 APP }

APP 监听ACTION_WIFI_DISCONNECTED，可以弹窗提示“内网不可用，热点已启用”。

4.6 技巧六：logcat的循环存储（防止日志撑爆 storage）

logcat -b all -v threadtime > /data/local/tmp/wifi.log会无限追加。用logrotate：

# /system/etc/logrotate.conf /data/local/tmp/wifi.log { size 1M rotate 5 compress missingok }

配合crond每小时执行一次logrotate /system/etc/logrotate.conf。

4.7 技巧七：双 WiFi 的健康检查脚本（一键诊断）

写一个check_wifi.sh，放在/system/bin/：

#!/system/bin/sh echo "=== WiFi Health Check ===" echo "1. Interface status:" ip link show wlan0 | grep "state UP" ip link show ap0 | grep "state UP" echo "2. IP assignment:" ip addr show ap0 | grep "inet 172.16.100" echo "3. iptables MASQUERADE:" iptables -t nat -L POSTROUTING | grep "MASQUERADE.*wlan0" echo "4. dnsmasq process:" pgrep dnsmasq echo "5. wpa_supplicant state:" wpa_cli -i wlan0 status | grep "wpa_state=COMPLETED" wpa_cli -i ap0 status | grep "bss[0-9]*"

运维人员只需adb shell check_wifi.sh，3 秒内定位问题模块。

5. 避坑指南：那些让你浪费三天却毫无进展的“常识性错误”

最后，分享 5 个我亲身踩过、且 90% 的开发者都会撞上的“常识性错误”。它们看起来 trivial，但足以让你在深夜对着 logcat 抓狂。

5.1 错误一：“我改了 BoardConfig.mk，为什么没生效？”

BoardConfig.mk里的BOARD_WLAN_CONCURRENT_MODE := true，只影响hardware/rockchip/wifi/下的 HAL 编译，不影响 kernel 驱动。驱动里的并发逻辑，是硬编码在drivers/staging/rtl8723bs/的 C 文件里。你必须同时改 kernel 和 HAL，缺一不可。验证方法：adb shell getprop | grep wifi，看有没有ro.wifi.concurrency=true，这个 prop 是 HAL 在wifi_init()里写的，如果没写，说明 HAL 没编译进libwifi_hal.so。

5.2 错误二：“我用 iwconfig 设置了 ap0 的 ESSID，为什么手机搜不到