Wlan学习备忘（下）

爱被打了一巴掌 2022-06-02 12:29 294阅读 0赞

HSM（对应的类是StateMachine）和AsyncChannel是Android Java Framework中两个重要  
的类。不过，它们目前还仅由Framework内部使用，SDK中并没有包含它们。这两个类的作  
用如下。  
·HSM在传统状态机对所有状态都一视同仁的基础上做了一些改变，使得状态和状态之  
间有了层级关系。HSM中的状态层级关系与Java中父子类的派生和继承关系类似，即在父状  
态中实现generic的功能，而在子状态中实现一些特定的处理。不过，和Java中类派生不同的  
是，HSM中父子状态对应的是毫无派生关系的两个类，所以使用时需要创建两个对象。而  
Java中子类则从其父类派生，实际使用时创建一个子类对象即可，该子类对象就能完成父类  
的工作。  
·AsyncChannel用于两个Handler之间的通信。具体的通信方式为源Handler通过  
sendMessage向目标Handler发送消息，而目标Handler通过replyToMessage回复源Handler处理

结果。注意，这两个Handler可位于同一个进程，也可分属两个不同的进程。  
  
**StateMachine**  
HSM在framework中的实现都是继承StateMachine，有WiFiStateMachine，WifiWatchdogMachine等。  
下面先说StateMachine的实现规则和原理：  
**addState：**添加一个状态。同时还可指定父状态。  
**·transitionTo**：将状态机切换到某个状态。  
**·obtainMessage**：由于HSM内部是围绕一个Handler来工作的，所以外界只能调用HSM的  
**obtainMessage**以获取一个Message ① 。  
·**sendMessage**：发送消息给HSM。HSM中的Handler会处理它。  
·**deferMessage**：保留某个消息。该消息将留待下一个新状态中去处理。其内部实现就是  
把这些被deferred的message保存到一个队列中。当HSM切换到新状态后，这些deferred消息将  
被移到HSM内部Handler所对应消息队列的头部，从而新状态能首先处理这些deferred消息。  
·start：启动状态机。  
·停止状态机可使用quit或quitNow函数。这两个函数均会发送SM\_QUIT\_CMD消息给HSM  
内部的Handler，不过效果略有区别。当使用quit时，SM\_QUIT\_CMD添加在消息队列尾；而  
使用quitNow时，SM\_QUIT\_CMD被添加到消息队列头。  
假设某个statemachine有如下关系的state：  
![SouthEast][]  
·SM启动后，初始状态的EA将按派生顺序执行。即其祖先状态的enter（）先执行，子状态的  
enter（）后执行。以示例代码中的初始状态mS5为例。当HSM的start调用完毕后，enter就（）调用顺序为  
mP0、mP1、mS1、mS5。  
  
·当State发生切换时，旧State的exit先执行，新State的enter后执行，并且新旧State派生树  
上对应的State也需要执行exit或enter函数。以mS5切换到mS4为例，在此切换过程中，首先执  
行的是exit，其顺序是mS5，mS1。注意，exit执行的终点是离mS4和mS5最近的一个公共  
（即同时是mS4和mS5的祖先）祖先State（此处是mP1），但公共祖先状态的exit不会执  
行。然后执行的是enter，其顺序是mS2、mS4。同理，公共祖先的EA也不会执行。细心的读者  
可以发现，HSM中enter和exit执行顺序和C++类构造/析构函数执行顺序类似。enter执行顺序由  
祖先类开始直至子孙类，而析构函数的执行先从子孙类开始，直到祖先类。  
  
