Data archiving method, data recovery method, equipment and program product

Abstract

The invention discloses a data archiving method and a data recovery method, the method is applied to electronic equipment, an operating system of the electronic equipment comprises an application layer and a framework layer, metadata of a first application is determined through the application layer, and the metadata of the first application is stored through the application layer; calling the framework layer through the application layer to archive the first application; creating a recovery entry of the first application based on the metadata of the first application; wherein the recovery entry of the first application is used for recovering the first application. Under the condition that a recovery instruction of the first application is obtained based on the recovery entry of the first application, metadata of the first application is obtained; sending a data packet request to a server of the first application based on the metadata of the first application; receiving an application package of the first application sent by the server of the first application; and recovering the first application based on the application package of the first application through the application layer.

Description

Technical Field

[0001] This application relates to the field of data processing and storage technology, and in particular to a data archiving method, a data recovery method, an electronic device, and a computer program product. Background Technology

[0002] Application archiving is a technology for managing application state in electronic devices, designed to free up storage space while preserving user data and configuration information. The basic idea is to reduce the storage footprint of infrequently used applications by removing them from the system foreground and saving them in a compressed or minimized form. Upon recovery, the system can reinstall or decompress the application based on the retained information, restoring it to its original state. This technology is widely used in mobile operating systems and desktop systems, becoming an important means of improving user experience and optimizing resource utilization.

[0003] However, the archiving process in related technologies is highly dependent on system services, which limits the realization of complete archiving and recovery capabilities and makes it difficult to adapt to diverse scenario requirements. Summary of the Invention

[0004] This application provides a data archiving method, a data recovery method, an electronic device, and a computer program product, which realize complete archiving and recovery capabilities, meet diverse scenario needs, and further improve the practicality and ease of use of archiving and recovery functions.

[0005] The technical solution of this application embodiment is implemented as follows: In a first aspect, embodiments of this application provide a data archiving method applied to an electronic device, wherein the operating system of the electronic device includes an application layer and a framework layer, and the method includes: The metadata of the first application is determined through the application layer, and the metadata of the first application is stored through the application layer. The first application is archived by calling the framework layer from the application layer. A recovery entry point for the first application is created based on the metadata of the first application; the recovery entry point for the first application is used to restore the first application.

[0006] Secondly, embodiments of this application provide a data recovery method applied to an electronic device. The operating system of the electronic device includes an application layer and a framework layer. The method includes: If the recovery instructions of the first application are obtained through the recovery entry of the first application, the metadata of the first application is obtained; Send a data packet request to the server of the first application based on the metadata of the first application; Receive the application package of the first application sent by the server of the first application; The first application is restored by using the application package of the first application at the application layer.

[0007] Thirdly, embodiments of this application provide a data archiving apparatus, which includes: A determining unit is used to determine the metadata of the first application and store the metadata of the first application; The archiving unit is used for archiving the first application; A creation unit is used to create a recovery entry for the first application based on the metadata of the first application; wherein, the recovery entry for the first application is used to restore the first application.

[0008] Fourthly, embodiments of this application provide a data recovery apparatus, which includes: The acquisition unit is used to acquire the metadata of the first application when the recovery instruction of the first application is obtained based on the recovery entry of the first application; The sending unit is used to send a data packet request to the server of the first application based on the metadata of the first application; The receiving unit is used to receive the application package of the first application sent by the server of the first application; The recovery unit is used to recover the first application based on the application package of the first application.

[0009] Fifthly, embodiments of this application provide an electronic device, which includes a processor and a memory storing processor-executable instructions, wherein when the instructions are executed by the processor, the method as described in the first or second aspect is implemented.

[0010] Sixthly, embodiments of this application provide a computer program product, including a computer program or instructions, which, when executed by a processor, implement the method as described in the first or second aspect.

[0011] This application provides a data archiving method, a data recovery method, an electronic device, and a computer program product. The method is applied to an electronic device whose operating system includes an application layer and a framework layer. The application layer determines and stores the metadata of a first application. The application layer calls the framework layer to perform archiving processing on the first application. A recovery entry point for the first application is created based on its metadata. This recovery entry point is used to recover the first application. Upon receiving a recovery instruction for the first application based on its recovery entry point, the method retrieves the metadata of the first application. It then sends a data packet request to the server of the first application based on the metadata. It receives the application package of the first application from the server of the first application. Finally, the application layer recovers the first application based on the application package. In other words, in this application, on the one hand, the application layer determines and stores the metadata of the first application, ensuring that key information is retained after archiving to support recovery operations. On the other hand, by calling the framework layer from the application layer to perform the archiving processing of the first application, it avoids direct reliance on system versions or developer implementations, thereby improving the compatibility and versatility of the solution. Furthermore, creating a recovery entry point based on metadata ensures convenient triggering of the recovery process subsequently. On the other hand, by creating a recovery entry point to trigger the recovery process of the first application, after obtaining the corresponding application package from the server based on the metadata of the first application, the recovery process of the first application is completed through the application layer. This allows for on-demand recovery of required content through the application layer, while ensuring that the application state after recovery is consistent with that before archiving. Therefore, this application can achieve complete archiving and recovery capabilities, meeting diverse scenario requirements and further improving the practicality and ease of use of archiving and recovery functions. Attached Figure Description

[0012] Figure 1 A schematic diagram illustrating the implementation of application archiving; Figure 2 A schematic diagram illustrating the implementation of application archive recovery; Figure 3 A schematic diagram of the operating system used in the data archiving and data recovery methods proposed in the embodiments of this application; Figure 4 A flowchart illustrating the data archiving method proposed in this application. Figure 1 ; Figure 5 A flowchart illustrating the data archiving method proposed in this application. Figure 2 ; Figure 6 A flowchart illustrating the data archiving method proposed in this application. Figure 3 ; Figure 7A flowchart illustrating the data archiving method proposed in this application. Figure 4 ; Figure 8 A flowchart illustrating the data archiving method proposed in this application. Figure 5 ; Figure 9 This is a schematic flowchart of the data recovery method proposed in the embodiments of this application; Figure 10 This is a schematic diagram illustrating the implementation of the data recovery method proposed in this application embodiment; Figure 11 This is a schematic diagram illustrating the implementation of the data archiving and data recovery methods proposed in the embodiments of this application. Figure 1 ; Figure 12 This is a schematic diagram illustrating the implementation of the data archiving and data recovery methods proposed in the embodiments of this application. Figure 2 ; Figure 13 This is a schematic diagram illustrating the implementation of the data archiving and data recovery methods proposed in the embodiments of this application. Figure 3 ; Figure 14 This is a schematic diagram illustrating the implementation of the data archiving and data recovery methods proposed in the embodiments of this application. Figure 4 ; Figure 15 This is a schematic diagram illustrating the implementation of the data archiving and data recovery methods proposed in the embodiments of this application. Figure 5 ; Figure 16 This is a schematic diagram illustrating the implementation of the data archiving and data recovery methods proposed in the embodiments of this application. Figure 6 ; Figure 17 This is a schematic diagram of the composition structure of the data archiving device proposed in the embodiments of this application; Figure 18 This is a schematic diagram of the composition of the data recovery device proposed in the embodiments of this application; Figure 19 This is a schematic diagram of the composition structure of the electronic device proposed in the embodiments of this application. Detailed Implementation

[0013] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for explaining the differences between the applications and are not intended to limit the application. Furthermore, it should be noted that, for ease of description, only the parts that differ from the relevant applications are shown in the accompanying drawings.

