CN106020942A - 一种基于多系统的WiFi设备复用方法及装置 - Google Patents

Abstract

本发明提供了一种基于多系统的WiFi设备复用方法及装置，依据状态存储模块中所有系统当前状态，对来自当前系统代理客户端的操作请求进行仲裁，决定是否执行操作；对需要执行的操作，执行操作；对不需要执行的操作，设置伪结果和/或伪消息；实现多个系统的WiFi设备复用。本发明在基于容器技术的多个系统上，通过事先对来自系统的操作请求进行仲裁，能够实现多个系统之间的独立运行，用户可以在任意一个系统中使用WiFi功能。由于每个系统对应的WiFi配置过滤表相互独立，使得每个系统对应的WiFi配置信息是相互独立的，各系统之间做到完全隔离。

Description

一种基于多系统的WiFi设备复用方法及装置

技术领域

本发明属于通信设备技术领域，涉及一种嵌入式移动终端，具体涉及一种基于多系统的WiFi设备复用方法及系统。

背景技术

操作系统(Operation System，简称OS)是管理和控制计算机硬件(包括移动终端)与软件资源的计算机程序，是直接运行在“裸机”上的最基本的系统，任何其它软件都必须在系统的支持下才能运行。操作系统是用户和计算机的接口，同时也是计算机硬件和其它软件的接口。

随着计算机技术的发展，为了满足用户的多种需求，越来越多的计算机硬件设备能够同时安装多个系统。以移动终端为例，随着容器技术的发展，能够实现在一台移动终端设备上运行多个系统。

容器是一种轻量级的虚拟化技术，可以很方便地隔离进程和资源，而不需要提供指令解释机制以及全虚拟化的其它复杂性。通过提供一种创建和进入容器的方式，让容器内的系统或应用程序就像在独立的机器上运行一样，但又能共享很多底层的资源。

Linux Container(LXC)是当前研究最热的容器技术之一。以Android系统为例，由于Android系统是一个基于Linux内核的开源移动终端设备系统，这使Android系统可以很方便地部署在Linux容器上，比如哥伦比亚大学的Cells即是基于Linux容器的Android虚拟化产品。

对于Cells，通过容器技术在一台移动终端设备上运行多个Android系统。虽然各个系统之间相互独立，但是仍然需要共享底层的硬件资源。Cells采用代理的方式，在Android系统的HAL层引入虚拟化技术，将HAL层的接口函数进行封装，作为代理客户端。这样当域内的Android系统调用HAL层的原函数调用接口时，首先会进入代理客户端；然后代理客户端将调用信息发给域外的代理服务端，代理服务端收到消息后，对其进行参数解析，然后调用真实的函数接口；最后代理服务端将真实的执行结果通过套接字反馈给域内的代理客户端。同样的，也可以通过上述代理方式，使域内的Android系统可以共享根域的唯一的WiFi设备。

然而，在对此方法的研究和实践过程中，本发明的发明人发现，上述代理的方式过于简单，存在至少以下技术缺陷：(1)底层的wpa_supplicant和Android系统上层都各自维护着一个状态机，一个容器的操作很容易引起另一个容器的状态机崩溃；(2)WiFi所有热点的配置信息(比如名称、密码等)都是底层的wpa_supplicant保存的，Android系统在每次打开WiFi时，都会从wpa_supplicant中获取所有的配置信息，因此多个Android系统之间的所有热点连接信息是共享的，即多个Android系统之间无法做到完全隔离。

由于上述技术缺陷，目前同一移动终端设备上的多个Android系统还不能实现同时共享WiFi设备。

发明内容

本发明的目的旨在针对上述现有技术中存在的问题，提供一种基于多系统的WiFi设备复用方法，通过该方法能够使多个系统都能正常使用WiFi设备，并且能够进一步实现多个系统之间WiFi信息相互独立，做到完全隔离。

本发明的另一目的旨在提供一种基于多系统的WiFi设备复用装置。

为了达到以上目的，本发明采用以下技术方案来实现。

本发明提供了一种基于多系统的WiFi设备复用方法，其特征在于，应用于基于Linux容器技术构建的多个系统，每个容器内的系统通过创建的虚拟网卡对与容器外部实现数据包在容器内外之间的传输；同时通过虚拟网卡与真实网卡之间的源地址转换，实现数据包在系统与外部设备之间的传输；所述WiFi设备复用方法包括以下步骤：

接收来自当前系统代理客户端的操作请求；

依据状态存储模块中所有系统当前状态，对来自当前系统代理客户端的操作请求进行仲裁，决定是否执行操作；

对需要执行的操作，执行操作；

对不需要执行的操作，构造伪结果和/或伪消息；

将执行结果或伪结果发送给当前系统代理客户端，将伪消息发送给当前系统的虚拟WPA客户端；实现多个系统的WiFi设备复用。

上述基于多系统的WiFi设备复用方法，状态保存模块用于保存所有系统对应的多种状态，包括驱动加载标志、守护进程启动标志、WiFi连接状态以及WiFi当前连接信息。

依据WiFi使用周期，WiFi所处阶段包括WiFi设备初始化阶段，WiFi使用阶段和WiFi设备终止阶段。

对WiFi设备初始化阶段，主要是需要判断WiFi设备是否已经初始化，如果已经被初始化，则当前系统进行伪初始化操作；如果没有被初始化，则正常执行初始化工作。本发明中操作请求依次为加载网卡硬件驱动、启动WiFi守护进程、打开虚拟WPA客户端、打开WPA客户端和启动消息接收线程；采用的具体实现方式包括以下步骤：

步骤201，接收来自当前系统代理客户端的WiFi设备初始化的操作请求；

步骤202，加载网卡硬件驱动；判断网卡硬件驱动是否被后台系统加载；如果没有被加载，则直接加载网卡硬件驱动；如果已经被加载过，则构造加载成功的伪结果；然后将真实操作结果或者伪结果反馈给当前系统代理客户端；

步骤203，启动WiFi守护进程；判断WiFi守护进程是否被后台系统启动；如果没有被启动，则直接启动WiFi守护进程；如果已经被启动，则构造启动成功的伪结果；然后将真实操作结果或者伪结果反馈给当前系统代理客户端；

步骤204，在代理客户端和代理服务端之间打开一个虚拟WPA客户端，代替原WPA客户端接收由代理服务端发送的消息。

步骤205，打开WPA客户端；判断WPA客户端是否被后台系统打开；如果没有被打开，则直接打开WPA客户端；如果已经被打开，则构造打开成功的伪结果；然后将真实操作结果或者伪结果反馈给当前系统代理客户端；WPA客户端构造在根域，并以WiFi守护进程作为服务端，构造状态事件消息通道；

步骤206，启动消息接收线程；判断是否在代理服务端已经启动了一个消息接收线程，如果没有，则启动该线程；如果已经启动，则构造启动成功的伪结果；然后将真实操作结果或者伪结果反馈给当前系统代理客户端。这个消息接收线程将从WPA客户端中接收由WiFi守护进程发送来的所有消息，并对这些消息进行解析处理以及状态保存，最后将消息发送给相应的虚拟WPA客户端。

WiFi设备初始化后，当前系统WiFi状态为断开状态。

对WiFi设备初始化阶段，操作请求进一步包括初始化WiFi配置表模块，具体实现方式进一步包括：

步骤207，初始化WiFi配置表模块；WiFi配置表模块包括WPA配置表和WiFi配置过滤表；WPA配置表为从WiFi守护进程获取的包含所有WiFi热点配置信息的配置表；WiFi配置过滤表为包含对应系统的所有WiFi热点配置信息的配置表；

WPA配置表初始化，判断WPA配置表是否被后台系统初始化；如果没有被初始化，则获取WiFi守护进程中所有WiFi热点配置信息，然后解析获取的信息获得WPA配置表，完成对WPA配置表的初始化，然后初始化WiFi配置过滤表；如果已经被初始化，则直接初始化WiFi配置过滤表；

WiFi配置过滤表初始化，打开当前系统在代理服务端对应的WiFi过滤表保存文件，读取内容，然后根据读取的内容在WPA配置表中获取ID信息，完成WiFi配置过滤表初始化。

对WiFi设备使用阶段，所述操作请求根据应用场景设定；此阶段，

在执行完操作后，与WiFi状态相关的，需要更改并保存当前系统的WiFi状态；