·State处理Message时，如果子状态不能处理（返回NOT\_HANDLED），则交给父状态去  
处理。这一点也和C++中类的派生函数类似。  
  
  
**AsyncChannel**  
AsyncChannel用于两个Handler之间的通信，其用法包含两种不同的应用模式（usage  
model）。  
·简单的request/response模式下，Server端无须维护Client的信息，它只要处理来自Client  
的请求即可。连接时，Client调用connectSync（同步连接）或connect（异步连接，连接成功  
后Client会收到CMD\_CHANNEL\_HALF\_CONNECTED消息）即可连接到Server。  
·与request/response模式相反，AsyncChannel中另外一种应用模式就是Server端维护Client  
的信息。这样，Server可以向Client发送自己的状态或者其他一些有意义的信息。与这种模式  
类似的应用场景就是第4章介绍的wpa\_cli和wpa\_supplicant。wpa\_cli可以发送命令给WPAS去  
执行。同时，WPAS也会将自己的状态及其他一些消息通知给wpa\_cli。  
在WifiService相关模块中，第二种应用模式使用得较多。另外，AsyncChannel中Client和  
Server端在最开始建立连接关系时，可以采用同步或异步的方式  
  
以异步方式为例介绍第二  
种应用模式中AsyncChannel的使用步骤。  
1）Client调用AsyncChannel的connect函数。Client的Handler会收到一个名为  
CMD\_CHANNEL\_HALF\_CONNECTED消息。  
2）Client在处理CMD\_CHANNEL\_HALF\_CONNECTED消息时，需通过sendMessage函数  
向Server端发送一个名为CMD\_CHANNEL\_FULL\_CONNECTION的消息。  
3）Server端的Handler将收到此CMD\_CHANNEL\_FULL\_CONNECTION消息。成功处理  
它后，Server端先调用AsyncChannel的connected函数，然后通过sendMessage函数向Client端发  
送CMD\_CHANNEL\_FULLY\_CONNECTED消息（特别注意，详情见下文）。  
4）Client端收到CMD\_CHANNEL\_FULLY\_CONNECTED消息。至此，Client和server端成  
功建立连接。  
5）Client和Server端的两个Handler可借助sendMessage和replyToMessge来完成请求消息及  
回复消息的传递。注意，只有针对那些需要回复的情况，Server端才需调用  
replyToMessage。  
6）最后，Client和Server的任意一端都可以调用disconnect函数以结束连接。该函数将导  
致Client和Server端都会收到CMD\_CHANNEL\_DISCONNECTED消息。  
特别说明　上述步骤的描述来自AsyncChannel.java文件中的注释。但实际上Server端代  
码在处理CMD\_CHANNEL\_FULL\_CONNECTION消息时并不能按照上面的描述开展工作。因  
为AsyncChannel对象一般由客户端创建，而CMD\_CHANNEL\_FULL\_CONNECTION消息无法  
携带AsyncChannel对象（AsyncChannel对象无法通过Binder进行跨进程传递）。所以，Server  
端并不能获取客户端创建的这个AsyncChannel对象，它也就没办法调用AsyncChannel的  
connected函数。  
  
下面结合WifiManager中相关代码来介绍AsyncChannel中第二种模式涉及的一些重要函数：  
在WifiManager和WifiService的通信中，AsyncChannel两端的Handler的分别是WifiManager\#ServiceHandler  
和WifiServiceImpl\#ClientHandler。  
虽然不知道他们是怎么透过binder通信，但是可以知道他们会收到这些跨进程的消息，这些消息都会在各自的handler中处理。  
  
WifiService构造函数中主要工作是创建一些核心对象，其中：  
·WifiStateMachine是WifiService中的核心  
  
**WifiStateMachine**  
WifiStateMachine类中重要的三个依赖，分别是WifiNative、WifiMonitor以及SupplicantStateTracker。  
**WifiNative**：WifiNative用于和WPAS通信，其内部定义了较多的native方法（对应的JNI模块是android\_net\_wifi\_Wifi）  
**WifiMonitor**：WifiMonitor最重要的内容是其内部的WifiMonitor线程，该线程专门用于接收来自WPAS的消息  
下面是该类中的重要方法：  
·handleSupplicantStateChange用于处理WPAS的状态变化（见下文解释），它将先把这些  
变化信息交给WifiStateMachine去处理。而WifiStateMachine将根据处理情况再决定是否需要  
由下一节介绍的SupplicantStateTracker来处理。handleSupplicant StateChange代码比较简单。  
·handleDriverEvent用于处理来Driver的信息 。  
·handleEvent用于处理其他消息事件  
  
