Method for activating Android process by multiple strategies
Technical Field
The invention relates to the technical field of application program pull-up, in particular to a method for pulling up an Android process by multiple strategies.
Background
In the Android system, lifecycle management of applications is automatically done by the system. When the system resources are tensed, the system kills some application programs running in the background according to a certain strategy so as to release the resources. This results in the possibility that the application may be killed by the system during background operation, thereby affecting the stable operation of the application. To address this problem, android developers typically use a technique called "pull-up". The "pull-live" is that by some technical means, the application program can be automatically restarted after being killed by the system, thereby ensuring the continuous running of the application program.
The Chinese patent with the application number of CN202011194366.9 discloses a keep-alive pull-alive method for checking and killing an application program, and the method monitors whether the application program is terminated by utilizing a daemon on the premise that the daemon works normally, and when the application program is terminated, the daemon restarts the application program to realize continuous running and restarting of the application program, so that the problems in the related technology are solved to a certain extent. However, this solution still has the following drawbacks: 1. the technical scheme of the dual service daemon is effective only at android8.0 and versions below, and the versions after android8.0 are ineffective, because an operating system can limit the operation of background service in order to save batteries and memory, and if the service is killed by the system, the dual service daemon cannot work normally; 2. the method has the advantages that the limitation is large, the device is not supported to be started and the software is not supported to be pulled after being installed, the scheme relies on broadcasting to inform daemon to be pulled, and the realization premise of broadcasting is that the software must be started to enter for registration and transmission after being installed; 3. detecting hysteresis, the scheme informs the daemon service process to be closed through the system checking and killing to detect whether the application program is checked and killed, and informs the remote service to be closed through a Binder mechanism after the system checking and killing, and the detection hysteresis can be caused because time consumption exists in cross-process communication, so that the daemon cannot be pulled to be active in the shortest time.
Disclosure of Invention
The method integrates various pull-up technical means, adopts an account synchronization mechanism to carry out the pull-up process when an application program is installed, adopts a contact directory mechanism to carry out the pull-up process when equipment is started, adopts a Native layer inter-process file lock monitoring mechanism to carry out the pull-up process when the application program is checked and killed, greatly improves the speed and success rate of re-pull-up after the application program is checked and killed, greatly improves compatibility, usability and efficiency, and can effectively pull up in the shortest time after the application program is checked and killed, and has good use effect.
In order to achieve the above purpose, the present invention adopts the following technical scheme:
a method for activating an Android process by multiple strategies comprises the following steps:
s1, when an application program is installed, an account synchronization mechanism is adopted to carry out a live pulling process; the pulling and activating process of the account synchronization mechanism comprises the following steps:
s11, installing an application program;
s12, respectively registering a content provider, a registration synchronization adapter service and a registration account authentication service;
s13, starting an application program;
s14, creating an automatic synchronous account: designating the name and type of the automatic synchronous account, declaring authority in the program list file, and starting the automatic synchronous function of the account by calling the setIsSyncable method of the contentResolver;
s15, adding a periodic synchronous account: after the synchronous account is established, a new synchronous account is added into the system by calling an addaccounterExplicitly method of an account manager AccountManager;
s16, carrying out live pulling on a regular account program: after the newly created synchronous account is added into the system, the account program of the system is notified to start automatic synchronization by calling the addPeriodiesSync method of the ContentResolver, and the system account program periodically performs synchronous pull-up;
s2, after the application program is installed, when the equipment is started, a contact directory mechanism is adopted to carry out a pull-alive process;
and S3, when the application program is checked and killed, a Native layer inter-process file lock monitoring mechanism is adopted to carry out a pull-active process.
Preferably, the process of registering the content provider in step S12 is: and registering account content providers in the manifest file of the application program, wherein the registered account content providers are used for searching the content providers of the corresponding accounts when the system performs account synchronization and are used for executing the account related query operation.
Preferably, the process of registering the synchronization adapter in step S12 is: in the manifest file of the application program, a synchronous adapter service is registered, the synchronous adapter service is associated with a system account program through a Binder communication mechanism, and the account program is periodically activated.
Preferably, the process of registering the account authentication service in step S12 is: in the manifest file of the application, an account authentication service for setting the type, name, and icon of the synchronous account is registered.
Preferably, the pull-alive procedure of the contact directory mechanism in step S2 is as follows:
s21, installing an application program: the package manager on the device is responsible for installing the application program and scanning the manifest file of the application program;
s22, registering the content provider: registering a contact directory content provider, contact directory, in a manifest file of an application, the content provider being for association with a contact program of a system;
s23, starting equipment: after the equipment is started, the contact person process service android.process.acore is responsible for pulling the program;
s24, detecting a contact directory: the contact program of the system detects a program with a contact directory content provider contact directory in real time;
s25, automatic pull-up procedure: the contacts of the system automatically pull the program of the contact directory content provider contact directory.
Preferably, in step S3, the pull-alive process of the Native layer inter-process file lock monitoring mechanism is as follows:
s31, installing an application program;
s32, registering the monitor: registering a monitor for specifying the target program to be pulled and the target process to be pulled in a manifest file of the application program;
s33, starting an application program;
s34, the application program respectively creates a service process 1 and a service process 2 in the JAVA layer;
s35, the application program calls a Native layer method in the service process 1, and creates a subprocess through twice fork, so as to obtain an orphan process 1; the application program calls a Native layer method in the service process 2, and creates a subprocess through twice fork, so as to obtain an orphan process 2;
s36, creating a shared file lock: the application program creates a shared file lock shared with each other in the orphan process 1 and orphan process 2 of the Native layer;
s37, searching and killing a perception process: the application program judges whether the orphan processes are checked and killed by the system or not by sensing the state of the shared file lock in the Native layer;
s38, the orphan processes are alive: the orphan process 1 and the orphan process 2 establish association through a shared file lock, one orphan process is immediately perceived by the other orphan process after being checked and killed by the system, and then a monitor is started by calling context.
After the technical scheme is adopted, compared with the background technology, the invention has the following advantages:
1. the invention has good compatibility: through testing, the device with the latest Android14 can be effectively activated, and the device with the latest Android14 can be activated on any existing Android version device due to an account synchronization mechanism AccountSyncAdapter.
2. The invention has strong usability: the invention supports the pulling and activating after the equipment is started and the program is installed, which benefits from the contact directory mechanism, when the program is installed or the equipment is started, the contact providing program of the system can automatically pull and activate the program containing the directory provider, thereby greatly improving the usability of the pulling and activating scene.
3. The invention has high pull-out efficiency: the invention can sense and effectively pull and activate in the shortest time after the program is checked and killed, which benefits from the inter-process file lock monitoring mechanism of the Native layer, the program needs to use at least two processes, the processes are related to each other through the file lock in the Native layer, and one process can pull up other related processes immediately after being checked and killed, thereby ensuring higher pull and activate rate.
Drawings
FIG. 1 is a schematic flow chart of the present invention;
FIG. 2 is a schematic diagram of a process for performing pull-up by the account synchronization mechanism of the present invention;
FIG. 3 is a flow chart of the contact directory mechanism of the present invention for pull-alive;
fig. 4 is a schematic flow chart of a Native layer inter-process file lock monitoring mechanism for carrying out pull-alive according to the present invention.
Detailed Description
The present invention will be described in further detail with reference to the drawings and examples, in order to make the objects, technical solutions and advantages of the present invention more apparent. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the invention.
It should be noted that, in the present invention, terms "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", etc. are all based on the orientation or positional relationship shown in the drawings, and are merely for convenience of describing the present invention and simplifying the description, and do not indicate or imply that the apparatus or element of the present invention must have a specific orientation, and thus should not be construed as limiting the present invention.
Examples
As shown in fig. 1 to 4, a method for activating an Android process by using multiple strategies includes the following steps:
s1, when an application program is installed, an account synchronization mechanism is adopted to carry out a live pulling process; the pulling and activating process of the account synchronization mechanism comprises the following steps:
s11, installing an application program;
s12, respectively registering a content provider, a registration synchronization adapter service and a registration account authentication service;
the process of registering the content provider in step S12 is: registering account content providers in a manifest file of an application program, wherein the registered account content providers are used for searching the content providers of corresponding accounts when the system performs account synchronization and executing related query operation of the accounts;
the process of registering the synchronization adapter in step S12 is as follows: registering a synchronous adapter service in a manifest file of an application program, associating the synchronous adapter service with a system account program through a Binder communication mechanism, and periodically activating the account program;
the process of registering the account authentication service in step S12 is as follows: registering an account authentication service in a manifest file of an application program, wherein the account authentication service is used for setting the type, the name and the icon of a synchronous account;
s13, starting an application program;
s14, creating an automatic synchronous account: designating the name and type of the automatic synchronous account, declaring authority in the program list file, and starting the automatic synchronous function of the account by calling the setIsSyncable method of the contentResolver;
s15, adding a periodic synchronous account: after the synchronous account is established, a new synchronous account is added into the system by calling an addaccounterExplicitly method of an account manager AccountManager;
s16, carrying out live pulling on a regular account program: after the newly created synchronous account is added into the system, the account program of the system is notified to start automatic synchronization by calling the addPeriodiesSync method of the ContentResolver, and the system account program periodically performs synchronous pull-up;
s2, after the application program is installed, when the equipment is started, a contact directory mechanism is adopted to carry out a pull-alive process;
the pull-alive process of the contact directory mechanism in step S2 is as follows:
s21, installing an application program: the package manager on the device is responsible for installing the application program and scanning the manifest file of the application program;
s22, registering the content provider: registering a contact directory content provider, contact directory, in a manifest file of an application, the content provider being for association with a contact program of a system;
s23, starting equipment: after the equipment is started, the contact person process service android.process.acore is responsible for pulling the program;
s24, detecting a contact directory: the contact program of the system detects a program with a contact directory content provider contact directory in real time;
s25, automatic pull-up procedure: the contact of the system automatically pulls up a program of a contact directory content provider contact directory;
s3, when the application program is checked and killed, a Native layer inter-process file lock monitoring mechanism is adopted to carry out a live process;
in step S3, the pull-alive process of the Native layer inter-process file lock monitoring mechanism is as follows:
s31, installing an application program;
s32, registering the monitor: registering a monitor for specifying the target program to be pulled and the target process to be pulled in a manifest file of the application program;
s33, starting an application program;
s34, the application program respectively creates a service process 1 and a service process 2 in the JAVA layer;
s35, the application program calls a Native layer method in the service process 1, and creates a subprocess through twice fork, so as to obtain an orphan process 1; the application program calls a Native layer method in the service process 2, and creates a subprocess through twice fork, so as to obtain an orphan process 2;
s36, creating a shared file lock: the application program creates a shared file lock shared with each other in the orphan process 1 and orphan process 2 of the Native layer;
s37, searching and killing a perception process: the application program judges whether the orphan processes are checked and killed by the system or not by sensing the state of the shared file lock in the Native layer;
s38, the orphan processes are alive: the orphan process 1 and the orphan process 2 establish association through a shared file lock, one orphan process is immediately perceived by the other orphan process after being checked and killed by the system, and then a monitor is started by calling context.
The present invention is not limited to the above-mentioned embodiments, and any changes or substitutions that can be easily understood by those skilled in the art within the technical scope of the present invention are intended to be included in the scope of the present invention. Therefore, the protection scope of the present invention should be subject to the protection scope of the claims.