Keep-alive application dynamic configuration method on Android platform and equipment medium

Abstract

The invention discloses a dynamic configuration method and equipment medium for keep-alive applications on an Android platform, and the method comprises the steps: defining an application white list format, and supporting the configuration of package names of a plurality of applications; the package names corresponding to the applications of which the priorities need to be improved are listed in an application white list; storing the application white list in a database; monitoring the data change of the application white list in the database in real time; when it is monitored that the data of the application white list changes, package names of all applications in the Android system are read and matched with the package names in the application white list, and the applications with the matched package names serve as target applications; and modifying the OOM Adj value of the target application process, and improving the priority of the target application when the memory is insufficient. The method has the characteristic of flexible configuration, and important applications are prevented from being killed in a low-memory running state.

Description

Technical Field

[0001] The present invention relates to the technical field of mobile Android platform, and in particular to a method for dynamically configuring a keep-alive application on an Android platform and a device medium. Background Art

[0002] Android application memory management is jointly completed by the Dalvik / ART virtual machine of the Android operating system and the Linux kernel. Due to the limitation of the physical memory size of Android devices, the system will set different upper limits for the memory usage of each running application process. If this limit is exceeded, an OOM exception (Out Of Memory) will be thrown. This problem is common in application memory leaks (a large number of objects occupying memory that cannot be released), or the required memory size is larger than the allocable memory size. For example, when loading a very large image resource, OOM may occur. On low-RAM devices, the application's memory upper limit will also be lower. Although developers can request a larger memory usage, the system will still limit memory usage.

[0003] Android uses Linux's cgroups (Control Groups) mechanism to limit and manage memory resources. Each application process is assigned to a different priority group, from high to low priority, namely foreground application, background service, and cache process. Android's ActivityManager uses OOM Adj value to determine the priority of the process.

[0004] At the same time, Android also uses the LMK (LowMemoryKiller) mechanism. LMK is a memory management mechanism modified from the standard Linux lernel OOM in the Android native system. It is also part of the Android kernel. It is specifically used to automatically terminate low-priority processes when the system memory is insufficient to release memory resources, avoid OOM in other applications, and ensure system stability and availability. The rule for this adjustment is to set a weight OOMAdj for each process, which represents the priority of the process. The higher the priority, the less likely it is to be recycled when the memory is insufficient. The OOM Adj of ordinary applications is greater than or equal to 0, while the OOM Adj of system processes is less than 0. In short, the smaller the OOM Adj value, the higher the priority of the application. According to the OOM Adj value, start killing the process with the lowest priority.

[0005] Although the physical memory size of most smartphones is above 6GB, low memory killing application scenarios do not occur frequently. However, in some special industries, such as industrial control or POS industries, low memory configurations such as 512MB and 1GB still exist. How to run service applications stably on these low-memory devices is an issue that requires great attention.

[0006] When the system memory is tight, it will kill applications or services that the system considers unimportant but are actually very important. In such cases, there are generally the following solutions:

[0007] How app developers can respond:

[0008] Optimize the application's own memory management. First, avoid memory leaks. You need to optimize the application's internal code logic and check for possible memory leaks, such as static references to Activity and Context objects that prevent memory from being released and unclosed file resources, to avoid invalid high memory usage. Second, reduce memory usage, such as optimizing data structures, avoiding redundant objects, and using recyclable list views.

[0009] Other common circumvention methods are to set the service as the foreground service and increase the priority; another method is to use the dual service heartbeat mechanism to prevent the target process from being killed. These methods require writing a lot of logic code to adapt to multiple Android versions, and as the Android version increases, the native mechanism restricts background applications more strictly, and these methods do not produce the expected results.

[0010] Solution on the system firmware side:

[0011] Device manufacturers set up whitelists for customers' special applications to prevent the applications from being killed. The whitelist mechanism can prevent developers from writing a lot of logic code to keep the applications alive, and leave the work of keeping the applications alive to firmware developers.

[0012] The general whitelist mechanism is a collaboration between application developers and device manufacturers. Manufacturers make special customizations to the firmware, which is generally a static configuration that does not have flexible adjustment features or cannot take effect immediately.