**SupplicantStateTracker**：  
SupplicantStateTracker用于跟踪和处理WPAS的状态变化。SupplicantStateTracker也从  
StateMachine派生，并且它还定义了8个状态对象  
WPAS的状态指的是wpa\_sm状态机中的状态，包括WPA\_DISCONNECTED、  
WPA\_INTERFACE\_DISABLED、WPA\_INACTIVE、WPA\_SCANNING、  
WPA\_AUTHENTICATING、WPA\_ASSOCIATING、WPA\_ASSOCIATED、  
WPA\_4WAY\_HANDSHAKE、WPA\_GROUP\_HANDSHAKE、WPA\_COMPLETED共10个状  
态。WifiService定义了SupplicantState类来描述WPAS的状态，包括DISCONNECTED、  
INTERFACE\_DISABLED、INACTIVE、SCANNING、AUTHENTICATING、ASSOCIATING、  
ASSOCIATED、FOUR\_WAY\_HANDSHAKE、GROUP\_HANDSHAKE、COMPLETED、  
DORMANT、UNINITIALIZED、INVALID共13个状态  
  
WifiStateMachine共定义30个状态，其种类和层级关系如图：  
![SouthEast 1][]  
当WifiStateMachine开始运行后，其最终将进入DriverUnloadedState  
  
Settings中Wi-Fi设置相关类：  
![SouthEast 2][]  
WifiSettings创建了一个广播接收对象，该对象关注的广播事件较多，其中四个重要的广播事件如下。  
·WIFI\_STATE\_CHANGED\_ACTION：该广播事件反映了Wi-Fi功能所对应的状态，这些状态是WIFI\_STATE\_DISABLED（Wi-Fi功能已被关闭）、WIFI\_STATE\_DISABLING（Wi-Fi功能正在关闭中）、WIFI\_STATE\_ENABLED（Wi-Fi功能已被打开）、  
WIFI\_STATE\_ENABLING（Wi-fi功能正在打开中）和WIFI\_STATE\_UNKNOWN（Wi-Fi功能状态未知）。  
·SCAN\_RESULTS\_AVAILABLE\_ACTION：该广播事件表示无线网络扫描完毕，可以从WPAS中获取扫描结果。  
·SUPPLICANT\_STATE\_CHANGED\_ACTION：该广播事件用于表示WPAS的状态发生了变化。它和5.2.3节中SupplicantStateTracker介绍的SupplicantState相关。  
·NETWORK\_STATE\_CHANGED\_ACTION：该广播事件用于表示Wi-Fi连接状态发生变化。其携带的信息一般是一个NetworkInfo对象。NetworkInfo类在前文代码注释中曾介绍过，它用于表达一个网络接口的状态（Describes the status of anetwork interface）。  
  
由于WifiEnabler先注册广播接收对象，所以对于WIFI\_STATE\_CHANGED\_ACTIONSUPPLICANT\_STATE\_CHANGED\_ACTION和NETWORK\_STATE\_CHANGED\_ACTION广播来说，WifiEnabler的广播接收对象将先被触发以处理这些消息，然后才是WifiSettings的广播接收对象 。  
提示　研究WifiEnabler广播接收对象的代码后，会发现实际上它真正处理的只有WIFI\_STATE\_CHANGED\_ACTION广播WifiEnabler将根据该广播的信息以更新Switch的界面  
  
