CN105183551B - Switching method among multiple Android systems based on Linux container technology - Google Patents

Abstract

the invention relates to a switching method among multiple Android systems based on a Linux container technology. The method comprises the following steps: creating at least two containers in a Linux kernel, and starting a system in the containers; changing the use state of the system in the container when a switching command of the container is called; based on the use state of the system, the Frame Buffer driver outputs the image to the corresponding address. According to the method, multiplexing of the display equipment is realized, simultaneous operation of a plurality of Android is supported, rapid switching among the plurality of Android is achieved, and user experience is improved.

Description

Switching method among multiple Android systems based on Linux container technology

Technical Field

the invention relates to computer virtualization, in particular to a switching method among multiple Android systems based on a Linux container technology.

background

At present, due to the openness and functionality of the Android system, the Android system is widely applied to embedded device products such as smart phones and tablet computers. On the other hand, due to the openness of the Android, the Android system is more vulnerable to malicious programs, so that the privacy of users can be stolen, the operation of the system can be damaged, and the like. Meanwhile, in order to meet different application requirements, a plurality of users can carry with the smart phones, on one hand, the privacy of the users can be protected, and on the other hand, public and private applications are separated. But this brings great inconvenience to the user and causes a great waste of resources.

virtualization technology can enable a plurality of systems to run on one device at the same time, thereby effectively solving the problems. However, the conventional virtualization technology is not suitable for the embedded device due to the excessive overhead. Container technology is more suitable for virtualization of embedded devices. A handover is required from one system to another. However, in the current switching method, a series of operations are mainly performed through software to realize the switching between systems, and the switching method is excessively complicated in process and low in switching speed, so that the user experience is influenced.

Disclosure of Invention

In order to better solve the problems, the invention aims to establish a plurality of containers in the Linux kernel, and each container independently runs an Android system, so that the plurality of Android systems share one Linux kernel and system equipment; then, aiming at the Adnrdoi system in a plurality of containers, a method for realizing quick and convenient switching between systems without installing any software is provided.

The invention provides a switching method among multiple Android systems based on a Linux container technology, which comprises the following steps:

creating at least two containers in a Linux kernel, and starting an Android system in the containers;

Changing the use state of the system in the container when a switching command of the container is called;

Based on the use state of the system, the Frame Buffer driver outputs the image to the corresponding address.

preferably, the usage states of the systems in the container include an active state and a dormant state.

preferably: the changing of the use state of the system in the container further comprises:

When the use state of the system is converted from activity to dormancy, outputting the system image, and remapping the system image to the memory buffer area; the image output memory buffer is remapped to the screen memory when the usage state of the system transitions from dormant to active.

Preferably, the switching command for invoking the container further includes:

in response to a user pressing a mobile device key, a container switch command is invoked.

Preferably: before the creating at least two containers, the method further comprises:

Different namespaces are defined for the containers, respectively.

Preferably: the Frame Buffer driver outputs the image to the address corresponding to the current container, and the method further comprises the following steps:

Implementing a virtual buffer for each container, deciding to invoke one of two mapping functions that output image output information to a screen and the virtual buffer, respectively, by determining whether different containers are active.

Preferably: after the switching command of the container is called, the method further comprises the following steps:

each virtual address of the system to be switched to the inactive state, which has been mapped to a process in the screen memory Framebuffer, is redirected to a new physical location.

Compared with the prior art, the switching method between the multiple Android systems based on the Linux container technology supports simultaneous operation of the multiple Android systems by multiplexing the display equipment, achieves fast switching between the multiple Android systems by using a convenient method for fast switching between the systems, and improves user experience.

drawings

Fig. 1 is a diagram of a multi-Android system framework employing container technology according to an embodiment of the present invention.

Fig. 2 is a diagram of a multiple system multiplexing Framebuffer driving process according to an embodiment of the present invention.

Fig. 3 is a process diagram of inter-system handoff according to an embodiment of the present invention.

Detailed Description

A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details.