[0014] Application archiving refers to removing temporarily unused applications from the system while retaining their configuration files, user data, and associated files for quick future recovery. Its core logic involves compressing and packaging application files (such as Android Packages (APKs), caches, etc.) and deleting the original installation path to free up storage space, while simultaneously restoring necessary information through metadata records.

[0015] For example, one application archiving scheme is based on the modularity of the Android AppBundle (AAB) open-source application installation package format. The AAB can be compiled into archive.apk, which has the same version and signature as the full-featured apk, with an added cloud overlay icon (to make the archiving process apparent to the user). However, only a bootloader is used to launch the app store and restore the application. Meanwhile, archive.apk is small (less than 100KB), freeing up space in the full-featured apk by installing the same version of archive.

[0016] For example, one APK-based application archiving scheme is implemented based on the Android system framework. In this scheme, the archiving operation removes the APK file but retains the user data directory ( / data / data / ). <package>This replaces the original APK by generating a lightweight archive.apk of only about 100KB. During archiving, the system saves the icon and entry component. Archived applications require desktop adaptation, displaying an icon on the desktop as a restore entry point.

[0017] When restoring archived applications, the system will re-download or decompress the application files based on the metadata and restore user data to its state before archiving. For example, one approach is to re-download the archived application and automatically restore settings and files; another approach is to restore via a single click using the archived file and mark the menu items.

[0018] For example, such as Figure 1 As shown, an application archiving execution process may include: the app store initiates an archiving request, the package manager performs permission verification and resource preparation, then saves the application archive state (ArchiveState) and the application icon (icon); then the archiving operation is performed, and user data is retained during the archiving process; finally, the system desktop is notified of the state change, and the system desktop displays the archive icon.

[0019] For example, such as Figure 2 As shown, an execution flow for restoring an archived application may include: after receiving the request to restore the archive, for example, when the user clicks the archive icon, the system desktop triggers a restoration request, the package manager creates a restoration session and initiates an installation process with the app store, and after the app store completes the installation and data restoration, the package manager updates the application status, at which point the system desktop displays a normal icon.

[0020] AAB-based application archiving mechanisms have significant advantages in cross-version compatibility and distribution processes: 1. It has compatibility with lower versions of Android, meaning it allows the application to run on lower versions of Android. 2. An icon appears on the desktop; users can re-download archived applications through the "Manage Apps" interface in the store. 3. Third-party store limitations, such as limited AAB parsing capabilities of third-party stores, which may result in error messages during updates; 4. Signature mandatory verification: AAB must be signed by the developer, and the signing key must be consistent with the original submission; otherwise, an update prompt will be triggered.

[0021] The core design of APK archiving is rooted in the system framework layer. This solution provides a closed-loop operation logic of archiving-uninstalling-restoring in system settings: users can trigger archiving behavior in the application management interface. The system compresses application data and resources into a quickly recoverable archive package while releasing runtime resources. The archived application remains on the desktop but is in a dormant state. Clicking the icon automatically decompresses the archive package and rebuilds the application context. This design achieves efficient state preservation through system-level services, but its technology implementation faces three challenges: First, older system versions cannot directly call the application state preservation and restoration functions; second, the desktop environment needs to pre-configure special icon rendering and click event handling logic to support archived applications; and finally, the application management module in system settings does not reserve an entry point for archiving operations, preventing users from triggering the archiving process through a unified interface.

[0022] In summary, AAB cannot effectively archive and restore archived applications in scenarios where ecosystem services are lacking or store compatibility is insufficient. Furthermore, APK archiving is also limited by version level, desktop environment, and system settings.

[0023] It is evident that current technologies have certain requirements regarding software version, settings, application environment, and developer signature during the archiving and recovery of applications. This limits their applicability to various scenarios, restricts the realization of complete archiving and recovery capabilities, and makes it difficult to adapt to diverse scenario needs and third-party application ecosystems.

[0024] To address the aforementioned issues, this application provides a data archiving method, a data recovery method, an electronic device, and a computer program product. The method is applied to an electronic device whose operating system includes an application layer and a framework layer. The application layer determines and stores the metadata of a first application. The application layer calls the framework layer to perform archiving processing on the first application. A recovery entry point for the first application is created based on its metadata. This recovery entry point is used to recover the first application. Upon receiving a recovery instruction for the first application based on its recovery entry point, the method retrieves the metadata of the first application. It then sends a data packet request to the server of the first application based on the metadata. It receives the application package of the first application from the server of the first application. Finally, the application layer recovers the first application based on the application package. In other words, in this application, on the one hand, the application layer determines and stores the metadata of the first application, ensuring that key information is retained after archiving to support recovery operations. On the other hand, by calling the framework layer from the application layer to perform archiving processing on the first application, it avoids direct reliance on system versions or developer implementations, thereby improving the compatibility and versatility of the solution. Furthermore, creating a recovery entry point based on metadata ensures convenient triggering of the recovery process subsequently. On the other hand, by creating a recovery entry point to trigger the recovery process of the first application, after obtaining the corresponding application package from the server based on the metadata of the first application, the recovery process of the first application is completed through the application layer. This allows for on-demand recovery of required content through the application layer, while ensuring that the application state after recovery is consistent with that before archiving. Therefore, this application can achieve complete archiving and recovery capabilities, meeting diverse scenario requirements and further improving the practicality and ease of use of archiving and recovery functions.

[0025] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0026] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0027] One embodiment of this application provides a data archiving method, which may include an application-layer-based data archiving method. This application-layer-based data archiving method can be executed by an electronic device, wherein the electronic device may be a smart terminal running an operating system, such as a smartphone or tablet computer.

[0028] In some embodiments, the operating system running on the electronic device is not specifically limited in this application. For example, the operating system may be Android or an OS.

[0029] Exemplary, in some embodiments, such as Figure 3 As shown, the operating system 10 running in the electronic device may include an application layer 101 and a framework layer 102. The framework layer is above the user interface layer and provides development support for the application layer. The application layer is located at the top layer and depends on the framework layer or directly calls the operating system application programming interface (API) to run.

[0030] In some embodiments, the application layer is a user-facing software layer within the operating system, including pre-installed system applications and third-party installed applications. The application layer is responsible for user interaction and business logic processing, and implements underlying functionalities by calling framework layer interfaces.

[0031] In some embodiments, the Framework Layer is located between the application layer and the system kernel, providing development APIs and service interfaces (such as PackageManagerService) to provide runtime environment support for the application layer, including application management, resource scheduling, lifecycle control, etc.

[0032] In some embodiments, the collaboration between the application layer and the framework layer is the core mechanism for software operation. Essentially, the framework layer provides standardized services to the application layer, and the application layer implements functions by calling the framework interface.

[0033] In the embodiments of this application, such as Figure 4 As shown, a data archiving method may include the following steps: Step 401: Determine the metadata of the first application through the application layer, and store the metadata of the first application through the application layer.

[0034] In this embodiment, the electronic device can first determine the metadata of the first application through the application layer, and then store the metadata of the first application through the application layer.

[0035] In some embodiments, the first application can be understood as an application to be archived. The electronic device may be equipped with one or more applications, and the first application may be one or more applications to be archived that are already installed on the electronic device.

[0036] In some embodiments, the first application is an application in an archiveable state, for example, the first application is not running or the background process is not active.