**启用Wi-Fi功能**  
打开wifi开关：  
1.首先：WifiManager\#setWifiEnabled(isChecked)  
setWifiEnabled流程：  
1）WifiService的setWifiEnabled函数将调用WifiStateMachine中的同名函数。在WifiStateMachine中，CMD\_LOAD\_DRIVER和CMD\_START\_SUPPLICANT两个消息将发送给状态机去执行。WifiStateMachine最初的状态是DriverUnloadedState。  
2）DriverUnloadedState接收到CMD\_LOAD\_DRIVER消息后将转入DriverLoadingState。而DriverLoadingState的enter函数将创建一个工作线程来执行WifiNative的loadDriver以加载Wlan驱动。如果driver加载成功，该线程会发送CMD\_LOAD\_DRIVER\_SUCCESS消息给状态机。  
3）DriverLoadingState将在其processMessage中处理CMD\_START\_SUPPLICANT和CMD\_LOAD\_DRIVER\_SUCCESS消息。其中，DriverLoadingState会延迟对CMD\_START\_SUPPLICANT的处理。而对于CMD\_LOAD\_DRIVER\_SUCCESS，DriverLoadingState将直接转入DriverLoadedState。  
4）DriverLoadedState将继续处理CMD\_START\_SUPPLICANT。在其processMessage中，wpa\_supplicant进程将被启动，并且WifiMonitor将建立WifiService和WPAS的关系。同时，状态机将转入SupplicantStartingState。另外，当WifiMonitor成功连接上WPAS后，它将发送一个SUP\_CONNECTION\_EVENT消息。  
5）SupplicantStartingState将处理SUP\_CONNECTION\_EVENT消息。这些处理包括设置初始化WPS相关的信息、设置WifiState、发送消息给SupplicantStateTracker状态机、初始化WifiConfigStore等。最后，SupplicantStartingState将转入DriverStartedState。DriverStartedState的父状态是SupplicantStartedState。所以这两个状态的enter函数均会被调用。  
6）SupplicantStartedState在其enter函数中将设置扫描间隔。而DriverStartedState在其enter函数中将完成诸如Country Code、Frequency Band、Bluetooth共存模式等设置工作。有些工作需要发送形如"DRIVER XXX"的命令给WPAS。最后，SupplicantStartedState将转入DisconnectedState。  
7）DisconnectedState的enter函数将被执行（其父状态ConnectModeState的enter函数没有完成什么实质性的工作）。该函数主要完成了后台扫描及定时扫描工作的一些设置。  
  
当Wi-Fi功能被启用时，将收到WIFI\_STATE\_CHANGED\_ACTION广播，而该广播的处理函数是updateWifiState：  
wifimanger\#startScan()  
从WPAS中获取扫描结果，并保存到mScanResults变量中，发送SCAN\_RESULTS\_AVAILABLE\_ACTION广播  
在4.2api中，是有参数选择scan\_type的，即选择passive或active，在5.0后就没有了  
2.假设WPAS扫描完毕，则WifiSettings将收到SCAN\_RESULTS\_AVAILABLE\_ACTION广  
播，该广播的处理函数为updateAccessPoints，更新AP列表  
  
点击列表选择ap  
1.点击连接按钮触发  
void submit(WifiConfigController configController) \{  
final WifiConfiguration config = configController.getConfig();  
if (config == null) \{  
......  
\} ......// 其他处理  
\} else \{  
if (configController.isEdit() || requireKeyStore(config))  
mWifiManager.save(config, mSaveListener);  
else mWifiManager.connect(config, mConnectListener);// 连接目标无线网络  
\}  
......  
\}  
如果一切顺利，它将接收一个NETWORK\_STATE\_CHANGED\_ACTION广播事件以告知手机成功已  
经加入目标无线网络  
  
connect流程：  
connect的流程包括如下几个关键点。  
·\*整个流程起源于WifiManager向WifiStateMachine发送的CONNECT\_NETWORK消息。  
  
\*·ConnectModeState将处理此消息。在其处理过程中，它将发送一系列命令给WPAS，而  
WPAS将完成802.11规范中所定义的身份认证、关联、四次握手等工作。ConnectModeState随  
之转入DisconnectingState。  
  
\*·当WPAS加入目标无线AP后，它将发送NETWORK\_CONNECTION\_EVENT给  
WifiStateMachine。DisconnectingState的父状态ConnectModeState将处理此消息，具体处理过程  
比较简单。最终，WifiStateMachine将转入ObtaingIpState。  
  
