Android cloud phone virtual WiFi implementation method

Abstract

The embodiment of the present disclosure provides a kind of Android cloud mobile phone virtual WiFi implementation method of simulation, belong to communication technical field, specifically include: the identification of target container is acquired and its network namespace is determined;Virtual wireless entity is created and registered, including the wiphy / radio of binding and the visible wlan0 interface;Create and start hotspot side AP simulation entity, configure SSID and authentication parameter, and generate 802.11 management frame;In target Android container, start wpa_supplicant, complete association authentication by nl80211 interface and host computer interaction;After authentication succeeds, network address is allocated by AP simulation entity;Configuration network address conversion and forwarding rule, traffic is mapped to the physical external interface of host computer, and the network connectivity of container is realized.The simulation degree, interface consistency, compatibility and migratability are improved by the scheme of the present disclosure.

Description

Technical Field

[0001] This disclosure relates to the field of communication technology, and in particular to a method for implementing simulated virtual WiFi on an Android cloud phone. Background Technology

[0002] Currently, the existing solutions for providing WiFi capabilities in cloud phones / cloud terminals are typically as follows: 1) Java / Framework layer field forgery scheme: This approach attempts to "appear as WiFi" by hooking the return values ​​of interfaces such as WifiManager, WifiInfo, ScanResult, and Connectivity. However, this method often fails to cover the actual wpa_supplicant interaction, nl80211 event, and scan / authentication state machine, leading to inconsistencies between the scan list, connection state, broadcast callbacks, and the system settings page. Furthermore, these inconsistencies are easily detected by business-side consistency checks.

[0003] 2) Solution that only performs data plane bridging (connecting containers to the network): While veth / bridge / NAT ensures "internet access," Android systems typically use Ethernet or VPN as the bearer, lacking true WiFi semantics (such as switching / scanning / saving networks / capability sets / connection events and timings), thus failing to meet the requirements for real device simulation and compatibility.

[0004] 3) User-space soft MAC / soft AP assembly solution: While constructing scan results or simulating some 802.11 behaviors in user space, it lacks a unified abstraction and complete event chain of kernel mac802.11, making it difficult to achieve multi-instance isolation and cross-version stability.

[0005] The above solutions generally suffer from problems such as insufficient realism, non-closed-loop system links, inconsistent cross-layer interfaces, unrealistic timing and abnormal branches, and weak multi-instance isolation capabilities.

[0006] It is evident that there is an urgent need for a method to implement realistic virtual WiFi on Android cloud phones with high fidelity, interface consistency, compatibility, and portability. Summary of the Invention

[0007] In view of this, the present disclosure provides a method for implementing simulated virtual WiFi on an Android cloud phone, which at least partially solves some of the problems existing in the prior art.

[0008] This disclosure provides a method for implementing simulated virtual WiFi on an Android cloud phone, applied to a Linux host machine with multiple Android cloud phone container instances deployed, including: Step 1: Obtain the identifier of the target Android container instance and determine the network namespace corresponding to the target Android container instance; Step 2: In the Linux host kernel, create and register virtual wireless entities for the network namespace, and establish a mapping relationship between container instances, network namespaces, and virtual wireless entities. The virtual wireless entities include wiphy / radio bound to the network namespace and the wlan0 network interface visible within the network namespace. Step 3: Create and start the hotspot-side AP emulation entity on the Linux host machine. The AP emulation entity is configured with SSID and authentication parameters and continuously generates 802.11 management frames. Step 4: Inside the target Android container instance, start the wpa_supplicant that comes with the Android system. It interacts with the host kernel through the standard nl80211 interface to initiate and complete the association authentication process based on the scanned SSID. Step 5: After successful association authentication, the AP emulation entity side allocates a network address to the target Android container instance; Step 6: Configure network address translation and forwarding rules in the Linux host machine to map the network traffic on the AP emulation entity side to the physical external network interface of the host machine, so that the target Android container instance can obtain network connectivity through the wlan0 interface.

[0009] According to one specific implementation of this disclosure, the virtual wireless entity further includes an independent MAC address and capability configuration template that matches the wlan0 interface.