[0037] In some embodiments, the application layer refers to the user-facing software layer within the operating system, typically including pre-installed system applications and third-party installed applications. These applications implement underlying functionalities by calling framework layer interfaces.

[0038] In some embodiments, metadata is used to describe key information about the application, such as package name, version number, signature information, icon path, etc.

[0039] For example, in some embodiments, the metadata of the first application may include, but is not limited to: the package name of the first application, the version information (versionCode and versionName) of the first application, the signature information of the first application, the icon resource path of the first application, etc.

[0040] In some embodiments, during the archiving process, metadata can be used to record the state of the first application before archiving for use in subsequent recovery operations.

[0041] In some embodiments, after obtaining the metadata of the first application, the metadata of the first application may be further stored.

[0042] In some embodiments, the metadata of the first application can be stored in an encrypted manner to ensure security, and access permissions can also be set to prevent unauthorized modification or reading.

[0043] In some embodiments, by storing complete metadata of the first application, the state of the first application can be accurately restored during the recovery phase, thereby ensuring the stability and consistency of the recovery process.

[0044] For example, in some embodiments, if a first application is installed on an electronic device and it is decided to archive it, the application layer will extract information (metadata) such as the package name, current version number (e.g., 2.25.0.86), and icon path of the first application. The application layer may also choose to store this information.

[0045] Step 402: Archive the first application through the application layer and the framework layer.

[0046] In the embodiments of this application, after determining the metadata of the first application through the application layer and storing the metadata of the first application through the application layer, the electronic device can further call the framework layer through the application layer to perform archiving processing on the first application.

[0047] In some embodiments, archiving refers to deleting the installation package (APK) of the first application while retaining user data (metadata of the first application), thereby freeing up storage space.

[0048] In embodiments of this application, the operating system of the electronic device further includes an application programming interface (API) corresponding to the framework layer. Accordingly, when the first application is archived by calling the framework layer through the application layer, the API can be called through the application layer to execute the archiving process of the first application through the framework layer.

[0049] For example, in some embodiments, the operating system also includes an application programming interface corresponding to the framework layer.

[0050] In some embodiments, an Application Programming Interface (API) refers to a standardized set of functions provided by the operating system for upper-layer applications, used to access and invoke specific functionalities. In this application, the API is part of the framework layer, and it provides itself to the application layer so that the application layer can invoke the functions of the framework layer in a standard manner.

[0051] In some embodiments, an application programming interface (API) is introduced into the operating system, enabling multiple types of applications to call the unified archiving logic of the first application without changing the underlying structure of the operating system, thereby improving compatibility and maintainability.

[0052] In some embodiments, when an application layer calls an application programming interface (API), it can be understood as an application layer calling an API to request the execution of an operation by a module or component in the application layer.

[0053] For example, in some embodiments, the application layer calls the archiving interface provided by the framework layer to trigger the archiving process of the first application. Here, the archiving process of the first application refers to removing the application from the system when it is not currently in use, but retaining the application's configuration files, user data, and associated files for quick future recovery.

[0054] Therefore, it is evident that in this application, by calling the application programming interface (API) at the application layer to perform the archiving operation of the first application, compatibility support for lower-version operating systems can be achieved without relying on the involvement of specific developers. Furthermore, after the archiving process of the first application is completed, the application's state information can still be restored through a specific entry point, thereby ensuring the integrity and availability of user data.

[0055] For example, in some embodiments, the application programming interface (API) acts as a bridge connecting the application layer and the framework layer, defining how the caller requests a service and how the service provider responds to the request. The application layer calls the API to initiate an archiving request for the first application. After receiving the request, the framework layer executes the archiving operation of the first application, ultimately completing the archiving process for the first application.

[0056] In some embodiments, data archiving processing may rely on APIs and service interfaces provided by the framework layer, such as PackageManagerService (PMS). The framework layer, acting as an intermediary between the application layer and the system kernel, provides the APIs and system services required for development, including application management, resource scheduling, and lifecycle control.

[0057] For example, in some embodiments, during archiving, the application layer can trigger the unloading process of the retained data directory by calling the PackageManager.deletePackage() method and passing in the DELETE_KEEP_DATA flag.

[0058] In some embodiments, the archiving process of the first application includes at least one or more of the following: storing the data directory of the first application; deleting the application package of the first application.

