Android Background KeepAlive Practice Summary: Instant Messaging applications cannot cure the "stubborn disease"

Objective

The Android process and service keepalive is a big problem for Android developers. Due to the power-saving and memory management strategies, the manufacturers based on their own understanding, in the self room published in the standard Android release as a more or less changes, so that the application layer program in the processing process and service keepalive problem is very complex, and difficult to compatible, Because there might be a change in which phone or version of the power-saving strategy, the difference between process and service keepalive is followed.

In the scenario, due to instant messaging applications (including IM chat application, message push service, etc.) in order to guarantee the full-time, real-time delivery ability of the message, the process or service must be guaranteed to live. This seemingly insignificant problem is actually handled because of the differences in the version of many Android phones and Android systems, which makes the problem handling fraught with uncertainty.

Based on the author's practice and the collation of relevant data, this paper summarizes the understanding of Android process and service KeepAlive, and hopes to inspire the development of your application.

Learning Communication

-More information on instant Messaging: Http://www.52im.net/forum.php?mod=collection&op=all

-Instant Messenger Development Exchange Group: 215891622 [ recommended ]

Overview

Recently made an Android project, involving the background process and service keepalive problem, the Internet to find a lot of information, the basic method of life-preserving test. The result: different mobile phones, different versions of the Android version of the KeepAlive effect vary. The hardest thing to get around is a manufacturer's management of "backstage program KeepAlive".

This paper mainly summarizes the corresponding practice results and the method of preserving life. However, because the author can be used to test the real machine is limited, there may be incomplete places, but also timely to correct and add, we make progress together.

Mobile QQ, such a large-scale IM how to solve the keepalive problem?

Taking Xiaomi mobile phone as an example, MIUI's hidden mode makes many IM and push development peers tangled: After Miui deep hibernation, the default socket is completely disconnected from the background app. But, QQ such application, MIUI official Post said: Give these 2 application special care. Well, special care, the normal app can only continue to toss.

(for a discussion of MIUI's implicit pattern, see this Post's reply:http://www.52im.net/thread-354-1-1.html)

The real machine model and version involved in this practice

Mobile: Samsung 9100-4.1.2, Samsung 9300-4.3, Huawei g730-4.1.2, Huawei tl00h-emui3.1 (Android 5.1.1), Meizu mx4-flyme4.2.8.2c (Android 4.4.2).

That's all the testing machines you can use on hand. The main test service is a basic service that outputs the trigger function for the corresponding life cycle. The test was not added to the background protection, note: Samsung's machine did not find a background protection settings where.

Why is our background process/service going to end?

What I think about is that there are three aspects:

• Android system memory recovery mechanism;
• A management system for the background program (that is, allowing the program to run the background);
• Third-party software cleanup (360 or something).

Some of the background programs to protect the end of the program at the same time will be the program to stop state, resulting in the inability to receive broadcasts!

What are our life-preserving programs? 1) control the return value of the Onstartcommand function:

My understanding of this function is: Do you want to restart the service when the service is terminated abnormally? In some articles, when using this as a keepalive, the change is flag, which is invalid in my actual test. A valid practice is to return parameters directly. In addition, the default flags value is 0, which is start_sticky_compatibility.

The specific code is as follows:

123456

@OverridepublicintonStartCommand(Intent intent,intflags,intstartId) {    // TODO Auto-generated method stub    returnSTART_STICKY;    //return super.onStartCommand(intent, flags, startId);}

Test results:
Meizu's machine is invalid, regardless of the default or modify parameters, in the DDMS directly after the process will not restart the service. Three other machines (9100 not tested): The default parameters will restart the service, return Start_sticky will restart, return start_not_sticky will not restart.

In addition: With 3,601 key cleanup, or 360 super root phone optimization, will kill the process, will be restarted later, but will be much slower, probably in the queue restart service.

2) Restart the service in Ondestory:

This is effective in all cases where the ondestory can be triggered. 4 test machines have been tested. Direct StartService or sending a broadcast restart is possible.

But can trigger the ondestory situation, I do not know that memory recovery will not trigger. The other two cases (2,3) are not triggered. My test method is to stop the service, running with settings, application management. (This is normal stop service, will trigger Ondestory, so the above Onstartcommand effect will not be triggered.) ）