[0010] According to a specific implementation of this disclosure, the step of creating and registering a virtual wireless entity for the network namespace in the Linux host kernel includes: In the mac80211 subsystem simulation module of the host kernel, a virtual wireless entity is simulated and generated; The virtual wireless entity is registered to the network namespace through the cfg80211 / nl80211 subsystem, so that the wlan0 interface is only visible and operable within this network namespace.

[0011] According to a specific implementation of this disclosure, the hotspot-side AP emulation entity is implemented by creating and configuring a wireless network interface running in HOST AP mode on the host machine, and by using the hostapd tool to manage frame generation and connection status management.

[0012] According to a specific implementation of an embodiment of this disclosure, step 5 specifically includes: Run a DHCP server on the AP emulation entity side, and have the DHCP client initiate requests within the target Android container instance to obtain the IP address, gateway, and DNS server address.

[0013] According to a specific implementation of this disclosure, the method further includes an isolation control step: For each Android container instance, the device status, connection status, and network routing table of the wlan0 interface are maintained independently in its corresponding network namespace, so that the Wi-Fi status and data traffic between container instances are isolated from each other.

[0014] According to a specific implementation of an embodiment of this disclosure, the method further includes a state maintenance step: When the target Android container instance experiences a connection loss or reconnection, the corresponding connection status event is reported through the host kernel emulation module based on the expected event sequence of wpa_supplicant and the Android network stack.

[0015] The simulated virtual WiFi implementation scheme for Android cloud phones in this embodiment includes: Step 1, obtaining the identifier of the target Android container instance and determining the network namespace corresponding to the target Android container instance; Step 2, creating and registering a virtual wireless entity for the network namespace in the Linux host kernel, and establishing a mapping relationship between the container instance, the network namespace, and the virtual wireless entity, wherein the virtual wireless entity includes wiphy / radio bound to the network namespace and the wlan0 network interface visible within the network namespace; Step 3, creating and starting a hotspot-side AP emulation entity on the Linux host side, wherein the AP emulation entity is configured with S Step 4: Inside the target Android container instance, start the Android system's built-in wpa_supplicant, which interacts with the host kernel through the standard nl80211 interface to initiate and complete the association authentication process based on the scanned SSID; Step 5: After successful association authentication, the AP emulation entity allocates a network address to the target Android container instance; Step 6: Configure network address translation and forwarding rules in the Linux host machine to map the network traffic of the AP emulation entity to the host machine's physical external network interface, so that the target Android container instance can obtain network connectivity through the wlan0 interface.

[0016] The beneficial effects of the embodiments disclosed herein are as follows: 1) Significantly improved realism: WiFi scanning and connection are completed through the native wpa_supplicant and the kernel 802.11 link. The results observed by the upper layer have the real protocol stack source, which significantly reduces the "field splicing error" and "event chain missing".

[0017] 2) Stronger interface consistency: Because the underlying link actually exists, the WifiManager display, system settings page, callback broadcast, connection state and network capabilities (WiFi vs Ethernet) are more likely to be consistent.

[0018] 3) Better compatibility and portability: Reuses AOSP native wpa_supplicant and Linux standard nl80211 / cfg80211 interface, reducing intrusive changes to the Android Framework and facilitating migration across Android versions and different ROMs.

[0019] 4) Multi-instance isolation and scalable deployment friendly: wlan0 is created with netns as the isolation boundary, which naturally supports the concurrent operation of multiple instances and reduces the complexity of cloud phone cluster operation and maintenance.

[0020] 5) Verifiable and measurable: It can verify each link of scanning, connection, DHCP, and outbound network through packet capture / log / kernel event link, which is convenient for forming experimental data support. Attached Figure Description

[0021] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a flowchart illustrating a method for implementing simulated virtual WiFi on an Android cloud phone, as provided in an embodiment of this disclosure. Detailed Implementation

[0023] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0024] The following specific examples illustrate the implementation of this disclosure. Those skilled in the art can easily understand other advantages and effects of this disclosure from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. This disclosure can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this disclosure. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0025] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0026] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this disclosure. The illustrations only show the components related to this disclosure and are not drawn according to the number, shape and size of the components in actual implementation. In actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0027] Furthermore, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that the described aspects can be practiced without these specific details.

[0028] This disclosure provides a method for implementing a simulated virtual WiFi on an Android cloud phone, which can be applied to the WiFi connection process in a cloud phone scenario.

