Data persistence storage method and electronic equipment

Abstract

The invention relates to the technical field of virtualization frameworks, in particular to a data persistence storage method and electronic equipment. The data persistence storage method is applied to an Android system, and comprises the following steps: starting a client application in the Android system, and creating a mapping file under an application sandbox directory of the client application; the method comprises the following steps: reading a system image in which a MicroAndroid is stored through a client application; adding the mapping file to the system mapping, and setting a block device corresponding to the mapping file; the method comprises the following steps: starting a virtual machine in an Android system, and loading a system image in the virtual machine to start MicroAndroid; the method comprises the following steps of: reading a preset key on the MicroAndroid, and performing encryption processing on block equipment by using the preset key to obtain encrypted block equipment; and on the MicroAndroid, based on the encryption block device and a preset key, creating a decryption block device, and mounting the decryption block device to the target directory. According to the method, when the virtual machine code is updated, the data stored in the mapping file is not influenced and can be persistently stored, and meanwhile, the data read-write security is ensured.

Description

Technical Field

[0001] This invention relates to the field of virtualization framework technology, and in particular to a data persistence storage method and electronic device. Background Technology

[0002] In related technologies, persistent data in Microdroid (a small Android system) is encrypted with a private key of the pVM (Protected Virtual Machine) instance. However, once the pVM code is updated, causing the private key to change, the persistent data synchronization fails. Summary of the Invention

[0003] The technical problem to be solved by this invention is to provide a data persistence method that allows pVM code updates to keep old data valid.

[0004] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A data persistence method, applied to the Android system, the method includes: Launch the client application in the Android system and create an image file in the application sandbox directory of the client application. The client application reads the system image containing Microdroid. Add the image file to the system image and set the block device corresponding to the image file; A virtual machine is started in the Android system, and the system image is loaded in the virtual machine to start Microdroid; On the Microdroid, a preset key is read, and the block device is encrypted using the preset key to obtain an encrypted block device; On the Microdroid, a decryption block device is created based on the encryption block device and the preset key, and the decryption block device is mounted to the target directory; To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: An electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the steps of the data persistence method described above.

[0005] The beneficial effects of this invention are as follows: To address the issue of persistent data loss due to pVM code updates in related technologies, a data persistence method is proposed. This method involves launching a client application in the Android system and creating an image file in the client application's application sandbox directory. Only the client application can access this image file, ensuring its security and privacy. The method reads the system image containing Microdroid, adds the image file to the system image, and sets the corresponding block device. A virtual machine is launched in the Android system, and the system image is mounted within the virtual machine to launch Microdroid. A preset key is read on Microdroid, and the block device is encrypted to obtain an encrypted block device. A decrypted block device is then created and mounted to the target directory. This method adds the image file from the client application's application sandbox directory to the Microdroid system image. After launching the system image, when files are stored in the target directory running on the Microdroid virtual machine, the data can be encrypted and stored in the image file in the client application's application sandbox directory in the Android system by decrypting the block device. This ensures that the data stored in the image file is unaffected when the virtual machine code is updated, achieving persistent storage. The use of a key for encryption and decryption guarantees data read and write security. Attached Figure Description

[0006] Figure 1 A flowchart illustrating the steps of a data persistence method provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the system architecture for a data persistence method provided in an embodiment of the present invention. Detailed Implementation

[0007] To make the technical problems, technical solutions, and beneficial effects to be solved by this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this application.

[0008] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0009] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0010] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0011] The following describes the relevant terms used in this invention: AVF: The Android Virtualization Framework (AVF) provides a secure and private execution environment for code execution. AVF is well-suited for security-oriented use cases that require a higher level of security, or even formally validated isolation guarantees, than those offered by the Android application sandbox.

[0012] pVM: An untrusted, isolated execution environment (client) that runs alongside the main Android operating system (host). pVM provides an isolated execution environment, enabling parts of an application to run with greater confidentiality and integrity than a regular Android environment.

