Method, apparatus for data recovery

Abstract

The application provides a data recovery method and device, which are used in the technical field of computers. The method comprises the following steps: determining first data, wherein the first data is application data when an application program is normally running; saving the first data to a handle record, wherein the handle record is managed by using a reference counting mechanism; obtaining the handle record when the application program is abnormally restarted; and restoring the application program to a state before the abnormality according to the handle record. By the method, the application data when the application program is normally running is persistently saved, and the application program is restored after the abnormal restart, so that the state and the data of the application program are consistent with those before the abnormal restart, and the user experience is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to methods for data recovery. Background Technology

[0002] The Android operating system, due to its open-source nature, has been widely adopted in various smart devices such as mobile phones, tablets, and wearable devices. As the Android system becomes increasingly popular, the number of its applications has grown year after year, with application development emerging in endless streams. Applications are subject to many uncertainties during operation, such as crashes, user deletion, or varying degrees of control by different Android derivative systems. Because volatile memory data used in Android processes, such as PenningIntent and IBinder, cannot be serialized for persistent storage, applications cannot be restored to their state before the exception occurred after a restart. This imposes significant limitations on Android application developers and negatively impacts the user experience.

[0003] To solve this problem, existing technologies mainly offer several solutions:

[0004] 1) At the system level, information related to the currently running application is parsed and extracted, serialized into a byte stream, and then stored in the database. However, this approach requires modification to the system-level code and lacks versatility.

[0005] 2) Monitor the target application process and store the stack information when it encounters an error locally. When an error occurs, restore the state based on the saved stack information. However, since stack information generally records information related to the process's running state and does not record data within the process, the restoration can only guarantee the restoration of the process and cannot guarantee the restoration of all data within the application, including volatile data in memory.

[0006] 3) This method provides an interactive keep-alive mechanism between parent and child processes, periodically sending keep-alive messages to the main process via pipe communication. This ensures that if one process crashes unexpectedly, the other can be quickly restarted and restored. However, this method only solves the recovery after one process terminates and cannot recover data when two processes terminate simultaneously. This method also increases communication costs, and the data recovery success rate is affected by the communication success rate.

[0007] Therefore, how to recover volatile memory data so that the process and application data can remain consistent with the state before the anomaly occurred after an Android application restarts due to an anomaly has become an urgent problem to be solved. Summary of the Invention

[0008] This application provides a data recovery method and apparatus, applied in the field of computer technology, to solve the following problems:

[0009] This feature enables data recovery in the event of an abnormal restart of an Android application, thereby improving the reliability of Android applications and enhancing the user experience.

[0010] In a first aspect, embodiments of this application provide a data recovery method, the method comprising: determining first data, wherein the first data is application data when an application is running normally; saving the first data to a handle record, wherein the handle record is managed using a reference counting mechanism; and when the application restarts abnormally, obtaining the handle record and restoring the application to its state before the abnormality based on the handle record.

[0011] Specifically, the first data can be defined by the application developer. This first data can be memory-volatile data or data that the application developer deems necessary to save. When the application restarts abnormally, this data can be used to generate the data needed to restore the application to its pre-abnormal state. After the first data is saved to a handle record, it is managed using reference counting. In this case, as long as the handle record is referenced, it will not be released by the system, thus persistently saving the first data. After the application restarts abnormally, it can be restored based on the saved first data, restoring its processes and application data to a state consistent with that before the abnormal restart.

[0012] Compared to existing technologies, this method is simpler, requires no modification to system-level code, has no restrictions on the data types saved (not limited to stack data), and eliminates the need for additional keep-alive processes, thus reducing communication costs. This method persistently saves application data during normal operation and restores the application after an abnormal restart, ensuring its state and data remain consistent with before the restart, thereby improving user experience.

[0013] In one possible implementation, the first data is memory-volatile data that cannot be serialized and saved to an external storage device.

[0014] Specifically, the memory volatile data can be context data of the intent to be triggered, remote object interface data, file descriptors, etc.

[0015] In one possible implementation, the handle record is managed using a reference counting mechanism, including referencing the handle record through a first system interface.

[0016] In one possible implementation, the handle record can be referenced through a first system interface by setting a timed task for the handle record, which may include a one-time task or a periodic task.

[0017] Specifically, the first system interface could be an alarm manager (AlarmManager) within the system components. Setting an extremely long alarm through the AlarmManager aims to prevent the scheduled task from being triggered, or setting a periodic alarm ensures that the handle record is always referenced and not released. It is understandable that the task scheduler (JobScheduler) within the system components could also achieve the same functionality as the AlarmManager.

[0018] In one possible implementation, the handle record can be referenced through a first system interface by setting trigger conditions for the handle record.

[0019] Specifically, the first system interface can be a task scheduler (JobScheduler) within the system components. The JobScheduler can trigger task execution by setting trigger conditions, such as low battery or the terminal device accessing the network. In this embodiment, handle records can be held by setting conditions that prevent triggering, such as excessively long duration, network outage, or sleep mode.

[0020] In one possible implementation, the handle record can also be referenced through a first system interface to set a notification task, which includes a persistent notification or a non-persistent notification.

[0021] Specifically, the first system interface can be the NotificationManager in the system component, through which notification tasks are set. After setting a notification task, a message will be displayed in the status bar. A persistent notification means that the notification will not disappear after an operation in the notification bar; a non-persistent notification means that the notification will automatically disappear after being clicked. It is understandable that persistent notifications allow for the long-term holding of the notification handle record, while non-persistent notifications may release the handle record after the notification event is triggered.