在构造伪结果后，与WiFi状态相关的，需要构造伪消息，同时更改并保存当前系统的WiFi状态。

应用场景包括开启WiFi、连接WiFi、删除WiFi、关闭WiFi、系统切换。

在WiFi使用阶段，针对不同应用场景，WiFi设备复用方法具体为：

(1)开启WiFi，即当用户打开设置界面的WiFi开启按钮时，首先当前系统会发送一条指令来获取当前系统所有可用热点的列表，当前系统再根据这个列表逐一从WiFi守护进程中获取热点的详细信息。因此从WiFi守护进程返回的热点列表必须在代理服务端经过WiFi配置过滤表过滤后再返回，这样可以使多个系统之间WiFi配置信息相互独立；

(2)连接WiFi热点，接收来自当前系统的建立连接的指令，判断待连接的WiFi热点是否是新建立的连接，如果是，则首先需要更新WiFi配置表模块(包括WPA配置表和WiFi配置过滤表)，然后判断当前准备连接的热点和后台系统连接的热点是否是同一个，如果是，则当前系统进行伪连接；如果不是，则执行真实的连接操作，并断开后台系统的连接；最后保存相应的WiFi状态；

(3)删除WiFi热点，接收来自当前系统的删除WiFi热点的指令，判断待删除的WiFi热点是否是真实连接；如果当前系统删除的是当前连接的热点，而且后台系统连接着同一个热点，并且后台是进行的伪连接，则此时不真实执行删除操作，直到后台系统都断开连接时，才执行真实的删除操作；否则直接执行删除操作；最后保存相应状态，并更新WiFi配置表模块(包括WPA配置表和WiFi配置过滤表)；

(4)关闭WiFi热点，接收来自当前系统的关闭WiFi热点的指令，判断待关闭的WiFi热点是否是真实连接；如果当前系统处于连接状态，则首先需要判断后台系统是否连接着同一个热点，如果是，则前台系统进行伪断开，以保持后台系统的WiFi继续使用，如果不是，则直接执行关闭操作即可；最后保存相应的状态；

(5)系统切换，接收来自当前系统的系统切换的指令，判断待切换的当前系统是否与后台系统连接了同一个WiFi热点；如果不是，由于前台系统连接了一个不同的热点而导致连接断开的后台系统再次切换到前台时，如果切换后没有后台系统处于连接状态，那么前台系统自动连接上之前被断开的热点；如果切换后有后台系统处于连接状态，则自动伪连接上相同的热点(前提是该容器有相同热点的配置信息)；最后保存相应的状态；。

对WiFi设备终止阶段，当用户想对当前系统的WiFi进行终止操作时，例如打开飞行模式时，当前系统会做一系列常规操作来停止WiFi设备的使用，此时需要判断是否还有其它后台系统正在使用，如果有，则不真实执行操作，进行伪终止操作；如果没有，则真实执行终止WiFi设备的操作，然后清除WiFi配置表(包括WPA配置表和WiFi配置过滤表)的内容，并保存相应的状态。本发明中操作请求依次为终止WiFi设备、关闭守护进程、关闭WPA客户端、关闭当前系统对应的WPA虚拟客户端，退出消息接收线程、卸载网卡硬件驱动、清除WPA配置表和当前系统的WiFi配置过滤表中所有内容，针对与所有系统相关的操作请求，均需要结合所有系统当前状态对操作请求进行仲裁，决定是否执行操作。

本发明进一步提供了一种基于多系统的WiFi设备复用装置，应用于基于Linux容器技术构建的多个系统，每个容器内的系统通过创建的虚拟网卡对与容器外部实现数据包在容器内外之间的传输；同时通过虚拟网卡与真实网卡之间的源地址转换，实现数据包在系统与外部设备之间的传输；该WiFi设备复用装置包括：

接收模块，接收来自当前系统代理客户端的操作请求；

仲裁模块，依据状态存储模块中所有系统当前状态，对来自当前系统代理客户端的操作请求进行仲裁，决定是否执行操作；

执行模块，对需要执行的操作，执行操作；

构造模块，对不需要执行的操作，构造伪结果和/或伪消息；

发送模块，将执行结果或伪结果发送给当前系统代理客户端，将伪消息发送给当前系统的虚拟WPA客户端。

上述基于多系统的WiFi设备复用装置，进一步包括：

状态保存模块，用于保存所有系统对应的多种状态，包括驱动加载标志、守护进程启动标志、WiFi连接状态以及WiFi当前连接信息。

上述基于多系统的WiFi设备复用装置，进一步包括：

WiFi配置表模块，用于对WiFi热点信息进行过滤操作，包括WPA配置表和WiFi配置过滤表；WPA配置表为从WiFi守护进程获取的包含所有WiFi热点配置信息的配置表，即所有连接过热点的信息；WiFi配置过滤表为包含对应系统的所有WiFi热点配置信息的配置表。

本发明提供的基于多系统的WiFi设备复用方法及装置，具有以下至少一项有益效果：

1、在基于容器技术的多个系统上，通过事先对来自系统的操作请求进行仲裁，能够实现多个系统之间的独立运行，用户可以在任意一个系统中使用WiFi功能；

2、由于每个系统对应的WiFi配置过滤表相互独立，使得每个系统对应的WiFi配置信息是相互独立的，各系统之间做到完全隔离；

3、在根域的代理服务端构造的状态保存模块，将上层系统状态机与下层WiFi守护进程状态机隔离开，状态保存模块中对应系统的WiFi状态与上层系统状态机保持一致；而下层WiFi守护进程状态机仅与与之真实连接的系统的状态一致；从而能够保证一个容器内系统的操作不会引起另一个容器的状态机崩溃；

4、通过构造伪结果和/或伪消息让容器内的系统在连接WiFi时进行伪连接，可以使多个系统连接上同一个热点，这样多个系统就可以同时上网，因此可以实现在同一时刻，多个系统同时访问网络数据。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，以下将对实施例或现有技术描述中所需要使用的附图作简单的介绍，显而易见地，以下描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员而言，在不付出创造性劳动的前提下，还可以根据这些附图所示实施例得到其它的实施例及其附图。

图1为本实施例的基于多Android系统的WiFi设备复用涉及的框架图。

图2为本实施例的WiFi配置表模块原理图；

图3为本实施例的状态保存模块中各WiFi状态转换关系图；

图4为本实施例的基于多Android系统的WiFi设备复用方法的流程图；

图5为本实施例的WiFi设备初始化流程图；

图6为本实施例的多Android系统的数据通道图；

图7为本实施例的WiFi使用阶段操作流程图；

图8为本实施例的WiFi设备终止流程图。

具体实施方式

以下将结合附图对本发明各实施例的技术方案进行清楚、完整的描述，显然，所描述实施例仅仅是本发明的一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所得到的所有其它实施例，都属于本发明所保护的范围。

利用容器技术在同一设备上同时运行两个或多个系统，在目前技术中已经得到实现，例如基于Linux内核的容器技术，能够在同一移动终端(如手机)上同时运行多个Android系统。而在多个系统中能够同时共享WiFi设备的技术，目前还没有较大进展，主要是因为一个容器中系统的操作可能引起另外一个容器中系统的崩溃，另外多个系统之间的热点配置信息未做到完全独立。

本发明针对基于Linux容器技术的多系统进行了相关研究，提供了一种WiFi设备复用方法，解决上述技术问题。为了能够更容易让本领域技术人员理解，以下实施例中均采用Android系统(Android系统)作为系统进行说明。但其并不构成对本发明的任何限制。本领域技术人员在本发明公开的技术内容启示下，将其应用于基于Linux容器技术的其它系统，例如Linux系统、WebOS等。

如图1所示，本实施例利用Linux容器技术在同一个移动终端上同时运行两个Android系统(Android1和Android2)，并采用通用的代理机制对WiFi设备进行复用。在HAL(Hardware Abstraction Layer)层引入设备虚拟化技术，将HAL层的原函数调用接口封装为代理客户端，Android系统的Framework层(构架层)调用HAL层的接口，首先会进入代理客户端，由代理客户端将调用信息发送给根域的代理服务端，然后由代理服务端来执行真实的HAL层的调用操作，从而与底层的WiFi守护进程(本实施例中为wpa_supplicant进程)进行通信。

为了便于理解，首先对本实施例涉及的两个比较重要的模块进行解释：WiFi配置表模块和状态保存模块。

