Android Process resident----Native 5.0 above program deduction process and code

Body:

On an article we through the parent-child process to establish a dual pipeline, to listen to the process of death, after testing, no power consumption problems, no memory consumption problems, can be in the Setup force close under the successful pull up, you can also get to the root of the 360/cleanmaster successfully survived.

But the system put into the 5.0+ can not be used, why? Let's see what the source 4.4 system and the 5.0 system did when the system force close was changed.

4.4.3 's Activitymanagerservice

、

implementation here

Then 5.0 of AMS

Realize

It can be seen that 5.0 of the source code in the system when the strong kill, together with all the processes in the group also killed, using the previous strategy by printing log we can also see that the parent process was killed, wahabbi like to be frozen, do not do anything, can not get the listener events. So what do we do?

Start your own brainstorming and come up with the following strategies:

1, abandon the Java process, using two pure native binary process, mutual keepalive, ensure that the native process resident, and then timely pull up the need for resident Java process.

2, using SETSID to change the session of the sub-process, whether it can let the system does not freeze the child process.

3, the child process to create a child process, and then commit suicide, repeat 1000 times, that is, the parent process and the child process of their own child process repeats 1000 times between the processes of mutual protection, whether you can let the system does not freeze the child process


After trying the code, you can guess, yes, and then the egg. None of these schemes can block the system's force close, let alone 360/cm with root.


So a change of mind, no longer entangled in the father-son process, but two ordinary processes between the mutual protection


In view of the previous use of pipe pipe, the first thought is the FIFO pipeline, which is a two-way pipeline under Linux that can be built between the processes that are not related. The same two processes establish a FIFO pipeline on Layer C, and then block read. But the problem is that this FIFO and pipe is essentially different, FIFO is through a file to do communication, the other side of the process of hanging off, their side will neither error nor return, but has been blocked until the pipeline has data. So, and then the egg.


So, when the process dies, you write the data in the pipeline, the other side of the block read the data can not know that this side of the dead? There was such a moment of ridiculous thought, but it was the first time to know your own death.


This ridiculous idea doesn't make any sense, but he inspires me, what will change between him and the other process when a process dies?


Along this train of thought, I thought of the file lock. Regardless of Windows or Linux will have a set of files of the process synchronization mechanism, for the synchronization of files between the processes, a process can give a file lock, after the operation is finished and then unlocked, other processes if worry about synchronization problems, will first check whether the file has a lock, if there is a lock, on behalf of others are operating , the operation of the file is deferred. Then when a process hangs, the lock he adds to the file will naturally disappear.


So according to this idea, process a to the file 1 lock, and then block read the file 2 of the lock, process B to file 2 lock, and then block read the file 1 lock, if the other process hangs, his process holds the file lock will be released immediately, then another process can be read to the release file lock file, listen to each other to hang up.


To implement this scenario, the first use of Java code, Java is a set of file lock API, but after writing, compile times wrong. I will not write the demo, the wrong message is the deadlock exception, two processes can not hold each other's lock. Java compiler is really a lot of things, so I would like to be able to use three processes, 1 take 2 of the lock, 2 take 3 of the lock, 3 take 1 of the lock, or not, deadlock exception.


With a disturbed mood I use C to achieve the attempt, fortunately, there is no problem in C. Principle, the rest is the code to write robust, the most difficult problem is the synchronization problem, AB two process, if the B process has not been to lock the file, a will begin to read the lock, then you will mistakenly think that the B process hangs. Demand:
1, need to let a process first lock the file 1, and then do not read the file 2, and so on the B process to do the same operation, both sides read the other side of the lock.
2. Need to consider the initial state of the re-entry of the program and the status of a single process waiting for the state conflict problem
3, can not be time-consuming!! Time is important, and later, it says


This piece really wanted to come out all night. Suitable solution, first of all certainly can not use the pipeline, signal these interprocess communication, even memset not consider, because time-consuming, Java layer mechanism is even not to consider! Then you can only use a number of marker means, such as a file in the process on behalf of one, a file is gone, on behalf of a process lock.
So the final synchronization scenario is:

1, 4 files, a process file a1,a2,b process b1,b2


2, a process plus lock file a1,b process similarly


3, a process to create a A2 file, and then poll to see if the B2 file exists (can poll here because of the time is very short), does not exist on behalf of the B process has not been created, B process the same


4, a process polling to the B2 file exists, on behalf of the B process has been created and may be in the B1 file lock, at this time to delete the file B2, on behalf of a process has been locked, allowing the B process to read a process lock, B process similarly


