Process management method of android system, electronic device and storage medium

Abstract

The application discloses a process management method of an Android system, an electronic device and a storage medium. The Android system runs an application process, a system service process and a system daemon process. The method comprises the following steps: the system service process acquires a process white list of the Android system; the application process sends a keep-alive request to the system service process; in response to the fact that the application process belongs to a process in the process white list, the system service process marks the application process, sends a corresponding mark of the application process to the system daemon process, and sends a keep-alive duration to the application process, so that the application process is kept running within the keep-alive duration. The application improves the utilization rate of system memory resources and overall stability.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a process management method for an Android system, an electronic device, and a storage medium. Background Technology

[0002] With the widespread adoption of Android in automotive, smart home, and industrial handheld devices, the number of processes running on a single device is constantly increasing, and the complexity of process execution logic is also significantly enhanced. The native Android system manages processes based on preset process priorities, terminating lower-priority processes when system resources are limited. Existing management mechanisms struggle to dynamically adjust process priorities based on the real-time importance of tasks, making them prone to accidental process termination, leading to business interruptions, and the loss of critical data. Summary of the Invention

[0003] This application provides at least one process management method for an Android system, an electronic device, and a storage medium.

[0004] This application provides a process management method for an Android system, wherein the Android system runs application processes, system service processes, and system daemon processes. The method includes: the system service process obtaining a process whitelist of the Android system; the application process sending a keep-alive request to the system service process; in response to the application process being a process in the process whitelist, the system service process marking the application process, sending the mark corresponding to the application process to the system daemon process, and simultaneously sending a keep-alive duration to the application process, thereby enabling the application process to continue running within the keep-alive duration; wherein, the system service process obtaining the process whitelist of the Android system includes: when the Android system starts, the system service process obtaining configuration information from a cloud server, generating the process whitelist and a corresponding configuration file, wherein the configuration file is used to configure corresponding level information for each process, the level information including a memory threshold and a termination level; or the system service process receiving updated configuration information sent by the cloud server in real time, generating the process whitelist and a corresponding configuration file, wherein the configuration file is used to configure corresponding level information for each process, the level information including a memory threshold and a termination level.

[0005] In some embodiments, in response to the application process not being a process in the process whitelist, the system service process sends a preset value to the application process to reject the application process's keep-alive request.

[0006] In some embodiments, in response to the application process being a process in the process whitelist, the system service process marks the application process and sends the mark corresponding to the application process to the system daemon process, further including: the system daemon process starting a timer to obtain the memory usage data of the application process; and the system service process reporting the memory usage data to the cloud server.

[0007] In some embodiments, the method further includes: in response to the application process sending a request to the system service process to cancel keep-alive, the system service process notifies the system daemon to cancel the tag corresponding to the application and to stop reporting the memory usage data of the application process.

[0008] In some embodiments, the method further includes: when the application process runs beyond the keep-alive duration, the system service process notifies the system daemon to revoke the tag corresponding to the application and to stop reporting the memory usage data of the application process.

[0009] In some embodiments, the memory threshold includes a first threshold and a second threshold, and the method further includes: the system daemon obtaining the memory usage value of the process; in response to the memory usage value being greater than the first threshold and less than the second threshold, performing only a log recording operation; and in response to the memory usage value being greater than the second threshold, dumping a memory snapshot file of the process and uploading it to a cloud server.

[0010] In some embodiments, the method further includes: in response to the process not being a process in the process whitelist, the system daemon determines whether to terminate the process based on the process's memory usage and priority.

[0011] In some embodiments, the Android system is applied to an electronic device, and the method further includes: the system daemon process obtaining the total memory value of the electronic device; in response to the total memory value being greater than a preset value, obtaining a target process set, and notifying the system service process to send a callback instruction to the application process, wherein the memory usage value of the processes in the target process set is greater than their corresponding memory threshold.

