您的位置:首页 > 运维架构 > Shell

Android系统中通过shell命令实现wifi的连接控制

2017-07-16 23:38 585 查看

简介

工作中遇到一个“变态”的需求,在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

感想

有时解决问题,需要一点点灵感,一下子的灵光乍现也能解决一些问题,但总感觉很虚,我更喜欢循序渐进的构建知识体系,感觉这样更踏实些。
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: 
相关文章推荐