WO2024138588A1

WO2024138588A1 - Dual-system secure mobile phone resetting method and apparatus, terminal, and storage medium

Info

Publication number: WO2024138588A1
Application number: PCT/CN2022/143688
Authority: WO
Inventors: 李海强; 李�杰; 刘振亚; 魏占旭
Original assignee: 天翼电信终端有限公司
Priority date: 2022-12-26
Filing date: 2022-12-30
Publication date: 2024-07-04
Also published as: CN116028267A

Abstract

Disclosed in embodiments of the present invention are a dual-system secure mobile phone resetting method and apparatus, a sever, and a storage medium. The method comprises: restarting a container corresponding to a resetting operation, and generating a restart modification sub-process by using an init process; determining an init process of a reset container and an init.rc file of the reset container; modifying a file mounting part in a main function of the init.rc file of the reset container by using the restart modification sub-process, to point to a data file corresponding to the corresponding resetting; loading a mirror image of the container when exiting last time; and adjusting the init process of the reset container by using the restart modification sub-process, so that the init process directly jumps to guide an init.rc script to record the running of the file mounting part. Therefore, the resetting operation omits an erasing process of the data file, without remounting hardware drive, thereby greatly saving system resetting time corresponding to the container, and improving the user experience using a dual-system mobile phone for resetting.

Description

Dual-system secure mobile phone reset method, device, terminal and storage medium

Technical Field

The embodiments of the present invention relate to the field of mobile terminal technology, and in particular to a dual-system secure mobile phone reset method, device, terminal and storage medium.

Background technique

With the continuous advancement of mobile terminal technology, smartphones are widely used in various scenarios. They have become an inseparable tool in daily work and life. In order to separate work and life, and for security reasons, some users adopt a dual-phone strategy, using one phone for life and the other for office use. Based on the above needs of users, dual-system security phones came into being. With the help of container technology, dual-system security phones can use two systems in parallel. And the background system can be woken up at any time to achieve simultaneous switching of the two systems;

In the process of implementing the present invention, the inventors found the following technical problems: during the use of the mobile phone, it is inevitable to restore the mobile phone to factory settings. However, for the above-mentioned dual-system mobile phone, since it actually has three systems: a slimmed-down Linux system for configuring and calling the underlying interface, and responsible for starting the Android system corresponding to each container, it is easy to generate errors and exceptions when the user performs a reset operation; in the existing method, the host is required to notify the container of the factory reset information, select the Boot Loader in the container, and then erase the corresponding file content in the file system to complete the restart. To achieve factory reset, the time consumption is close to that of OTA upgrade, which affects the user experience.

Summary of the invention

The embodiments of the present invention provide a dual-system secure mobile phone reset method, device, terminal and storage medium to solve the technical problem that the dual-system secure mobile phone restoration setting operation takes a long time in the prior art.

In a first aspect, an embodiment of the present invention provides a dual-system secure mobile phone reset method, comprising:

Restart the container corresponding to the reset operation, and use the init process to generate a restart modification subprocess;

Determine the init process for resetting the container and the init.rc file for resetting the container;

The file mounting part in the main function of the init.rc file of the reset container is modified by using the restart modification subprocess to point to the corresponding reset corresponding data file to load the image of the container when it was last exited;

The init process of the reset container is adjusted by restarting the modification subprocess, so that the init process directly jumps to the file mounting part recorded in the boot init.rc script to run.

In a second aspect, an embodiment of the present invention further provides a dual-system secure mobile phone reset device, comprising:

Generate a module, which is used to restart the container corresponding to the reset operation, and use the init process to generate a restart modification subprocess;

A determination module is used to determine the init process of resetting the container and the init.rc file of resetting the container;

A modification module, used to modify the file mounting part in the main function of the init.rc file of the reset container by restarting the modification subprocess to point to the corresponding reset corresponding data file;

A loading module, used to load the image of the container when it was last exited;

The adjustment module is used to adjust the init process of the reset container by restarting the modification subprocess, so that the init process directly jumps to the file mounting part recorded in the boot init.rc script to run.

In a third aspect, an embodiment of the present invention further provides a terminal, including:

one or more processors;

A storage device for storing one or more programs;