\*·在ObtaingIpState的enter函数中，DhcpStateMachine对象将被创建。DhcpStateMachine和  
dpcpcd有关。相关代码比较简单，请读者自行阅读。在WifiStateMachine和DhcpStateMachine  
的交互过程中，DhcpStateMachine将向WifiStateMachine发送CMD\_PRE\_DHCP\_ACTION和  
CMD\_POST\_DHCP\_ACTION消息。在CMD\_POST\_DHCP\_ACTION消息的处理过程  
中，WifiStateMachine将转入VerifyingLinkState。  
  
\*·VerifyingLinkState将和WifiWatchdogStateMachine交互。WifiWatchdogStateMachine用于监  
控无线网络信号的好坏。如果一切正确，它将转入CaptivePortalCheckState。  
  
\*·CaptivePortalCheckState用于检查目标无线网络提供商是否需要Captive Portal Check。如果一切正常，WifiStateMachine最终将转入ConnectedState。该状态就是本章第二条分析路线的终点。  
  
  
**WifiWatchdogStateMachine**  
WifiWatchdogStateMachine用于监控无线网络的信号质量，在WifiService的  
checkAndStartWifi函数中被创建，其创建函数是makeWifiWatchdogStateMachine  
  
WifiWatchdogStateMachine中的各个状态及层级关系：  
![SouthEast 3][]  
WifiWatchdogStateMachine完全靠广播事件来驱动，相关代码在setupNetworkReceiver函数中

private void setupNetworkReceiver() {
            mBroadcastReceiver = new BroadcastReceiver() {
                @Override
                public void onReceive(Context context, Intent intent) {
                    String action = intent.getAction();
                    if (action.equals(WifiManager.RSSI_CHANGED_ACTION)) {
                        obtainMessage(EVENT_RSSI_CHANGE,
                                intent.getIntExtra(WifiManager.EXTRA_NEW_RSSI, -200), 0).sendToTarget();
                    } else if (action.equals(WifiManager.SUPPLICANT_STATE_CHANGED_ACTION)) {
                        sendMessage(EVENT_SUPPLICANT_STATE_CHANGE, intent);
                    } else if (action.equals(WifiManager.NETWORK_STATE_CHANGED_ACTION)) {
                        sendMessage(EVENT_NETWORK_STATE_CHANGE, intent);
                    } else if (action.equals(Intent.ACTION_SCREEN_ON)) {
                        sendMessage(EVENT_SCREEN_ON);
                    } else if (action.equals(Intent.ACTION_SCREEN_OFF)) {
                        sendMessage(EVENT_SCREEN_OFF);
                    } else if (action.equals(WifiManager.WIFI_STATE_CHANGED_ACTION)) {
                        sendMessage(EVENT_WIFI_RADIO_STATE_CHANGE,intent.getIntExtra(
                                WifiManager.EXTRA_WIFI_STATE, WifiManager.WIFI_STATE_UNKNOWN));
                    }
                }
            };
    
            mIntentFilter = new IntentFilter();
            mIntentFilter.addAction(WifiManager.NETWORK_STATE_CHANGED_ACTION);
            mIntentFilter.addAction(WifiManager.WIFI_STATE_CHANGED_ACTION);
            mIntentFilter.addAction(WifiManager.RSSI_CHANGED_ACTION);
            mIntentFilter.addAction(WifiManager.SUPPLICANT_STATE_CHANGED_ACTION);
            mIntentFilter.addAction(Intent.ACTION_SCREEN_ON);
            mIntentFilter.addAction(Intent.ACTION_SCREEN_OFF);
            mContext.registerReceiver(mBroadcastReceiver, mIntentFilter);
        }

[SouthEast]: /images/20220602/de78727a935d49caa2f77193876cef75.png
[SouthEast 1]: /images/20220602/aee91eda64c148f68a6c2661691a53c0.png
[SouthEast 2]: /images/20220602/37c811d390e34026a8ea467b42945fd8.png
[SouthEast 3]: /images/20220602/eafc1fc2d1e545d793e6367a707087e1.png