[0012] In some embodiments, the termination levels include a first termination level, a second termination level, a third termination level, and a fourth termination level; wherein, the first termination level indicates that the corresponding process continues to run when managed by the Android system memory mechanism; the second termination level indicates that the corresponding process continues to run when the electronic device is in a hibernation state or the application process is in the background; the third termination level indicates that the corresponding process is terminated when the electronic device is in a hibernation state; and the fourth termination level indicates that the corresponding process is terminated when the memory threshold is exceeded.

[0013] A second aspect of this application provides an electronic device including a memory and a processor coupled to each other, the processor being configured to execute program instructions stored in the memory to implement the process management method of the Android system described above.

[0014] A third aspect of this application provides a computer-readable storage medium having program instructions stored thereon, which, when executed by a processor, implement the process management method of the Android system described above.

[0015] The beneficial effects of this application are as follows: the system service process obtains the Android system's process whitelist; the application process sends a keep-alive request to the system service process; in response to the application process being a process in the process whitelist, the system service process marks the application process, sends the corresponding mark to the system daemon process, and simultaneously sends a keep-alive duration to the application process, thereby enabling the application process to continue running within the keep-alive duration. In particular, by having the application process send a keep-alive request, the process actively requests memory protection, overcoming the deficiency of the native mechanism where processes can only passively rely on static priorities, which is beneficial for the full utilization of system memory resources and the improvement of overall stability.

[0016] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this application. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application.

[0018] Figure 1 This is a schematic diagram of the architecture of the Android system according to an embodiment of this application; Figure 2 This is a flowchart illustrating the process management method of the Android system according to an embodiment of this application; Figure 3This is a flowchart illustrating a process management method for an Android system according to an embodiment of this application; Figure 4 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a non-volatile computer-readable storage medium according to an embodiment of this application. Detailed Implementation

[0019] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0020] In this document, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects are in an "or" relationship. Furthermore, "many" in this document means two or more. Additionally, the term "at least one" in this document means any combination of at least two of any one or more of a plurality of objects. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C. Furthermore, the terms "first," "second," and "third" in this application are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features.

[0021] Taking LMKD (Low Memory Killer Daemon) as an example, the native Android system relies on LMKD for memory management. When system memory resources are scarce, LMKD terminates lower-priority processes based on process priority policies to free up system memory resources. However, the oom_adj (Out of Memory Adjustment) of native processes is mostly determined during application installation or system startup, making it impossible to temporarily increase process priority based on the real-time importance of tasks, such as during navigation, voice interaction, or FOTA (Firmware Over the Air) upgrades. Critical applications cannot actively request the system not to terminate them in the short term; they can only passively rely on the system to judge based on preset priorities. When a non-critical process experiences a memory leak, it will also consume memory resources, potentially causing the system to kill important processes. The native solution lacks dynamic monitoring and degradation / reporting mechanisms based on process levels. Furthermore, system administrators or car manufacturers cannot remotely adjust memory policies (such as modifying whitelists or adjusting memory thresholds) and must upgrade via OTA (Over the Air) system updates, resulting in poor flexibility.

[0022] To address these issues, this application proposes a process management method for an Android system, an electronic device, and a storage medium.

[0023] To enable those skilled in the art to better understand the technical solution of this application, the technical solution of this application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0024] like Figure 1 As shown, Figure 1 This is a schematic diagram of the architecture of the Android system according to an embodiment of this application. The Android system 10 runs application process 11, system service process 12 and system daemon process 13.

[0025] Application process 11 can correspond to one or more applications running in Android system 10, such as App1, App2, etc. System service process 12 is the core running process of the Framework layer, including system_server (system service) and SPM (System Power Manager) process. The SPM process interacts with cloud server 20 over the network, receives configuration information from cloud server 20, and / or reports device status data to cloud server 20. System daemon process 13 runs in the Native layer, including LMKD and WtMemKiller (Watch Trigger Memory Killer) process.