WiFi配置表模块包括WPA配置表和WiFi配置过滤表；WPA配置表为从WiFi守护进程获取的包含所有WiFi热点配置信息的配置表；WiFi配置过滤表为包含对应系统的所有WiFi热点配置信息的配置表。

以Android系统为例，WiFi配置表模块，通过使用如图2所示的WiFi配置表对WiFi热点信息进行过滤操作，这样就可以使多个Android系统之间可用热点相互独立，各自都有自己的热点连接信息。WiFi配置表模块包括WPA(Wi-Fi Protected Access)配置表和WiFi配置过滤表。WPA配置表里面存储着所有连接过的热点的配置信息(与wpa_supplicant进程中保存的信息一致)，每一条记录包括热点名称(WiFi_name)、wpa_id[]的最大下标(max_num)、以及该热点在WPA中的id(wpa_id[]，这是一个数组，存储了所有容器中对应该热点的id)，其中max_num加1即表示连接过该热点的容器数(系统数目)。而WiFi配置过滤表里面只存储对应Android系统的热点的配置信息，每一条记录包括热点名称(WiFi_name)、连接顺序(add_num)、以及该热点连接在wpa_supplicant中的id，连接顺序表示了该Android系统对这个热点建立连接的顺序，即对应了WPA配置表中wpa_id[]的下标。每个过滤表对应一个保存文件，文件里只存储热点名称和连接顺序，以供下次初始化WiFi配置过滤表时使用。通过这样的过滤表在每次从wpa_supplicant中获取配置信息时对信息进行过滤，从而使各个容器中的系统都只能看到自己的连接信息。如图2所示，Android1和Android2过滤表中的信息不相同；WPA配置表中的信息是两个过滤表信息之和；以wifi_name名称为Ap_3为例，虽然两个过滤表中也都有其相关信息，但是其在两个过滤表中的wpa_id不同，对wpa_supplicant来说这是两条相互独立的记录；WPA配置表中max_num的数值是Ap_3连接过的系统数目减1。

状态保存模块用于保存所有系统对应的多种状态，包括驱动加载标志、守护进程启动标志、WiFi连接状态以及WiFi当前连接信息等。驱动加载标志用来记录当前系统是否已经加载了驱动；守护进程启动标志用来记录当前系统是否已经启动了WiFi守护进程；WiFi连接状态用来记录当前系统的WiFi状态，WiFi状态包括连接状态、断开状态、后台不可用状态、终止状态；WiFi当前连接信息记录了当前系统正在使用的热点的信息，包括名称、网卡地址等。

以基于容器技术的的多Android系统为例，状态保护模块位于根域代理服务端中，进行Android系统相应状态保存，包括驱动加载标志(LOADED、UNLOADED)、守护进程启动标志(START、STOP)、WiFi连接状态以及WiFi当前连接信息(热点名称、网卡地址、热点的wpa_id、真实连接的热点的wpa_id)。其中WiFi连接状态主要用于协调wpa_supplicant状态机和多个Android上层的状态机之间的关系，使多个Android上层的状态机之间能相互独立工作。状态保存模块针对每个系统构造有相应的状态保存子模块。在代理服务端的状态保存模块中，WiFi连接状态主要有如下六种：

CONNECTED：连接状态，表示该系统正连接着某个热点；

DISCONNECTED：断开状态，系统未连接网络，或者系统的WiFi处于关闭状态；

BACK_DISABLE：后台不可用状态，其所有可用网络被构造为disabled的状态。

CONNECTING：这是一个中间状态，表示系统正在连接某个热点的过程；

DISCONNECTING：这是一个中间状态，表示系统正在断开某个热点连接的过程；

TERMINATE：终止状态，表示系统关闭了守护进程，卸载了硬件驱动，此时该容器的WiFi功能不可用。

各WiFi状态之间的转换关系如图3，其中DISCONNECTED可以与CONNECTED、BACK_DISABLE、TERMINATE状态之间进行相互转换；但CONNECTED、BACK_DISABLE、TERMINATE状态之间不能直接进行相互转换，必须经转换成DISCONNECTED状态，再进行其它状态转换。CONNECTING、DISCONNECTING是DISCONNECTED与CONNECTED之间相互转换的中间过程。

下面结合图1及图4，对本实施例提供的基于多Android系统的WiFi设备复用方法进行详细解释，该方法主要包括以下步骤：

步骤001，接收来自当前系统代理客户端的操作请求。

本步骤中，针对WiFi处在不同的阶段(初始化阶段、使用阶段和终止阶段)，其涉及的操作请求不同，其表现形式也可能有所不同。在基于Android的系统中，操作请求的具体形式主要为接口调用或者具体的指令。

以WiFi处于使用阶段为例，其操作请求可以是连接热点，而这一个操作的完成，则需要一组操作指令序列构成。

步骤002，依据状态存储模块中所有系统当前状态，对来自当前系统代理客户端的操作请求进行仲裁，决定是否执行操作。

本步骤的目的是对操作请求进行仲裁，确定是否真实执行。进行仲裁的判断依据为存储在代理服务端状态保存模块中所有系统的当前状态。

仲裁对象包括接口调用和指令。接口调用指由代理客户端发送给代理服务端的原HAL层的接口调用。指令指由代理客户端通过一个接口调用的参数向WiFi守护进程(wpa_supplicant)发送的具体指令。通常Android系统完成一个操作(比如连接热点)需要一组指令序列。这些接口调用和指令在代理服务端接收到时，都需要先根据其执行场景进行仲裁判断，然后根据仲裁结果来决定是否需要真实的执行，如果不需要，则做相应的处理并返回伪结果，如果需要，则正常执行。

步骤003，对需要执行的操作，执行操作。

本步骤的目的是，依据操作请求，执行操作。根据具体的操作请求(例如加载网卡驱动、开启WiFi、连接WiFi等)，本领域技术人员可以选用本领域常规手段来实现。

步骤004，对不需要执行的操作，构造伪结果和/或伪消息；

步骤005，将执行结果或伪结果发送给当前系统代理客户端，伪消息发送给当前系统的虚拟WPA客户端；实现多个系统的WiFi设备复用。

步骤004和005的目的是，对于不需要执行的操作请求，构造伪结果和/或伪消息，然后反馈给当前系统代理客户端；让当前系统认为已经执行操作；从而实现WiFi设备在多个系统的复用，也即多个系统独立运行。

要进一步实现多个Android系统共享WiFi，需要在多个Android系统与wpa_supplicant进程之间建立传输数据包的通道。为了达到该目的，在每个容器内外构建成对的虚拟网卡，每个容器内的Android系统通过创建的虚拟网卡与容器外部实现数据包在容器内外之间的传输；同时通过虚拟网卡与真实网卡之间的源地址转换，实现数据包在系统与外部设备之间的传输；进而实现多个Android系统同时共享WiFi设备。

下面结合在WiFi使用周期中WiFi所处不同阶段(WiFi设备初始化阶段、WiFi使用阶段和WiFi设备终止阶段)的具体情况，对本发明提供的WiFi设备复用方法进行详细的解释。

上面提到的几个阶段，是在容器已启动，Android系统和代理服务端初始化，代理客户端被加载的前提下进行的。由于上述技术可以采用本领域常规技术来实现，这里就不在详细阐述。

此外，在用户启动容器阶段，还需要建立数据通道(如图6所示)，具体实现方式包括以下步骤：

步骤101：在容器内外创建匹配的虚拟网卡。

在这里，在容器刚开始启动时，使用虚拟网络设备技术(Veth pair)为每个容器创建一对虚拟网卡<wlan0,tapx>，这对虚拟网卡是一对假造网卡，从任意一端网卡收到的数据包能够直接到达另一端网卡。利用这个特性，将虚拟网卡wlan0放置在容器内，tapx放置在容器外，然后为tapx事先分配好IP地址，容器内部的wlan0在连接WiFi热点时会获得一个与tapx在同一个网段的IP地址，这样容器内部waln0的数据就能直接到达容器外部的tapx，从而保证了数据包在容器内外之间的传输。

步骤102：虚拟网卡与真实网卡之间的源地址转换。

在这里，由于tapx和容器内部的wlan0都是使用的本地IP地址，是无法与因特网上的其它主机进行通信的，设备上的所有数据包只能从真实网卡wlan0发送到外部的其它设备上，因此可以通过NAT技术进行源地址转换，使用一条SNAT语句将内网段地址绑定到真实网卡wlan0上(即虚拟网卡与真实网卡之间的源地址转换)，使数据包在发送时，源地址可以自动转换为真实网卡wlan0的实际IP地址。