[0022] Specifically, the handle record mentioned above can be an intent object to be triggered in the system. It is understood that the handle record can also be other resources in the system that can be referenced, and this application does not impose any restrictions.

[0023] It should be noted that the handle record can also be referenced by other methods in the embodiments of this application, and this application does not impose any restrictions.

[0024] By referencing the handle record through the first system interface, the handle record can be prevented from being released by the system, thereby achieving the purpose of persistently storing volatile data in memory.

[0025] In one possible implementation, saving the first data as a handle record during the saving process includes storing the first data in hierarchical buckets.

[0026] Specifically, during the process of saving the first data, it will be stored hierarchically and in buckets through the second system interface. The capacity of each bucket is fixed. If a bucket is full during storage, a new bucket will be generated. Whenever new data needs to be added, all existing buckets will be iterated to see if there is enough space to store the new data. If so, the data will be stored in the bucket with space. Otherwise, a new bucket will be created, and the new data will be stored in this new bucket.

[0027] By using buckets for storage, storage space can be fully utilized. On the other hand, since application data changes during application operation and needs to be updated, when updating data, only the bucket containing the data to be updated needs to be found and the corresponding data is updated. There is no need to update all data, which reduces the amount of data to be updated and also reduces the impact of update failure, thereby improving the reliability of data updates.

[0028] It should be noted that the bucket capacity can also be unlimited, with all data related to the handle record stored in a single bucket. Compared to multiple buckets, this method requires updating all data in the entire bucket during updates, resulting in a larger volume of data being updated and a wider impact from update failures.

[0029] In one possible implementation, storing the first data in hierarchical buckets includes:

[0030] A bucket mapping table is established, which includes a correspondence between at least one key and at least one bucket address. The key is a unique identifier of a piece of the first data, and the bucket address is a variable pointing to the storage location of the first data. The bucket mapping table is used to find the storage location of the first data in the bucket according to the key when the data is updated or deleted.

[0031] In one possible implementation, the bucket addressing can be a bucket number, which is the number of a bucket assigned to a piece of the first data.

[0032] In another possible implementation, the bucket addressing can also be a combination of a bucket number and a bucket key value, wherein the bucket number is the number of a bucket assigned to a piece of the first data, and the bucket key value is the position of a piece of the first data within a bucket.

[0033] Understandably, establishing a bucketing mapping table allows for accurate location of the data to be updated during subsequent data updates, improving update efficiency. If bucketing addressing includes the bucket number and its key value, a linear search is unnecessary, further enhancing efficiency.

[0034] In one possible implementation, the hierarchical bucketing of the first data further includes updating the bucketing mapping table after each new data is added. The bucketing mapping table can be located at the top layer of the hierarchically bucketed storage of the first data, or it can be stored in other spaces within the system.

[0035] Specifically, when storing data, the system will determine whether a top-level bucket exists. The top-level bucket can be predefined by the system during its generation. If a top-level bucket already exists, after storing the first data in the second-level bucket, the second-level bucket is stored into the top-level bucket via the second system interface, and the bucket mapping table is updated. If a top-level bucket does not exist, it is created, and after storing the first data, the second-level bucket is stored into the top-level bucket via the second system interface, and the bucket mapping table is updated.

[0036] Understandably, to improve storage space utilization, when storing the first data into the second-level bucket, it is possible to first iterate through the existing buckets to see if there is enough space to store the first data. If there is, the first data is stored in the bucket with space; otherwise, a new second-level bucket is generated for storage.

[0037] Understandably, during the data storage process, three or more layers of bucket storage can be used depending on factors such as the size of the data.

[0038] In one possible implementation, referencing the handle record via the first system interface includes referencing the top layer of the first data stored in a hierarchical bucketed manner via the first system interface.

[0039] Specifically, when referencing a handle record, the first system interface can prevent the top layer of the hierarchical bucketed storage from being released by referencing the top layer of the first data. Furthermore, by accessing the second-level buckets stored in the top-level bucket, the data stored in each bucket can be found, thus achieving the effect of referencing the entire handle record.

[0040] In one possible implementation, embodiments of this application further include updating or deleting the first data according to the bucket mapping table when the application is running normally, so that the first data is consistent with the application data of the latest running state of the application.

[0041] By updating and deleting the initial data, it is possible to ensure that the stored initial data remains consistent with the real-time state of the application, thereby ensuring that the application can be restored to the latest state in the event of an abnormal restart.

[0042] In one possible implementation, when the application restarts abnormally, the handle record is obtained, and the application is restored to its state before the abnormality based on the handle record. This includes obtaining the handle record of the application through a second system interface based on the application identifier, where the application identifier is a unique identifier for the application; parsing the handle record and restoring the data in the obtained handle record to the application.

[0043] It should be noted that there is a one-to-one correspondence between the application identifier and the application handle record. During the recovery of the first data, the application handle record can be found based on the application identifier, and then the data can be recovered layer by layer. Specifically, the top layer of the handle record is parsed first to obtain the second-level buckets storing the first data. The second-level buckets are then parsed to find the entity object storing the first data, and then the data is recovered layer by layer to complete the entire recovery process.

[0044] Specifically, the second system interface can be interface methods such as getBroadcast, getService, or getActivity. It is understood that the second system interface can also be other interface methods capable of obtaining handle records.

[0045] It should be noted that during data storage, three or more levels of bucketing can be used depending on factors such as the data volume. Correspondingly, during recovery, it is necessary to resolve these three or more levels of buckets for recovery.

[0046] This method allows the application to be restored to its pre-abnormal state after an abnormal restart, improving the user experience.