[0013] Microdroid: A mini version of Android OS running in the pVM. Providing robust confidentiality and integrity protection in traditional operating systems requires a significant amount of work (often repetitive). This is because traditional operating systems are not well-integrated with the overall Android architecture. For example, with the standard Android architecture, developers need to implement a way to securely load and execute parts of their applications in the pVM, while also building payloads based on glibc (the GNU C Library, the core C standard library in Linux). However, Android applications require Bionic (a C standard library specifically optimized for Android), communication requires a custom protocol based on vsock, and debugging requires the complex and cumbersome adb commands. Microdroid easily bridges these differences. It provides a well-designed, off-the-shelf operating system image, allowing developers to offload parts of their applications to the pVM in the most effortless way. Microdroid's native code is based on Bionic, and communication is achieved through Binder. It supports importing APEX from the host Android and exposes some Android APIs, such as the keystore needed for encryption using hardware-backed keys. In summary, Microdroid provides developers with a familiar environment, containing all the tools they already know from the full version of the Android OS.

[0014] Virtual machine sockets (vsock): The primary interface for communication between pVMs is vsock, a standard Virtio socket interface. Each virtual machine is identified by a 32-bit context identifier (CID) (similar to an IP address). When a virtual machine is created, the system service assigns this identifier to the virtual machine, and it can expose services on any port number chosen by the virtual machine.

[0015] VirtualizationService is an Android service that manages the lifecycle of pVMs. It primarily manages multiple guest virtual machines running on the Android system by managing instances of crosvm (crosvm is a virtual machine monitor written in Rust. crosvm allocates virtual machine memory, creates virtual CPU threads, and implements the backend for virtual devices). VirtualizationService exposes an AIDL (Android Interface Definition Language) API, which system services or applications can use to start, monitor, and stop virtual machines.

[0016] crosvm supports two different virtual machine boot methods: providing a kernel and initrd, or providing a bootloader. Furthermore, in either case, any number of disk images can be provided; these can be raw images or combinations of multiple partitions. These images are provided by the client as file descriptors.

[0017] The VirtualizationService builds composite disk images on demand. This process is necessary because composite disk files internally reference various partition image files that make up the disk. These image files are passed by the client (usually an application that needs to start a virtual machine) and may not be directly accessible through crosvm. To address this, the VirtualizationService ensures that the file descriptor numbers inherited by crosvm are the same as the file descriptor numbers used by the VirtualizationService to create the composite image. Composite disk images use filenames in the form " / proc / self / fd / N" to represent each partition file.

[0018] dm-crypt: dm-crypt is a kernel module that provides transparent encryption for block devices using device mapper technology. This means it can encrypt entire partitions, logical volumes, or files, automatically encrypting data when it's written to disk and automatically decrypting it when it's read. dm-crypt supports various encryption algorithms, such as AES, Blowfish, and CAST5. dm-crypt works by mapping the original block device to a new, encrypted device. All read and write operations on the encrypted device are processed by the dm-crypt module. Using dm-crypt effectively protects data from unauthorized access, and it's transparent to upper-layer applications, allowing encryption to be implemented without modifying the application itself.

[0019] App Sandbox Directory: The App Sandbox Directory is located in the non-shared storage space allocated by the Android system for each app.

[0020] In related technologies, persistent data stored in Microdroid is protected by pVM keys. Based on the virtual machine identity and key generation mechanism, each virtual machine (VM) has a unique 32-byte key (called the VM identity). This key is not exposed to the host and typically remains unchanged when the same VM is stopped and restarted. In Android 14, the key is dynamically generated using the following elements: a device-specific random value, the complete system image, the salt value for each instance, the code running in the VM (bootloader, kernel, Microdroid, payload), and key VM configuration options (e.g., whether debug mode is enabled). Any modification to these elements (such as code changes or configuration adjustments) will generate a completely new key. Attempting to start an older VM instance without the same key will fail immediately. In other words, when the code running in the pVM (including the bootloader, kernel, Microdroid, and payload) is updated, the key generated for the pVM instance—the VM identity—will change, rendering the old pVM instance unusable, and its encrypted persistent data unusable.