以上方法目的是建立多个Android系统与因特网上的其它主机通信的数据通道。上述具体实现方式仅是为了便于本领域技术人员便于理解，并不构成对本发明的任何限定。本领域技术人员可以在上述思想指导下，采用其它实现方式来实现，但其它实现方式也落入本发明的保护范围。

一、WiFi设备初始化阶段

以Android系统4.3为例，容器内的Android系统启动过程中，或者从飞行模式恢复到正常模式时，会进入WiFi设备的初始化阶段；对于Android系统5.0，则每次打开WiFi时都需要首先对WiFi设备初始化。在Android系统技术进化过程中也可能存在其它情形，但不管怎样，在初始化阶段，WiFi状态默认为TERMINATE，待初始化成功后，状态转换为DISCONNECTED，如图3中的转换关系2。

下面结合图5，对WiFi设备初始化阶段的WiFi设备复用方案进行说明，包括以下步骤：

步骤201，接收来自当前系统代理客户端的WiFi设备初始化的操作请求。

在这里，操作请求依次为加载网卡的硬件驱动、启动守护进程、打开虚拟WPA客户端、打开WPA客户端和启动消息接收线程。

步骤202，加载网卡硬件驱动；根据状态保存模块中的驱动加载标志判断网卡硬件驱动是否被后台系统加载；如果没有被加载，则直接加载网卡硬件驱动；如果已经被加载过，则构造加载成功的伪结果；然后将真实操作结果或者伪结果反馈给当前系统代理客户端，并置对应的驱动加载标志为LOADED。

在这里，首先会加载网卡的硬件驱动，此时，代理服务端需要先判断是否有其它Android系统(后台Android系统)已经加载过驱动；如果没有，则直接加载驱动，加载成功后，将加载成功的操作结果发送给当前Android系统代理客户端；而如果硬件驱动已经被其它Android系统成功加载，则此时代理服务端不需要真实执行加载操作，只需构造加载成功的伪结果，并将其发送给当前Android系统代理客户端。由于加载驱动，对本领域技术人员来讲是个常规操作，这里就不再详细描述。下面还会涉及类似的常规操作，比如启动守护进程、打开一个域套接字、开启WiFi的真实执行操作、关闭WiFi的真实执行操作等，均不再进行详细描述。

步骤203，启动WiFi守护进程；根据状态保存模块中的守护进程启动标志判断WiFi守护进程是否被后台系统启动；如果没有被启动，则直接启动WiFi守护进程；如果已经被启动，则构造启动成功的伪结果；然后将真实操作结果或者伪结果反馈给当前系统代理客户端，并置对应的守护进程启动标志为START。

在这里，加载完硬件驱动后，下一步是启动wpa_supplicant守护进程，wpa_supplicant守护进程有且只能有一个，因此，代理服务端同样需要先判断是否有其它Android系统已经启动了这个守护进程，如果没有，则直接启动该进程，将启动成功的操作结果发送给当前Android系统代理客户端；而如果该进程已经被其它Android系统成功启动，则此时代理服务端不需要真实执行启动wpa_supplicant守护进程的操作，构造加载成功的伪结果，并将其发送给当前Android系统代理客户端。

步骤204，在代理客户端和代理服务端之间打开一个虚拟WPA客户端，代替原WPA客户端接收由代理服务端发送的消息。

在这里，原Android系统在WiFi的使用周期中，会通过一个接口调用循环读取原WPA客户端的消息，即wpa_supplicant发送给上层的消息。在本实施例的多Android系统中，每个系统各自打开一个虚拟的WPA客户端，其服务端都为WiFi代理服务端。

步骤205，打开WPA客户端；判断WPA客户端是否被后台系统打开；如果没有被打开，则直接打开WPA客户端；如果已经被打开，则构造打开成功的伪结果；然后将真实操作结果或者伪结果反馈给当前系统代理客户端；WPA客户端构造在根域，并以WiFi守护进程作为服务端，构造状态事件消息通道；

在这里，成功启动wpa_supplicant进程后，当前Android系统会在根域打开一个域套接字作为WPA客户端，其服务端为wpa_supplicant进程，wpa_supplicant就是通过这个套接字向上层发送状态事件等消息。在本实施例的多Android平台上，这个wpa客户端只能有一个，由代理服务端的消息接收线程来接收这个客户端的所有消息，然后对接收到的全部消息进行分析，最后分发给对应的Android系统的虚拟WPA客户端。因此在打开wpa客户端时，代理服务端同样需要检查WPA客户端是否已经被其它Android系统打开，如果没有，再执行真实的打开操作，将打开成功的操作结果发送给当前Android系统代理客户端；如果已经被打开，则直接构造打开成功的伪结果，并将其发送给当前Android系统代理客户端。

步骤206，启动消息接收线程；判断是否在代理服务端已经启动了一个消息接收线程，如果没有，则启动该线程；如果已经启动，则构造启动成功的伪结果；然后将真实操作结果或者伪结果反馈给当前系统代理客户端。

在这里，成功打开WPA客户端后，需要启动一个消息接收线程，这个线程将从WPA客户端中循环读取消息，然后解析消息，保存相应的状态，最后将消息发送对应的虚拟WPA客户端，Android系统则从自己的虚拟WPA客户端中接收到这些消息。

至此，WiFi设备已经初始化完毕，但是根据WiFi配置表模块可知，为了使多个Android平台之间WiFi配置信息相互独立，最后还需要初始化WiFi配置表，即操作请求进一步包括初始化WiFi配置表模块，因此此阶段进一步包括：

步骤207，初始化WiFi配置表模块，包括初始化WPA配置表和WiFi配置过滤表；WPA配置表初始化，判断WPA配置表是否被后台系统初始化；如果没有被初始化，则获取WiFi守护进程中所有WiFi热点配置信息，然后解析获取的信息获得WPA配置表，完成对WPA配置表的初始化，然后初始化WiFi配置过滤表；如果已经被初始化，则直接初始化WiFi配置过滤表；WiFi配置过滤表初始化，打开当前系统在代理服务端对应的WiFi过滤表保存文件，读取内容，然后根据读取的内容在WPA配置表中获取ID信息，完成WiFi配置过滤表初始化。

在这里，首先检查WPA配置表是否已经初始化，如果已经初始化，则直接开始初始化当前Android系统的WiFi配置过滤表。如果没有，则通过执行一次“LIST_NETWORKS”指令来获取wpa_supplicant中的所有热点配置信息，然后解析这些信息，对WPA配置表进行初始化；然后开始初始化WiFi配置过滤表；打开每个Android系统对应的WiFi过滤表保存文件，逐行读取里面的内容，然后根据读取到的WiFi名称(WiFi_name)和连接顺序(add_num)从wpa配置表中找到对应的wpa_id，并将该条记录加入WiFi配置过滤表中，继续读取文件内容，完成整个配置表的初始化过程。

二、WiFi使用阶段

当前Android系统启动成功后，用户便可以使用WiFi功能。在WiFi设备使用阶段，又分为不同的应用场景，例如开启WiFi、连接WiFi、删除WiFi、关闭WiFi、系统切换。虽然应用场景有多种，但WiFi设备复用过程存在很多相似之处，如图7所示，概括讲，本实施例中此阶段WiFi设备复用方法包括以下步骤：

S1，接收来自当前系统代理客户端的操作请求。

在这里操作请求可以根据应用场景设定。目前，操作请求主要包括来自开启WiFi、连接WiFi、删除WiFi、关闭WiFi、系统切换等应用场景的具体指令操作。

S2，依据所有系统状态，对应用场景进行分析，根据分析结果决定是否需要执行操作请求，若执行，进入步骤S3；不执行，进入步骤S5；

S3，真实执行操作请求，然后进入步骤S4；

S4，依据操作结果，判断当前系统对应的WiFi状态是否需要更改，若需要，更改并保存WiFi状态，然后进入步骤S8；

本步骤中的操作结果一般分为操作成功和操作不成功两类；若操作成功，还要看当前操作是否与WiFi状态有关，若与WiFi状态有关，则WiFi状态需要更改。若操作不成功或者当前操作与WiFi无关，WiFi状态不需要更改。

S5，依据操作请求，构造伪结果；

S6，依据构造的伪结果，判断是否需要返回伪消息，若需要，构造WiFi设备伪消息；