[0047] Secondly, in conjunction with the method provided in this application, embodiments of this application also provide a data recovery apparatus, which has the functionality to implement any of the methods provided in the first aspect. These functions can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above functions. The apparatus can exist in the form of a chip product. Specifically, the data recovery apparatus can be a terminal or a functional module fixed or removable on the terminal.

[0048] Thirdly, embodiments of this application provide a terminal, characterized in that the computer device includes a processor and a memory, the memory being used to store software programs, and the processor being used to read the software programs stored in the memory and execute the method provided in any implementation of the first aspect.

[0049] Fourthly, embodiments of this application provide a storage medium, characterized in that it includes a computer program, which, when run on one or more processors, is used to implement the method provided in any implementation of the first aspect.

[0050] Fifthly, embodiments of this application provide a computer program product, characterized in that it includes a computer program, which, when run on one or more processors, is used to implement the method provided in any of the implementations of the first aspect.

[0051] The technical effects of any of the design methods in aspects two through five can be found in the technical effects of different design methods in aspect one, and will not be repeated here. Attached Figure Description

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

[0053] Figure 1 This is a schematic diagram of the structure of the terminal device used in the embodiments of this application;

[0054] Figure 2 This is a schematic diagram of the architecture of the Android system provided in the embodiments of this application;

[0055] Figure 3 A flowchart illustrating a data recovery method provided in an embodiment of this application;

[0056] Figure 4 A schematic diagram illustrating the relationship between PendingIntent, Intent, and PendingIntentRecord provided for embodiments of this application;

[0057] Figure 5 A schematic diagram of the hierarchical storage process provided in an embodiment of this application;

[0058] Figure 6 This is a schematic diagram illustrating the effect of hierarchical storage provided in an embodiment of this application;

[0059] Figure 7 A schematic diagram illustrating the process of application recovery based on hierarchically stored data, provided as an embodiment of this application;

[0060] Figure 8A schematic diagram illustrating the process of using AlarmManager to set an alarm holding PendingIntent for data recovery, as provided in this embodiment of the application;

[0061] Figure 9 A schematic diagram illustrating the process of data recovery using JobScheduler holding PendingIntent, provided for embodiments of this application;

[0062] Figure 10 A schematic diagram illustrating the process of using NotificationManager to set up a notification holder for PendingIntent for data recovery, as provided in this embodiment of the application;

[0063] Figure 11 A schematic diagram of a data recovery device provided in an embodiment of this application. Detailed Implementation

[0064] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0065] In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more. The term "and / or" or the character " / " in this application is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or, or A / B, can represent: A existing alone, A and B existing simultaneously, and B existing alone.

[0066] The following explanations of some terms used in this application are provided to facilitate understanding by those skilled in the art.

[0067] 1) Memory-volatile data: This refers to data that is difficult to persist to external storage through serialization within the system, such as PendingIntent, IBinder, and WakeLock objects in the Android system. The memory-volatile data mentioned in this application can also be other data that the developer determines needs to be saved. This data can be used to restore the application to its state and data before an abnormal restart.

[0068] 2) Bucketing: Data is stored in different buckets by using keywords, thus achieving data classification and bucketing storage.

[0069] 3) ActivityManagerService: The most important core service in Android, abbreviated as AMS, is mainly responsible for the startup, switching, scheduling, and application process management and scheduling of the four major components in the system: Activities, Services, Broadcast Receivers, and Content Providers. Its responsibilities are similar to the process management and scheduling module in the operating system. It is created when SystemServer executes the run() method and runs in an independent process.

[0070] 4) Reference counting is a memory management technique in computer programming languages. It refers to the process of keeping track of the number of times a resource (which can be an object, memory, or disk space, etc.) is referenced, and releasing it when the reference count becomes zero. Reference counting can be used to achieve automatic resource management. Reference counting can also refer to garbage collection algorithms that use reference counting to reclaim unused resources.

[0071] In the following description, PenningIntent is a specific form of the aforementioned bucketing. The data recovery process will be illustrated using an example of volatile memory data as the primary data source.

[0072] This application provides a data recovery method that can be applied to a terminal device. The terminal device can also be called a User Equipment (UE), Mobile Station (MS), Mobile Terminal, etc. Optionally, the terminal may have the ability to communicate with one or more core networks via a Radio Access Network (RAN). For example, the terminal may be a mobile phone (or "cellular" phone), or a mobile computer, etc. For example, the terminal may also be a portable, pocket-sized, handheld, computer-embedded, or vehicle-mounted mobile device.

[0073] Figure 1 A schematic diagram of the terminal device is shown. (For example...) Figure 1As shown, the terminal device 100 includes a memory 180, a processor 150, and a display device 140. The memory 180 stores computer programs, including an operating system program 182 and application programs 181, etc. The processor 150 is used to read the computer programs from the memory 180 and then execute the methods defined by the computer programs. For example, the processor 150 reads the operating system program 182 to run the operating system and implement various functions of the operating system on the terminal device 100, or reads one or more application programs 181 to run applications on the terminal device.

[0074] Processor 150 may include one or more processors. For example, processor 150 may include one or more central processing units (CPUs), or it may include one CPU and one graphics processing unit (GPU). When processor 150 includes multiple processors, these processors may be integrated on the same chip or may be separate chips. A processor may include one or more processing cores.

[0075] In addition, memory 180 also stores other data 183 besides computer programs. Other data 183 may include data generated after the operating system 182 or application 181 is run. This data includes system data (such as the configuration parameters of the operating system) and user data, such as the data cached by the application opened by the user, which is typical user data.