When the one or more programs are executed by the one or more processors, the one or more processors implement the dual-system secure mobile phone reset method provided in the above embodiment.

In a fourth aspect, an embodiment of the present invention further provides a storage medium comprising computer executable instructions, which, when executed by a computer processor, are used to execute the dual-system secure mobile phone reset method provided in the above embodiment.

The dual-system secure mobile phone reset method, device, terminal and storage medium provided by the embodiment of the present invention restarts the container corresponding to the reset operation, generates a restart modification subprocess by using the init process; determines the init process of the reset container and the init.rc file of the reset container; uses the restart modification subprocess to modify the file mounting part in the main function of the init.rc file of the reset container to point to the corresponding reset corresponding data file; loads the image of the container when it was last exited; uses the restart modification subprocess to adjust the init process of the reset container, so that the init process directly jumps to the file mounting part recorded in the boot init.rc script to run. The host machine's interference ability with the container is fully utilized, and the restart modification subprocess is generated by using the kernel process of the host machine. Modify the init.rc script of the container that needs to reset the system, adjust the corresponding mount file data, and adjust the init process corresponding to the container to directly jump to the file mounting part recorded in the boot init.rc script to run. There is no need to reconfigure the corresponding hardware mounting part, so that the reset operation saves the data file erasing process and does not need to remount the hardware driver, which greatly saves the system reset time corresponding to the container and improves the user experience of users resetting using dual-system phones.

BRIEF DESCRIPTION OF THE DRAWINGS

Other features, objects and advantages of the present invention will become more apparent from the detailed description of non-limiting embodiments made with reference to the following drawings:

FIG1 is a flow chart of a dual-system secure mobile phone reset method provided in Embodiment 1 of the present invention;

FIG2 is a schematic diagram of a dual-system secure mobile phone architecture in a dual-system secure mobile phone reset method provided in Embodiment 1 of the present invention;

3 is a flow chart of a dual-system secure mobile phone reset method provided in Embodiment 2 of the present invention;

4 is a flow chart of a dual-system secure mobile phone reset method provided in Embodiment 3 of the present invention;

5 is a structural diagram of a dual-system secure mobile phone reset device provided in Embodiment 4 of the present invention;

FIG6 is a structural diagram of a terminal provided in Embodiment 5 of the present invention.

Detailed ways

The present invention will be further described in detail below in conjunction with the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are only used to explain the present invention, rather than to limit the present invention. It should also be noted that, for ease of description, only parts related to the present invention, rather than all structures, are shown in the accompanying drawings.

Embodiment 1

FIG1 is a flow chart of a dual-system secure mobile phone reset method provided in Embodiment 1 of the present invention. This embodiment is applicable to the case where one of the systems in a dual-system secure mobile phone is quickly reset. The method can be executed by a dual-system secure mobile phone reset device and is correspondingly set in a terminal of the dual-system secure mobile phone. Specifically, the method includes the following steps:

Step 110: restart the container corresponding to the reset operation, and use the init process to generate a restart modification subprocess.

Exemplarily, a dual-system mobile phone can be implemented using container technology. FIG2 is a schematic diagram of the dual-system secure mobile phone architecture in the dual-system secure mobile phone reset method provided in the first embodiment of the present invention. Referring to FIG2 , the dual-system secure mobile phone includes: a slimmed-down Linux system (basic platform), and the slimmed-down Linux system is used for underlying hardware and corresponding drivers to provide a corresponding hardware foundation for the dual system. The dual system is implemented through container technology. Exemplarily, LXC (Linux Container) technology can be used. LXC can provide lightweight virtualization to isolate processes and resources, and does not require an instruction interpretation mechanism and other complexities of full virtualization. LXC can use the hardware driver of the basic platform to achieve hardware control of the basic platform.

In this embodiment, the user can reset the system corresponding to the LXC through operation, that is, restore the factory settings.

When a reset operation is received, the container corresponding to the factory reset operation is restarted. Exemplarily, at startup, the init process of the slimmed-down Linux system is used to generate a restart modification subprocess. The init process is one of the indispensable programs in the Linux system operation and is a user-level process started by the kernel.