本步骤主要是针与WiFi状态有关的状态事件。本步骤的解释跟步骤S4的相类似，伪结果一般分为操作成功和操作不成功两类；若伪结果为操作成功，还要看当前构造的伪操作是否与WiFi状态有关，若与WiFi状态有关，需要构造相应的伪消息。

S7，依据构造的伪结果，判断当前系统对应的WiFi状态是否需要更改，若需要，更改并保存WiFi状态，然后进入步骤S8；

若与WiFi状态有关，则WiFi状态需要更改。若伪操作构造为操作不成功或者当前操作与WiFi无关，WiFi状态不需要更改。

S8，将执行结果或者伪结果发送给代理客户端，将伪消息发送给虚拟的WPA客户端。

不管是否真正执行操作请求，涉及到WiFi状态需要更改的，均需要将更改后的WiFi状态进行保存。

然而，针对不同的应用场景，具体操作流程又不完全一致，下面以几个典型的应用场景分别进行说明。

1、开启WiFi

当应用场景为开启WiFi，用户打开WiFi开启按钮时，在代理服务端执行“LIST_NETWORKS”指令成功后，需要对从wpa_supplicant进程反馈的结果进行过滤，具体步骤包括：

步骤301，接收来自当前Android系统代理客户端开启WiFi的操作请求。

步骤302，执行开启WiFi的操作请求，从WiFi守护进程获取所有WiFi热点配置信息。

在这里即执行“LIST_NETWORKS”指令。

步骤303，解析所获取的信息，根据每个WiFi热点的ID信息在与当前Android系统对应的WiFi配置过滤表中进行查找。

在这里，逐行解析“LIST_NETWORKS”指令的返回结果，根据每个热点的wpa_id在与Android系统对应的WiFi配置过滤表中进行查找，如果找到，则说明该热点属于这个Android系统，如果没有找到，则说明这个热点的连接是由其它Android系统建立的，不属于当前Android系统。

步骤304，解析完毕后，将所有属于当前系统的热点重新排列，组成一个新的WiFi热点列表，并将其发送给Android系统。

在这里，对指令执行结果逐行解析完毕后，需要重组这个执行结果，将所有属于这个Android系统的WiFi热点重新排列，组成一个新的热点列表，将这个新的列表发送给对应的Android系统，然后Android系统就会根据这个重组的列表从wpa_supplicant中获取热点的详细信息，从而完成了过滤功能，使每个容器看到的热点信息相互独立。

2、连接WiFi

用户在连接WiFi时，主要需要考虑到前后台的连接状况。在热点的连接过程中，状态经由CONNECTING最后转为CONNECTED，如图3中的转换关系3，连接过程的具体步骤包括：

步骤401，接收来自当前系统代理客户端的连接WiFi的操作请求；判断是否是第一次连接该热点，若是，则更新代理服务端中的WPA配置表和当前系统的WiFi过滤表，然后进入步骤402；若不是，则直接进入步骤403；

在这里，当前Android系统查询周围可用热点。用户在连接某个热点时，首先置状态为CONNECTING，然后判断是否是第一次连接该热点。这里所说的第一次连接，是针对当前Android系统而言。如果是新建立的连接，则在代理服务端中首先要将这个新的热点连接加入到WPA配置表和Android系统对应的过滤表中。WPA配置表的添加首先需要查找是否已有相同热点，如果有，则直接在对应记录的wpa_id中保存这个热点的id，然后max_num加1；如果没有，则在WPA配置表中新建一条记录，保存这个热点的信息；当前Android系统对应的过滤表的添加则直接新建一条记录即可，里面保存这个热点的信息，最后更新这个过滤表对应的保存文件，

步骤402，根据所有系统的WiFi状态，判断代理服务端中后台是否有系统处于连接状态，若是有进入步骤403；若是没有，进入步骤405。

在这里，在新建立的连接建立好或者Android从wpa_supplicant中获得了这个热点的信息后，会通过执行“SELECT_NETWORK”指令或“RECONNECT”等指令来让wpa_supplicant真实连接这个热点。此时需要判断后台Android系统的连接状态，如果后台有Android系统处于CONNECTED状态，则进入步骤403，如果没有，则进入步骤405。

步骤403，判断代理服务端中后台系统连接的热点与当前系统连接的热点是否是同一个热点，如果是，则进入步骤406；若不是同一个热点，进入步骤404。

在这里，可以通过查询后台系统WiFi当前连接信息，比对WiFi名称是否与当前系统待连接的WiFi热点名称相同；若相同，则是同一个热点；若不同，则不是同一个热点。

上述并不是用来判断同一热点的唯一方法，例如，也可以通过比对当前系统的WiFi配置过滤表和后台系统的WiFi配置过滤表的方法来判断；或者是否WiFi状态均为连接状态等。本领域技术人员可以根据应用场景选择最为合适的方式。

步骤404，断开后台系统与其它热点的连接；然后进入步骤405。

该步骤进一步包括以下分步骤：

步骤4041，向所有处于连接状态的后台系统的虚拟WPA客户端发送断开连接的伪消息。

在这里，当前Android系统与后台Android连接的不是同一个热点的时候，为了方便用户的使用，优先保证前台Android系统的连接，因此需要断开所有后台Android系统的连接。首先给所有处于CONNECTED状态的后台Android系统发送断开连接的伪消息，接着将其状态置为DISCONNECTED。

此外，虽然处于DISCONNECTED，不影响当前Android系统连接热点，但由于后台Android系统WiFi状态是伪断开，很容易被重新连接，状态很不稳定。比较好的方式是关闭后台Android系统的热点，将后台Android系统的状态转换为BACK_DISABLE。

因此，步骤404进一步包括分步骤：

步骤4042，将后台Android系统的可用热点全部置为不可用，并将代理服务端中后台系统WiFi状态构造为处于后台状态。

在这里，通过“DISABLE_NETWORK”指令将所有后台Android系统的可用热点全部置为disabled状态，以防止其影响前台容器的工作，最后置相应后台Android系统的状态为BACK_DISABLE，状态转换如图3中的转换关系5。

步骤405，对当前系统真实执行连接WiFi热点操作，并获取外部IP地址和本地IP地址。

在这里，当前Android系统真实执行连接操作，代理服务端会接收到一条连接成功的事件消息，此时，首先启动一个dhcp客户端为根域的wlan0网卡获取外部IP等信息，然后根据获取到的信息中的DNS地址再启动一个dhcp服务器，这个服务器用于给域内的虚拟网卡wlan0提供本地IP地址，启动成功后进入步骤407。

步骤406，构造执行成功的伪结果，同时构造连接成功的伪消息。

在这里，由于连接WiFi事件与WiFi状态有关，需要根据相关信息构造伪消息；具体为，通过后台系统的状态保存模块中的WiFi连接信息以及相同热点在当前系统的WiFi配置过滤表中的id来构造连接成功的伪消息；并将热点名称以及网卡地址等保存到当前容器的状态保存模块中。其中wifi连接信息中记录的当前连接的热点id与记录的真实连接热点id不同，当前连接的热点id为这个热点在当前系统的wifi配置过滤表中的id，而真实连接热点的id为此时后台真实连接热点的id，也就是说，如果在状态保存模块的wifi连接信息中这两个id不同，则表明当前系统进行的是伪连接。

步骤407，保存当前系统WiFi状态，并将执行结果或者伪结果发送给当前系统的代理客户端，然后将伪消息发送给当前系统的虚拟WPA客户端。

在这里，如果是真实连接，热点连接成功后，在代理服务端会收到一条连接成功的状态消息，这条消息中包括热点名称，热点的网卡硬件地址，以及热点的wpa_id，解析这条消息，在状态保存模块的WiFi连接信息中记录这些信息，其中当前连接热点的id与真实连接热点的id相同。这些信息主要用于在后续的操作中进行仲裁判断(例如是伪连接、伪断开、真实连接、真实断开等)或者发送伪消息，最后将当前Android系统的连接状态置为CONNECTED。

3、删除WiFi

用户清除某个热点时，在代理服务端需要处理的步骤包括：

步骤501，接收来自当前系统的删除WiFi的操作请求。

步骤502，根据所有系统的WiFi状态，判断待删除的WiFi热点是否是当前连接的热点，若是，进入步骤503；若不是，则直接执行删除指令，然后进入步骤505。