[0076] Memory typically includes main memory and secondary storage. Main memory can be random access memory (RAM), read-only memory (ROM), and cache, etc. Secondary storage can be hard disks, optical discs, USB drives, floppy disks, flash memory, or magnetic tape drives, etc. Computer programs are usually stored on secondary storage, and the processor loads the computer program from secondary storage into main memory before executing it.

[0077] The operating system program 182 includes a computer program that can implement the data recovery method provided in the embodiments of this application, so that after the processor 150 reads the operating system program 182 and runs the operating system, the operating system can have the function of restoring the application to the state before the abnormal restart provided in the embodiments of this application.

[0078] The terminal device 100 may also include an input device 130 for receiving input digital information, character information, or contact touch operations / non-contact gestures, as well as generating signal inputs related to user settings and function control of the terminal device 100.

[0079] The terminal device 100 may further include a display device 140, which includes a display panel 141 for displaying information input by the user or information provided to the user, as well as various menu interfaces of the terminal device 100. In some other embodiments, a touch panel 131 may cover the display panel 141 to form a touch display screen.

[0080] In addition to the above, the terminal device 100 may also include a power supply 190 for powering other modules and a camera 160 for taking photos or videos. The terminal device 100 may also include one or more sensors 120, such as an accelerometer, a light sensor, etc. The terminal device 100 may also include a radio frequency (RF) circuit 110 for network communication with wireless network devices, and may also include a WiFi module 170 for WiFi communication with other devices.

[0081] This application Figure 1 The software system of the terminal device shown can adopt a layered architecture. This application uses the Android operating system as an example to illustrate the software system of the terminal device.

[0082] like Figure 2 The diagram shown is an architectural schematic of the Android system provided in an embodiment of this application. This computer system 200 can be installed on a terminal device or other types of computer devices.

[0083] The Android system includes an application layer 210, an application framework layer 220, a system runtime library layer 230, a Linux operating system kernel layer 240, and a hardware layer 250.

[0084] The application layer 210 may include one or more applications, such as camera, SMS, contacts, and third-party applications. Third-party applications may include WeChat, maps, navigation, music, etc.

[0085] The application framework layer 220 may include an Activity Manager, an Alarm Manager, a JobScheduler, and a Notification Manager. The application framework layer 220 provides developers with the application programming interfaces (APIs) needed to develop applications, supporting developers in replacing or adding applications based on the APIs.

[0086] The system runtime library layer 230 may include interface management 231, multimedia library 232, etc.

[0087] The Linux operating system kernel layer 240 provides the core and management of the operating system, including memory management 241, storage device drivers 242, etc.

[0088] Hardware layer 250 may include memory 251 and storage device 252 (equivalent to...) Figure 1 (such as the memory 180 in the memory).

[0089] The following describes the workflow of the software and hardware of the terminal device in conjunction with the data recovery method of the embodiments of this application.

[0090] like Figure 3 The diagram shown is a flowchart illustrating a data recovery method provided in an embodiment of this application. The method includes:

[0091] 301. Determine the first data, which is the application data during normal operation of the application;

[0092] 302. Save the first data to a handle record, wherein the handle record is managed using a reference counting mechanism;

[0093] 303. When the application restarts abnormally, obtain the handle record and restore the application to the state before the abnormality based on the handle record.

[0094] The method provided in this application will be described below using the example of saving volatile memory data to an Intent data structure. It is understood that the volatile memory data is one type of data among the first types of data.

[0095] In the Android system, the PendingIntentRecord stored in AMS exists using reference counting; as long as this object is referenced, it will not be cleaned up. Based on this principle, this application describes a method for using the Intent in the PendingIntent to carry volatile memory data and storing it in the Android system process memory, and for restoring the process based on the saved volatile memory data.

[0096] Before introducing the specific process, let's first explain the relationship between PenningIntent, Intent, and PenningIntentRecord. For example... Figure 4 The diagram shown illustrates the relationship between PendingIntent, Intent, and PendingIntentRecord provided in this embodiment of the application.

[0097] An intent is a desired action or action that is to be performed immediately. An intent is a message object used to pass requests for actions from other application components. Data can also be carried within an intent via the `extra` directive.

[0098] A piercingIntent is a description of an Intent, a mechanism for asynchronously triggering an Intent. It does not execute a certain behavior immediately, but only executes the specified behavior after certain conditions are met or certain events are triggered.

[0099] Intent and PendingIntent are only paired, not aggregated. Intent is cached in AMS. After the triggering semantics of PendingIntent are passed to AMS, AMS attempts to find several intents corresponding to this PendingIntent and deliver them.

[0100] PendingIntentRecord is the corresponding entity object of PendingIntent in AMS, and PendingIntent is a reference to PendingIntentRecord.

[0101] The following section will describe the process of saving volatile data in memory during application execution.

[0102] When developing third-party applications, developers determine the primary data that needs to be saved. This data can be volatile or other data that can be regenerated to recover the information. The following explanation uses volatile memory data as an example.

[0103] During application execution, volatile memory data that needs to be saved in the process can be written into a transmissible data carrier. For example, the data that needs to be saved can be written into the Intent data structure in the Android operating system through putExtra.

[0104] Understandably, due to the size limitations of data transfer in Android operating systems for system interface calls, hierarchical and bucketed storage can be used during the saving process. The following will illustrate the process of this application using a two-layer PendingIntent structure as an example:

[0105] Top-level PendingIntent: The top-level PendingIntent is used to manage the second-level PendingIntent nodes. After the data storage is completed, all the second-level PendingIntents need to be stored in the top-level PendingIntent's Intent.