Since it is necessary to control the restart of the container, it is necessary to implant the corresponding process in the slimmed-down Linux system to achieve the purpose of controlling the restart of the container. Since the slimmed-down Linux system only provides hardware drivers to provide the hardware foundation for LXC, the number of its own processes is relatively small, and the only process that can survive the normal cycle of the slimmed-down Linux system is the init process. Therefore, the init process can be used to generate a restart modification subprocess, and the restart modification subprocess can be used to adjust and control the system in the LXC container.

Step 120: Determine the init process of resetting the container and the init.rc file of resetting the container.

In this embodiment, since there are three systems, and the reset only corresponds to one of the systems, it is first necessary to determine the init process corresponding to the restart system and the init.rc file of the reset container. Since the restart system is implemented using an LXC container, it is necessary to determine the init process of the reset container and the init.rc file of the reset container. Exemplarily, the init process of the reset container and the init.rc file of the reset container can be determined by the corresponding label or generation time.

Step 130: Use the restart modification subprocess to modify the file mounting part in the main function of the init.rc file of the reset container to point to the corresponding reset corresponding data file.

init.rc is based on AIL (Android Init Language), a very simple language, which is mainly used to define what needs to be done in the initialization process. In init.rc, there is a main function, which mainly contains five types of statements: Action, Command, Service, Option, and Import. Options is an optional option for Service and is used in conjunction with service. The corresponding data files can be defined in it. Exemplarily, the chown<owner><group><path>option statement can be used to load the data files corresponding to the reset. Among them, chown is used to change the owner and/or group of each file. In this embodiment, it can be defined as the group of the container, and the path of the reset corresponding data file is written into the corresponding <path>, and the corresponding service is started with the on tag.

Step 140: Load the image of the container when it was last exited.

After the container is started, the corresponding image needs to be loaded, and the image can be the image when the container was last exited.

Step 150: Use the restart modification subprocess to adjust the init process of the reset container so that the init process directly jumps to the file mounting part recorded in the boot init.rc script to run.

Under normal circumstances, since the previous image has been loaded, the init process usually only needs to remain alive without any adjustment. In this embodiment, since the file data has been changed, the init.rc script has been modified accordingly. Therefore, it is necessary to adjust the init process to register the file data in the main function in the init.rc script. Since the image loading method is adopted, the hardware driver part has been loaded, and the init process does not need to reload the hardware driver, but only needs to reregister the corresponding data file. Therefore, the init process of the reset container can be controlled by restarting the modified subprocess, skipping the loading of the hardware driver part, and directly jumping to the boot init.rc record file mounting part to run the script.

This embodiment generates a restart modification subprocess by restarting the container corresponding to the reset operation, using the init process; determining the init process of the reset container and the init.rc file of the reset container; using the restart modification subprocess to modify the file mounting part in the main function of the init.rc file of the reset container to point to the corresponding reset corresponding data file; loading the image of the container when it was last exited; using the restart modification subprocess to adjust the init process of the reset container, so that the init process directly jumps to the file mounting part recorded in the boot init.rc script to run. The host machine's interference ability with the container is fully utilized, and the restart modification subprocess is generated by utilizing the kernel process of the host machine. The init.rc script of the container that needs to be reset is modified, the corresponding mount file data is adjusted, and the init process corresponding to the container is adjusted to jump directly to the file mounting part recorded in the boot init.rc script to run, without reconfiguring the corresponding hardware mounting part, so that the reset operation saves the data file erasing process, and there is no need to remount the hardware driver, which greatly saves the system reset time corresponding to the container and improves the user experience of users using dual-system mobile phones to reset.

In a preferred implementation of this embodiment, the method may further add the following steps: using the restart modification subprocess to add a factory reset broadcast service in the container system, broadcasting the factory reset information, and enabling the Android system to clear the memory content. Since the mobile phone service is provided by using the container loading image method, and there are still some active processes in the loaded image, including system processes and application processes, and these processes may occupy the original user data. At this time, the restart modification subprocess may also be used to derive a subprocess from the init process in the container system to provide the corresponding broadcast service, broadcast the corresponding factory reset information to all processes in the container system, and enable the corresponding process to clear the memory content to avoid read and write errors in the system.

Embodiment 2