3) Increase the priority of the service:

This is primarily the case for the first kill service, the memory recovery mechanism. Because this test is more difficult to build. 360 Clean out what the process of the background is killed, the concept of priority is not reflected. My advice is to be able to improve on the following several experiments.

[1] Front desk service:
Create a notification to make yourself a front service
Test results:
3,601-Key cleanup and phone optimizer will not end the service.

[2] For background protection:
Huawei G730 does not end the service, Meizu and Huawei Tl00h will end the service. Notification bar of the keepalive effect is still possible, the general application requirements can be satisfied.

[3] If you have root privileges:
Android:persistent= "true" and put in System/app
Test results:
In general, Samsung 9100 on the use of 360 and other cleaning tools to kill the process, in the Huawei G730 no effect. (This test has a little disturbance with Onstartcommand).

4) daemon process:

Dual service: 360 will kill two services at the same time, the same as two apk.
Native Daemon: 360 will not kill native daemon, but will be killed in Meizu and Huawei Tl00h after a period of standby.

Conclusion and continued:
1. After the general application is added to the background protection process, change the Onstartcommand return value and add a notification. Basically, most of them can survive.
2. Dual service I think there is no native daemon to the good, although 360, what there are several process services, but if not added to the background to live, the effect of the same can not be guaranteed to live, will also enter the stop state.
3. But. 360 The phone helper creates a double-natice daemon to do with each other's guards. The effect of survival will be a little bit higher. "Not added to the background keepalive" generally only kills once, (Meizu is 5 minutes after the screen is closed, Huawei Tl00h is when the screen is closed).

Attach a native daemon: using a socket to determine whether a service exists, you need to create a listening socket in the service you are guaranteed to live in. The debug information creates a Daemon.log in the SD card directory. How to use: Ndkfork port Package name/. Service name. Specific download Links:
http://download.csdn.net/detail/pvlking/9412815

A summary of the fundamentals of the Android app for KeepAlive

Is through the two-process mutual pull and the importance of setting the process, unless you root, set your own process into a system process.

There are a number of ways to pull each other:

• You can pull yourself up by listening to the system broadcast.
• Multiple apps can pull each other
• Can make their own services into the front desk service
• Return Statr_stick in the OnStart method of the service
• Add manifest file property value android:persistent= "true"
• OnDestroy Method for overwrite service
• Services are bound to each other
• Set alarms, wake up regularly
• Your app fork a subprocess in the native layer to pull with the main process.

In summary, the conclusion is that the current implementation of the Android back-end is not a perfect implementation, only for different models integrated use of the methods listed above, while praying that the user of the app do not encounter the life of the work of the wonderful model.

Recommend an open source Solution 1) Source Hosting address

The source managed address is: Https://github.com/52im/MarsDaemon.

2) Principle of implementation

principle: using JNI, in the C-end fork process, to detect whether the service is alive, if the service has been killed, then restart the service.    As for the detection mode, you can poll to get the child process PID, if it is 1, then the child process was adopted by the INIT process, has become an orphan process. However, this method consumes more power, and because of the changes made by different phone systems, the parent process is not necessarily killed when the application is forced to stop, so it is not possible to judge on some specific models. It is recommended to use the LIUNX socket to detect similar heartbeat packets, and before triggering the detection service is killed, you need to determine whether the application has been uninstalled, if the application has been uninstalled, no longer detect service behavior, call exit (0) to exit the child process To avoid wasting system resources and consuming power.

Note: currently on the Android 5.0 system will be the fork out of the process into a process group, when the program master process hangs, will also kill the entire process group, so the fork can not be used in Android5.0 and above the system to implement the daemon. This is a system-level limitation, of course, to optimize the overall system environment, the daemon to the mobile phone experience is not good

See the source code specifically:
http://androidxref.com/5.0.0_r2/.../processrecord.java


Good news:
Android5.0 above is now in the Https://github.com/52im/MarsDaemon by the black technology to conquer, some models may not play a role, but the idea is worth reference, code structure is also good, the specific program please see the source OH.

(This article was released synchronously at: http://www.52im.net/thread-429-1-1.html)

Android Background KeepAlive Practice Summary: Instant Messaging applications cannot cure the "stubborn disease"