[0106] It should be noted that during the process of storing the top-level PendingIntent, the number of PendingIntents may or may not be stored, and this application embodiment does not impose any restrictions.

[0107] The second layer, PendingIntent, stores the primary data, especially volatile data in memory.

[0108] It should be noted that, in the actual process of saving data, a three- or more-layered PendingIntent structure can be used for storage, depending on factors such as the size of the data.

[0109] A flowchart illustrating the tiered storage process of Pend ingIn ntent is shown below. Figure 5 As shown.

[0110] Please refer to Figure 5 The following is a schematic diagram of the specific process of step S302 in the data recovery method provided in this application embodiment, in which the first data is saved to a handle record, and the handle record is managed using a reference counting mechanism. The process includes the following steps:

[0111] Step S501: Query whether a top-level Pending Intent exists.

[0112] If so, then execute S503;

[0113] If not, then execute S502;

[0114] Step S502: Generate a top-level PendingIntent, then continue to step S503;

[0115] Before saving volatile data in memory, the system determines whether a top-level PendingIntent exists. For example, a PendingIntent can be defined using TOP_LEVEL. In this application, the PendingIntent with number 0 will be used as the top-level PendingIntent. If no top-level PendingIntent exists, a PendingIntent with number 0 is generated, and the process of saving the data in the second-level PendingIntent continues. It is understood that the number of the top-level PendingIntent can also be other numbers defined by TOP_LEVEL; 0 here is merely an example number.

[0116] Step S503: Check if there is space in all existing second-level Pending Intents to store the data to be saved.

[0117] If so, proceed to step S506;

[0118] If not, proceed to step S504;

[0119] Step S504: Generate a new PendingIntent, and continue to step S505;

[0120] The amount of data that each PenningIntent can store is determined by the system. During the process of storing volatile memory data into the PenningIntent, a PenningIntent is first generated, numbered 1 for ease of understanding. If PenningIntent number 1 is full, and there is still volatile memory data to be stored, then another PenningIntent is generated, numbered 2, and the storage continues, until all the volatile memory data to be stored is stored.

[0121] Whenever new memory-volatile data needs to be stored, first iterate through the current k PendingIntents (numbered 1-k) to see if there is enough space to store the new memory-volatile data. If there is, store the memory-volatile data in the PendingIntent with available space. Otherwise, create a new PendingIntent and number it k+1, then store the new memory-volatile data in the Intent of this PendingIntent.

[0122] It is understood that the numbers 1 and 2 mentioned above are merely illustrative and do not necessarily indicate that the actual implementation will follow an ascending order starting from number 1. During implementation, the PenningIntent can be numbered using RequestCode.

[0123] Step S505: Through the second system interface, such as getBroadcast, getService, getActivity, store the newly added PendingIntent into the Intent of the top-level PendingIntent, update the bucket mapping table, and continue to step S506.

[0124] Step S506: Write the data to be saved into the Intent corresponding to the PendingIntent using PutExtra.

[0125] This process is now complete.

[0126] In this step, after each storage operation, the number of second-level PendingIntents and PendingIntents needs to be stored in the top-level PendingIntent's Intent, i.e., the PendingIntent with the number 0 mentioned above. If the number of the top-level PendingIntent is a random value, the specific value of the number is stored using RequestCode. It can be understood that a specific bucket, i.e., a specific PendingIntent, can be found based on the RequestCode. During the storage process, the system creates a bucket mapping table, which represents the correspondence between the key of at least one memory-volatile data item and at least one bucket address. The key is a unique identifier for a piece of memory-volatile data, and the bucket address is a variable pointing to the data storage location of that piece of memory-volatile data. The bucket mapping table is used to find the storage location of that piece of memory-volatile data in the bucket based on the key when data is updated or deleted. The bucket addressing described below will use the bucket number and location within the bucket as an example, where the bucket number corresponds to the PenningIntent. This bucket mapping table can be stored at the top level of the buckets or elsewhere in the system. After each piece of memory-volatile data is stored, the correspondence between the key of each piece of memory-volatile data and the PenningIntent number, as well as the corresponding number of this piece of memory-volatile data within the bucket, needs to be stored in the bucket mapping table for maintenance. This table will be used during subsequent data updates or deletions. If memory-volatile data needs to be updated or deleted later, it is only necessary to find the corresponding PenningIntent number in the table, and then update or delete the corresponding memory-volatile data in the (second-level) PenningIntent's Intent according to the memory-volatile data's number within the bucket; it is not necessary to update the memory-volatile data in the Intents corresponding to other PenningIntents. The key can be a hash value.

[0127] A diagram illustrating the effect of tiered storage is shown below. Figure 6 As shown.

[0128] After volatile memory data is stored through hierarchical Pendant entries, it can be referred to as a handle record. In this embodiment, the system handle record can be held using a first system interface to ensure it is not released. For example, the top-level Pendant can be held by setting an alarm with an extremely long duration using the AlarmManager interface provided in the Android system, setting a notification using NotificationManager, or setting a task that is difficult to trigger using JobScheduler. This mechanism prevents the corresponding Pendant from being released in AMS.

[0129] It is understandable that during the real-time operation of an application, application-related memory-volatile data will change, requiring updates to the saved memory-volatile data. Storing memory-volatile data through hierarchical PenningIntents is more efficient in terms of data updates than storing all memory-volatile data in a single PenningIntent Intent. In this embodiment, handle records can be obtained through system interfaces to update data. For example, the top-level PenningIntent can be obtained using the FLAG_UPDATE_CURRENT parameter through system interfaces such as getBroadcast, getService, or getActivity, and then the PenningIntent data can be updated.