Figure 3 is a flow chart of a dual-system secure mobile phone reset method provided in Embodiment 2 of the present invention. This embodiment is optimized based on the above embodiment. In this embodiment, the method may further add the following steps: upon receiving a current system reset operation, save the container image corresponding to the current system; read the init process from the kernel, and obtain the container code corresponding to the current system from the init process, and reset the user data in the current system; close the container corresponding to the container code.

Accordingly, the dual-system secure mobile phone reset method provided in this embodiment specifically includes:

Step 210: When receiving a current system reset operation, save the container image corresponding to the current system.

In this embodiment, the user can reset the currently used system by operating the dual-system secure mobile phone. To facilitate user operation, the system reset operation can be consistent with normal mobile phone operation. When receiving the system reset operation, the container currently in the foreground active state is determined, and the container image corresponding to the current system is saved.

Step 220: read the init process from the kernel, obtain the container code corresponding to the current system from the init process, and reset the user data in the current system.

The init process of the slimmed-down Linux system is read from the kernel of the slimmed-down Linux system. The init process of the slimmed-down Linux system is responsible for managing the container. The container code of the current system is obtained from the process, and the container code is used to reset the user data in the current system.

Exemplarily, the file system environment corresponding to the container number can be searched, and the file system environment can be a folder under the root2 (2 is the container number) directory, including: /dev, /sys, /etc, /data, /cache, /metadata and other folders.

Clear the original data file system, including folders such as /data, /cache, and /metadata, to reset the user data in the current system.

Step 230: Close the container corresponding to the container code.

Close the container corresponding to the container code to facilitate a subsequent restart and restore the system to factory settings.

Step 240: restart the container corresponding to the reset operation, and use the init process to generate a restart modification subprocess.

Step 250: Determine the init process of resetting the container and the init.rc file of resetting the container.

Step 260: Use the restart modification subprocess to modify the file mounting part in the main function of the init.rc file of the reset container to point to the corresponding reset corresponding data file.

Step 260: Load the image of the container when it was last exited.

Step 270: Use the restart modification subprocess to adjust the init process of the reset container so that the init process directly jumps to the file mounting part recorded in the boot init.rc script to run.

This embodiment adds the following steps: when receiving the current system reset operation, save the container image corresponding to the current system; read the init process from the kernel, and obtain the container code corresponding to the current system from the init process, reset the user data in the current system; close the container corresponding to the container code. When receiving the reset operation, the container system corresponding to the reset operation can be clearly determined to avoid the interference of the reset on other systems, and the user data files that need to be restored to factory settings can be correctly selected.

In a preferred implementation of this embodiment, after closing the container corresponding to the container code and before restarting the container, the method may further add the following step: using a namespace to distinguish and isolate the user data of the current system. Namespace is a form of code organization used by many programming languages, which is classified by namespace. Using a namespace, the user data of the current system can be effectively distinguished from other user data.

In another preferred implementation of this embodiment, the method may further add the following steps: according to the resources of the container when it last exited, the resources of the restarted container are divided using cgroup so as to be consistent with the resources exited last time. Cgroup can refer to a specific process group. Cgroup is a mechanism for managing processes by group under Linux. From the user level, Cgroup technology can organize all processes in each system into an independent tree. Each tree contains all processes in the system, and each node of the tree is a process group. Through the Cgroup mechanism, all processes when the container last exited can be determined, and the corresponding resources can be determined. The resources required by various processes can be set accordingly, and the resources after the container is started can be kept consistent. Avoid system errors.

Embodiment 3

FIG4 is a flow chart of a dual-system secure mobile phone reset method provided by Embodiment 3 of the present invention. This embodiment is optimized based on the above embodiment. In this embodiment, the data file corresponding to the reset is specifically optimized as: the data file before the reset operation, and the data file before the reset operation includes: the container belonging to the hidden attribute and the recovery hidden mark attribute; accordingly, the current system reset operation package is specifically optimized as: the current system recovery operation; accordingly, the init process of the reset container is adjusted by the restart modification subprocess, and is specifically optimized as: the init process of the reset container is increased to the recovery operation level by the restart modification subprocess, and the recovery operation level corresponds to the init process of the container directly jumping to the boot init.rc script to record the file mounting part to run.

Step 310: restart the container corresponding to the recovery operation, and use the init process to generate a restart modification subprocess.