在这里，用户在前台Android系统点击清除按钮，将清除wpa_supplicant中这个热点的所有配置信息，Android系统主要通过执行“REMOVE_NETWORK”指令来完成这个操作，当代理服务端接收到从代理客户端发送的这个指令时，首先根据之前保存的WiFi状态和WiFi当前连接信息，判断准备删除的这个热点是否是当前连接正在使用的热点，如果是，进入步骤503，如果不是，则直接执行删除指令“REMOVE_NETWORK”，然后进入步骤505。

步骤503，判断待删除的热点是进行的伪连接还是真实连接，如果是伪连接，则构造删除成功的伪结果和断开连接的伪消息，然后进入步骤505；若不是伪连接进入步骤504。

在这里，依据保存的WiFi连接信息中当前热点的id和记录的真实连接热点id是否相同，判断当前正在使用的热点是进行的伪连接还是真实连接，如果不同，则为伪连接，则表示底层的wpa_supplicant实际上连接的是这个热点的另一条记录，是由后台的某个Android系统建立的连接，此时可以直接执行删除指令。该删除操作不会影响后台的连接，由于当前Android系统是伪连接，执行删除指令并不会产生断开连接的事件消息，所以还需要向当前Android系统的虚拟WPA客户端发送断开连接的伪消息，并将当前Android系统的状态置为“DISCONNECTED”，最后进入步骤505，而如果当前Android系统是真实连接，则进入步骤504；

步骤504，判断是否还有后台系统处于连接状态，若没有，则直接执行删除命令，然后进入步骤505；若有，则构造删除成功的伪结果和断开连接的伪消息，然后进入步骤505。

在这里，当前Android系统是真实连接，则需要查找后台是否还有其它Android系统处于CONNECTED状态，即查找后台是否有Android系统对这个热点建立了伪连接，如果没有，则直接执行删除指令“REMOVE_NETWORK”，然后进入步骤505，而如果后台有Android系统处于连接状态，则需要进一步考虑。因为“REMOVE_NETWORK”指令会断开wpa的真实连接，所以执行这个指令会影响后台的伪连接，导致后台Android系统WiFi不可用，因此，在这种情况下，不能真实执行这条指令，直接构造执行成功的伪结果即可。由于未真实执行删除指令，相应地也不会产生断开连接的事件消息，因此还需要构造断开连接的伪消息。并将伪结果发送给当前Android系统的代理客户端，然后将伪消息发送给当前Android的虚拟WPA客户端。最后将当前Android系统的状态置为DISCONNECTED，然后进入步骤505；

步骤505，更新WPA配置表和WiFi配置过滤表。

在这里不管指令“REMOVE_NETWORK”是真实执行还是伪执行，待删除的这个热点对上层的Android系统来说已经成功删除了，因此需要更新WPA配置表和过滤表。WPA配置表的删除直接在该热点对应记录的wpa_id中清除这个热点的id，然后max_num减1，如果这是该热点的最后一条记录，则删除这个热点的整条记录；过滤表的更新比较复杂，主要包括当前Android系统的过滤表更新、后台Android系统的过滤表更新和未启动Android系统的过滤表保存文件更新：

(1)当前Android系统对应的过滤表的删除直接删除这个热点对应的记录即可，然后更新这个过滤表对应的保存文件；

(2)如果当前Android系统删除的这个热点的连接顺序在后台Android系统之前，那么删除了这个热点后，后台Android系统相同热点的连接顺序需要前移一个，所以需要逐个查找所有后台Android系统的过滤表，如果有这个相同热点的信息，且其连接顺序在当前Android系统之后，则需要更新这个后台Android系统的过滤表，并重新保存对应的过滤表保存文件；

(3)针对未启动的Android系统，不需要考虑其过滤表，直接查找其过滤表保存文件，和上面一样，如果有相同热点的信息，且其保存的连接顺序是在当前Android系统之后，则更新该文件的内容，这样这个容器的Android系统在下次启动时，才能正确地初始化过滤表。

删除操作还进一步需要考虑，如果删除指令是进行的伪执行，虽然WiFi配置表模块等已经进行了相应的更新，但是实际上在底层的wpa_supplicant中仍然存在，所以当所有后台Android系统的伪连接全部断开时，需要执行真实的删除操作，重新执行“REMOVE_NETWORK”指令将之前未删除的热点从wpa中删除。

4、关闭WiFi

关闭WiFi的操作和删除热点类似，主要需要考虑操作是否会影响后台Android系统。当用户点击关闭WiFi的按钮时，首先置状态为DISCONNECTING，若不对当前Android系统的WiFi状态进行判断，Android系统会向wpa_supplicant发送一条“DISCONNECT”指令，wpa_supplicant收到这条指令后会断开WiFi的连接；如果此时后台也有Android系统处于CONNECTED状态，即前台Android系统和后台Android系统连接了同一个热点，该指令会断开真实的热点连接，导致后台容器wifi不可用。为了避免上述问题，本实施例采取的具体实施方式包括以下步骤：

步骤601，接收来自当前系统客户端的关闭WiFi的操作请求。

步骤602，判断当前系统是否处于连接状态，若不是，则进入步骤604；若是则进入步骤603。

在这里，若当前Android系统没有处于连接状态，可以直接进入步骤604。

在这里，主要是判断当前Android系统是否处于连接状态；若是，还需要判断是否只有当前Android系统处于连接、当前Android系统是伪连接还是真实连接等；若不是，则需要结合后台Android系统的WiFi状态进行判断。

步骤603，判断是否只有当前系统处于连接状态，若是，则直接执行断开命令，置当前系统为断开状态；若不是，则直接构造执行成功的伪结果和断开连接的伪消息，并置当前系统为断开状态，然后进入步骤604。

在这里，只有当前Android系统处于连接状态时，直接执行DISCONNECT指令，然后代理服务端会接收到一条断开连接的事件消息，此时需要关闭为真实wlan0网卡打开的dhcp客户端，然后关闭为域内的容器打开的dhcp服务器。接着判断当前Android系统是真实连接还是伪连接，如果当前Android系统的连接是真实连接，则直接进入步骤604；而如果是伪连接，则表示此时断开的真实连接属于另外一个Android系统，和上面删除WiFi的最后一步相对应，如果此时断开的连接已经被所属容器执行过删除操作(伪删除)，这时就需要将这个真实连接的热点从WPA配置表中删除，最后置当前Android系统的状态为DISCONNECTED，整个状态转换过程如图3中的转换关系4。

若后台也有Android系统处于连接状态，即当前Android系统和后台Android系统连接了同一热点，这时就不能真实执行这条指令，只需要直接构造执行成功的伪结果，然后给对应的虚拟WPA客户端发送断开连接的伪事件消息，并置当前容器的状态为DISCONNECTED。

步骤604：在关闭WiFi时，还会依次执行“DISABLE_NETWORK”指令来将当前系统的所有可用热点置为不可用状态，此时需要判断后台系统的伪连接是否建立在当前系统的对应热点上；若是则直接构造执行成功的伪结果；若不是，则直接执行“DISABLE_NETWORK”指令。

在这里，若后台Android系统的伪连接建立在当前Android系统对应热点上；执行DISABLE_NETWORK x(x为真实连接的热点id)指令同样也会断开真实连接，从而影响后台Android系统的WiFi使用，因此此时对这条指令需要进行伪执行，以保证后台Androdid系统WiFi的可用性，否则直接执行指令即可。

5、系统切换

当用户将当前Android系统切换到后台，然后从后台Android系统中唤醒一个Android系统到前台时，为了方便用户的使用，所做处理包括以下步骤：

步骤701，接收来自当前系统代理客户端的系统切换的操作请求。

步骤702，将当前系统置于后台。

在这里，在切换操作前一刻，即当前Android系统即将切换到后台，如果当前Android系统的WiFi功能是打开的，并且不是处于CONNECTED状态或者BACK_DISABLE状态，则将当前Android系统的所有可用热点置为disabled状态，然后将当前Android系统的状态置为BACK_DISABLE，接着进入步骤703；

步骤703，唤醒一台后台系统，同时将后台系统的WiFi状态置为断开状态。

在这里，在切换操作后一刻，即已经从后台唤醒了一个Android系统作为前台系统，如果这个前台系统的WiFi功能是开启的，且其状态为BACK_DISABLE，则通过执行“ENABLE_NETWORK”指令将所有可用热点置为enabled状态，从而保证前台系统的WiFi使用，并将状态置为DISCONNECTED，如图3中的转换关系6，然后进入步骤704；