[0130] It should be noted that the getActivity system interface method is detected by the user and will redirect to the corresponding Activity interface.

[0131] By establishing a bucket mapping table during the storage of memory volatile data, when memory volatile data needs to be updated or deleted, the PenningIntent number of the memory volatile data to be updated is first found in the bucket mapping table. Then, the PenningIntent corresponding to that number is found in the second level. Finally, the corresponding memory volatile data is updated or deleted in the Intent of that PenningIntent according to the number of the memory volatile data in the bucket. During this process, the memory volatile data in the Intents corresponding to other PenningIntent numbers are not affected and will not be updated.

[0132] The following will describe the process of data recovery after an application restarts abnormally.

[0133] After an abnormal application restart, this embodiment of the application will acquire the memory volatile data and restore the application to its state before the abnormality based on the memory volatile data. When restoring the memory volatile data, a layered recovery parsing process is required. First, the top-level handle record, i.e., the top-level PendingIntent, is parsed, and then recovery is performed layer by layer. That is, the second-level PendingIntent is parsed from the top-level PendingIntent, and then the memory volatile data is parsed from the second-level PendingIntent, thus completing the entire recovery process.

[0134] A flowchart illustrating the application recovery process based on tiered data storage is shown below. Figure 7 As shown.

[0135] Please refer to Figure 7 The following is a schematic diagram of the specific process of step S303 of the data recovery method provided in this application embodiment, which involves obtaining the handle record after an abnormal application restart and restoring the application to its state before the abnormal restart, and includes the following steps:

[0136] Step S701: Query whether the top-level PendingIntent exists in AMS:

[0137] If so, then execute S702;

[0138] If not, then end this process;

[0139] Step S702: Activate the top-level Pending Intent, and continue to step S703;

[0140] Step S703: Query whether the second-level Pending Information exists in AMS:

[0141] If so, proceed to step S704;

[0142] If not, then end this process;

[0143] Step S704: Activate the second layer PendingIntent and obtain the Intent data of PendingIntent through GetExtra.

[0144] This process is now complete.

[0145] When recovering data after an application's abnormal restart, a handle can be obtained through a second system interface. For example, the `getBroadcast`, `getService`, or `getActivity` methods in the Android system can be used, with the parameter set to `FLAG_NO_CREATE`, to retrieve the `PendingIntent` record stored in AMS. The process can obtain the corresponding content by activating the system handle record using system methods. For example, the `send` method in the `PendingIntent` class in the Android system can be used to activate it. Specifically:

[0146] If the getBroadcast interface is used, the memory-volatile data stored in the Intent is parsed in the corresponding broadcast receiver;

[0147] If the getService interface is used, the Intent data is parsed in the OnStartCommand method of the corresponding Service;

[0148] If the getActivity interface is used, the Intent data is parsed in the onResume method of the corresponding Activity. This method is sensitive to the user and will redirect to the corresponding Activity interface.

[0149] After introducing the process of saving, holding, updating, and restoring volatile memory data, the following section will use specific examples to illustrate different ways of holding PenningIntent.

[0150] Example 1: Using AlarmManager to set an alarm holding Pendant for data recovery, such as... Figure 8 As shown, process A is responsible for storing and restoring volatile data in memory, while process B is responsible for the callback of process A upon its death.

[0151] The main process is as follows:

[0152] 1. After process A determines that data storage is required, it uses `putExtra` to write the memory-volatile data containing the Awareness information from the update request to an `Intent`, and then saves it to the AMS system process memory space using a `PendingIntent`. The `PendingIntent` can be generated using the `getBroadcast`, `getService`, or `getActivity` methods with the `FLAG_UPDATE_CURRENT` parameter.

[0153] For detailed instructions on this step, please refer to [link / reference]. Figure 5 And a description of the relevant steps.

[0154] 2. Set an extra-long alarm for the top-level PendingIntent so that the system holds onto the PendingIntent for an extended period, preventing it from being reclaimed.

[0155] 3. Add a death proxy for process A in process B. When process A dies unexpectedly, process B receives a death callback notification from process A and then restarts process A.

[0156] 4. After process A restarts, it retrieves the PendingIntent stored in AMS using the getBroadcast, getService, or getActivity methods with the FLAG_NO_CREATE parameter. By activating the PendingIntent and parsing it, it obtains the stored data for recovery.

[0157] For detailed instructions on step 4, please refer to the following: Figure 7 And a description of the relevant steps.

[0158] At this point, data recovery for process A is complete, and the volatile memory data of process A has been restored to its state before the abnormal restart. In this embodiment, by setting an extremely long alarm in the AlarmManager to ensure it will not be triggered, the PenningIntent is persisted, thus achieving the effect of storing non-persistent data and successfully solving the problem of data loss after an abnormal process restart. For this embodiment, in addition to using the getActivity method, other methods can also be implemented seamlessly for the user, resulting in a more user-friendly experience.

[0159] Example 2: Using JobScheduler to hold PendingIntent for data recovery, such as... Figure 9 As shown, this example illustrates the process of an Android app being unexpectedly killed or crashing. The main steps are as follows:

[0160] 1. In the APP process, write the memory-volatile data that needs to be stored to an Intent using putExtra, and save it to the AMS system process memory space using PendingIntent. The generation of PendingIntent can be achieved by using the getBroadcast, getService, or getActivity methods with the FLAG_UPDATE_CURRENT parameter.