[0021] The following describes a data persistence method of the present invention, applied to the Android system, with reference to the appendix. Figure 1 This includes steps 110 to 160: Step 110: Launch the client application in the Android system and create an image file in the application sandbox directory of the client application. The image file is a binary file that is assigned a fixed storage size when it is created. It is created in the application sandbox directory of the client and is protected by the Android system's sandbox mechanism, making it inaccessible to other applications.

[0022] Step 120: Read the system image containing Microdroid through the client application; the Microdroid system image is a composite disk image that contains core components such as bootloader, boot.img (kernel and initial memory disk), vendor_boot.img (virtual machine-specific driver), super.img (system and vendor logical partition), and vbmeta.img (verification metadata). Its components are securely stored in the read-only system partition and application sandbox directory, and are finally dynamically assembled into a virtual composite disk by the Virtualization Service for the Microdroid virtual machine to run.

[0023] Step 130: Add the image file to the system image and set the block device corresponding to the image file; specifically, place the image file in the corresponding directory of the Microdroid system image and modify the corresponding configuration file so that the image file can be mounted as a virtual block device after startup.

[0024] Step 140: Start the virtual machine in the Android system, and load the system image in the virtual machine to start Microdroid; specifically, in the Android system, the client application requests to start the virtual machine through the AIDL API provided by the VirtualizationService. The VirtualizationService creates a separate crosvm instance for each virtual machine to run it and manages this instance on behalf of the client.

[0025] Step 150: On Microdroid, read the preset key and use the preset key to encrypt the block device to obtain the encrypted block device; Step 160: On Microdroid, create a decryption block device based on the encryption block device and the preset key, and mount the decryption block device to the target directory; As described above, this embodiment starts a client application in the Android system, creates an image file in the application sandbox directory of the client application, reads the system image storing Microdroid, adds the image file to the system image, sets the block device corresponding to the image file, starts a virtual machine in the Android system, loads the system image in the virtual machine to start Microdroid, reads a preset key on Microdroid, encrypts the block device to obtain an encrypted block device, maps and creates a decrypted block device, and mounts it to the target directory. This method adds the image file in the application sandbox directory of the client application to the Microdroid system image, and after starting the system image, ensures that when files are stored in the target directory running on the Microdroid virtual machine, the data can be encrypted and stored in the image file in the application sandbox directory of the Android system client application by decrypting the block device. This ensures that when the virtual machine code is updated, the data stored in the image file is unaffected and can be persistently saved. Data read / write security is guaranteed by using a key for encryption and decryption.

[0026] In one embodiment of this application, step 110 involves creating an image file in the application sandbox directory of the client application, including: virtual machine parameters for enabling persistent storage; and creating an image file in the application sandbox directory of the client application based on the virtual machine parameters. The virtual machine parameters include virtual machine name, CPU architecture topology, virtual machine memory size, whether it is debuggable, and persistent storage size. The persistent storage size is an optional parameter, and specifying this parameter indicates that persistent storage is enabled.

[0027] As described above, in this embodiment, by enabling persistent storage in the virtual machine parameters, an image file is created in the application sandbox directory of the client application. This method utilizes a virtual machine-level persistence mechanism to ensure the stable creation and maintenance of the image file in the application's private storage space. This not only ensures the security of data storage but also achieves automated management of the storage process through system-level parameter configuration, thereby improving the reliability and execution efficiency of file operations.