[0029] See Figure 1 This is a flowchart illustrating a method for implementing simulated virtual WiFi on an Android cloud phone according to an embodiment of this disclosure. Figure 1 As shown, the method mainly includes the following steps: Step 1: Obtain the identifier of the target Android container instance and determine the network namespace corresponding to the target Android container instance; Step 2: In the Linux host kernel, create and register virtual wireless entities for the network namespace, and establish a mapping relationship between container instances, network namespaces, and virtual wireless entities. The virtual wireless entities include wiphy / radio bound to the network namespace and the wlan0 network interface visible within the network namespace. Step 3: Create and start the hotspot-side AP emulation entity on the Linux host machine. The AP emulation entity is configured with SSID and authentication parameters and continuously generates 802.11 management frames. Step 4: Inside the target Android container instance, start the wpa_supplicant that comes with the Android system. It interacts with the host kernel through the standard nl80211 interface to initiate and complete the association authentication process based on the scanned SSID. Step 5: After successful association authentication, the AP emulation entity side allocates a network address to the target Android container instance; Step 6: Configure network address translation and forwarding rules in the Linux host machine to map the network traffic on the AP emulation entity side to the physical external network interface of the host machine, so that the target Android container instance can obtain network connectivity through the wlan0 interface.

[0030] This invention adopts an architecture of "high-fidelity kernel-side emulation + Android native control link reuse": 1) Android container side: Use AOSP's built-in wpa_supplicant as the WiFi control entity, and communicate with the Linux kernel through the nl80211 interface (without relying on third-party Hooks or custom HAL protocol stacks).

[0031] 2) Host kernel side: Simulate the behavior of 802.11 wireless network card under mac80211 subsystem in Linux kernel layer, expose wlan0 network card node to each container network namespace, and provide capabilities such as scanning, authentication, association, management frame sending and receiving, and status event reporting.

[0032] 3) Host machine network bearer side: The host machine creates a simulated WiFi hotspot (soft AP), configures the SSID and password, and acts as a DHCP server; the container acts as a DHCP client to obtain the address. The host machine uses iptables to perform NAT / forwarding on the hotspot side traffic with eth0 as the exit point, ensuring that the container can access the network, thus forming "WiFi semantics like a real machine + a real and usable data plane".

[0033] The key to this design is that Android does not see a "fake result," but rather the result obtained through real interaction between wpa_supplicant and the kernel 802.11 stack, thus ensuring authenticity from the source.

[0034] In practical implementation, the method disclosed herein can be executed by a specific high-fidelity virtual WiFi system. This high-fidelity virtual WiFi system is deployed on a Linux host machine, running multiple Android cloud phone container instances. The system includes: 1) Virtual Wireless Entity Generation and Binding Module: This module is used to create and register virtual wireless entities for the network namespace of each Android container. The virtual wireless entities include wiphy / radio and their corresponding wlan0 network interfaces. It also establishes a one-to-one correspondence between container instances and the virtual wireless entities, ensuring that each container instance has an independent WiFi device view and configuration storage space.

[0035] 2) mac80211 protocol stack emulation module: used to simulate the behavior of the 802.11 MAC layer under the mac80211 subsystem in the host kernel, and provide standard control interfaces through cfg80211 / nl80211, so that the wpa_supplicant in the container's AOSP can drive scanning, connection and event subscription in the same way as a real mobile phone.

[0036] 3) Hotspot-side AP emulation module: Used to create hotspot interfaces (AP roles) on the host side, configure SSID, authentication method and key, and generate management frames and connection process events that can be scanned, so that wlan0 on the container side can scan and connect to the hotspot.

[0037] 4) Address Allocation Module (DHCP): The hotspot acts as a DHCP server, allocating IP addresses, gateways, and DNS to successfully associated container instances; inside the container, it acts as a DHCP client to obtain addresses.

[0038] 5) Data plane mapping and outbound network module: Used to establish a forwarding / NAT mapping relationship between the hotspot side network and the host machine's external network exit (e.g., eth0), ensuring that the container has usable network connectivity after a successful WiFi connection.

[0039] 6) Isolation control module: Used to isolate the wlan0 device, connection state, IP address and routing table of each container instance based on the network namespace boundary, and suppress cross-instance crosstalk.