[0161] For detailed instructions on this step, please refer to [link / reference]. Figure 5 And a description of the relevant steps.

[0162] 2. By setting up the JobScheduler and placing the top-level PendingIntent into its transientExtras, the top-level PendingIntent can be kept in AMS.

[0163] 3. The app can automatically restart itself by setting up a daemon process and broadcast listening mechanisms.

[0164] 4. After the APP restarts, use the getBroadcast, getService, or getActivity methods with the FLAG_NO_CREATE parameter to obtain the top-level PendingIntent stored in AMS, use the send method to trigger this PendingIntent, and parse the data stored in the Intent in the corresponding broadcast receiver. This completes the entire recovery process.

[0165] For detailed instructions on step 4, please refer to the following: Figure 7 And a description of the relevant steps.

[0166] In this embodiment, any app can use this method to recover volatile data that the system cannot persist. For developers, this method will not restrict their development process in any way. Moreover, for Embodiment 2, in addition to using the getActivity method, other methods can be implemented without the user's awareness, making the user experience more user-friendly.

[0167] Example 3: Using NotificationManager to set up notification holding intent for data recovery, such as... Figure 10 As shown. Taking the unexpected killing or crashing of any Android app as an example, the main process is similar to Example 2, the difference being that step 2 in this example sets a notification instead of setting a JobScheduler. The main process is as follows:

[0168] 1. In the APP process, write the memory-volatile data that needs to be stored to an Intent using putExtra, and save it to the AMS system process memory space using PendingIntent. The generation of PendingIntent can be achieved by using the getBroadcast, getService, or getActivity methods with the FLAG_UPDATE_CURRENT parameter.

[0169] For detailed instructions on this step, please refer to [link / reference]. Figure 5 And a description of the relevant steps.

[0170] 2. Set a persistent notification for the top-level PendingIntent through NotificationManager to keep this PendingIntent in AMS.

[0171] 3. The app can automatically restart itself by setting up a daemon process and broadcast listening mechanisms.

[0172] 4. After the APP restarts, use the getBroadcast, getService, or getActivity methods with the FLAG_NO_CREATE parameter to obtain the top-level PendingIntent stored in AMS, use the send method to trigger this PendingIntent, and parse the data stored in the Intent in the corresponding broadcast receiver. This completes the entire recovery process.

[0173] For detailed instructions on step 4, please refer to the following: Figure 7 And a description of the relevant steps.

[0174] In this embodiment, any app can use this method to recover volatile data that the system cannot persist, without imposing any restrictions on the development process for developers. Once a persistent notification is set, users can find it in the Android system's drop-down menu. Therefore, by using this embodiment for data recovery, users will be fully aware of the data storage and recovery process.

[0175] The above is a detailed description of the data recovery method provided in the embodiments of this application.

[0176] The method provided in any of the foregoing embodiments of this application can be implemented in... Figure 2 The operating system layer 260 and the application layer 210 are shown.

[0177] The foregoing primarily describes the solutions of the embodiments of this application from a methodological perspective. It is understood that, in order to achieve the aforementioned functions, the data recovery apparatus includes hardware structures and / or software modules corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0178] This application embodiment can divide the data recovery device into functional units according to the above method example. For example, each function can be divided into separate functional units, or two or more functions can be integrated into one processing unit. The integrated unit can be implemented in hardware or as a software functional unit. It should be noted that the unit division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0179] In one example, when dividing functional units according to various functions, please refer to [link / reference]. Figure 11 The data recovery apparatus 1100 provided in this application embodiment includes:

[0180] The determination module 1110 is used to determine the first data, which is the application data when the application is running normally.

[0181] The storage module 1120 is used to save the first data to a handle record, which is managed using a reference counting mechanism;

[0182] The recovery module 1130 is used to obtain the handle record when the application restarts abnormally, and restore the application to the state before the abnormality based on the handle record.

[0183] The update module 1140 is used to update or delete the first data according to the bucket mapping table when the application is running normally, so that the first data is consistent with the application data of the latest state of the application.

[0184] The specific implementation of the schemes involved in the device embodiments can be referred to the foregoing method embodiments, and will not be repeated here.

[0185] When the above-mentioned multiple functional units (or modules) are integrated into a single processing unit, the actions performed by each of the functional units can be executed by the processing unit according to the program stored in the storage unit. The processing unit can be a processor or a controller. The storage unit can be a memory. When the processing unit is a processor and the storage unit is a memory, the actions performed by each of the functional units can be executed by the processor according to the program stored in the memory. For example, when the hardware structure diagram of the data recovery device is shown in the figure... Figure 1 As shown, the processor can be processor 150, and the memory can be memory 180.

[0186] This application also provides a computer-readable storage medium including instructions that, when run on a computer, cause the computer to perform the above-described method.

[0187] This application also provides a computer program product containing instructions that, when run on a computer, cause the computer to perform the above-described method.

[0188] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software programs, implementation can be, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device containing one or more servers, data centers, etc., that can be integrated with the medium. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state disks (SSDs)).

[0189] Although this application has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings, the disclosure, and the appended claims, will understand and implement other variations of the disclosed embodiments in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude multiple instances. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce good results.

[0190] Although this application has been described in conjunction with specific features and embodiments, it will be apparent that various modifications and combinations can be made therein without departing from the spirit and scope of this application. Accordingly, this specification and drawings are merely exemplary illustrations of the application as defined by the appended claims, and are to be considered as covering any and all modifications, variations, combinations, or equivalents within the scope of this application.

Claims