[0028] In one embodiment of this application, step 120 involves reading the system image storing Microdroid via a client application, followed by: Step 121: Open the image file in read-write mode to obtain the image file descriptor; Step 122: Using the image file descriptor as a parameter, call the virtual machine creation interface in the Android system's virtualization service to create a virtual machine; where virtualization service refers to VirtualizationService. The client passes the custom image file as a file descriptor to VirtualizationService, and VirtualizationService creates the virtual machine through AIDLAPI.

[0029] Step 130, adding the image file to the system image and setting the corresponding block device for the image file, also includes: adding the image file to the system image in the virtualization service and setting the corresponding block device for the image file; specifically, adding the image file to the corresponding directory of the system image, and then constructing a composite disk image through VirtualizationService. VirtualizationService will create a dedicated partition for the added custom image file.

[0030] Step 140, loading the system image in the virtual machine to start Microdroid, further includes: loading the system image on the virtual machine through the virtualization service, and starting Microdroid after loading; specifically, the client application starts crosvm through the virtualization service, passes the above system image to crosvm and runs Microdroid.

[0031] As described above, in this embodiment, a file descriptor is obtained by opening the image file in read-write mode, and a virtual machine is created by calling the virtual machine creation interface of the Android system virtualization service based on the descriptor. The image file is added to the system image and the corresponding block device is set in the virtualization service. Finally, the system image is loaded onto the virtual machine through the virtualization service to start Microdroid. Thus, this method indirectly creates a virtual machine by calling the system-level VirtualizationService through the client application and passing the file descriptor of the custom image file to construct a composite disk image as the system image. This ensures that Microdroid has a storage space located under the application sandbox directory of the client application after startup, making it unaffected by changes in the virtual machine's identity. Using read-write mode to open the image file ensures the modifiability of the image data, and the above operations enable applications to start Microdroid more securely.

[0032] In one embodiment of this application, step 150, reading a preset key and using the preset key to encrypt the block device, includes: The encryption module of Microdroid is invoked; a preset key is read, and the block device is encrypted using the key; wherein, the encryption module refers to encryptedstore.

[0033] Step 160, creating a decryption block device based on the encryption block device and a preset key, further includes: The encryption module's creation function creates a decryption block device based on the encryption block device and a preset key.

[0034] That is, using encryptedstore's dm-crypt to create decrypted block devices based on encrypted block devices and preset keys.

[0035] Specifically, the decrypted block device is a virtual device mapping (e.g., / dev / mapper / myvault). All I / O requests sent to this mapped device are decrypted (read operations) or encrypted (write operations) by dm-crypt before being forwarded to the underlying encrypted physical device. The Microdroid manager passes the mount directory as a parameter to encryptedstore, which then performs the mounting. Mounting refers to using dm-crypt, based on the encrypted block device and a preset key, to create a decrypted device mapping node in the specified mount directory, thereby providing access to the data.

[0036] As described above, in this embodiment, the block device is encrypted by reading a preset key and calling Microdroid's encryptedstore. Then, a virtual decryption block device is created based on the encrypted block device and the preset key using encryptedstore's dm-crypt. Thus, this method uses the preset key to encrypt and protect the data in the block device, ensures the standardization of encryption operations through encryptedstore's standardized encryption interface, and automatically restores the data access capability during decryption using the dm-crypt mechanism. This not only ensures the confidentiality and integrity of the stored data, but also achieves a secure and efficient data encryption and decryption process through the collaboration of the key and encryption components.

[0037] In one embodiment of this application, step 120, reading the system image storing Microdroid through a client application, further includes: initializing the image file and setting an unformatted flag for the image file through the client application; specifically, the client application calls VirtualizationService to initialize the image file. The newly created image file will have the unformatted flag written to it during the initialization process.

[0038] In step 160, creating a decryption block device based on the encrypted block device and a preset key also includes: formatting the decryption block device and clearing the unformatted identifier of the image file; specifically, after creating the decryption block device, encryptedstore determines whether the image file has been formatted by judging whether the image file has an unformatted identifier. If the identifier exists, it means that the decryption block device has not been formatted. Then, the decryption block device is formatted with a file system, and the formatting process will clear the unformatted identifier.