[0013] Currently, the Android native system does not provide a way to externally adjust the priority of application processes. The urgent problem to be solved is how to mark which applications are higher priority applications in a more convenient way, dynamically adjust the priority of the target application process, and make it take effect permanently after configuration to improve the stability of customer application operation. Summary of the invention

[0014] In view of this, the purpose of the present invention is to propose a dynamic configuration method for keep-alive applications on the Android platform, which is based on the whitelist mechanism, is customer-oriented, and has the characteristics of flexible configuration. The purpose is to provide target customers with a simpler and faster way to configure the application whitelist, and it can take effect immediately to avoid important applications from being killed when running in a low-memory state.

[0015] In order to achieve the above technical objectives, the technical solution adopted by the present invention is:

[0016] The present invention provides a method for dynamically configuring a keep-alive application on an Android platform, comprising the following steps:

[0017] Step 1: Define an application whitelist format to support configuring the package names of multiple applications;

[0018] Step 2: Add the package name of the application that needs to increase the priority to the application whitelist;

[0019] Step 3: Store the application whitelist in the database;

[0020] Step 4: monitor the data changes of the application whitelist in the database in real time;

[0021] Step 5: When the data in the application whitelist is monitored to change, the package names of all applications in the Android system are read and matched with the package names in the application whitelist. The application with the matching package name is used as the target application.

[0022] Step 6: Modify the OOM Adj value of the target application process to increase the priority of the target application to survive when memory is insufficient.

[0023] Furthermore, the package name of the application is a unique identification string that distinguishes each application on Android.

[0024] Furthermore, the step 3 is specifically as follows: using the Android native Settings API interface as the entry of the application whitelist, and storing the application whitelist in the Secure database of the Settings system through the Settings API interface.

[0025] Furthermore, the step 4 specifically includes:

[0026] Step 41: When the application whitelist is created, it has a corresponding field. A unique URI is configured for the field of the application whitelist. The URI is stored together with the field of the application whitelist in the Secure database.

[0027] Step 42: Set up a mechanism for monitoring URI data changes;

[0028] Step 43: When there is no application whitelist in the Secure database, the default URI is None;

[0029] Step 44: monitor the URI of the application whitelist in the Secure database in real time through the data change mechanism, compare the newly received URI with the existing URI, and if the URI of the application whitelist is monitored to change, including the URI from non-existent to existing and the URI value change, it means that the field of the application whitelist has changed, and enter step 45; if the URI of the application whitelist is monitored to be unchanged, it means that the field of the application whitelist has not changed, and no processing is performed;

[0030] Step 45: Update the application whitelist and corresponding URI in the Secure database.

[0031] Furthermore, after step 45, the following steps are further included:

[0032] Step 46: The user registers in the service process and specifies the URI corresponding to the field of the application whitelist. When a change in the URI is detected, a notification message is generated and sent to the service process.

[0033] Further, the step 5 comprises:

[0034] Step 51: When a change in the URI is detected, read the list of all applications in the Android system and traverse the package name list of all applications;

[0035] Step 52: Compare each package name in the package name list of all applications with the package name in the application whitelist one by one;

[0036] Step 53: Determine whether the package name in the package name list of all applications matches the package name in the application whitelist according to the comparison result. If so, take the application with the matching package name as the target application and proceed to step 6; otherwise, do nothing.

[0037] Furthermore, the step 6 specifically includes:

[0038] Step 61: When the application starts the process, it is assigned a default OOM Adj value.

[0039] Step 62, judging the running state of the target application, if the target application is not in the running state, then wait until the next time the target application process is started, and then proceed to step 63; if the target application is already in the running state, then directly proceed to step 63;

[0040] Step 63: Enter the file node of the current process of the target application to modify the OOM Adj value of the target application process;

[0041] Step 64: Calculate the OOM score value according to the memory usage ratio of the target application process and the OOM Adj value. The calculation formula is as follows:

[0042] OOM score = (OOM Adj + 1000) / 2000 * memory usage percentage * 100;

[0043] Among them, the memory usage percentage is the ratio of the memory used by the process to the total system memory;