步骤704，判断是否有后台系统处于连接状态；若有，则进入步骤705；若没有，则直接执行恢复连接命令，使切换后的当前系统自动重新连接上任一可用热点，并置切换后的当前系统WiFi状态为CONNECTED。

在这里，判断此时是否有后台Android系统处于CONNECTED状态，如果有后台Android系统处于连接状态，则需要进一步判断。如果没有后台Android系统处于连接状态，则执行一条“RECONNECT”指令使切换后的前台Android系统自动重新连接上某个可用热点，通常情况下wpa会默认连接上之前在后台被断开的那个热点，最后置前台Android系统的WiFi状态为CONNECTED。

步骤705，后台系统处于连接状态，如果前台系统也有相同热点的配置信息，则构造连接成功的伪消息，发送给前台系统的虚拟WPA客户端，让前台系统进行自动伪连接，并置其WiFi状态为连接状态；如果没有，则不做处理，保证后台系统可以继续使用。

在这里，查询后台Android系统的WiFi状态，如果有后台Android系统处于CONNECTED状态，则根据后台Android系统的WiFi连接信息在前台系统对应的WiFi配置过滤表中查找是否有相同热点的配置信息，若有，则表示前台Android系统和后台Android系统具有相同的热点，则让前台Android系统对这个热点自动进行伪连接，即向其对应的虚拟WPA客户端发送连接成功的伪消息，并置其状态为CONNECTED，如果没有相同热点的信息，则不做处理，保证后台Android系统可以继续使用WiFi。

三、WiFi设备终止阶段

在整个WiFi设备的使用周期中，主要是针对多个Anroid系统中的一个来讲，还有最后一个阶段，即WiFi设备终止阶段，这个阶段与WiFi初始化阶段相对应，以Android系统4.3为例，容器内的Android系统关机过程中，或者打开飞行模式时，会进入WiFi设备的终止阶段；对于Android系统5.0，则每次关闭WiFi时都会进入WiFi设备终止阶段。在Android系统技术进化过程中也可能存在其它情形，但不管怎样，在WiFi设备终止阶段，待终止操作完成后，将当前Android系统的状态置为TERMINATE，如图3中的转换关系7。在此阶段，涉及的操作请求依次为终止WiFi设备、关闭守护进程、关闭WPA客户端、关闭当前系统对应的WPA虚拟客户端，退出消息接收线程、卸载网卡硬件驱动、清除WPA配置表和当前系统的WiFi配置过滤表中所有内容，针对与所有系统相关的操作请求，均需要结合所有系统当前状态对操作请求进行仲裁，决定是否执行操作。结合图8，此阶段的WiFi设备复用方案具体包括以下步骤：

步骤801，接收来自当前系统的终止WiFi设备的操作请求。

在这里，用户终止WiFi设备(比如打开飞行模式)时，Android系统首先会发送一条“TERMINATE”指令给wpa_supplicant，用来通知wpa_supplicant即将终止WiFi设备的使用；如果此时WiFi正处于连接状态，wpa会断开WiFi的连接。采用代理机制后，代理客户端会首先将这条命令发送给代理服务端，由代理服务端进行判断。

步骤802，依据代理服务端中所有后台系统状态，判断是否有后台系统没有处于终止状态，若所有后台系统均处于终止状态，进入步骤803；若有后台系统没有处于终止状态，进入步骤804；

在这里，比如当一个容器打开飞行模式时，如果还有其它Android系统没有打开飞行模式，此时就不能真实执行“TERMINATE”指令，此时进入步骤804。只有当所有Android系统打开了飞行模式，才进入步骤803。

步骤803，执行终止WiFi设备的操作，并将执行结果发送给当前系统代理客户端。

执行终止WiFi设备的操作，断开连接，关闭WiFi守护进程，关闭WPA客户端，关闭虚拟WPA客户端，退出消息接收线程，卸载网卡硬件驱动，清除WPA配置表和当前系统的WiFi配置过滤表中所有内容；最后将执行结果发送给当前系统代理客户端。

步骤804，设置执行成功的结果，并将伪结果发送给当前系统代理客户端。

针对终止指令、WiFi守护进程、WPA客户端、网卡硬件驱动，构造执行成功、关闭WiFi守护进程成功、关闭WPA客户端成功、关闭网卡硬件驱动成功的伪结果发送给当前系统的代理客户端；针对当前系统对应的虚拟WPA客户端，则直接执行关闭操作；最后清除当前系统对应的WiFi配置过滤表中的所有内容。

步骤804进一步包括以下分步骤：

步骤8041，针对终止指令，构造执行成功的伪结果；进一步判断当前系统与后台系统是否均处于连接状态；决定是否执行断开命令。

在这里，只需要向上层发送一条执行成功的伪事件消息，同时，如果只有当前Android系统处于连接状态，由于没有真实执行“TERMINATE”指令，WiFi连接不会自动断开，因此需要先执行一条DISCONNECT指令断开WiFi的连接，收到断开连接成功事件消息时将状态置为DISCONNECTED，而如果不只前台Android系统处于连接状态，还有后台Android系统也正处于连接状态，此时只需要向当前Android系统的虚拟WPA客户端发送断开连接的伪消息即可，并将状态置为DISCONNECTED；

步骤8042，针对WiFi守护进程，构造关闭成功的伪结果，并发送给当前系统代理客户端。

在这里，当指令“TERMINATE”执行成功后，下一步就是关闭wpa_supplicant守护进程，如果还有其它Android系统在使用WiFi设备，此时就不能真实关闭这个守护进程，只需要给代理客户端返回关闭成功的伪结果即可，只有最后一个容器终止WiFi设备时才真实地关闭该进程，并置当前系统的状态保存模块的守护进程启动标志为STOP。

步骤8043，针对WPA客户端，构造关闭成功的伪结果，并发送给当前系统代理客户端。

在这里，关闭wpa_supplicant守护进程后，还需要关闭WPA客户端，即关闭之前打开的域套接字，同样，如果还有其它Android系统正在使用WiFi，此时就不真实执行关闭操作，只需要向对应的代理客户端发送关闭成功的伪结果，只有最后一个容器执行关闭操作时才真实关闭该域套接字。

步骤8044，关闭当前系统对应的WPA虚拟客户端。

在这里，每个系统都有各自的虚拟WPA客户端，当前系统选择终止WiFi设备，那么就需要关闭该虚拟客户端，不在接收由代理服务端发送的消息。

步骤8045，针对消息接收线程，此时可以不做处理。

在这里，当最后一个系统执行了关闭WPA客户端的操作后，消息接收线程将收到一条WPA客户端“connection-closed”的消息，此时说明所有系统都已经终止了WiFi设备，那么消息接收线程也就不需要继续接收消息，此时消息接收线程自动退出。

步骤8046，针对网卡硬件驱动，构造卸载成功的伪操作结果，并发送给当前系统代理客户端。

在这里，终止WiFi设备的最后一步是卸载硬件驱动，关闭网卡设备，这个操作同样只需要执行一次，根据状态保存模块中的所有Android的驱动加载标志来判断是否所有系统都执行了卸载操作，当所有的Android系统都执行了卸载操作时，才真实地卸载硬件驱动，之前的Android系统进行的都是伪执行，从而保证WiFi设备可供其它Android系统继续使用，最后置当前系统的驱动加载标志为UNLOADED。

步骤8045，清除当前系统对应的WiFi配置过滤表。

根据WiFi配置表模块可知，在终止WiFi设备时，还需要清除WiFi配置表，当一个Android系统打开飞行模式后，需要清除对应的WiFi配置过滤表，这个表将在该Android系统下次初始化WiFi设备时重新初始化。而WPA配置表只在最后真实终止WiFi设备时才清除表中的所有内容；其它情况下，WPA配置表可以不做处理。

本发明实施例提供的基于多Android系统的WiFi设备复用方法，能够在基于容器的多Android平台上实现WiFi设备复用，使多个平台都可以独立地使用WiFi，并且多个Android平台可同时连接一个相同的热点，做到多容器同时上网。

本实施例进一步提供了一种基于多系统的WiFi设备复用装置，

应用于基于Linux容器技术构建的多个系统，每个容器内的系统通过创建的虚拟网卡与容器外部实现数据包在容器内外之间的传输；同时通过虚拟网卡与真实网卡之间的源地址转换，实现数据包在系统与外部设备之间的传输；该WiFi设备复用装置包括：