The technical scheme adopted by the invention for solving the problems is that the multiplexing of the display equipment is realized to support that a plurality of Android devices can run simultaneously, and a convenient method for fast switching between the systems is designed to realize the fast switching between the plurality of Android devices, and the method specifically comprises the following steps:

1) Multiplexing of display devices

1-1) the Android system relies on the standard Linux Framebuffer (FB) to provide a physical screen display, but can only support one Android system display at a time. In order to realize multiplexing of FB, firstly, introducing a new name space mechanism to an Android kernel;

1-2) modifying related source codes of the FB in the Android kernel, and realizing the virtualization of the FB by combining with a newly introduced namespace.

1-3) the modified FB drive can output different system image output information to different places for storage.

2) switching between containers:

2-1) a relatively effective container management command can be realized only by properly packaging Namespace and Cgroups mechanism related commands in a Linux kernel;

2-2) creating a container by the management command and starting a system in the container. When a container is created, the newly-built container is added into a container list so as to facilitate switching;

2-3) after the system in the container is started, the system in use is called active system, and the other systems are called dormant system. When the system accesses the FB to output images, the FB driver outputs the images of different systems to different places for storage according to different states of the system;

2-4) calling a container switching command by using a shortcut key, converting an active system into a dormant system and converting a dormant system into an active system. Outputting the system image which is active before, and remapping the system image to a memory buffer area; the image output memory buffer to be the active system is remapped to the screen memory.

The following provides a detailed description of the main implementation principle of the technical method of the present invention and the corresponding advantageous effects thereof with reference to fig. 1, fig. 2, and fig. 3 in turn.

fig. 1 illustrates a multi-Android system framework 100 employing container technology. In order to realize the quick switching among a plurality of Android, some modifications need to be made to the Linux kernel 101, a New _ Namespace mechanism 104 is added to the Linux kernel 101, and the mechanism is combined with the FB driver to complete the virtualization of the FB 105; and creates a set of container API interfaces 103 to facilitate the container management module 102 to manage and switch containers.

fig. 2 is a diagram 200 of a multi-system multiplexed FB drive process. By modifying the existing FB drive, a New _ Namespace mechanism is introduced into the FB drive, packaged as a New multi _ FB drive 201, and registered as the FB drive. The currently in-use system is referred to as the active Android system 202, the currently unused system is referred to as the inactive Android system 203, and the modified FB driver implements a buffer 204 associated with only a single container in the system RAM for each container to store the image output information of the inactive Android system. The active Android system directly maps the image output information to the screen Framebuffer205 by operating the multi _ fb driver 201 to be directly presented on the physical screen 206; while the inactive Android system maps the image output information into the buffer 204 corresponding to the system by operating the multi _ fb driver 201.

The operating system used in this embodiment is open-source Android 4.3, the kernel version is 3.4, and the running platform is a Google Nexus 4 mobile phone.

The implementation steps of the New _ Namespace mechanism and the container management tool are as follows:

step 101: in order to realize the virtualization of the FB, a New name space mechanism New _ Namessapce mechanism needs to be introduced into a Linux kernel; meanwhile, in order to facilitate the switching of the system in the container, related commands of the Namespace and Cgrops mechanisms in the Linux kernel are packaged;

The steps are specifically realized as follows:

firstly, a process is described by a data structure task _ struct in a Linux kernel, an nsproxy structure pointer is arranged in the structure, and the nsproxy structure defines structure pointers of various different namespaces. The init nsproxy structure will be used to initialize the namespace pointer in nsproxy when task is initialized. The definition of a structure pointer of New _ Namespace is added into an nsproxy structure, and an initialization statement of the structure pointer of New _ Namespace is added into an init _ nsproxy structure to be used for initializing the structure pointer.

Adding source codes of the corresponding function and definition of New _ Namespace, wherein the structure of the source codes is mainly as follows: the example of stmct new _ ns _ desc is a system global variable, and is mainly used for storing some information related to operation new _ namespace, which is registered in the system by all devices; the instances of structnew _ namespace are local variables used for representing different device namespaces; the truck new _ ns _ info stores the registration information of the primary storage device driver.