[0044] Step 65: Increase the priority of the target application according to the OOM score value. The OOM score value determines the priority of killing the process. The larger the OOM score value, the lower the priority.

[0045] Furthermore, the OOM Adj value is an integer value indicating the OOM priority of the process; a larger value of the OOM Adj value indicates a lower priority;

[0046] The OOM Adj value is managed by ActivityManagerService and LowMemoryKiller drivers, and the allocated OOM Adj values ​​are as follows from large to small: the maximum OOM Adj value of the invisible process, the minimum adj value of the invisible process, the OOM Adj value of the Service service in list B, the OOM Adj value of the first application in the cached application, the OOM Adj value of the process where the Home application is located, the OOM Adj value of the service process, the OOM Adj value of the heavyweight process in the background, the OOM Adj value of the process entering the background, the OOM Adj value of the perceptible process, the OOM Adj value of the visible process, the OOM Adj value of the foreground process, the OOM Adj value of the process bound to the system or persistent process, the OOM Adj value of the system persistent process, the OOM Adj value of the system process, and the OOM Adj value of the local process;

[0047] Change the OOM Adj value of the target application process to the OOM Adj value corresponding to the system persistent process.

[0048] The present invention also provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the method for dynamically configuring keep-alive applications on the Android platform as described above is implemented.

[0049] The present invention also provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the method for dynamically configuring keep-alive applications on an Android platform as described above is implemented.

[0050] By adopting the above technical solution, the present invention has the following beneficial effects compared with the prior art:

[0051] 1. Improve the survival rate of key applications: Use the application whitelist mechanism to mark applications that are business-critical or require long-term memory retention and increase their priority.

[0052] 2. Flexibility and dynamic adjustment capabilities: Use the SettingsAPI interface to store the application whitelist. The system service can dynamically sense the changes in the application whitelist and make real-time adjustments. It allows the priority of the process to be dynamically adjusted while the target application process is running without restarting or redeploying.

[0053] 3. Enhance the controllability of system resources: System resources are limited. Some critical tasks may require higher priority, while ordinary applications can be restricted. Through the application whitelist mechanism, the process priority is dynamically managed to improve the accuracy of resource allocation and avoid resources being occupied by low-priority processes, which affects the execution of critical tasks.

[0054] 4. Configurability, reducing development costs: Usually, manually setting priorities for applications requires a lot of code changes or device root permission support. The present invention uses the SettingsAPI interface to centrally manage application whitelists, reducing development and maintenance costs. Provide customer-oriented configurability. In enterprise-level devices or special scenarios, special priority policies need to be provided for specific applications. Customers can also write a visual interface based on this set of solutions to manage whitelist applications. Users can add or remove whitelists through UI interactions. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0056] Figure 1 The present invention provides an implementation flow chart of a method for dynamically configuring keep-alive applications on an Android platform.

[0057] Figure 2 It is a schematic diagram of an electronic device provided by an embodiment of the present invention.

[0058] Figure 3 It is a schematic diagram of a computer-readable storage medium provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0059] The present invention will be further described in detail below in conjunction with the accompanying drawings and examples. It is particularly noted that the following examples are only used to illustrate the present invention, but are not intended to limit the scope of the present invention. Similarly, the following examples are only partial embodiments of the present invention rather than all embodiments, and all other embodiments obtained by those of ordinary skill in the art without creative work are within the scope of protection of the present invention.

[0060] See also Figure 1 , a method for dynamically configuring keep-alive applications on an Android platform of the present invention comprises the following steps:

[0061] Step 1: define an application whitelist format, supporting the configuration of multiple application package names; the application package name is a unique identification string that distinguishes each application on Android; different applications can be identified by the package name, thereby clarifying the corresponding application in the application whitelist;

[0062] For example, the format of the application whitelist is: "Package name 1, package name 2, package name 3...". The application whitelist is used to mark applications that need to have a higher priority and can be specifically configured by the customer.

[0063] Step 2: Add the package names of applications that need to have their priorities raised to the application whitelist. Users can select applications based on their importance in the system and add them to the application whitelist. The purpose of setting up an application whitelist is to notify the system which applications that are currently running or about to run are of high importance and will eventually need to modify the application process. Through the application whitelist mechanism, applications that are business-critical or require long-term memory retention can be marked and their priorities can be raised, thereby increasing the survival rate of critical applications. For example, long-connection service applications can reduce the risk of service interruptions due to memory pressure, thereby improving user experience.