Step 320: Determine the init process of the recovery container and the init.rc file of the recovery container.

Step 330: Use the restart modification subprocess to modify the file mounting part in the main function of the init.rc file of the recovery container to point to the corresponding data file before the reset operation.

In this embodiment, not only can mobile phone reset be provided, but also recovery service can be provided. That is, if the user restores the factory settings of the current system by mistake due to misoperation or other reasons and hopes to restore to the previous state, it can be implemented in the manner provided by this embodiment. Exemplarily, the data file before the reset operation includes: a container belonging hidden attribute and a recovery hidden mark attribute. In this embodiment, after receiving the user's reset operation, the existing user data file can be transferred to other storage locations and set to a non-writable state. At the same time, according to the correspondence between the user data file and the container, a container belonging hidden attribute can be added to the user data file. The hidden attribute is in an invisible state and can only be read by the init process of the Linux system after slimming down. Accordingly, new user data is created for the current system, and a container belonging hidden attribute is added to the new user data to avoid file pointing errors. In addition, for the data file before the reset operation, it is necessary to additionally increase or decrease the recovery hidden mark attribute to indicate the corresponding container and the time of the reset operation, so as to facilitate the search for the corresponding user data file during recovery.

Step 340: Load the image of the container when it was last exited.

Step 350: Use the restart modification subprocess to add a recovery operation level to the init process of the reset container. The recovery operation level corresponds to the init process of the container directly jumping to the file mounting part recorded in the boot init.rc script to run.

The original init is divided into 7 levels, which are shutdown, single-user mode, multi-user (not connected to the Internet), full multi-user mode (standard operation level), safe mode, graphical interface mode, and restart. In this embodiment, it can be adjusted to increase the recovery level. The user can generate a recovery operation by combining the physical buttons of the dual-system security phone. Add a recovery operation level to the init process of the reset container so that the init process directly jumps to the file mounting part recorded in the boot init.rc script to run, realizing the fast recovery function.

This embodiment optimizes the data file corresponding to the reset to: the data file before the reset operation, the data file before the reset operation includes: the container belonging to the hidden attribute and the recovery hidden mark attribute; accordingly, the current system reset operation package is optimized to: the current system recovery operation; accordingly, the init process of the reset container is adjusted by the restart modification subprocess, and is optimized to: the init process of the reset container is increased to the recovery operation level by the restart modification subprocess, and the recovery operation level corresponds to the init process of the container directly jumping to the file mounting part recorded in the boot init.rc script to run. The rapid recovery operation of a single system in a dual-system security mobile phone can be realized.

Embodiment 4

FIG5 is a schematic diagram of the structure of a dual-system secure mobile phone reset device provided in Embodiment 4 of the present invention. As shown in FIG5 , the device includes:

A generation module 410 is used to restart the container corresponding to the reset operation and generate a restart modification subprocess using an init process;

A determination module 420 is used to determine an init process for resetting a container and an init.rc file for resetting a container;

The modification module 430 is used to modify the file mounting part in the main function of the init.rc file of the reset container by restarting the modification subprocess to point to the corresponding reset corresponding data file;

A loading module 440, used to load the image of the container when it was last exited;

The adjustment module 450 is used to adjust the init process of the reset container by restarting the modification subprocess, so that the init process directly jumps to the file mounting part recorded in the boot init.rc script to run.

The dual-system secure mobile phone reset device provided in this embodiment restarts the container corresponding to the reset operation, generates a restart modification subprocess by using the init process; determines the init process of the reset container and the init.rc file of the reset container; uses the restart modification subprocess to modify the file mounting part in the main function of the init.rc file of the reset container to point to the corresponding reset corresponding data file; loads the image of the container when it was last exited; uses the restart modification subprocess to adjust the init process of the reset container so that the init process directly jumps to the file mounting part recorded in the boot init.rc script to run. The host machine's interference ability with the container is fully utilized, and the restart modification subprocess is generated by using the kernel process of the host machine. The init.rc script of the container that needs to be reset is modified, the corresponding mount file data is adjusted, and the init process corresponding to the container is adjusted so that it directly jumps to the file mounting part recorded in the boot init.rc script to run, without reconfiguring the corresponding hardware mounting part, so that the reset operation saves the data file erasing process, and there is no need to remount the hardware driver, which greatly saves the system reset time corresponding to the container and improves the user experience of users using dual-system mobile phones to reset.