[0040] The method disclosed herein includes the following steps: 1) S1 (Instance Identifier and NetNS Determination): Obtain the PID identifier of the target Android container instance, and obtain pid_task based on PID, thereby determining the network namespace corresponding to the container.

[0041] 2) S2 (Create a virtual WiFi wireless entity for netns): Create and register a virtual wireless entity for the network namespace in the host kernel. The virtual wireless entity includes at least: ① The wiphy / radio namespace bound to this namespace; ② The wlan0 interface node visible within this namespace; ③ The capability template and independent MAC address configuration that match this interface; ④ Ensure that the IEEE 80211_ops data format is consistent with the actual device.

[0042] ⑤ Distribute configurations, update status, and scan results via netlink / virtio.

[0043] And create a mapping entry for "container instance—netns—wiphy / radio—wlan0".

[0044] 3) S3 (Start Hotspot Side AP Emulation Entity): Create a hotspot interface (AP role) on the host side, configure SSID, authentication method and key parameters, and continuously generate management frames such as Beacon / Probe Response, so that the SSID can be found by scanning inside the container.

[0045] 4) S4 (Reuse AOSP native wpa_supplicant control plane): Starts the AOSP-provided wpa_supplicant within the container, which interacts with the host kernel via the standard nl80211 to perform scanning, select networks, initiate authentication and association, and receive events such as connection / disconnection / scan completion.

[0046] 5) S5 (DHCP triggered after successful association): After the container instance completes the association with the hotspot and meets the security parameter verification, the DHCP client in the container initiates an address request to the DHCP server on the hotspot and obtains network parameters.

[0047] 6) S6 (Data Plane Outbound Mapping): Configure forwarding and NAT rules on the host machine to bind the data traffic of the hotspot side network to the external network egress interface, so as to achieve network reachability within the container.

[0048] 7) S7 (Isolation and State Maintenance): Independently maintains the WiFi device state, connection state, and network parameters for each container instance; when a disconnection or reconnection occurs, it ensures that the event reporting and connection process conforms to the expected order and semantics of the wpa_supplicant / Android network stack.

[0049] This embodiment provides a method for implementing realistic virtual WiFi on an Android cloud phone. It uses a Linux host kernel to perform software simulation of the IEEE 802.11 protocol stack, providing the Android system with a method and system for highly realistic WiFi scanning, connection, and data link carrying capabilities. Its core relies on cross-technology involving Linux kernel mac80211 / cfg80211 / nl80211 subsystem simulation, network namespace isolation, container network carrying mapping, and compatibility adaptation with the Android native WiFi framework.

[0050] The method disclosed herein will be further described below with reference to a specific embodiment. This invention has been prototyped and verified in a Linux host machine + Docker containerized Android instance environment. Verification covered key indicators such as "scanning visibility, connection availability, IP acquisition, stable network access, and multi-instance isolation," and the results show that the solution is feasible and has engineering deployability.

[0051] Experimental environment: Linux host (kernel version: 5.10), Docker version: 20.10; Android container version (AOSP / custom ROM): Android13; Hotspot configuration (2.4G / 5G, WPA2 / WPA3): 2.4G / WPA2.

[0052] Functionality verification: On the host machine, the wlan1 node is used as an AP hotspot (HOST AP mode). 1) Enable NAT forwarding # ifconfig wlan1 192.168.200.1 netmask 255.255.255.0 up # echo 1> / proc / sys / net / ipv4 / ip_forward # iptables -t nat -I POSTROUTING -o eth0 -j MASQUERADE # iptables -A FORWARD -s 192.168.200.1 / 24 -j ACCEPT # iptables -A FORWARD -d 192.168.200.1 / 24 -j ACCEPT 2) Enable DHCP service Place dnsmasq.conf in the / etc / directory. The contents of the dnsmasq.conf file are as follows: user=root listen-address=0.0.0.0 interface=wlan1 dhcp-range=192.168.200.100,192.168.200.200 server= / google / 8.8.8.8 # dnsmasq -C / etc / dnsmasq.conf 3) Enable hotspot Place hostapd.conf in the / etc / directory. The contents of the hostapd.conf file are as follows: interface=wlan1 driver=nl80211 ssid=AndroidAP channel=6 ieee80211n=1 hw_mode=g ignore_broadcast_ssid=0 wowlan_triggers=any wpa=2 rsn_pairwise=CCMP wpa_passphrase=88888888 # hostapd -B / etc / hostapd.conf In an Android container, scanning: After WiFi is enabled inside the container, it can reliably scan for the host machine's hotspot SSID. The scan refresh cycle is [not specified], and the scan results have complete fields (SSID / BSSID / RSSI / frequency band / encryption capabilities, etc.).

