Android JB2 Wifi scan机制

一. 背景介绍

在Android上下发scan命令，一般是在WiFiNative通过JNI调到Wpa_supplicant中。wpa_supplciant调用kernel网络协议栈，网络协议栈然后再下发到wifi driver，driver下发到firmware。firmware完成后会返回scan done消息，然后是scan_result消息。但是最基本的scan路是WifiNative，再向上是WifiStatemachine的startScan()。

今天分析的是app层和framework层的scan机制，一个是在Setting app中，另外一个是在framework层的WifiStateMachine中。

二. Setting app中的scan机制

在WifiSetting.java中有定义Scanner类，基于Handler。定义如下：

在Scanner中会处理message：0，直接调用mWifimanager.startScan()，这个函数就是通过WifiNative下发Scan命令。然后有延迟WIFI_RESCAN_INTERVAL_MS：10*1000ms发送message：0。这样就形成了间隔10s下发scan的机制。

在WifiSetting中有定义对象mScanner，在Wifi setting进入前台时启动。当Wifi setting放入后台时，调用mScanner.pause()，会把handler消息机制暂停。这样当Wifi Setting放入后台时，setting app将不进行scan。

三. Framework层的WifiStatemachine中的scan机制

这里包含了两种，一个15s间隔，一个是5min的间隔。两种不同的机制是应对不一样的情形设计的。

1. 15s的scan机制

在WifiStatemachine中的DisconnectedState里会处理如下消息：

可以看出，收到CMD_NO_NETWORKS_PERIODIC_SCAN时，会发送CMD_START_SCAN消息，处理这个消息会调用到WifiNative的scan函数，下发scan命令。然后延迟mSupplicantScanIntervalMs：15000ms再去发送该消息。这样就形成了间隔15s下发scan命令的机制。

注意，这里有一个判断mWificonfigstroe.getConfiguredNetworks().size() == 0，这个判断是说，没有已保存的ap。如果之前连接过ap，将不会有定时15s进行scan的机制了。

2. 5min的scan机制

在DisconnectedState类里有定义setScanAlarm()，code如下：

这里通过AlarmManager定时mFrameworkScanIntervalMs：300*1000ms时间发送mScanIntent，mScanIntent最后发送CMD_START_SCAN的消息，向WifiNative下发scan命令。这样形成了5min的定时scan。

需要强调一点，setScanAlarm()是结合系统支不支持在background下scan行为进行的。若不支持background下scan，则调用setScanAlarm()。若支持，将走另外一套机制。这里默认不支持。

四. 总结

总结来看，有下面四种情况：

在前台没有已保存ap，有10s、15s、5min的scan机制混合进行。

在前台有已保存ap，有10s，5min的scan机制混合进行。

在后台没有已保存ap，有15s，5min的scan机制混合进行。

在后台有已保存ap，有5min的scan机制。

注：默认系统不支持background下的scan。