And the Linux kernel is provided with commands for managing Namespace and Cgroups, such as mount, chroma, clone, execute and the like. However, the containers cannot be effectively managed only by the commands, and a certain encapsulation is needed to form effective management commands. The container start command calls _ do _ start (), a container _ nsexec () function in the _ do _ start encapsulates a mount for mounting the file system to a corresponding directory, and a do _ clone () function in the function encapsulates a clone command for executing a clone of the process; the do _ child () in do _ clone () encapsulates the chroma command to switch under the root directory of the corresponding container in order to execute the init program under the container. The current container is added to the container list at the time of container creation.

Step 102: the management module of the container is essentially a container with the highest authority, by mounting a very compact file system aufs therein, and the container has no graphical interface and does not require any graphical information output. A daemon process is operated in the management system to monitor the management command of the container, and when the management command related to the container is received, the daemon process analyzes and then calls an interface function provided by the API of the container to manage the container.

the Framebuffer virtualization procedure is as follows:

Step 201: the New _ Namespace mechanism is introduced by adding New source codes to the FB drive and implements one virtual buffer for each container associated with only a single container. The FB driver is modified by using a New _ Namespace mechanism. Since each buffer device has a struct fb _ info structure corresponding to it. The fb _ info and New _ Namespace structures are encapsulated into the fb _ ns structure and additionally implement a fb _ ns _ mmap function. The multi _ fb driver can decide whether to call the native fb _ mmap mapping function or the fb _ ns _ mmap mapping function by determining whether different bins are active. The two mapping functions respectively output image output information to a screen and a virtual buffer area, so that the aim of multiplexing is fulfilled.

Step 202: the new FB driver may pass the active state Android system access directly to the hardware to the multi _ FB driver. This includes standard ioctls as well as custom ioctls. When the active system runs an application mmap multi _ fb device, the multi _ fb driver simply maps the physical memory of the screen controlled by the hardware driver.

step 203: when mmap the Framebuffer device is applied, running on an inactive system, the multi _ fb driver maps the backing buffer in RAM to the virtual address space of the process. And a brand-new notification API is adopted to replace the transmission of ioctls to the hardware driver, so that the multi _ fb driver cannot transmit the access of the system in the inactivated state to the hardware back end, and the access of the system in the activated state to exclusive hardware is ensured.

Fig. 3 is an intersystem handover procedure, which includes the following steps:

step 301: when the user presses the shortcut key combination, the currently activated system will sequentially: screen memory remapping → screen memory depth replication → hardware state synchronization → GPU coordination, four operations. The detailed process is as follows:

Rc file by adding the following code:

The method and the device realize that the up-down key of the volume of the mobile phone is pressed simultaneously to call the switching command of the container, and the system after the system is currently activated in the container list is converted into an activated state. 115 and 114 represent up and down keys of the volume of the mobile phone respectively;

② screen memory remapping

Screen memory remapping is done by changing the page table entries, which redirects each virtual address mapped to a process in screen memory FB to be switched to the inactive state system to a new physical location. The virtual addresses are remapd to a backup buffer area of the system RAM corresponding to the container;

screen memory deep replication

the deep copy of the screen memory to be switched to the inactive state system is to copy the contents of the system in the screen memory to a back buffer;

Hardware state synchronization

The hardware synchronization that is to be switched to the inactive state system is to save the current hardware state into the virtual hardware state of the system.

synchronization of GPU

The GPU is notified of the transformation of the screen memory address so that it can update the mapping of any internal image memory.

Step 302: when the user presses the shortcut key combination, the system to be switched to the active state will also perform the four operations in step 301 in sequence, and the detailed process is as follows:

(ii) Screen memory remapping

Each virtual address mapped to the screen process in the back-up buffer area to be switched to the active state system is from the new mmap to the FB of the screen memory;

Screen memory deep replication

The deep copy of the screen memory to be switched to the active state system is to copy the contents of the system stored in the look-aside buffer into the screen memory;

state synchronization of hardware

the hardware synchronization to be switched to the active state system is to set the hardware state to the state that the system saved in the virtual hardware state.

synchronizing GPU

The GPU is notified of the transformation of the screen memory address so that it can update the mapping of any internal image memory.