[0039] As described above, in this embodiment, the initial state of the image file is ensured to be controllable through initialization operations. The mechanism for setting and clearing the unformatted identifier enables dynamic management of the image file's state. This allows for subsequent data reuse, where the presence or absence of the unformatted identifier can determine whether the image file can be directly reused, providing a basis for data reuse and ensuring accurate data reuse. Combined with formatting processing, the storage structure of the decryption block device is standardized, thereby improving the reliability of data processing and the consistency of system operation.

[0040] In one embodiment of this application, it further includes: Step 610: After successfully mounting the decrypted block device to the target directory, write files to the target directory via Microdroid. Mounting refers to associating a storage device (corresponding to the decrypted block device in this solution) with a specific directory in the file system directory tree, for example, the target directory is " / mnt / persiststore". This directory is the entry point for Microdroid to access the contents of the decrypted block device.

[0041] Step 620: Encrypt the file and save it to the image file; Specifically, after the aforementioned decryption block device is mounted to the target directory of Microdroid, system services or applications on Microdroid can write files to that target directory. The file will then be encrypted and synchronously saved to the image file.

[0042] As described above, in this embodiment, an association path between the decryption block device and the target directory is established through the mounting operation, targeted writing of files is achieved using system services or applications, the confidentiality of file content is ensured through encryption, and the real-time consistency of image file and directory operations is ensured by the synchronous saving mechanism, thereby enhancing the security of data storage.

[0043] In one embodiment of this application, step 150, reading the preset key, further includes: Step 710: Use an algorithm to generate a random number as the preset key; Step 720: Store the preset key in the Microdroid kernel; Specifically, the preset key is pre-installed in the Microdroid kernel code and is generated before any modifications to the Microdroid kernel are made. Optionally, the preset key is a 32-byte random number generated by tools such as OpenSSL.

[0044] As described above, in this embodiment, the unpredictability and uniqueness of the key are ensured by the random number generation mechanism, and the key is stored in the Microdroid kernel code to ensure the security isolation and tamper resistance of the key, thereby enhancing the overall security of the system's encryption operations.

[0045] In one embodiment of this application, it further includes: Step 810: When the client application starts the virtual machine with persistent storage enabled, determine whether the original image file exists in the application sandbox directory of the client application; Step 820: If it exists, open the original image file in read-write mode to obtain the original image file descriptor, and call the virtual machine creation interface in the virtualization service of the Android system with the original image file descriptor as the parameter; specifically, if the original image file already exists in the application sandbox directory, no initialization is performed, and the pVM creation interface of VirtualizationService is called with the original image file descriptor as the parameter.

[0046] If it does not exist, create an image file for data persistence according to steps 110 to 160 and load it into Microdroid.

[0047] As described above, this embodiment achieves flexible control of the persistence function through parameterized configuration. It determines whether the original image file exists in the application sandbox directory of the client application. If it does, a new image file is not created, allowing the original image file to be reused and achieving data persistence. This ensures the correct identification and initialization of the image file and guarantees data consistency.

[0048] In one embodiment of this application, step 160, creating a decryption block device based on the encryption block device and a preset key, further includes: Determine if the image file has an unformatted identifier. If not, create a decryption block device based on the encrypted block device corresponding to the image file and a preset key, and mount the decryption block device to the Microdroid target directory.

[0049] Specifically, it is determined that the decryption block device does not have an unformatted identifier, so there is no need to format the decryption block device. After the original image file is mapped to the decryption block device, it is mounted to the specified target directory, so that the data in the original image file can be reused.

[0050] As described above, in this embodiment, the unformatted identifier detection mechanism avoids repeated formatting operations, the key decryption process ensures the security of data access, and the target directory mounting operation enables access to the original image file's data on Microdroid, thus achieving data reuse.