5, a process monitoring file A2, if A2 is deleted, on behalf of the B process to step 4 has been to the B1 lock completion, you can start to read the B1 file lock (not directly listen to the A2 file deletion, that is, can not skip 34 steps, which is the most difficult part, if that is possible at this time B process has not been created, and the B process is created and the lock completion state is the same, will let process a mistakenly for process B lock complete), B process similarly



Look at the code
/marsdaemon/libmarsdaemon/jni/daemon_api21.c

Where A and b two processes will execute this code, for a process, Indicator_self_path corresponds to a1,indicator_daemon_path corresponding b1,observer_self_path corresponding a2,observer_ Daemon_path corresponds to B2,b process

First lock yourself, then add the Sync module notify_and_waitfor

The above code is the above synchronization logic

After the synchronization is complete, two processes simultaneously listens to each other's lock, one side hangs off the other party immediately can monitor hears. This scheme can be used to monitor each other's death status on 5.0+, because they are blocking methods, so there is no power consumption efficiency problem.

Here's to say, Perhaps you read the source code you will ask why step under 5.0, because this program is required to hang two processes, although compared with the parent-child process, under Linux are two processes two PID, but in the Android system settings, the native process in the parent-child process is not the Android system statistics, Will not be listed, will not let users feel why you start so many processes. So from the user experience point of view, 5.0 or below is the use of the previous blog post.

OK, monitor success, the other side to kill each other to pull up, and then suicide, re-initialization. Replace the scheme to find that 5.0 is OK, 360/cm with Root is OK, but in 5.1 is invalid. Why?


Print Log we found that 5.1 on the monitor death status is OK, but can not pull the other side up.


Well, we're going to start with the second point, and that's how to start the other one.


Originally our plan is to use an alarm clock to start the other side, but in 5.1, the alarm clock in force close, the alarm clock will also be discarded, the previous pull-up scheme does not work, then began to think how to pull the other side of the process up, think for a long time there is no other way, Sending intent does not seem to execute at all, but at this point the situation can only continue to investigate why the intent is not executed.


By printing log, we found that when force close, the system killed the application of the corresponding process, the speed is very fast, in a process to hear the B process was killed, the system's death sickle has reached the a process, about dozens of milliseconds time! and send a intent we know he was in his own process using the system Activitymanagerservice a proxy class, through a binder to pass intent to the system, although most of the operation is in AMS, But our execution time actually also in hundred millisecond level, no wonder intent send out.

So time is very important!!! We need to a footrace with the system.

So now the question is how to send intent, view the source code, we can see that the intent is actually activitymanagernative this class, he holds a binder, Used to communicate with the system's Activitymanagerservice, and then we send intent to initialize a parcel, through binder transcate past.

Time is spent on the creation of Pacel.

Then we can put these time-consuming operations at the beginning of the process to complete, wait until the hearing process hangs, call directly.

But that binder we can't get directly, we need to use reflection here.

Look at the code:

Code Com.marswin89.marsdaemon.strategy.DaemonStrategy22.java

Get the Activitymanagernative instance and take the binder, which is one of his member variables Mremote

And then the pacel initialized, here is my line of comments out of the test, in order to save time, in the premise of achieving the goal, the less time the better, so the parameters can be less transmitted.

It then calls the Transcate method directly when it detects that the other process is dead.

Two-way guard can also be implemented on ok,5.1.

But unfortunately, 6.0 on kneeling again.

After the investigation, it was found that the method of binder transcate in the above way could not start a service. What should we do then? Try to hold the heart tried Broadcastreceiver, indeed broadcast is possible. The same principle uses the binder in the activitymanagernative transcate a pacel to initiate a broadcast pull up process.

It is also the pacel of the broadcast that imitates the system source code.

Code Com.marswin89.marsdaemon.strategy.DaemonStrategy22.java

ok,6.0 is also done.

The system force close succeeded in pulling up the other side, but there was a certain chance that the 360\clean master with root would kneel. Through the log can be seen, in a key cleanup when there is a successful pull up, but 360\cm will be repeated kill, was pulled up the new process has not been initialized to complete, and was killed.

Again, time is very important!!! We're going to a footrace with 360\cm.

Here we use multi-threading when the process was just created, and synchronizing the file with the lock to start another process at the same time, which can save about 100 milliseconds.

Done!

From 5.0 to 6.0, the force close and 360\cm with root can be used to protect each other under one key cleanup.

Android Process resident----Native 5.0 above program deduction process and code