at this point, the switching of the different systems in the container is complete.

In summary, the invention provides a switching method between multiple Android systems based on a Linux container technology, which supports simultaneous operation of multiple Android systems by multiplexing display equipment, achieves fast switching between multiple Android systems, and improves user experience.

The above description is only for the purpose of helping to understand the method of the present invention and its core idea; meanwhile, for a person skilled in the art, according to the idea of the present invention, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present invention. Therefore, any modification, equivalent replacement, improvement and the like made without departing from the spirit and scope of the present invention should be included in the protection scope of the present invention. Further, it is intended that the appended claims cover all such variations and modifications as fall within the scope and boundaries of the appended claims or the equivalents of such scope and boundaries.

Claims (7)

1. a switching method among multiple Android systems is characterized by comprising the following steps:

introducing a New _ Namespace mechanism into a Linux kernel, introducing the New _ Namespace mechanism by adding a New source code into an FB driver, and realizing a virtual buffer which is only associated with a single container for each container;

At least two containers are created in a Linux kernel, an Android system independently runs in each container, and the plurality of Android systems share one Linux kernel and hardware equipment;

Changing the use state of the system in the container when a switching command of the container is called;

based on the using state of the system, outputting the image to a corresponding address by the FrameBuffer drive;

In order to facilitate the switching of the system in the container, related commands of a Namespace mechanism and a Cgroups mechanism in a Linux kernel are packaged; the steps are specifically realized as follows:

the method comprises the following steps that firstly, nsproxy structure pointers in a Linux kernel define structure pointers of various different namespaces, the definition of a New _ Namespace structure pointer is added into an nsproxy structure, and an initialization statement of the New _ Namespace structure pointer is added into an init _ nsproxy structure to initialize the structure pointers;

Secondly, adding a source code with a corresponding function and definition of New _ Namespace, wherein the structure is as follows: the instance of struct New _ ns _ desc is a system global variable used for storing information related to operation New _ namespace registered in the system by all devices; the instances of struct new _ namespace are local variables used for representing different device namespaces; struct new _ ns _ info stores the registration information of the device driver;

The Linux kernel encapsulates the command for managing the Namespace and the Cgroups to form an effective management command; the container start command calls _ do _ start (), a container _ nsexec () function in the _ do _ start encapsulates a mount for mounting the file system to a corresponding directory, and a do _ clone () function in the function encapsulates a clone command for executing a clone of the process; the do _ child () in the do _ clone () encapsulates the chroma command to switch to under the root directory of the corresponding container, so as to execute the init program under the container; the current container is added to the container list at the time of container creation.

2. The method for switching between multiple Android systems of claim 1, wherein:

The usage states of the systems in the container include an active state and a dormant state.

3. The method for switching between multiple Android systems of claim 1, wherein: the changing of the use state of the system in the container further comprises:

When the use state of the system is converted from activity to dormancy, outputting the system image, and remapping the system image to the memory buffer area; the image output memory buffer is remapped to the screen memory when the usage state of the system transitions from dormant to active.

4. The method for switching between multiple Android systems of claim 3, wherein the manner of switching the call container further comprises:

the key switching mode is that a switching command of the container is called in response to the user pressing a key of the mobile equipment;

And a software switching mode, namely clicking a switching program by a user to call a switching command of the container.

5. The method for switching between multiple Android systems of claim 1, wherein: before the creating at least two containers, the method further comprises:

different operation spaces are respectively defined for the containers, so that programs and data in the two containers are completely isolated.

6. The method for switching between multiple Android systems of claim 1, wherein: the FrameBuffer driver outputs the image to the address corresponding to the current container, and further comprises:

implementing a virtual buffer for each container, deciding to invoke one of two mapping functions that output image output information to a screen and the virtual buffer, respectively, by determining whether different containers are active.

7. The method for switching between multiple Android systems of claim 6, wherein: after the switching command of the container is called, the method further comprises the following steps:

each virtual address of the system to be switched to the inactive state, which has been mapped to a process in the screen memory Framebuffer, is redirected to a new physical location.