[0051] Applying the above-described data persistence method to a real-world scenario includes steps a through e. Please refer to... Figure 3 , Figure 3 This is a schematic diagram of the system architecture of the above method. In this diagram, the client is used to call the interface of VirtualizationService to start or stop pVM. VirtualizationService is used to manage the lifecycle of pVM. After Microdroid starts, it communicates with the client application through vsock.

[0052] Step a: Start the pVM client application and enable persistent storage by setting VM (virtual machine) parameters, such as by setting the persistent storage size parameter. Based on the configuration parameters, create an image file of the specified storage size in the application sandbox directory. This corresponds to step 110 above.

[0053] Step b: The client application calls VirtualizationService to initialize the image file (mainly identifying the file as an unformatted image file), then opens the image file in read-write mode, calls the pVM creation interface of VirtualizationService, and passes the image file descriptor. This corresponds to step 120 above.

[0054] Step c: In VirtualizationService, add the image file to the Microdroid system image and specify the corresponding block device name. This corresponds to step 130 above.

[0055] Step d: During the Microdroid startup process, the Microdroid Manager reads the preset key, calls encryptedstore, and encrypts the block device specified in step c by specifying the key and mount path. This corresponds to steps 140 to 150 above.

[0056] Step e: In encryptedstore, dm-crypt is used to map the specified block device to a new device (corresponding to the decrypted block device in step 160 above). Then, the decrypted block device is initialized with file system formatting (this process clears unformatted identifiers from the image file). Finally, the decrypted block device is mounted to the specified target directory. After successful mounting, files written to this target directory by Microdroid system services or applications will be encrypted and synchronously saved to the persistent image file created in step a. This corresponds to step 160 above.

[0057] Optionally, when the pVM key changes, rendering the old pVM unusable, the client application needs to delete the old pVM instance in its application sandbox directory and create a new pVM, but retain the persistent image file created by the old pVM. If the new pVM needs to reuse the persistent image file of the old pVM, steps i to m are also included: Step i: When the client application sets VM parameters to start a new pVM, if the configuration parameters still enable persistent storage, determine whether a persistent data image file exists in its application sandbox directory. If it does not exist, create the persistent data image file according to the process described in steps a to e and load it into Microdroid; if it exists, share the image file used for data persistence according to the following steps.

[0058] Step j: The client application opens the image file in read-write mode, calls the pVM creation interface of VirtualizationService, and passes the image file descriptor.

[0059] Step k: In VirtualizationService, add the image file to the Microdroid system image and specify the corresponding block device name.

[0060] Step 1: During the Microdroid startup process, microdroid_manager reads the preset key, calls encryptedstore, and specifies the key and mount path to encrypt the target device. Here, microdroid_manager is the Microdroid manager, which manages the pVM lifecycle and instance disks within the pVM.

[0061] Step m: In encryptedstore, dm-crypt is used to map the encrypted block device to a new decrypted block device. It can be determined that the encrypted block device does not have an unformatted identifier, so there is no need to format the encrypted block device. After mapping to the decrypted block device, it is mounted to the specified target directory, so that the data in the original persistent image file can be reused.

[0062] Please refer to Figure 2 The present invention also provides an electronic device 400, including a memory 402 and a processor 401, and a computer program stored on the memory 402 and running on the processor 401. When the processor 401 executes the computer program, it implements the various steps in the data persistence method described above.

[0063] The beneficial effects of the electronic device of the present invention are the same as those of the method described above, and will not be repeated here.