接收模块，接收来自当前系统代理客户端的操作请求；

仲裁模块，依据状态存储模块中所有系统当前状态，对来自当前系统代理客户端的操作请求进行仲裁，决定是否执行操作；

执行模块，对需要执行的操作，执行操作；

构造模块，对不需要执行的操作，构造伪结果和/或伪消息；

发送模块，将执行结果或伪结果发送给当前系统代理客户端，将伪消息发送给当前系统的虚拟WPA客户端。

上述基于多系统的WiFi设备复用装置，进一步包括状态保护模块和WiFi配置表模块。

以上对本发明实施例所提供的基于多Android系统的WiFi设备复用方法进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (9)

1.一种基于多系统的WiFi设备复用方法，其特征在于，应用于基于Linux容器技术构建的多个系统，每个容器内的系统通过创建的虚拟网卡与容器外部实现数据包在容器内外之间的传输；同时通过虚拟网卡与真实网卡之间的源地址转换，实现数据包在系统与外部设备之间的传输；所述WiFi设备复用方法包括以下步骤：

接收来自当前系统代理客户端的操作请求；

依据状态存储模块中所有系统当前状态，对来自当前系统代理客户端的操作请求进行仲裁，决定是否执行操作；

对需要执行的操作，执行操作；

对不需要执行的操作，构造伪结果和/或伪消息；

将执行结果或伪结果发送给当前系统代理客户端，将伪消息发送给当前系统的虚拟WPA客户端；实现多个系统的WiFi设备复用。

2.根据权利要求1所述的基于多系统的WiFi设备复用方法，其特征在于，状态保存模块用于保存所有系统对应的多种状态，包括驱动加载标志、守护进程启动标志、WiFi连接状态以及WiFi当前连接信息。

3.根据权利要求2所述的基于多系统的WiFi设备复用方法，其特征在于，对WiFi设备初始化阶段，所述操作请求依次为加载网卡硬件驱动、启动WiFi守护进程、打开虚拟WPA客户端、打开WPA客户端和启动消息接收线程；具体实现方式包括以下步骤：

步骤201，接收来自当前系统代理客户端的WiFi设备初始化的操作请求；

步骤202，加载网卡硬件驱动；判断网卡硬件驱动是否被后台系统加载；如果没有被加载，则直接加载网卡硬件驱动；如果已经被加载过，则构造加载成功的伪结果；然后将真实操作结果或者伪结果反馈给当前系统代理客户端；

步骤203，启动WiFi守护进程；判断WiFi守护进程是否被后台系统启动；如果没有被启动，则直接启动WiFi守护进程；如果已经被启动，则构造启动成功的伪结果；然后将真实操作结果或者伪结果反馈给当前系统代理客户端；

步骤204，在代理客户端和代理服务端之间打开一个虚拟WPA客户端，代替原WPA客户端接收由代理服务端发送的消息；

步骤205，打开WPA客户端；判断WPA客户端是否被后台系统打开；如果没有被打开，则直接打开WPA客户端；如果已经被打开，则构造打开成功的伪结果；然后将真实操作结果或者伪结果反馈给当前系统代理客户端；WPA客户端设置在根域，并以WiFi守护进程作为服务端，构造状态事件消息通道；

步骤206，启动消息接收线程；判断是否在代理服务端已经启动了一个消息接收线程，如果没有，则启动该线程；如果已经启动，则构造启动成功的伪结果；然后将真实操作结果或者伪结果反馈给当前系统代理客户端；

WiFi设备初始化后，当前系统WiFi状态为断开状态。

4.根据权利要求3所述的基于多系统的WiFi设备复用方法，其特征在于，所述操作请求进一步包括初始化WiFi配置表模块，具体实现方式进一步包括：

步骤207，初始化WiFi配置表模块；WiFi配置表模块包括WPA配置表和WiFi配置过滤表；WPA配置表为从WiFi守护进程获取的包含所有WiFi热点配置信息的配置表；WiFi配置过滤表为包含对应系统的所有WiFi热点配置信息的配置表；

WPA配置表初始化，判断WPA配置表是否被后台系统初始化；如果没有被初始化，则获取WiFi守护进程中所有WiFi热点配置信息，然后解析获取的信息获得WPA配置表，完成对WPA配置表的初始化，然后初始化WiFi配置过滤表；如果已经被初始化，则直接初始化WiFi配置过滤表；

WiFi配置过滤表初始化，打开当前系统在代理服务端对应的WiFi过滤表保存文件，读取内容，然后根据读取的内容在WPA配置表中获取ID信息，完成WiFi配置过滤表初始化。

5.根据权利要求2至4任一所述的基于多系统的WiFi设备复用方法，其特征在于，对WiFi设备使用阶段，所述操作请求根据应用场景设定；此阶段，

在执行完操作后，与WiFi状态相关的，需要更改并保存当前系统的WiFi状态；

在构造伪结果后，与WiFi状态相关的，需要构造伪消息，同时更改并保存当前系统的WiFi状态。

6.根据权利要求5所述的基于多系统的WiFi设备复用方法，其特征在于，应用场景包括开启WiFi、连接WiFi、删除WiFi、关闭WiFi、系统切换。

7.根据权利要求6所述的基于多系统的WiFi设备复用方法，其特征在于，

当应用场景为开启WiFi时，依据WiFi守护进程返回的热点列表，经当前系统对应WiFi配置表过滤，获取当前系统所有可用热点的列表，然后发送给当前系统代理客户端；

当应用场景为连接WiFi时，首先判断待连接的WiFi热点是否是新建立的连接，如果是，则更新WiFi配置表模块；然后判断当前待连接的热点和后台系统连接的是否是同一热点，如果是，则当前系统进行伪连接；构造伪结果和伪消息；如果不是，则执行连接操作，并断开后台系统的连接；最后保存相应的WiFi状态；

当应用场景为删除WiFi热点时，判断待删除的WiFi热点是否是真实连接；如果当前系统删除的是当前连接的热点，而且后台系统连接着同一个热点，并且后台是进行的伪连接，则此时不真实执行删除操作，构造伪结果和伪消息，直到后台系统都断开连接时，才执行真实的删除操作；否则直接执行删除操作；最后保存相应的状态，并更新WiFi配置表模块；

当应用场景为关闭WiFi时，判断待关闭的WiFi热点是否是真实连接；如果当前系统处于连接状态，则首先需要判断后台系统是否连接着同一个热点，如果是，则前台系统构造伪结果和伪消息，进行伪断开，以保持后台系统的WiFi继续使用；如果不是，则直接执行关闭操作即可；最后保存相应的状态；

当应用场景为系统切换时，判断待切换的当前系统是否与后台系统连接了同一个WiFi热点；如果不是，由于前台系统连接了一个不同的热点而导致连接断开的后台系统再次切换到前台，如果切换后没有后台系统处于连接状态，那么前台系统自动连接上之前被断开的热点；如果切换后有后台系统处于连接状态，则自动伪连接上相同的热点；最后保存相应的状态。

8.根据权利要求3所述的基于多系统的WiFi设备复用方法，其特征在于，对WiFi设备终止阶段，所述操作请求依次为终止WiFi设备、关闭守护进程、关闭WPA客户端、关闭当前系统对应的WPA虚拟客户端，退出消息接收线程、卸载网卡硬件驱动、清除WPA配置表和当前系统的WiFi配置过滤表中所有内容，针对与所有系统相关的操作请求，均需要结合所有系统当前状态对操作请求进行仲裁，决定是否执行操作。

9.一种基于多系统的WiFi设备复用装置，其特征在于，应用于基于Linux容器技术构建的多个系统，每个容器内的系统通过创建的虚拟网卡与容器外部实现数据包在容器内外之间的传输；同时通过虚拟网卡与真实网卡之间的源地址转换，实现数据包在系统与外部设备之间的传输；该WiFi设备复用装置包括：

接收模块，接收来自当前系统代理客户端的操作请求；

仲裁模块，依据状态存储模块中所有系统当前状态，对来自当前系统代理客户端的操作请求进行仲裁，决定是否执行操作；

执行模块，对需要执行的操作，执行操作；

构造模块，对不需要执行的操作，构造伪结果和/或伪消息；

发送模块，将执行结果或伪结果发送给当前系统代理客户端，将伪消息发送给当前系统的虚拟WPA客户端。