[0064] All applications can be divided into system applications and common applications. System applications have read and write permissions, while common applications can only read but not write. If you need common applications to have write functions, you need to configure permissions for the common applications in advance. In this way, when you need to modify an application in the application whitelist, you can modify the package name of the application based on the write permission.

[0065] Step 3: Store the application whitelist in the database;

[0066] In this embodiment, step 3 is specifically as follows: using Android's native Settings API interface as the entry point for the application whitelist, and storing the application whitelist in the Secure database of the Settings system through the Settings API interface to achieve data persistence. Design an application layer interface method to provide an entry point for setting the application whitelist. Using Android's native Settings API interface, there is no need to add a new interface. Using the Settings API interface to centrally manage the application whitelist saves interface resources and reduces development and maintenance costs. By using the Settings API interface to store the application whitelist, the system service can dynamically perceive changes in the application whitelist and can adjust it in real time; it allows the priority of the process to be dynamically adjusted while the target application process is running, without the need to restart or redeploy.

[0067] There are three levels of databases in the Settings system, namely System database, Secure database and Global database. The System database and Global database can be accessed or modified by ordinary applications, where system-wide preference data such as system brightness and media volume are stored; while the Secure database can be accessed or modified by ordinary applications and system applications, and stores more system-sensitive data, such as accessibility settings and location settings. Ordinary applications are read-only and cannot write, while system permission applications have write permissions. Application whitelist data is designed to be stored in the Secure database, and ordinary applications with system or special permissions can modify the content of the application whitelist.

[0068] The application needs to declare custom permissions in the AndroidManifest.xml (application registration manifest) file in the code project; if custom permissions have been declared, the system will allow the application to read and write the Secure database. To avoid the expansion of permissions, only the fields in the application whitelist are allowed to be modified, and other fields remain read-only.

[0069] Step 4: monitor the data changes of the application whitelist in the database in real time;

[0070] In this embodiment, step 4 specifically includes:

[0071] Step 41: When the application whitelist is created, it has a corresponding field. A unique URI (Uniform Resource Identifier, a string used to identify a certain Internet resource name) is configured for the field of the application whitelist. The URI is stored together with the field of the application whitelist in the Secure database.

[0072] Step 42: Set up a mechanism for monitoring URI data changes. The mechanism is implemented as ContentObserver. ContentObserver is a component in the Android system used to monitor data changes. It is mainly used to monitor data updates set by ContentProvider or system settings. When the data under a specific RI changes, the system will notify the registered observers, thereby achieving real-time data updates.

[0073] Step 43: When there is no application whitelist in the Secure database, the default URI is None;

[0074] Step 44: monitor the URI of the application whitelist in the Secure database in real time through the data change mechanism, compare the newly received URI with the existing URI, and if the URI of the application whitelist is monitored to change, including the URI from non-existent to existing and the URI value change, it means that the field of the application whitelist has changed, and enter step 45; if the URI of the application whitelist is monitored to be unchanged, it means that the field of the application whitelist has not changed, and no processing is performed;

[0075] Step 45: Update the application whitelist and corresponding URI in the Secure database;

[0076] Step 46: The user registers in the service process (as an observer) and specifies the URI corresponding to the field of the application whitelist. When a change in the URI is detected, a notification message is generated and sent to the service process.

[0077] Step 5: When the data in the application whitelist is monitored to change, the package names of all applications in the Android system are read and matched with the package names in the application whitelist. The application with the matching package name is used as the target application.

[0078] In this embodiment, step 5 comprises:

[0079] Step 51: When a change in the URI is detected, read the list of all applications in the Android system and traverse the package name list of all applications;

[0080] Step 52: Compare each package name in the package name list of all applications with the package name in the application whitelist one by one;

[0081] Step 53: Determine whether the package name in the package name list of all applications matches the package name in the application whitelist according to the comparison result. If so, take the application with the matching package name as the target application and proceed to step 6; otherwise, do nothing.