[0026] Please see Figure 2 , Figure 2 This is a flowchart illustrating the process management method of an Android system according to an embodiment of this application. The Android system can be... Figure 1 The Android system 10 in the system runs application process 11, system service process 12 and system daemon process 13.

[0027] It should be noted that if substantially the same result is obtained, the method of this application is not based on... Figure 2 The illustrated process sequence is limited. For example... Figure 2 As shown, the method may include the following steps: Step S21: The system service process obtains the Android system's process whitelist.

[0028] A process whitelist is used to store identifiers of protected processes. Processes on this whitelist are not subject to memory reclamation or termination by the system. (See reference) Figure 1 System service process 12 obtains the process whitelist of Android system 10. For example, the SPM process can obtain the process whitelist of Android system 10 from cloud server 20.

[0029] Step S22: The application process sends a keep-alive request to the system service process.

[0030] Application process 11 sends a keep-alive request to system service process 12. For example, when App1 needs to perform a short-term, uninterruptible task, it can send a keep-alive request to System_server to request the system not to perform memory reclamation and termination operations on App1.

[0031] Step S23: In response to the fact that the application process belongs to the process whitelist, the system service process marks the application process, sends the mark corresponding to the application process to the system daemon process, and sends the keep-alive duration to the application process, so that the application process continues to run within the keep-alive duration.

[0032] In response to the fact that application process 11 is a process in the process whitelist, system service process 12 marks application process 11, sends the mark corresponding to application process 11 to system daemon process 13, and sends a keep-alive duration to application process 11, so that application process 11 continues to run within the keep-alive duration and is not terminated.

[0033] For example, taking App1 as an example, System_server queries the process whitelist to determine whether the process corresponding to App1 is in the process whitelist. If App1 is a process in the process whitelist, System_server marks App1 and sends the mark corresponding to App1 to LMKD and WtMemKiller. At the same time, it sends a keep-alive duration T to App1, so that App1 will not be terminated within the keep-alive duration T and can continue to run.

[0034] In this embodiment, the system service process obtains the Android system's process whitelist. The application process sends a keep-alive request to the system service process. Responding to the application process being on the whitelist, the system service process marks the application process, sends the corresponding mark to the system daemon process, and simultaneously sends a keep-alive duration to the application process, thus ensuring the application process continues running within that duration. By having the application process send a keep-alive request, the process proactively requests memory protection, overcoming the limitation of the native mechanism where processes can only passively rely on static priorities. This is beneficial for fully utilizing system memory resources and improving overall stability.

[0035] Specifically, in response to whitelist matching, the system service process marks the application and synchronizes it to the system daemon process. This allows the daemon process to identify and exempt protected processes during memory reclamation decisions, thereby ensuring that critical business operations are not terminated within a specified time. Simultaneously, a keep-alive duration is sent to the application process, clearly defining the time boundary of protection. This allows the application to reasonably anticipate system behavior and release resources promptly after the keep-alive period ends.

[0036] In some embodiments, in response to an application process not being a process in the process whitelist, the system service process sends a preset value to the application process to indicate that the application process's keep-alive request is rejected.

[0037] In one implementation, reference Figure 1 Application process 11 sends a keep-alive request to system service process 12. In response that application process 11 is not a process in the process whitelist, system service process 12 sends a preset value to application process 11 to reject the keep-alive request of application process 11.

[0038] The preset value can be the keep-alive duration T0, for example, T0=0. When App1 needs to perform a short-term, uninterruptible task, it can send a keep-alive request to System_server. System_server determines that App1 is not a process in the process whitelist and returns 0, indicating that keep-alive is refused.

[0039] In some embodiments, in response to the application process being a process in the process whitelist, the system service process marks the application process and sends the mark corresponding to the application process to the system daemon process, further including: the system daemon process starting a timer to obtain the memory usage data of the application process; and the system service process reporting the memory usage data to the cloud server.