[0064] In summary, this invention provides a method and electronic device for persistent data storage. Specifically, by launching a client application in the Android system, an image file is created in the application sandbox directory of the client application, ensuring the security and privacy of the image file. The system image storing Microdroid is read, the image file is added to the system image, and the corresponding block device is set. A virtual machine is launched in the Android system, and the system image is loaded into the virtual machine to launch Microdroid. A preset key is read on Microdroid, and the block device is encrypted to obtain an encrypted block device. A decrypted block device is created and mounted to the target directory. This method adds the image file from the application sandbox directory of the client application to the Microdroid system image. After launching the system image, when a file is stored in the target directory running on the Microdroid virtual machine, the data can be encrypted and stored in the image file in the application sandbox directory of the Android system client application by decrypting the block device. This ensures that when the virtual machine code is updated, the data stored in the image file is unaffected and can be persistently stored. The use of a key for encryption and decryption ensures data read and write security. It also avoids repeated formatting operations through an unformatted identifier detection mechanism, ensures the security of data access through the key decryption process, and enables access to the original image file's data on Microdroid by combining the target directory mounting operation, thus achieving secure data reuse.

[0065] The above are merely embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention's specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for persistent data storage, characterized in that, Applied to the Android system, the method includes: Launch the client application in the Android system and create an image file in the application sandbox directory of the client application. The client application reads the system image containing Microdroid. Add the image file to the system image and set the block device corresponding to the image file; A virtual machine is started in the Android system, and the system image is loaded in the virtual machine to start Microdroid; On the Microdroid, a preset key is read, and the block device is encrypted using the preset key to obtain an encrypted block device; On the Microdroid, a decryption block device is created based on the encryption block device and the preset key, and the decryption block device is mounted to the target directory.

2. The data persistence method according to claim 1, characterized in that, Creating an image file in the application sandbox directory of the client application includes: The virtual machine parameters for enabling persistent storage are used to create an image file in the application sandbox directory of the client application.

3. The data persistence method according to claim 1, characterized in that, The step of reading the system image storing Microdroid through the client application further includes: The image file is opened in read-write mode to obtain an image file descriptor; Using the image file descriptor as a parameter, the virtual machine creation interface in the virtualization service of the Android system is called to create a virtual machine; The step of adding the image file to the system image and setting the block device corresponding to the image file further includes: In the virtualization service, the image file is added to the system image, and the block device corresponding to the image file is configured; The step of loading the system image in the virtual machine to launch Microdroid further includes: The system image is loaded onto the virtual machine via the virtualization service, and Microdroid is launched after the loading is complete.

4. The data persistence method according to claim 1, characterized in that, The step of reading a preset key and using the preset key to encrypt the block device includes: Invoke the encryption module of the Microdroid; Read the preset key and use the key to encrypt the block device; The method of creating a decryption block device based on the encryption block device and the preset key further includes: The encryption module's creation function creates a decryption block device based on the encryption block device and the preset key.

5. A data persistence method according to claim 1, characterized in that, The step of reading the system image storing Microdroid through the client application also includes: The client application initializes the image file and sets an unformatted flag for the image file. The method of creating a decryption block device based on the encryption block device and the preset key further includes: Format the decryption block device and remove the unformatted identifier from the image file.

6. The data persistence method according to claim 1, characterized in that, Also includes: After successfully mounting the decryption block device to the target directory, the Microdroid writes files to the target directory. The file is encrypted and saved to the image file.

7. The data persistence method according to claim 1, characterized in that, Before reading the preset key, the process also includes: Use an algorithm to generate random numbers as a preset key; The preset key is stored in the kernel of the Microdroid.

8. The data persistence method according to claim 1, characterized in that, Also includes: When the client application starts the virtual machine with persistent storage enabled, it determines whether the original image file exists in the application sandbox directory of the client application. If it exists, open the original image file in read-write mode to obtain the original image file descriptor, and use the original image file descriptor as a parameter to call the virtual machine creation interface in the virtualization service of the Android system.

9. A data persistence method according to claim 8, characterized in that, Also includes: Determine whether the image file has an unformatted identifier. If it does not, create a decryption block device based on the encryption block device corresponding to the image file and the preset key, and mount the decryption block device to the target directory of the Microdroid.

10. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of a data persistence method according to any one of claims 1 to 9.

Images