[0082] Step 6: Modify the OOM Adj value of the target application process to increase the priority of the target application to survive when memory is insufficient.

[0083] In this embodiment, step 6 specifically includes:

[0084] Step 61: When the application starts the process, it is assigned a default OOM Adj value; in this embodiment, OOMAdj (Out of Memory Adjust) is an important parameter used by the Linux kernel for process memory management. It affects the priority of the system to kill the process when the memory is insufficient. The OOM Adj value is an integer value, indicating the OOM priority of the process; the larger the OOM Adj value, the lower the priority;

[0085] The OOM Adj value is managed by ActivityManagerService and LowMemoryKiller drivers, and the allocated OOM Adj values ​​are as follows from large to small: the maximum OOM Adj value of the invisible process, the minimum adj value of the invisible process, the OOM Adj value of the Service service in list B, the OOM Adj value of the first application in the cached application, the OOM Adj value of the process where the Home application is located, the OOM Adj value of the service process, the OOM Adj value of the heavyweight process in the background, the OOM Adj value of the process entering the background, the OOM Adj value of the perceptible process, the OOM Adj value of the visible process, the OOM Adj value of the foreground process, the OOM Adj value of the process bound to the system or persistent process, the OOM Adj value of the system persistent process, the OOM Adj value of the system process, and the OOM Adj value of the local process;

[0086] The OOM Adj value is an integer value ranging from -1000 to 1000. -1000 means that it will never be killed. It is a critical process of the system. The higher the value from 0 to 1000, the easier it is to be killed. For example:

[0087] CACHED_APP_MAX_ADJ=906, the maximum adj value of the invisible process;

[0088] CACHED_APP_MIN_ADJ=900, minimum adj value of invisible process;

[0089] SERVICE_B_ADJ=800, Service services in list B, these services are older and less likely to be used again;

[0090] PREVIOUS_APP_ADJ=700, the first application in the cache application;

[0091] HOME_APP_ADJ=600, the process where the Home application is located;

[0092] SERVICE_ADJ=500, service process;

[0093] HEAVY_WEIGHT_APP_ADJ=400, heavyweight background process;

[0094] BACKUP_APP_ADJ=300, enter the background process;

[0095] PERCEPTIBLE_APP_ADJ = 200, which means that the process can be perceived, such as playing music in the background;

[0096] VISIBLE_APP_ADJ=100, visible process;

[0097] FOREGROUND_APP_ADJ=0, foreground process;

[0098] PERSISTENT_SERVICE_ADJ = -700, the process bound to the system or persistent process;

[0099] PERSISTENT_PROC_ADJ=-800, system persistence process;

[0100] SYSTEM_ADJ=-900, system process;

[0101] NATIVE_ADJ=-1000, local process, not controlled by the system.

[0102] Step 62: Determine the running state of the target application. Regardless of whether the application has been started, the application whitelist can take effect immediately. If the target application is not in the running state, wait until the next time the target application process is started, and then enter step 63. If the target application is already in the running state, directly enter step 63.

[0103] Step 63: Enter the file node of the current process of the target application ( / proc / <pid> / oom_adj) to modify the OOM Adj value of the target application process;

[0104] The OOM Adj value of a process can be directly read from the system / proc / <pid> / oom_adj file. Modifying this file can also modify the OOM Adj value of the process in real time, and modify the OOM Adj value of the target application process to the OOM Adj value corresponding to the system persistent process; the write operation requires system permissions and can be implemented by system services.

[0105] Step 64: Calculate the OOM score value according to the memory usage ratio of the target application process and the OOM Adj value. The calculation formula is as follows:

[0106] OOM score = (OOM Adj + 1000) / 2000 * memory usage percentage * 100;

[0107] Among them, the memory usage percentage refers to the proportion of memory used by the process to the total system memory. The higher the usage, the easier it is to be killed. For example: the OOM Adj value is 500 (a normal service process that has not been set up with an application whitelist), the process occupies 10% of the total memory, and the OOM score calculation value is 7.5. If oom_adj is -800 (application whitelist process), the OOM score value is 1. The higher the OOM score value, the easier it is for the application to be killed. In this case, the process that has not been set up with an application whitelist will be killed first when there is insufficient memory, while the process that has been set up with an application whitelist is more likely to survive.