[0040] In one implementation, reference Figure 1 Application process 11 sends a keep-alive request to system service process 12. In response to the fact that application process 11 is a process in the process whitelist, system service process 12 marks application process 11 and sends the mark corresponding to application process 11 to system daemon process 13. System daemon process 13 starts a timer to obtain the memory usage data of application process 11. System service process 12 reports the memory usage data to cloud server 20.

[0041] For example, when App1 sends a keep-alive request to System_server, and App1 is a process in the process whitelist, System_server marks App1 in the process whitelist array through bit operations, sends the corresponding mark of App1 to LMKD and WtMemKiller, and sends the keep-alive duration T to App1, so that App1 will not be terminated within the keep-alive duration T.

[0042] System_server simultaneously notifies WtMemKiller of the changes to the process whitelist array, and WtMemKiller then starts a timer to periodically check the memory usage of App1, while reporting the memory usage data of App1 to the cloud server 20 through the SPM process.

[0043] In some embodiments, in response to an application process sending a request to the system service process to cancel keep-alive, the system service process notifies the system daemon to cancel the flag corresponding to the application and to stop reporting the memory usage data of the application process.

[0044] In one implementation, reference Figure 1 In response to the application process 11 sending a request to the system service process 12 to cancel the keep-alive, the system service process 12 notifies the system daemon process 13 to cancel the flag corresponding to the application, and the system daemon process 13 stops reporting the memory usage data of the application process 11.

[0045] For example, when App1 sends a keep-alive request to System_server, and App1 is a process in the process whitelist, System_server marks App1 in the process whitelist array through bit operations, sends the corresponding mark of App1 to LMKD and WtMemKiller, and sends the keep-alive duration T to App1, so that App1 will not be terminated within the keep-alive duration T.

[0046] Furthermore, after completing its task, App1 proactively sends a request to System_server to revoke its keep-alive status. System_server then notifies LMKD and WtMemKiller to withdraw App1's antivirus evasion flag, and WtMemKiller to cancel the periodic reporting of App1's memory usage.

[0047] In some embodiments, when an application process exceeds its keep-alive duration, the system service process notifies the system daemon to remove the flag corresponding to the application and to stop reporting the memory usage data of the application process.

[0048] In one implementation, reference Figure 1 When the application process 11 runs beyond the keep-alive timeout, the system service process 12 notifies the system daemon process 13 to remove the flag corresponding to the application and the system daemon process 13 to stop reporting the memory usage data of the application process 11.

[0049] For example, when App1 sends a keep-alive request to System_server, and App1 is a process in the process whitelist, System_server marks App1 in the process whitelist array through bit operations, sends the corresponding mark of App1 to LMKD and WtMemKiller, and sends the keep-alive duration T to App1, so that App1 will not be terminated within the keep-alive duration T.

[0050] Furthermore, after App1 runs for more than the keep-alive duration T, System_server notifies LMKD and WtMemKiller to withdraw the antivirus evasion flag of App1, and WtMemKiller to cancel the periodic reporting of App1's memory usage.

[0051] In some embodiments, the system service process obtains the process whitelist of the Android system, including: when the Android system starts, the system service process obtains configuration information from the cloud server and generates the process whitelist and corresponding configuration file, or the system service process receives updated configuration information sent by the cloud server in real time and generates the process whitelist and corresponding configuration file, wherein the configuration file is used to configure corresponding level information for each process, and the level information includes memory threshold and termination level.

[0052] refer to Figure 1 When Android system 10 starts, system service process 12 obtains configuration information from cloud server 20, generates process whitelist and corresponding configuration files. The configuration files are used to configure corresponding level information for each process, including memory threshold and termination level.

[0053] For example, when Android 10 boots up, the SPM process reads the latest configuration from cloud server 20 and synchronizes it to the process whitelist and wt_mem_conf.xml. System_server, LMKD, and WtMemKiller read the process whitelist. WtMemKiller reads wt_mem_conf.xml to configure dynamic memory monitoring, such as configuring memory thresholds and process names for each level. Furthermore, cloud server 20 can distribute new process whitelists and wt_mem_conf.xml configurations in real time, enabling hot reloading of the system. In essence, process whitelists, dynamic monitoring thresholds, and level schemes can all be configured and distributed in real time via cloud server 20 without requiring system upgrades.