1. A data recovery method, characterized in that, include: The first data is determined, which is the application data when the application is running normally, and the first data is memory-volatile data; The first data is saved to a handle record through the activity management service. The handle record is managed using a reference counting mechanism. The activity management service runs in an independent process. The first data is written into the intent and saved to the memory space of the activity management service system process. The reference counting mechanism stores the number of times the resource is referenced. When the application restarts abnormally, the handle record is obtained, and the application is restored to its state before the abnormality based on the handle record.

2. The method according to claim 1, characterized in that, The first data cannot be saved to an external storage device via serialization.

3. The method according to claim 1, characterized in that, The handle records are managed using a reference counting mechanism, including: The handle record is referenced through the first system interface.

4. The method according to claim 3, characterized in that, The reference handle record via the first system interface includes: A timed task is set for the handle record, the timed task including a one-time task or a periodic task; or Set trigger conditions for the handle record; or A notification task is set for the handle record, and the notification task includes a persistent notification or a non-persistent notification.

5. The method according to claim 1, characterized in that, Saving the first data to the handle record includes: The first data is stored in hierarchical and bucketed formats.

6. The method according to claim 5, characterized in that, The step of storing the first data in hierarchical and bucketed manner includes: A bucket mapping table is established, which includes a correspondence between at least one key and at least one bucket address. The key is a unique identifier of a piece of the first data, and the bucket address is a variable pointing to the storage location of the first data. The bucket mapping table is used to find the storage location of the first data in the bucket according to the key when the data is updated or deleted.

7. The method according to claim 6, characterized in that, The bucket addressing includes: The bin number; or The combination of the bucket number and the key value within the bucket; The bucket number is the number of a bucket assigned to a piece of the first data, and the bucket key value is the position of a piece of the first data within a bucket.

8. The method according to any one of claims 5-7, characterized in that, The reference to the handle record via the first system interface includes: The top layer of the first data, stored in hierarchical buckets, is referenced through the first system interface.

9. The method according to any one of claims 6-8, characterized in that, The method further includes: When the application is running normally, the first data is updated or deleted according to the bucket mapping table so that the first data is consistent with the application data of the latest state of the application.

10. The method according to claim 1, characterized in that, When the application restarts abnormally, obtaining the handle record and restoring the application to its state before the abnormal restart based on the handle record includes: The handle record of the application is obtained through the second system interface based on the application identifier, where the application identifier is a unique identifier for the application. The handle record is parsed and the data in the handle record is restored to the application.

11. A data recovery apparatus, characterized in that, Includes a determination module, a save module, and a restore module: The determining module is used to: determine first data, wherein the first data is application data during normal operation of the application, and the first data is memory volatile data; The storage module is used to: save the first data to a handle record through the activity management service. The handle record is managed using a reference counting mechanism. The activity management service runs in an independent process. The first data is written into the intent and saved to the memory space of the activity management service system process. The reference counting mechanism stores the number of times the resource is referenced. The recovery module is used to: when the application restarts abnormally, obtain the handle record, and restore the application to its state before the abnormality based on the handle record.

12. The data recovery apparatus according to claim 11, characterized in that, The first data cannot be saved to an external storage device via serialization.

13. The data recovery apparatus according to claim 11 or 12, characterized in that, The storage module is specifically used for: The handle record is referenced through the first system interface.

14. The data recovery apparatus according to claim 13, characterized in that, The storage module is specifically used for: A timed task is set for the handle record, the timed task including a one-time task or a periodic task; or Set trigger conditions for the handle record; or A notification task is set for the handle record, and the notification task includes a persistent notification or a non-persistent notification.

15. The data recovery apparatus according to claim 14, characterized in that, The storage module is specifically used for: The first data is stored in hierarchical and bucketed formats.

16. The data recovery apparatus according to claim 15, characterized in that, The storage module is specifically used for: A bucket mapping table is established, which includes a correspondence between at least one key and at least one bucket address. The key is a unique identifier of a piece of the first data, and the bucket address is a variable pointing to the storage space of the first data. The bucket mapping table is used to find the storage location of the first data in the bucket according to the key when the data is updated or deleted.

17. The data recovery apparatus according to claim 16, characterized in that, The bucket addressing includes: The bin number; or The combination of the bucket number and the key value within the bucket; The bucket number is the number of a bucket assigned to a piece of the first data, and the bucket key value is the position of a piece of the first data within a bucket.

18. The data recovery apparatus according to any one of claims 15-17, characterized in that, The storage module is specifically used for: The top layer of the first data, stored in hierarchical buckets, is referenced through the first system interface.

19. The data recovery apparatus according to any one of claims 16-18, characterized in that, It also includes an update module: The update module is used for: When the application is running normally, the first data is updated or deleted according to the bucket mapping table so that the first data is consistent with the application data of the latest state of the application.

20. The data recovery apparatus according to claim 11, characterized in that, The recovery module is specifically used for: The handle record of the application is obtained through the second system interface based on the application identifier, where the application identifier is a unique identifier for the application. The handle record is parsed and the data in the handle record is restored to the application.

21. A terminal, characterized in that, The computer device includes a processor and a memory, the memory being used to store software programs, and the processor being used to read the software programs stored in the memory and execute the data recovery method as described in any one of claims 1-10.

22. A storage medium, characterized in that, Includes a computer program, which, when run on one or more processors, is used to implement the data recovery method as described in any one of claims 1-10.

23. A computer program product, characterized in that, Includes a computer program, which, when run on one or more processors, is used to implement the data recovery method as described in any one of claims 1-10.

Images