[0108] Step 65: Increase the priority of the target application according to the OOM score value. The OOM score value determines the priority of killing the process. The larger the OOM score value, the lower the priority. System resources are limited. Some critical tasks may require higher priorities, while ordinary applications can be restricted. Through the application whitelist mechanism, the process priority is dynamically managed to improve the accuracy of resource allocation and avoid resources being occupied by low-priority processes, which affects the execution of critical tasks.

[0109] The OOM Adj value set for the target application in the application whitelist of the present invention is PERSISTENT_PROC_ADJ=-800, which is a system persistent process; the OOM Adj value of this process is more persistent and stable than the value of -700 to 1000, and is not easily killed; but if SYSTEM_ADJ=-900 and NATIVE_ADJ=-1000 are used, although it is more stable, it is easy to interfere with the default application in the system and cause the system to crash. Because it is most reasonable to use OOM Adj value=-800. Processes at this priority level will survive first when memory is insufficient, and the system will immediately restart the process even if it is killed or crashes, so the user's key process can be set at this priority.

[0110] The design points of the present invention are as follows:

[0111] 1. Design and implementation of dynamic application whitelist mechanism:

[0112] Process management based on application whitelist refines traditional global process management to the level of individual applications, and implements dynamic and scenario-based priority adjustment through application whitelist.

[0113] 2. Dynamically store and manage process priorities through Android Settings:

[0114] There is no need to add custom APIs. Process priority adjustment, centralization and ease of use can be achieved directly through the Android native Settings API interface, avoiding direct operation of the underlying / proc file.

[0115] 3. Strategies and implementation methods for dynamically adjusting application priorities:

[0116] Balance system resources and user experience, adjust OOM Adj value through application whitelist, ensure priority survival of key businesses, and reasonably release system resources for non-critical tasks to achieve a balance between performance and stability.

[0117] 4. Application whitelist permission control and access mechanism:

[0118] All applications can read the application whitelist, and the write permission of the application whitelist is restricted to applications with customized special permissions, avoiding the risk of external applications manipulating the application whitelist.

[0119] 5. User-friendly and visual management:

[0120] Based on the deep integration of Settings API and system settings interface, customers can also customize their own operation interface, allowing administrators and users to easily configure application whitelists without the need for professional technical background.

[0121] 6. Reduce development and maintenance costs:

[0122] Use Settings API and system services to replace complex code modifications on the application side, eliminating the need to write a large amount of code logic for keep-alive measures, greatly reducing development complexity and subsequent maintenance workload.

[0123] like Figure 2 As shown, an embodiment of the present invention further provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above-mentioned method for dynamically configuring keep-alive applications on the Android platform when executing the program.

[0124] like Figure 3 As shown, an embodiment of the present invention further provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the method for dynamically configuring keep-alive applications on the Android platform is implemented.

[0125] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0126] If the integrated unit is implemented in the form of 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 the present invention, 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, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, server, or network device, etc.) or a processor (processor) to perform all or part of the steps of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0127] The above descriptions are only some embodiments of the present invention, and are not intended to limit the protection scope of the present invention. Any equivalent device or equivalent process transformation made using the contents of the present invention specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present invention.< / pid> < / pid>

Claims

1. A method for dynamically configuring keep-alive applications on an Android platform, characterized in that: The steps include: Step 1: Define an application whitelist format to support configuring the package names of multiple applications; Step 2: Add the package name of the application that needs to increase the priority to the application whitelist; Step 3: Store the application whitelist in the database; Step 4: monitor the data changes of the application whitelist in the database in real time; Step 5: When the data in the application whitelist is monitored to change, the package names of all applications in the Android system are read and matched with the package names in the application whitelist. The application with the matching package name is used as the target application. Step 6: Modify the OOM Adj value of the target application process to increase the priority of the target application to survive when memory is insufficient.

2. The method for dynamically configuring keep-alive applications on an Android platform as claimed in claim 1, characterized in that: The package name of the application is a unique identification string that distinguishes each application on Android.