[0054] Among these, the level information is a core field in the configuration file, configured independently for each process. A process can refer to one of the application processes (11), system service processes (12), or system daemons (13). The memory threshold refers to the preset monitoring or processing actions triggered when the actual memory usage of a process reaches this value, such as logging, generating a heap dump file, or triggering a memory reclamation mechanism. The termination level refers to the priority or minimum privilege level at which the process is allowed to be terminated by the system when the overall system memory is insufficient and memory reclamation is required.

[0055] In some embodiments, the memory threshold includes a first threshold and a second threshold. The method further includes: a system daemon obtaining the memory usage value of a process; in response to the memory usage value being greater than the first threshold and less than the second threshold, performing only a logging operation; and in response to the memory usage value being greater than the second threshold, dumping the memory snapshot file of the process and uploading it to a cloud server.

[0056] In one implementation, reference Figure 1 When an app experiences a continuous increase in memory usage during operation, such as due to circularly holding objects that cannot be released, WtMemKiller can detect through monitoring that its memory usage exceeds the threshold configured in wt_mem_conf for that process (or that type of process) and trigger different actions.

[0057] For example, the memory thresholds for App2 in the configuration file include a first threshold K1 and a second threshold K2. If the monitored memory usage of App2 is greater than the first threshold K1 but less than the second threshold K2, only logging is performed. If the monitored memory usage of App2 is greater than the second threshold K2, the hprof file (HeapProfile) of App2 is directly dumped and uploaded to the cloud server 20.

[0058] In some embodiments, in response to a process not being in the process whitelist, the system daemon determines whether to terminate the process based on the process's memory usage and priority.

[0059] For example, refer to Figure 1 In response to process P not being in the process whitelist, system daemon 13 determines whether to terminate process P based on its memory usage and priority. For example, if App2 is not in the process whitelist and its memory usage is too high, WtMemKiller will determine whether to terminate it based on its process priority (e.g., whether it is a foreground process).

[0060] In some embodiments, the Android system is applied to an electronic device, and the method further includes: a system daemon process obtaining the total memory value of the electronic device; in response to the total memory value being greater than a preset value, obtaining a target process set, and notifying a system service process to send a callback instruction to the application process, wherein the memory usage value of the processes in the target process set is greater than their corresponding memory threshold.

[0061] The Android system is used in electronic devices, such as in-vehicle systems and smart terminals.

[0062] In one implementation, reference Figure 1The system daemon process 13 obtains the total memory value of the electronic device. In response to the total memory value being greater than a preset value, it obtains the target process set and notifies the system service process 12 to send a callback instruction to the application process 11, wherein the memory usage value of the processes in the target process set is greater than their corresponding memory threshold.

[0063] For example, WtMemKiller periodically checks the vehicle's infotainment system memory. After certain calculations, if the total system memory exceeds a preset value, it triggers a system-wide memory reclamation process. WtMemKiller obtains a set of processes whose running memory exceeds the memory threshold and notifies the System_server to send an onLowMemory() callback to all applications, thereby notifying the applications that memory is low. Further, it iterates through the target process set to perform configuration level operations, trigger anti-virus evasion checks, etc.

[0064] In some embodiments, the termination levels include a first termination level, a second termination level, a third termination level, and a fourth termination level; wherein, the first termination level indicates that the corresponding process continues to run when managed by the Android system memory mechanism; the second termination level indicates that the corresponding process continues to run when the electronic device is in a hibernation state or the application process is in the background; the third termination level indicates that the corresponding process is terminated when the electronic device is in a hibernation state; and the fourth termination level indicates that the corresponding process is terminated when the memory threshold is exceeded.

