简介

工作中遇到一个“变态”的需求，在android系统中不通过java层控制wifi的连接（主要是修改ap的essid和password），而是需要通过native层实现对wifi的控制。

How

• 接到这个需求时，第一个想法是如何找到Android native层对应的wifi控制接口（也就是一些c层的接口），由于c层的接口都是android framework层的接口，属于内部接口，android系统在设计之初就没想暴露太多这层的接口，所以并没有相关的文档说明（其实我也没花太多时间去搜索，所以暂且认为没有官方文档吧，不过我估计对android wifi模块有深入研究的人，应该会比较熟悉这方面的接口）
• 分析wpa_supplicant service参数，wifi的控制逃不开wpa相关的服务，通过ps查看了wpa_supplicant的启动参数发现androd系统是通过解析/data/misc/wifi/wpa_supplicant.conf 这个conf文件来控制连接哪个ap，所以我么只需要修改这个conf文件，然后重启wpa_supplicant这个服务即可。
• 基于前面的分析，貌似该问题很容易解决，但是对wpa_supplicant服务的启停，遇到问题，kill掉后，重启wpa_supplicant无效，在没有查明问题原因的时候，发现了svc wifi enable/disable命令，这个命令实现了wpa_supplicant的启停而不用关心参数的设置。
• 有了svc wifi这个命令，一切都简单多了，但是调试过程中，仍然遇到了问题，比如我输入错误的password，android会尝试多次重现连接ap，最后显示无法连接，然后我们修改wpa_supplicant.conf输入正确的password后，通过svc wifi启停wpa_supplicant服务，android系统不会尝试重新连接，仍然显示之前的错误状态，甚至重启系统，仍然不会重新连接。
• 在反复尝试确定前面的现象后，又陷入了一个僵局，一直找不到通过shell触发重新连接的方式。在试过各种情况后，已经想不到其他尝试的方式后，安静下来，思考了下，突然意识到这个状态一定是缓存了，而且不是缓存在代码层面（内存），而是缓存在文件上，否则重启应该不会再记录之前的状态。所以无目的的查看了/data/misc/wifi目录下的文件，发现networkHistory.txt这么个文件，直觉上感觉就是它了，删除之，通过svc wifi重启wpa_supplicant服务，立马触发连接。

总结

通过上面的分析，通过shell命令实现wifi的连接控制只需要：

• 通过svc wifi disable关闭wifi
• 修改/data/misc/wifi/wpa_supplicant.conf配置文件
• 删除/data/misc/wifi/networkHistory.txt文件
• 通过svc wifi enable打开wifi

由于对该“变态”的需求没有太多的兴趣，所以导致连看看networkHistory.txt的内容都没有，更没有去深入研究这个文件对连接的影响，想想自己探究问题本质的欲望怎么越来越小了呢。由于笔者换了技术方向，近期也没时间深入研究这个了，写这个篇文章时大概搜索了下，发现了一篇文章貌似讲到了这个连接过程的，有兴趣的朋友可以继续看看http://www.itnose.net/detail/6637117.html。

感想

有时解决问题，需要一点点灵感，一下子的灵光乍现也能解决一些问题，但总感觉很虚，我更喜欢循序渐进的构建知识体系，感觉这样更踏实些。