[0059] In some embodiments, the data directory refers to a collection of user data, cache files, configuration information, etc., related to the first application, typically stored in a specified path, such as ` / data / data / `. <package>`in.

[0060] In some embodiments, the data directory of the first application contains key data such as user preferences, downloaded content, and local databases, ensuring that the user's personalized configuration and usage traces can still be retained after archiving.

[0061] In some embodiments, during the archiving process, the data directory of the first application is completely retained on the disk without modifying or deleting the data directory of the first application. Among them, since the operation of completely retaining the data directory of the first application is performed, it can be ensured that when the first application is restored, it can be quickly restored to the state before archiving, thus avoiding the risk of reconfiguration or data loss. At the same time, during the subsequent restoration of the first application, there is no need to reconfigure the first application, so the usage experience and operation efficiency can be improved.

[0062] In some embodiments, the application package refers to the core installation file (such as APK) that constitutes the first application, usually located in paths such as ` / data / app / ` or ` / system / priv-app / ` of the device.

[0063] In some embodiments, the application package of the first application contains the code, resources, icons, etc. of the first application, which is the basis for the operation of the first application.

[0064] In some embodiments, during the archiving process, the application package of the first application will be deleted, but the data directory associated with the application package of the first application will not be deleted. For example, for the first application with a large volume, by only retaining the data directory and deleting the application package of the first application, the storage occupancy can be significantly reduced without affecting the user data, optimizing the available space of the device.

[0065] Exemplarily, in some embodiments, when archiving the first application, APK metadata (such as Activity and Service registration information) can be removed from the internal structure, but the user data in the / data / data / <package_name> directory is retained, and at the same time, the APK file and derivative files (such as the base APK under / data / app and the dex file under / data / dalvik-cache) are deleted.

[0066] Exemplarily, in some embodiments, when archiving the first application at the application layer, after the application layer obtains and stores the metadata of the first application, it can call the corresponding API to delete / data / app / com.tencent.mm-1 / base.apk, and the chat records, cache files, etc. of the user in the / data / data / com.tencent.mm directory can be retained.

[0067] Step 403: Create a recovery entry for the first application based on the metadata of the first application; wherein, the recovery entry for the first application is used to restore the first application.

[0068] In the embodiments of this application, after the first application is archived by calling the framework layer through the application layer, the electronic device can further create a recovery entry for the first application based on the metadata of the first application.

[0069] In the embodiments of this application, the recovery entry for the first application can be created based on the metadata of the first application, and the recovery entry can be used to restore the first application.

[0070] In other words, in this application, the recovery entry of the first application refers to the entry created by the electronic device based on the metadata of the first application stored in the device for restoring the archived first application. By setting the recovery entry of the first application, the recovery process can be triggered to re-download or decompress the application package and restore the data.

[0071] For example, in some embodiments, the creation of the recovery entry for the first application should minimize user interaction, such as by silently adding a desktop shortcut, to avoid requiring manual confirmation from the user each time a recovery is performed.

[0072] For example, in some embodiments, in order to improve the user experience, the design of the recovery entry of the first application should be intuitive and easy to understand, so that users can quickly identify and understand the purpose of the recovery entry of the first application.

[0073] For example, in some embodiments, the recovery entry of the first application can support multiple recovery methods, such as directly restoring to the latest version or restoring to a specific version.

[0074] In the embodiments of this application, such as Figure 5 As shown, after creating the recovery entry for the first application based on its metadata, i.e., after step 403, the data archiving method may further include the following steps: Step 404: Display the recovery entry of the first application based on the preset method; wherein the preset method includes at least one or more of the following: desktop shortcut; desktop card.

[0075] In the embodiments of this application, after creating a recovery entry for the first application based on its metadata, the recovery entry can be displayed to facilitate subsequent recovery processing. For example, the recovery entry can be displayed using a preset method.

[0076] In some embodiments, the preset method can be any type of display method, that is, the display format of the recovery entry of the first application is not specifically limited in this application. For example, the preset method includes at least one or more of the following: desktop shortcut; desktop card.

[0077] For example, in some embodiments, the recovery entry for the first application can be displayed as a desktop shortcut. For instance, a desktop shortcut for the first application can be invoked on the display interface, such as the icon of the first application. In order to distinguish it from other unarchived applications, different display methods can be used to make users aware that the first application has been archived. For example, the desktop shortcut of the first application can be dynamically overlaid with a cloud overlay icon, or the desktop shortcut of the first application can be displayed as a gray icon.

[0078] For example, in some embodiments, the recovery entry for the first application can be displayed in the form of a notification card. For instance, relevant information about the first application can be displayed in the drop-down status bar of the display interface or lock screen interface, including but not limited to rich elements such as title, content, image, and progress bar.

[0079] In some embodiments, the preset method may include, but is not limited to, one or more of the following: desktop icon, recovery option in system settings, recovery reminder in notification center.

[0080] In the embodiments of this application, such as Figure 6 As shown, before determining the metadata of the first application through the application layer and storing the metadata of the first application through the application layer, i.e. before step 401, the data archiving method may further include the following steps: Step 405: If the archiving instruction of the first application is obtained and the first application belongs to the application layer, determine the first application to be archived.

[0081] In the embodiments of this application, before performing archiving processing on the first application, it can be determined whether the conditions for application archiving are met. For example, after obtaining the archiving instruction for the first application, if it is determined that the first application is an application in the application layer, then it can be further determined to perform archiving processing on the first application.

[0082] In some embodiments, the archiving instruction may refer to an archiving operation command of a first application that is manually triggered by the user or automatically triggered by the system. This application does not limit the method of obtaining the archiving instruction.

[0083] For example, in some embodiments, user-triggered archiving commands can be initiated through a graphical interface (such as an app store or system settings). For instance, when a user selects the archiving option, the electronic device can obtain the archiving command based on the user's selection of the archiving option.

[0084] For example, in some embodiments, the archiving instruction triggered automatically by the system can be initiated through a background service (such as a scheduled cleanup task). For instance, for applications that meet the cleanup conditions, the electronic device can obtain the archiving instruction through the cleanup task of a background service.

[0085] For example, in some embodiments, after obtaining the archiving instruction for the first application, it can be further determined whether the first application meets the archiving conditions. For instance, if it is determined that the first application is an application installed from a store, it is determined that the first application meets the archiving conditions.

[0086] For example, in some embodiments, the first application belongs to the application layer, which can be understood as the first application being an application installed by the application layer, and / or, it can be understood as the first application being an application managed by the application layer.

[0087] For example, in some embodiments, the first application belongs to the application layer, which can be understood as an application installed by an app store, and / or as a specific application instance running in the application layer, and / or as an application managed by the application layer.

[0088] In the embodiments of this application, such as Figure 7 As shown, before determining the metadata of the first application through the application layer and storing the metadata of the first application through the application layer, i.e. before step 401, the data archiving method may further include the following steps: Step 406: If the first application meets the automatic archiving conditions and the first application belongs to the application layer, determine the first application to be archived.

[0089] In the embodiments of this application, before performing archiving processing on the first application, it can be determined whether the first application meets the automatic archiving conditions. If it is determined that the first application meets the automatic archiving conditions and that the first application is an application in the application layer, then it can be further determined to perform archiving processing on the first application.

[0090] In the embodiments of this application, the automatic archiving conditions include at least one or more of the following: the automatic archiving function of the first application has been enabled; the first application has not been used within a preset time period; the first application belongs to the application layer.

[0091] In other words, in this application, if the first application meets the following conditions: the automatic archiving function of the first application is enabled, and / or the first application is not used by the user within a preset time period, and / or the first application belongs to the application layer, then it can be determined that the first application meets the automatic archiving conditions.

[0092] In some embodiments, based on the settings of automatic archiving conditions, an application archiving mechanism triggered by specific conditions can be implemented, which can optimize storage space without relying on the system framework and is suitable for low-version operating systems.

[0093] For example, in some embodiments, when the first application meets the automatic archiving conditions, such as the first application being set by the user to be automatically archived, not being used for a period of time, and one or more of the applications managed by the application layer being met, it can be further determined whether the first application belongs to the application layer. If it does, the application layer will perform the archiving operation.

[0094] For example, in some embodiments, when determining whether the first application meets the automatic archiving conditions, it is first determined whether the automatic archiving function of the first application has been enabled. If it has been enabled, the usage records of the first application are further checked, and it is determined whether the first application has not been used within a preset time period (e.g., 30 days). If the first application has not been used within the preset time period, it is further determined whether the first application belongs to the application layer, for example, whether the first application is an application installed from the store. If so, it is determined that the first application meets the automatic archiving conditions.

[0095] In the embodiments of this application, such as Figure 8 As shown, before creating the recovery entry for the first application based on its metadata, i.e., before step 403, the data archiving method may further include the following steps: Step 407: If the metadata of the first application exists in the local cache, the electronic device retrieves the metadata of the first application from the local cache.

[0096] Step 408: If the metadata of the first application does not exist in the local cache, the electronic device sends a query request to the server of the first application and receives the metadata of the first application sent by the server of the first application.

[0097] In the embodiments of this application, before creating the recovery entry of the first application based on the metadata of the first application, the electronic device may first obtain the original data of the first application.

[0098] In some embodiments, if the metadata of the first application exists in the local cache, the electronic device retrieves the metadata of the first application from the local cache.

[0099] In some embodiments, if the metadata of the first application does not exist in the local cache, the electronic device sends a query request to the server of the first application and receives the metadata of the first application sent by the server of the first application.

[0100] In some embodiments, local cache refers to a temporary data storage area stored locally on the device (such as a mobile phone or tablet) for quick access to frequently used information. Local cache can be a system-level cache directory (such as / data / cache) or a data structure maintained by the application itself.

[0101] In some embodiments, the metadata of the first application is not only used to identify the application's identity, but also serves as a key basis for restoring the archive operation. For example, in the archived state, the system can determine whether the application supports restoration by reading the metadata of the first application in the local cache, and provide the corresponding restoration entry point.

[0102] In some embodiments, the electronic device may not be able to directly obtain the metadata of the first application stored in the application layer in step 401 above. Therefore, before creating the recovery entry for the first application, the electronic device needs to obtain the metadata of the first application first. Specifically, it can first try to read the metadata of the first application from the local cache. If it does not exist in the local cache, the electronic device can further obtain the metadata of the first application from the server.

[0103] For example, in some embodiments, when the metadata of the first application is not found in the local cache, the electronic device can proactively initiate a query request to the server of the first application. This query request typically includes a unique identifier for the first application (such as a package name) and relevant device information (such as operating system version and device model) so that the server can return the appropriate metadata for the first application.

[0104] Accordingly, in some embodiments, after receiving a query request, the server will search its own database and return the metadata of the first application, including but not limited to the latest version number, icon URL, function description, etc.

[0105] In some embodiments, a server query request is a network communication method based on the HTTP or HTTPS protocol, used for data interaction between the client and the server.

[0106] In some embodiments, by maintaining a redundant copy of metadata on the server side, the metadata of the first application can still be obtained when the local cache is unavailable or invalid, thereby enabling a more flexible and stable application management mechanism.

[0107] For example, in some embodiments, when the metadata of the first application is detected in the local cache, the data in the local cache will be used first; when the metadata of the first application is not detected in the local cache, the relevant data will be obtained by initiating a query to the server.

[0108] In some embodiments, after obtaining the metadata of the first application by initiating a query to the server, the metadata of the first application can be further stored in a local cache.

[0109] The data archiving method proposed in this application embodiment implements application archiving functionality by calling APIs provided by the framework layer. Specifically, the application layer determines which applications can be archived and executes the corresponding processing logic. That is, the application layer has the ability to independently determine and process archiving requests without relying on developers to perform special adaptations to the application itself.

[0110] For example, in some embodiments, when a user issues an archive request, the application layer receives an archive instruction and verifies whether the first application meets the archive conditions (such as whether it belongs to the first application in the current application layer). If the verification passes, the application layer will trigger an archive operation, including deleting the APK file, retaining the user data directory, etc., thereby freeing up storage space.

[0111] For example, in some embodiments, for a first application that meets the automatic archiving conditions, after confirming that the application is a registered application in the application layer, the application layer can perform archiving operations, including deleting APK files, retaining user data directories, etc., thereby freeing up storage space.

[0112] Understandably, the above-mentioned archiving mechanism allows archiving operations to be completed without relying on a specific operating system version, making it suitable for lower-version operating systems and improving compatibility and usability.

[0113] For example, in some embodiments, after archiving is completed, an icon of the first archived application can be displayed on the display interface (desktop) so that subsequent users can trigger the recovery process by clicking the archive icon. For instance, the archived first application may be displayed as a recovery entry with a special identifier (such as a cloud overlay) on the desktop or other application list of an electronic device to indicate to the user that the first application is in an archived state.

[0114] The data archiving method provided in this application determines and stores the metadata of a first application at the application layer, performs archiving processing using the framework layer interface, and finally creates a recovery entry point for the first application. This achieves efficient archiving and rapid recovery of a first application on a lower version operating system without depending on the underlying system version. Specifically, the data archiving method can release the storage space of the first application without deleting user data, and through the recovery entry point of the first application, users can restore the first application to its state before archiving with one click, significantly improving storage management efficiency and user experience.

[0115] In summary, in the embodiments of this application, the application layer autonomously determines and executes the archiving operation. This approach avoids dependence on specific operating system versions or developers, allowing the archiving function to be deployed on older operating systems (such as Android), further improving storage space utilization.

[0116] This application proposes a data archiving method applied to an electronic device. The operating system of the electronic device includes an application layer and a framework layer. The method involves determining and storing the metadata of a first application through the application layer; calling the framework layer from the application layer to perform archiving processing on the first application; and creating a recovery entry point for the first application based on its metadata. This recovery entry point is used to restore the first application. In other words, this application determines and stores the metadata of the first application, ensuring that key information is retained after archiving to support recovery operations. Furthermore, the application layer's call to the framework layer executes the archiving process for the first application, avoiding direct reliance on system versions or developer implementations, thus improving the compatibility and versatility of the solution. Creating a recovery entry point based on metadata ensures convenient triggering of the recovery process subsequently. Therefore, this application can achieve complete archiving and recovery capabilities, meeting diverse scenario requirements and further enhancing the practicality and ease of use of archiving and recovery functions.

[0117] Based on the above embodiments, another embodiment of this application provides a data recovery method, which may include an application-layer-based data recovery method. This application-layer-based data recovery method can be executed by an electronic device, wherein the electronic device may be a smart terminal running an operating system, such as a smartphone or tablet computer.

[0118] In the embodiments of this application, such as Figure 9 As shown, data recovery methods may include the following steps: Step 901: If the recovery instruction of the first application is obtained through the recovery entry of the first application, the metadata of the first application is obtained.

[0119] In the embodiments of this application, the electronic device can obtain the recovery instruction of the first application through the recovery entry of the first application, and further obtain the metadata of the first application if the recovery instruction of the first application is obtained.

[0120] In some embodiments, the recovery command for the first application is used to instruct the first application to be restored to a runnable state.

[0121] For example, in some embodiments, the recovery instructions for the first application can be obtained through the recovery entry point of the first application. For instance, such as... Figure 10 As shown, when a user clicks the application icon of the archived application (the first application) (i.e., the recovery entry point of the first application), the operating system of the electronic device will trigger the recovery command of the first application.

[0122] In some embodiments, the recovery entry for the first application refers to an entry point created by the electronic device based on the metadata of the first application for restoring the archived first application. For example, the specific form of the recovery entry for the first application may be a desktop icon of the electronic device, a recovery option in system settings, or a recovery reminder in the notification center.

[0123] In some embodiments, when a user clicks the recovery entry of the first application, the recovery process can be triggered to re-download or decompress the application package and restore the data.

[0124] In some embodiments, the recovery entry of the first application should also support multiple recovery methods, such as directly restoring to the latest version or restoring to a specific version.

[0125] In some embodiments, the metadata of the first application refers to key information saved during the archiving process of the first application, such as the application package name, version number, signature information, etc., which is crucial for the correct download and installation of the application.

[0126] In some embodiments, by parsing user click events, it is confirmed that the user click events belong to the recovery behavior of the first application, and metadata related to the first application is read from local or remote storage. The metadata of the first application is typically generated and saved by the archiving service when the first application is archived, to ensure that the recovery process can accurately identify the target application and its configuration.

[0127] In embodiments of this application, when obtaining the metadata of the first application, the metadata of the first application is obtained from the local cache; or, an application package information list is obtained, and the metadata of the first application is determined based on the application package information list.

[0128] In some embodiments, the electronic device can directly retrieve the metadata of the first application from a local cache. Here, the local cache refers to a temporary storage area stored locally on the device for quick access to application-related metadata.

[0129] In some embodiments, after the recovery entry of the first application is constructed based on the metadata of the first application, the metadata of the first application can be stored in the local cache. Therefore, the electronic device can directly read the metadata of the first application from the local cache.

[0130] In some embodiments, local caching can be managed by the system framework layer. For example, PackageManagerService in Android maintains basic information about installed applications (such as version number, icon path, signature information, etc.). The metadata of the first application maintained by PackageManagerService can be directly accessed by PackageManagerService without re-parsing the APK file, thereby improving efficiency.

[0131] In some embodiments, the PackageInfo list is a data collection containing basic information about all installed applications in the system, typically provided by PackageManagerService. Each entry contains key fields such as the application's unique identifier (e.g., package name), version information, installation path, and signature hash value.

[0132] In some embodiments, the application package information list is not only used for internal system management, but can also serve as a source for external applications or services to obtain metadata of a specific application.

[0133] In some embodiments, the electronic device can search for information about a target application (first application) from an application package information list. The process of searching for information about the target application from the application package information list may involve traversing the entire list of installed applications to match a specified application name or package name.

[0134] In some embodiments, dynamically obtaining the metadata of the first application through the application package information list can support flexible adaptation under different device configurations and meet diverse terminal needs.

[0135] For example, in some embodiments, the metadata of the first application can be obtained by retrieving it from a local cache or by retrieving it from an application package information list, thereby ensuring that the metadata of the first application can be retrieved efficiently in various scenarios.

[0136] Step 902: Send a data packet request to the server of the first application based on the metadata of the first application.

[0137] In the embodiments of this application, when the recovery instruction of the first application is obtained based on the recovery entry of the first application, after obtaining the metadata of the first application, the electronic device can further send a data packet request to the server of the first application based on the metadata of the first application.

[0138] In some embodiments, after obtaining the metadata of the first application, the electronic device sends a data packet request to the corresponding application server based on information in the metadata, such as the application package name and signature hash, to obtain the complete version of the application package (APK). The data packet request typically includes verification information to ensure that the application package (APK) matches the current user's archived data and has a correct digital signature, thereby preventing malicious tampering or the installation of incompatible versions.

[0139] Step 903: Receive the application package of the first application sent by the server of the first application.

[0140] In embodiments of this application, after sending a data packet request to the server of the first application based on the metadata of the first application, the electronic device may further receive the application package of the first application sent by the server of the first application.

[0141] In some embodiments, the server receives a request from the client (electronic device), locates the corresponding APK file based on the identifier in the metadata of the first application, and then returns the APK file to the client.

[0142] In some embodiments, after receiving a server response from the first application, the electronic device downloads and caches the application package (APK) of the first application for subsequent installation and restoration operations.

[0143] In some embodiments, after the application package of the first application is downloaded, the electronic device performs an integrity check on the application package, such as by comparing hash values, to ensure that the application package has not been tampered with. If the check passes, the electronic device will proceed to the next step of the installation process; otherwise, the electronic device may prompt the user to try downloading again or check the network connection. This ensures that the APK file used during the recovery process is complete and secure, thereby avoiding installation failures due to corrupted or missing APK files, and thus ensuring the success rate and reliability of application recovery.

[0144] Step 904: Restore the first application by using the application package based on the first application at the application layer.

[0145] In the embodiments of this application, after receiving the application package of the first application sent by the server of the first application, the electronic device can further restore the first application based on the application package of the first application through the application layer.

[0146] In some embodiments, after the download of the application package (APK) of the first application is completed, the electronic device can use the previously acquired metadata of the first application and the currently downloaded APK file to perform a restore operation of the first application.

[0147] In some embodiments, the recovery operation of the first application includes installing the APK into the system and restoring the user data (such as settings, cache, database, etc.) retained during the archiving period to the storage directory of the first application, thereby restoring the first application to its state before archiving.

[0148] For example, in some embodiments, when performing a recovery operation, the electronic device can call the underlying PackageInstaller interface to start the installation process.

[0149] For example, in some embodiments, after installation is complete, the electronic device may notify the application layer to update the icon status of the first application, switching the icon status of the first application from the archived application icon to the installed application icon.

[0150] Therefore, in this application, the recovery command of the first application can be triggered first through user interaction behavior, then the first application can be located based on the metadata of the first application, then the corresponding application package can be requested from the server of the first application, and finally the recovery operation can be completed by combining the metadata of the first application and the APK.

[0151] For example, in some embodiments, after archiving the first application, the electronic device generates a shortcut with a cloud icon on the desktop. When the user clicks this icon, a recovery process is triggered. The electronic device re-downloads the complete APK of the first application based on the previously stored metadata and restores the user data to the original path. The electronic device detects the archiving status of the first application by calling the PackageManager.getArchivedPackages() API and broadcasts an update notification to the desktop icon status via PackageManager.EXTRA_ARCHIVAL_STATE. Furthermore, the electronic device can initiate the recovery process by calling PackageManagerSessionParams.setArchived(true).

[0152] This application proposes a data recovery method applied to an electronic device. The operating system of the electronic device includes an application layer and a framework layer. Upon receiving a recovery instruction for the first application through a recovery entry point, the method acquires the metadata of the first application; sends a data packet request to the server of the first application based on the metadata; receives the application package of the first application sent by the server; and recovers the first application through the application layer based on the application package. In other words, this application triggers the recovery process of the first application through a created recovery entry point. After obtaining the corresponding application package from the server based on the metadata of the first application, the recovery process of the first application is completed through the application layer. This allows for on-demand recovery of required content through the application layer, while ensuring that the application state after recovery is consistent with that before archiving. Therefore, this application can achieve complete archiving and recovery capabilities, meeting diverse scenario requirements and further improving the practicality and ease of use of archiving and recovery functions.

[0153] Based on the above embodiments, another embodiment of this application proposes a data archiving method and a data recovery method that can be implemented on older operating systems. Since users of older machines often have greater storage space issues, this solution is more valuable. It does not require developer involvement and is a capability provided by the application layer (such as a first-party software store).

[0154] In related technologies, application archiving is a technique that frees up storage space by removing the installation files of infrequently used applications while retaining their configuration, user data, and associated information. Its core logic involves compressing and packaging application files and deleting their original paths, while simultaneously recording the metadata needed for recovery. During recovery, the files are re-downloaded or decompressed based on this metadata, restoring the application to its state before archiving. For example, Windows 11 automatically downloads archived applications through the Microsoft Store, while the CleanSweep tool restores them with a single click using the .BUA format.

[0155] like Figure 11 As shown, the disk space occupied by an application after installation includes the space occupied by the application, data, and cache.

[0156] The application module consists of three parts, corresponding to different storage paths and functions: / data / app / : Stores the application's base.apk (application installation package); / data / dalvik-cache / : Stores a cache of dex files (an optimized cache of dex files by the Dalvik virtual machine); / data / data / : This directory contains the lib subdirectory (the application's .so library files).

[0157] The data module is divided into a "private sandbox directory" and an "SD card private directory": Private sandbox directory (9MB): The path is / data / data / , accessible only by the current application, and other applications do not have permission to access it; SD card private directory (18MB): The path is / sdcard / Android / data / , and access requires "Storage Management" permissions.

[0158] The cache module path is the cache subdirectory under / data / data / , which contains temporary files that can be cleaned up (such as the cache in the manager application can be cleaned up).

[0159] Application archiving can free up some application space. Before archiving, it occupies 366MB, and after archiving, the remaining data and cache occupy 27MB + 77MB = 104MB.

[0160] Application archiving solutions for the Android platform mainly fall into two categories: one is based on AAB (Android App Bundle) to generate a lightweight archive.apk, and the other is based on Android Package Archive to achieve system-level optimization. Both application archiving solutions for the Android platform can effectively reduce the application's footprint while ensuring the integrity and recoverability of user data. Specifically, the archive.apk is small in size (usually less than 100KB) and maintains version consistency and signature compatibility with the original APK, facilitating quick replacement and freeing up storage space.

[0161] However, some shortcomings still exist in these technologies. For example, some solutions rely on specific operating system versions or require developer cooperation to save archived states and maintain entry components. This design approach limits the versatility and applicability of some solutions. Furthermore, there are limitations in the display of archived icons, the design of the recovery process, and desktop adaptation, all of which affect the end-user experience.

[0162] To overcome the above problems and further improve the practicality and ease of use of the archiving function, this application proposes a data archiving method and a data recovery method, which can achieve efficient space release and has good cross-version compatibility, and can be completed without relying on developer participation.

[0163] The archiving and recovery methods proposed in this application can be implemented based on the operating system running in the electronic device. This application does not specifically limit the operating system running on the electronic device. For example, the operating system can be Android or an OS.

[0164] like Figure 12 As shown, the diagram illustrates the complete state change logic of an application from "Not Installed" to "Installed," "Activated," and "Archived," and then to "Restore Archive" or "Uninstall," through four core states: "Not Installed," "Installed," "Activated," and "Archived." Application archiving helps applications quickly return to an active state. For example, if an application is running (after startup), the "Archived" operation can lead to the "Archived" state (the application is archived, releasing storage space but retaining data); the application is then archived (the application itself is removed but data is retained), placing it in the "Pending Recovery" state. The "Restore Archive" operation returns it to the "Activated" state (the application resumes running).

[0165] The following description uses the Android platform (Android system) as an example to illustrate this application.

[0166] like Figure 13 As shown, the archiving method proposed in this application is implemented based on the application layer. Archiving can be triggered manually or automatically. For example, when a user decides to archive an application, an archiving request is triggered. The archiving request can come from an app store or other management interface. For automatic triggering, the automatic archiving switch status can be checked to determine if automatic archiving is enabled. If it is not enabled, archiving is not performed. If it is enabled, a scanning process is performed to check application usage records and further determine if there are any applications that have not been used for more than 30 days (a preset time period). If not, archiving is not performed. If it exists, it is further determined whether the application was installed from an app store. If so, the application is added to the list of applications to be archived so that the path can be automatically triggered in subsequent processes. After triggering archiving, it can first determine whether the application to be archived was installed from an app store. If not, archiving is not performed. If so, pre-archiving preparation is performed, such as caching the application's metadata and preparing necessary resources, such as temporary storage space. Then, the archiving operation is performed, for example, deleting the APK file but retaining the user data directory ( / data storage directory (data / data) / ). <package>During the archiving process, only a very small archive.apk is left to replace the original APK, thereby freeing up storage space. Finally, updating the archive record can also send status change notifications to relevant components, informing them that the application is now in an archived state.

[0167] In some embodiments, the archiving method proposed in this application can free up 60% of the storage space for infrequently used applications, can be moved to older operating systems, is more lightweight than uninstallation, and for periodically used applications, can be immediately restored to an active state after archiving without the need for a cumbersome login verification process.

[0168] like Figure 14 As shown, the archiving method proposed in this application can create an application archive recovery entry based on the application's metadata. In this process, the archived application information does not heavily rely on the local cache; if it is not present, the metadata is obtained from the store service. Specifically, a list of application package information (PackageInfo) for archived applications can be obtained first. Then, the PackageInfo list is filtered, and recoverable applications are marked; for unrecoverable applications, the creation of the archive recovery entry is skipped. Next, it is further determined whether the application's metadata exists in the local cache. If it exists, the application's metadata is directly obtained from the local cache; if it does not exist, the application's metadata can be further obtained from the server. For example, a query request can be actively initiated to the server of the first application, and the server returns the metadata of the adapted application. After obtaining the application's metadata by initiating a query to the server, the application's metadata can be further stored in the local cache. Finally, an application archive recovery entry can be created based on the obtained application metadata. This recovery entry can provide archive recovery and uninstallation functions. Similar to normal application uninstallation, silent uninstallation of "data-only" applications is supported.

[0169] like Figure 15 As shown, the application archive recovery entry point is only available when creating metadata. This recovery entry point can be displayed in any way, such as displaying a desktop card on the desktop to indicate to the user that the archived application has completed the archiving process.

[0170] like Figure 16 As shown, the data recovery method proposed in this application is implemented at the application layer. When performing archived application recovery processing, archived recovery can be triggered through a displayed recovery entry point or by residual data prompts from the file manager. For example, when a user wants to recover an archived application, they can trigger a recovery request by clicking the archive icon on the desktop. After clicking the archive icon, a recovery request will be triggered, preparing to start the recovery process. The application layer obtains the metadata of the application to be recovered from the local cache, or it can obtain the metadata of the application to be recovered by querying the application package information list (PackageInfo list). Based on the application's metadata, a data packet request is sent to the corresponding server to obtain the application package of the application from the server. The server, after completing the matching judgment of package name and signature, can search for application packages that meet the matching conditions of package name and signature based on a version matching strategy. After downloading the application package, the application layer can install the application, thereby realizing the archived application recovery processing. For example, after the recovery request is accepted, a recovery session is created to manage various activities throughout the recovery process. Once the session is successfully restored, the installation process will automatically begin, attempting to re-download or extract the required full APK file based on previously saved information. As the installation progresses, the new APK will be installed, and previously saved user data will be restored to the corresponding system directory. After both installation and data restoration are successfully completed, the application's status will be updated accordingly, confirming that the application has transitioned from an archived state back to a normal operating state. Finally, the application's regular icon will be updated and displayed on the desktop, indicating that the application is now active and ready to use.

[0171] In summary, the beneficial effects of the archiving and recovery methods proposed in this application include, but are not limited to: freeing up to 60% of the storage space occupied by infrequently used applications; enabling migration to older operating systems; the value of this solution is more significant because users of older devices typically face greater storage space issues; compared to direct uninstallation methods, the current method is more lightweight, and the operation module reduces the user's decision-making cost; for periodically used applications, after completing the archiving operation, periodically used applications can be immediately restored to an active state without needing to perform a cumbersome login verification process for periodically used applications.

[0172] In other words, the archiving and recovery methods proposed in this application can run on older operating systems (such as older OS systems); since older mobile phone users usually face greater storage space limitations, the archiving and recovery methods proposed in this application have higher application value compared to other solutions; at the same time, an automatic update function is directly provided by the official platform of the software store, and this automatic update function is a first-party capability provided by the software store, so developers do not need to participate in the installation and configuration process.

[0173] The archiving and recovery methods proposed in this application can also be extended to multiple fields, such as being used as uninstallation retention solutions, quick activation solutions, or to completely release the space occupied by the application by uploading application data to the cloud.

[0174] In summary, the archiving and recovery methods proposed in this application not only solve many problems existing in traditional application archiving methods, but also provide more flexible and efficient solutions. The solutions provided by the archiving and recovery methods proposed in this application are applicable to various needs in different scenarios.

[0175] This application proposes a data archiving method and a data recovery method. The application layer determines and stores the metadata of a first application, ensuring that critical information is retained after archiving to support recovery operations. Simultaneously, the archiving process of the first application is executed through calls from the application layer to the framework layer, avoiding direct reliance on system versions or developer implementations, thus improving the compatibility and versatility of the solution. Furthermore, creating a recovery entry point based on metadata ensures convenient triggering of the recovery process subsequently. On the other hand, the recovery process of the first application is triggered through the created recovery entry point. After obtaining the corresponding application package from the server based on the first application's metadata, the recovery process of the first application is completed through the application layer. This allows for on-demand recovery of required content through the application layer, while ensuring that the application state after recovery is consistent with that before archiving. Therefore, this application can achieve complete archiving and recovery capabilities, meeting diverse scenario requirements and further improving the practicality and ease of use of archiving and recovery functions.

[0176] Based on the above embodiments, in another embodiment of this application... Figure 17 This is a schematic diagram of the composition structure of the data archiving device proposed in the embodiments of this application, as shown below. Figure 17 As shown, the data archiving apparatus 110 proposed in this application embodiment may include: The determining unit 1101 is used to determine the metadata of the first application and store the metadata of the first application; The archiving unit 1102 is used for archiving the first application; The creation unit 1103 is used to create a recovery entry for the first application based on the metadata of the first application; wherein the recovery entry for the first application is used to restore the first application.

[0177] Figure 18 This is a schematic diagram of the composition of the data recovery device proposed in the embodiments of this application, as shown below. Figure 18 As shown, the data recovery apparatus 210 proposed in this application embodiment may include: The acquisition unit 2101 is used to acquire the metadata of the first application when the recovery instruction of the first application is obtained based on the recovery entry of the first application; Sending unit 2102 is used to send a data packet request to the server of the first application based on the metadata of the first application; The receiving unit 2103 is used to receive the application package of the first application sent by the server of the first application; Recovery unit 2104 is used to restore the first application based on the application package of the first application.

[0178] In the embodiments of this application, further, Figure 19 This is a schematic diagram of the composition structure of the electronic device proposed in the embodiments of this application, such as... Figure 19 As shown, the electronic device 120 proposed in this application embodiment may include a processor 1201, a memory 1202, a communication interface 1203, and a bus 1204 for connecting the processor 1201, the memory 1202 and the communication interface 1203.

[0179] In the embodiments of this application, the processor 1201 can be at least one of the following: Application-Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field-Programmable Gate Array (FPGA), Central Processing Unit (CPU), Controller, Microcontroller, and Microprocessor. It is understood that for different devices, the electronic device used to implement the above-mentioned processor function can also be other, and this application embodiment does not specifically limit it. The electronic device 120 may also include a memory 1202, which can be connected to the processor 1201. The memory 1202 is used to store executable program code, which includes computer operation instructions. The memory 1202 may include high-speed RAM memory and may also include non-volatile memory, such as at least two disk drives.

[0180] In embodiments of this application, bus 1204 is used to connect communication interface 1203, processor 1201, and memory 1202, as well as the mutual communication between these devices.

[0181] In practical applications, the aforementioned memory 1202 can be volatile memory, such as random-access memory (RAM); or non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); or a combination of the above types of memory, and provide instructions and data to the processor 1201.

[0182] For example, in an embodiment of this application, processor 1201 is configured to determine the metadata of a first application through the application layer and store the metadata of the first application through the application layer; to perform archiving processing on the first application by calling the framework layer through the application layer; and to create a recovery entry for the first application based on the metadata of the first application; wherein the recovery entry for the first application is used to restore the first application.

[0183] For example, in an embodiment of this application, the processor 1201 is configured to: obtain the metadata of the first application when a recovery instruction for the first application is obtained based on the recovery entry of the first application; send a data packet request to the server of the first application based on the metadata of the first application; receive the application package of the first application sent by the server of the first application; and restore the first application based on the application package of the first application through the application layer.

[0184] Furthermore, in this embodiment, the functional modules can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional module.

[0185] If the integrated unit is implemented as a software functional module and is not sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this embodiment, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the method of this embodiment. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0186] This application provides a computer-readable storage medium storing a program thereon, which, when executed by a processor, implements the archiving method and the recovery method as described above.

[0187] Specifically, the program instructions corresponding to a data archiving method in this embodiment can be stored on storage media such as optical discs, hard disks, and USB flash drives. When the program instructions corresponding to a data archiving method in the storage media are read or executed by an electronic device, the following steps are included: The metadata of the first application is determined by the application layer and stored by the application layer; the first application is archived by calling the framework layer through the application layer; a recovery entry for the first application is created based on the metadata of the first application; wherein, the recovery entry for the first application is used to restore the first application.

[0188] Specifically, the program instructions corresponding to a data recovery method in this embodiment can be stored on storage media such as optical discs, hard disks, and USB flash drives. When the program instructions corresponding to a data recovery method in the storage media are read or executed by an electronic device, the following steps are included: If the recovery instruction of the first application is obtained through the recovery entry of the first application, the metadata of the first application is obtained; a data packet request is sent to the server of the first application based on the metadata of the first application; the application package of the first application sent by the server of the first application is received; and the first application is restored through the application layer based on the application package of the first application.

[0189] This application also provides a computer program product.

[0190] In some embodiments, the computer program product may include a computer program or instructions.

[0191] In some embodiments, the computer program product can be applied to the computer device in the embodiments of this application, and the computer program instructions cause the computer to execute the corresponding processes implemented by the computer device in the various methods of the embodiments of this application. For the sake of brevity, they will not be described in detail here.

[0192] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of hardware embodiments, software embodiments, or embodiments combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

[0193] This application is described with reference to schematic and / or block diagrams of implementations of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the schematic and / or block diagrams can be implemented by computer program instructions, and combinations of blocks in the schematic and / or block diagrams can be implemented. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the schematic and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0194] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in the implementation flow diagram. Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0195] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0196] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application.< / package> < / package> < / package>

Claims

1. A data archiving method, characterized in that, The method is applied to an electronic device, the operating system of which includes an application layer and a framework layer, and the method includes: The metadata of the first application is determined through the application layer, and the metadata of the first application is stored through the application layer. The first application is archived by calling the framework layer through the application layer; A recovery entry for the first application is created based on the metadata of the first application; wherein, the recovery entry for the first application is used to restore the first application.

2. The method according to claim 1, characterized in that, The operating system also includes an application programming interface (API) corresponding to the framework layer; the step of calling the framework layer through the application layer to perform archiving processing on the first application includes: The application layer calls the application interface to perform the archiving process of the first application through the framework layer.

3. The method according to claim 1, wherein, The method further includes: If an archiving instruction for the first application is received and the first application belongs to the application layer, it is determined that the first application should be archived.

4. The method according to any one of claims 1-3, wherein, The method further includes: If the first application meets the automatic archiving conditions and the first application belongs to the application layer, the first application is determined to be archived. in, The automatic archiving conditions include at least one or more of the following: The automatic archiving function of the first application is enabled; The first application was not used within the preset time period; The first application belongs to the application layer.

5. The method according to any one of claims 1-3, characterized in that, Before creating the recovery entry for the first application based on its metadata, the method further includes: If the metadata of the first application exists in the local cache, retrieve the metadata of the first application from the local cache; or, If the metadata of the first application does not exist in the local cache, a query request is sent to the server of the first application, and the metadata of the first application sent by the server of the first application is received.

6. The method according to any one of claims 1-3, characterized in that, The method further includes: The recovery entry for the first application is displayed based on a preset method; wherein the preset method includes at least one or more of the following: desktop shortcut; desktop card.

7. A data recovery method, characterized in that, The method is applied to an electronic device, the operating system of which includes an application layer and a framework layer, and the method includes: If the recovery instructions of the first application are obtained through the recovery entry of the first application, the metadata of the first application is obtained; Send a data packet request to the server of the first application based on the metadata of the first application; Receive the application package of the first application sent by the server of the first application; The application layer restores the first application based on the application package of the first application.

8. The method according to claim 7, characterized in that, Obtain the metadata of the first application, including: Retrieve the metadata of the first application from the local cache; or, Obtain a list of application package information and determine the metadata of the first application based on the list of application package information.

9. An electronic device, characterized in that, The electronic device includes a processor and a memory storing processor-executable instructions, which, when executed by the processor, implement the method as described in any one of claims 1-6 or 7-8.

10. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or the instructions are executed by the processor, the method of any one of claims 1-6 or 7-8 is implemented.

Images