[0065] For example, the first termination level corresponds to level 0, the second termination level corresponds to level 1, the third termination level corresponds to level 2, and the fourth termination level corresponds to level 3. In the configuration file, App1's termination level is level 0, App2's termination level is level 1, App3's termination level is level 2, and App4's termination level is level 3.

[0066] Level 0 indicates that App1 is managed by Android's native memory mechanism and will not be terminated; App1 will continue to run during this period. Level 1 indicates that when the electronic device is in sleep mode or App2 is in the background, App2's process will not be terminated, and App2 will continue to run. Level 2 indicates that when the electronic device is in sleep mode, App3's process can be terminated. Level 3 indicates that when App4's memory threshold is reached, App4's process can be terminated.

[0067] In one implementation, WtMemKiller iterates through all current processes and determines the termination level based on the configuration level of each process (obtained from the wt_mem_conf.xml configuration). When terminating a process, WtMemKiller can dump the current memory snapshot, process list, level information, etc., to a file for uploading.

[0068] To facilitate understanding, the application of the process management method of the Android system in the embodiments of this application will be illustrated with examples, such as... Figure 3 As shown, Figure 3 This is a flowchart illustrating a process management method for an Android system according to an embodiment of this application, comprising the following steps: S31: Receive keep-alive request.

[0069] For example, when an application process (such as navigation or emergency call) needs to perform a short-term, uninterrupted task, it sends a keep-alive request to the System_server, which then receives the keep-alive request.

[0070] S32: Determine whether the application process is in the process whitelist.

[0071] System_server determines whether the application process is in the process whitelist.

[0072] If the application process is not in the process whitelist, proceed to step S33; if the application process is in the process whitelist, proceed to step S34.

[0073] S33: Send keep-alive duration T1 to the application process.

[0074] System_server sends a keep-alive duration T1 to the application process, for example, T1=0.

[0075] S34: Notification system daemon.

[0076] System_server performs bit operations and notifies LMKD and WtMemKiller of the resulting flags.

[0077] S35: Send keep-alive duration T2 to the application process.

[0078] System_server sends a keep-alive duration T2 to the application process, for example, T2=n, n≥30.

[0079] Furthermore, WtMemKiller starts a timer to periodically check the memory usage of the application process, and simultaneously reports the memory usage data of the application process to the cloud through the SPM process.

[0080] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0081] Please see Figure 4 , Figure 4 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application. The electronic device 40 includes a memory 41 and a processor 42 coupled to each other. The processor 42 is used to execute program instructions stored in the memory 41 to implement the steps in the above-described Android system process management method embodiment. In a specific implementation scenario, the electronic device 40 may include, but is not limited to, a microcomputer or a server. Furthermore, the electronic device 40 may also include mobile devices such as laptops and tablets, without limitation.

[0082] Specifically, processor 42 controls itself and memory 41 to implement the steps in the above-described Android system process management method embodiment. Processor 42 can also be referred to as a CPU (Central Processing Unit). Processor 42 may be an integrated circuit chip with signal processing capabilities. Processor 42 can also be a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. A general-purpose processor can be a microprocessor or any conventional processor. Furthermore, processor 42 can be implemented using integrated circuit chips.

[0083] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of a non-volatile computer-readable storage medium according to an embodiment of this application. The non-volatile computer-readable storage medium 50 stores program instructions 501 that can be executed by a processor. The program instructions 501 are used to implement the steps in the process management method embodiment of the Android system described above.

[0084] In some embodiments, the functions or modules of the apparatus provided in this disclosure can be used to perform the methods described in the above method embodiments. The specific implementation can be referred to the description of the above method embodiments, and for the sake of brevity, it will not be repeated here.

[0085] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities between them can be referred to, and for the sake of brevity, they will not be repeated here.

[0086] In the several embodiments provided in this application, it should be understood that the disclosed methods and apparatus can be implemented in other ways. For example, the apparatus implementations described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0087] Furthermore, the functional units in the various embodiments of this application 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 unit.

