版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/voidreturn/article/details/75213206
简介
工作中遇到一个“变态”的需求,在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 。
感想
有时解决问题,需要一点点灵感,一下子的灵光乍现也能解决一些问题,但总感觉很虚,我更喜欢循序渐进的构建知识体系,感觉这样更踏实些。