3. The method for dynamically configuring keep-alive applications on an Android platform as claimed in claim 1, characterized in that: The step 3 is specifically as follows: using the Android native Settings API interface as the entry of the application whitelist, and storing the application whitelist in the Secure database of the Settings system through the Settings API interface.

4. The method for dynamically configuring keep-alive applications on an Android platform as claimed in claim 3, characterized in that: The step 4 specifically includes: Step 41: When the application whitelist is created, it has a corresponding field. A unique URI is configured for the field of the application whitelist. The URI is stored together with the field of the application whitelist in the Secure database. Step 42: Set up a mechanism for monitoring URI data changes; Step 43: When there is no application whitelist in the Secure database, the default URI is None; Step 44: monitor the URI of the application whitelist in the Secure database in real time through the data change mechanism, compare the newly received URI with the existing URI, and if the URI of the application whitelist is monitored to change, including the URI from non-existent to existing and the URI value change, it means that the field of the application whitelist has changed, and enter step 45; if the URI of the application whitelist is monitored to be unchanged, it means that the field of the application whitelist has not changed, and no processing is performed; Step 45: Update the application whitelist and corresponding URI in the Secure database.

5. The method for dynamically configuring keep-alive applications on an Android platform as claimed in claim 4, characterized in that: After step 45, the following steps are also included: Step 46: The user registers in the service process and specifies the URI corresponding to the field of the application whitelist. When a change in the URI is detected, a notification message is generated and sent to the service process.

6. The method for dynamically configuring keep-alive applications on an Android platform as claimed in claim 4, characterized in that: The step 5 comprises: Step 51: When a change in the URI is detected, read the list of all applications in the Android system and traverse the package name list of all applications; Step 52: Compare each package name in the package name list of all applications with the package name in the application whitelist one by one; Step 53: Determine whether the package name in the package name list of all applications matches the package name in the application whitelist according to the comparison result. If so, take the application with the matching package name as the target application and proceed to step 6; otherwise, do nothing.

7. The method for dynamically configuring keep-alive applications on an Android platform as claimed in claim 1, characterized in that: The step 6 specifically includes: Step 61: When the application starts the process, it is assigned a default OOM Adj value. Step 62, judging the running state of the target application, if the target application is not in the running state, then wait until the next time the target application process is started, and then proceed to step 63; if the target application is already in the running state, then directly proceed to step 63; Step 63: Enter the file node of the current process of the target application to modify the OOM Adj value of the target application process; Step 64: Calculate the OOM score value according to the memory usage ratio of the target application process and the OOM Adj value. The calculation formula is as follows: OOM score = (OOM Adj + 1000) / 2000 * memory usage percentage * 100; Among them, the memory usage percentage is the ratio of the memory used by the process to the total system memory; Step 65: Increase the priority of the target application according to the OOM score value. The OOM score value determines the priority of killing the process. The larger the OOM score value, the lower the priority.

8. The method for dynamically configuring keep-alive applications on an Android platform as claimed in claim 7, characterized in that: The OOMAdj value is an integer value indicating the OOM priority of the process; the larger the OOM Adj value, the lower the priority; The OOM Adj value is managed by ActivityManagerService and LowMemoryKiller drivers, and the allocated OOM Adj values ​​are, from large to small, the maximum OOM Adj value of the invisible process, the minimum adj value of the invisible process, the OOM Adj value of the Service service in list B, the OOM Adj value of the first application in the cached application, the OOM Adj value of the process where the Home application is located, the OOM Adj value of the service process, the OOM Adj value of the heavyweight process in the background, the OOM Adj value of the process entering the background, the OOM Adj value of the perceptible process, the OOM Adj value of the visible process, the OOM Adj value of the foreground process, the OOM Adj value of the process bound to the system or persistent process, the OOM Adj value of the system persistent process, the OOMAdj value of the system process, and the OOM Adj value of the local process; Change the OOM Adj value of the target application process to the OOM Adj value corresponding to the system persistent process.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the method for dynamically configuring keep-alive applications on an Android platform as described in any one of claims 1 to 8 is implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method for dynamically configuring keep-alive applications on an Android platform as described in any one of claims 1 to 8 is implemented.

Images