[0088] If the integrated unit is implemented as a software functional unit and 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 application, 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 methods of various embodiments of this application. 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.

[0089] Those skilled in the art will readily recognize that numerous modifications and variations can be made to the apparatus and method while maintaining the teachings of this application. Therefore, the above disclosure should be considered limited only by the scope of the appended claims.

Claims

1. A process management method for an Android system, characterized in that, The Android system runs application processes, system service processes, and system daemons; the method includes: The system service process obtains the process whitelist of the Android system; The application process sends a keep-alive request to the system service process; In response to the fact that the application process belongs to the process whitelist, the system service process marks the application process, sends the mark corresponding to the application process to the system daemon process, and sends a keep-alive duration to the application process, thereby enabling the application process to continue running within the keep-alive duration; The system service process obtains the Android system's process whitelist, including: When the Android system starts, the system service process obtains configuration information from the cloud server and generates the process whitelist and corresponding configuration files; or The system service process receives updated configuration information from the cloud server in real time and generates a process whitelist and corresponding configuration files. The configuration file is used to configure corresponding level information for each process, including memory threshold and termination level.

2. The method according to claim 1, characterized in that, include: In response to the fact that the application process is not a process in the process whitelist, the system service process sends a preset value to the application process to reject the application process's keep-alive request.

3. The method according to claim 1, characterized in that, In response to the application process belonging to the process whitelist, the system service process marks the application process and sends the mark corresponding to the application process to the system daemon process, further including: The system daemon starts a timer to obtain the memory usage data of the application process; The system service process reports the memory usage data to the cloud server.

4. The method according to claim 3, characterized in that, Further including: In response to the application process sending a request to the system service process to cancel keep-alive, the system service process notifies the system daemon to cancel the flag corresponding to the application and to stop reporting the memory usage data of the application process.

5. The method according to claim 3, characterized in that, Further including: When the application process runs beyond the keep-alive duration, the system service process notifies the system daemon to remove the flag corresponding to the application and to stop reporting the memory usage data of the application process.

6. The method according to claim 1, characterized in that, The memory threshold includes a first threshold and a second threshold, and the method further includes: The system daemon process obtains the memory usage value of the process; If the memory usage value is greater than the first threshold and less than the second threshold, only a log recording operation is performed. In response to the memory usage value exceeding the second threshold, a memory snapshot file of the process is dumped and uploaded to the cloud server.

7. The method according to claim 6, characterized in that, Also includes: In response to a process that is not in the process whitelist, the system daemon determines whether to terminate the process based on the process's memory usage and priority.

8. The method according to claim 1, characterized in that, The Android system is applied to an electronic device, and the method further includes: The system daemon process obtains the total memory value of the electronic device; In response to the total memory value being greater than a preset value, a target process set is obtained, and the system service process is notified to send a callback instruction to the application process, wherein the memory usage value of the processes in the target process set is greater than their corresponding memory threshold.

9. The method according to claim 8, characterized in that, The termination levels include a first termination level, a second termination level, a third termination level, and a fourth termination level; Wherein, the first termination level is used to indicate that the process corresponding to the memory management of the Android system is maintained in operation; The second termination level is used to indicate that when the electronic device is in a hibernation state or the application process is in the background, the corresponding process continues to run; The third termination level is used to indicate that when the electronic device is in a sleep state, the corresponding process is terminated. The fourth termination level is used to indicate that when the memory threshold is exceeded, the corresponding process is terminated.

10. An electronic device, characterized in that, The system includes a memory and a processor that are coupled to each other, the processor being used to execute program instructions stored in the memory to implement the process management method of the Android system according to any one of claims 1 to 9.

11. A computer-readable storage medium having program instructions stored thereon, characterized in that, When the program instructions are executed by the processor, they implement the process management method of the Android system as described in any one of claims 1 to 9.

Images