[0053] Connection: Entering the correct password will complete the connection within seconds and trigger the system connection success callback; entering the wrong password will trigger authentication failure and retry / prompt according to the policy.

[0054] DHCP: After connection, the container can obtain IP, gateway and DNS within milliseconds, and the lease renewal behavior is normal.

[0055] Outbound: The container can stably access the external network (DNS / HTTP / HTTPS) through the host machine's NAT, and can run continuously without abnormal disconnections (or automatically reconnect if a connection is lost).

[0056] Multiple instances: When multiple container instances are running concurrently, each instance can independently scan / connect / obtain an IP address and go out of the network without affecting each other.

[0057] # docker exec -it android-01 sh The virtual Wi-Fi has successfully obtained an IP address via DHCP and can ping external networks.

[0058] Experimental results show that the present invention can provide WiFi usage path and system performance consistent with real mobile phones in cloud phone scenarios, meeting the requirements of high realism, availability and scalability.

[0059] It should be understood that the various parts of this disclosure can be implemented in hardware, software, firmware, or a combination thereof.

[0060] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A method for implementing simulated virtual WiFi in Android cloud phones, applied to a Linux host machine with multiple Android cloud phone container instances deployed, characterized in that... include: Step 1: Obtain the identifier of the target Android container instance and determine the network namespace corresponding to the target Android container instance; Step 2: In the Linux host kernel, create and register virtual wireless entities for the network namespace, and establish a mapping relationship between container instances, network namespaces, and virtual wireless entities. The virtual wireless entities include wiphy / radio bound to the network namespace and the wlan0 network interface visible within the network namespace. Step 3: Create and start the hotspot-side AP emulation entity on the Linux host machine. The AP emulation entity is configured with SSID and authentication parameters and continuously generates 802.11 management frames. Step 4: Inside the target Android container instance, start the wpa_supplicant that comes with the Android system. It interacts with the host kernel through the standard nl80211 interface to initiate and complete the association authentication process based on the scanned SSID. Step 5: After successful association authentication, the AP emulation entity side allocates a network address to the target Android container instance; Step 6: Configure network address translation and forwarding rules in the Linux host machine to map the network traffic on the AP emulation entity side to the physical external network interface of the host machine, so that the target Android container instance can obtain network connectivity through the wlan0 interface.

2. The method according to claim 1, characterized in that, The virtual wireless entity also includes an independent MAC address and capability configuration template that matches the wlan0 interface.

3. The method according to claim 1, characterized in that, The step of creating and registering virtual wireless entities for the network namespace in the Linux host kernel includes: In the mac80211 subsystem simulation module of the host kernel, a virtual wireless entity is simulated and generated; The virtual wireless entity is registered to the network namespace through the cfg80211 / nl80211 subsystem, so that the wlan0 interface is only visible and operable within this network namespace.

4. The method according to claim 1, characterized in that, The hotspot-side AP emulation entity is implemented by creating and configuring a wireless network interface running in HOST AP mode on the host machine, and by using the hostapd tool to manage frame generation and connection status management.

5. The method according to claim 1, characterized in that, Step 5 specifically includes: Run a DHCP server on the AP emulation entity side, and have the DHCP client initiate requests within the target Android container instance to obtain the IP address, gateway, and DNS server address.

6. The method according to claim 1, characterized in that, The method also includes an isolation control step: For each Android container instance, the device status, connection status, and network routing table of the wlan0 interface are maintained independently in its corresponding network namespace, so that the Wi-Fi status and data traffic between container instances are isolated from each other.

7. The method according to claim 1, characterized in that, The method further includes a state maintenance step: When the target Android container instance experiences a connection loss or reconnection, the corresponding connection status event is reported through the host kernel emulation module based on the expected event sequence of wpa_supplicant and the Android network stack.

Images