Based on the above embodiments, the device further includes:

A saving module is used to save the container image corresponding to the current system when receiving a current system reset operation;

A reading module, used to read the init process from the kernel, obtain the container code corresponding to the current system from the init process, and reset the user data in the current system;

The closing module is used to close the container corresponding to the container code.

Based on the above embodiments, the upgrade code temporary storage area has the same size as the second flash memory area of the vehicle ECU.

Based on the above embodiments, the device further includes:

The isolation module is used to differentiate and isolate user data of the current system by using a namespace.

Based on the above embodiments, the device further includes:

The partitioning module is used to partition the resources of the restarted container by using cgroup according to the resources of the container when it was last exited, so as to make them consistent with the resources exited last time.

Based on the above embodiments, the device further includes:

An attribute adding module, used for adding a container attribution hidden attribute to the user data file according to the corresponding relationship between the user data file and the container;

Accordingly, the reading module includes:

The new creation unit is used to create new user data for the current system and add a container-attribution hidden attribute to the new user data.

Based on the above embodiments, the resetting of the corresponding data file includes:

The data file before the reset operation includes: a container attribution hidden attribute and a restore hidden mark attribute;

The current system reset operation includes:

Current system recovery operation;

The adjustment module comprises:

The level increasing unit is used to increase the recovery operation level of the init process of the reset container by restarting the modification subprocess, and the recovery operation level corresponds to the init process of the container directly jumping to the file mounting part recorded in the boot init.rc script to run.

The dual-system secure mobile phone reset device provided in the embodiment of the present invention can execute the dual-system secure mobile phone reset method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

Embodiment 5

Figure 6 is a schematic diagram of the structure of a terminal provided in Embodiment 5 of the present invention. Figure 6 shows a block diagram of an exemplary terminal 12 suitable for implementing the embodiments of the present invention. The terminal 12 shown in Figure 6 is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

As shown in Fig. 6, terminal 12 is in the form of a general-purpose computing terminal. Components of terminal 12 may include, but are not limited to: one or more processors or processing units 16, system memory 28, and bus 18 connecting different system components (including system memory 28 and processing unit 16).

Bus 18 represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processor or a local bus using any of a variety of bus architectures. By way of example, these architectures include, but are not limited to, an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MAC) bus, an Enhanced ISA bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus.

Terminal 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by terminal 12, including volatile and non-volatile media, removable and non-removable media.

The system memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and/or cache 32. The terminal 12 may further include other removable/non-removable, volatile/non-volatile computer system storage media. By way of example only, the storage system 34 may be used to read and write non-removable, non-volatile magnetic media (not shown in FIG. 6 , commonly referred to as a “hard drive”). Although not shown in FIG. 6 , a disk drive for reading and writing to a removable non-volatile disk (e.g., a “floppy disk”) and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM or other optical media) may be provided. In these cases, each drive may be connected to the bus 18 via one or more data media interfaces. The system memory 28 may include at least one program product having a set (e.g., at least one) of program modules that are configured to perform the functions of various embodiments of the present invention.

A program/utility 40 having a set (at least one) of program modules 42 may be stored, for example, in system memory 28, such program modules 42 including, but not limited to, an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment. Program modules 42 generally perform the functions and/or methods of the embodiments described herein.

The terminal 12 may also communicate with one or more external terminals 14 (e.g., keyboards, pointing terminals, displays 24, etc.), one or more terminals that enable a user to interact with the terminal 12, and/or any terminal that enables the terminal 12 to communicate with one or more other computing terminals (e.g., network cards, modems, etc.). Such communication may be performed via an input/output (I/O) interface 22. Furthermore, the terminal 12 may also communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and/or public networks, such as the Internet) via a network adapter 20. As shown, the network adapter 20 communicates with other modules of the terminal 12 via a bus 18. It should be understood that, although not shown in the figure, other hardware and/or software modules may be used in conjunction with the terminal 12, including but not limited to: microcode, terminal drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

The processing unit 16 executes various functional applications and data processing by running the programs stored in the system memory 28, such as implementing the dual-system secure mobile phone reset method provided in the embodiment of the present invention.

Embodiment 6

Embodiment 6 of the present invention further provides a storage medium containing computer executable instructions, which, when executed by a computer processor, are used to execute any of the dual-system secure mobile phone reset methods provided in the above embodiments.

The computer storage medium of the embodiment of the present invention can adopt any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, for example, - but not limited to - an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples (non-exhaustive list) of computer-readable storage media include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program, which can be used by an instruction execution system, device or device or used in combination with it.

Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, which carry computer-readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for performing the operations of the present invention may be written in one or more programming languages or a combination thereof, including object-oriented programming languages such as Java, Smalltalk, C++, and conventional procedural programming languages such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or terminal. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

Note that the above are only preferred embodiments of the present invention and the technical principles used. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in more detail through the above embodiments, the present invention is not limited to the above embodiments, and may include more other equivalent embodiments without departing from the concept of the present invention, and the scope of the present invention is determined by the scope of the appended claims.

Claims

A dual-system secure mobile phone reset method, characterized by comprising:

Restart the container corresponding to the reset operation, and use the init process to generate a restart modification subprocess;

Determine the init process for resetting the container and the init.rc file for resetting the container;

The file mounting part in the main function of the init.rc file of the reset container is modified by using the restart modification subprocess to point to the corresponding reset corresponding data file;

Load the image of the container when it was last exited;

The init process of the reset container is adjusted by restarting the modification subprocess, so that the init process directly jumps to the file mounting part recorded in the boot init.rc script to run.
The method according to claim 1, characterized in that the method further comprises:

When receiving the current system reset operation, save the container image corresponding to the current system;

Reading the init process from the kernel, and obtaining the container code corresponding to the current system from the init process, and resetting the user data in the current system;

Close the container corresponding to the container code.
The method according to claim 2, characterized in that after closing the container corresponding to the container code and before restarting the container, the method further comprises:

The namespace is used to distinguish and isolate the user data of the current system.
The method according to claim 3, characterized in that the method further comprises:

According to the resources of the container when it was last exited, the resources of the restarted container are divided by using cgroup to make them consistent with the resources when it was last exited.
The method according to claim 4, characterized in that the method further comprises:

According to the correspondence between the user data file and the container, a container-attribution hidden attribute is added to the user data file;

Accordingly, resetting the user data in the current system includes:

Create new user data for the current system, and add a container-attribution hidden attribute to the newly created user data.
The method according to claim 5, characterized in that resetting the corresponding data file comprises:

The data file before the reset operation includes: a container attribution hidden attribute and a restore hidden mark attribute;

Accordingly, the current system reset operation includes:

Current system recovery operation;

Correspondingly, the use of restarting and modifying the subprocess to adjust the init process of resetting the container includes:

The restart modification subprocess is used to add a recovery operation level to the init process of the reset container. The recovery operation level corresponds to the init process of the container directly jumping to the file mounting part recorded in the boot init.rc script to run.
The method according to any one of claims 1 to 6, characterized in that the method further comprises:

By using the restart modification subprocess to add a factory reset broadcast service in the container system, the factory reset information is broadcasted, so that the system of the reset container can clear the memory content.
A dual-system secure mobile phone reset device, characterized by comprising:

Generate a module, which is used to restart the container corresponding to the reset operation, and use the init process to generate a restart modification subprocess;

A determination module is used to determine the init process of resetting the container and the init.rc file of resetting the container;

A modification module, used to modify the file mounting part in the main function of the init.rc file of the reset container by restarting the modification subprocess to point to the corresponding reset corresponding data file;

A loading module, used to load the image of the container when it was last exited;

The adjustment module is used to adjust the init process of the reset container by restarting the modification subprocess, so that the init process directly jumps to the file mounting part recorded in the boot init.rc script to run.
A server, characterized in that the server comprises:

one or more processors;

A storage device for storing one or more programs;

When the one or more programs are executed by the one or more processors, the one or more processors implement the dual-system secure mobile phone reset method as described in any one of claims 1-7.
A storage medium containing computer executable instructions, wherein the computer executable instructions are used to execute the dual-system secure mobile phone reset method as described in any one of claims 1-7 when executed by a computer processor.