Android Service active attack and defense

The company launched a project in June of 15, which is similar to the application of travel software to upload real-time latitude and longitude, which involves the problem of backstage Service security. Because of the business scene, the problem of keeping alive is actually encountered by many developers, and many people ask questions on the Internet, such as: how to make the Android program run in the background, like QQ, WeChat and not killed? There are many respondents, but there are several ways to achieve the desired effect. Next, I will talk about the various plans combined with my own development experience.

One, why do you want to live?

The source of the survival is because we hope that our service or process can run in the background, but there are all kinds of reasons that cause our hopes to be disillusioned. The main reasons are as follows: 1, Android system recovery; 2, mobile phone manufacturer’s custom management system, such as power management, memory management, and so on; 3, third square. Software; 4, user manual end.

Two. The means of keeping alive

1. Modify the return value of the onStartCommand method of Service

Can the service be restarted when the service is aborted? The general practice is to modify the return value and return START_ STICKY. OnStartCommand () returns an integer value to describe whether the system will continue to start the service after killing the service. There are three kinds of return values:

START_STICKY: if the service process is dropped by kill, the state of the reservation of the service is the start state, but the delivery intent object is not retained, and the system will then try to recreate the service.

START_NOT_STICKY: when using this return value, if the service is dropped by the exception kill after the execution of the onStartCommand, the system will set it to a started state, and the system will not automatically restart the service.

START_REDELIVER_INTENT: when using this return value, if the service is dropped by the exception kill after the execution of the onStartCommand, it will automatically restart the service after a period of time and pass the value of the Intent into it.

[feasibility] see the explanation of the three return values, which looks like the hope of keeping alive. Is it possible to achieve our goal by setting the return value to START_ STICKY or START_REDELIVER INTENT? But in fact, after the actual test, only a few cases and models can be restarted except for the lack of memory.

2, Service onDestory method restarted

After onDestory sends a broadcast and receives the broadcast, it restarts the Service.


Public void onDestroy () {

StopForeground (true);

Intent intent = new Intent ("");

SendBroadcast (intent);

Super.onDestroy ();


[feasibility] under 4 reasons of appeal, Service was killed, and the APP process was basically dry out, and neither the onDestroy method was executed, so there was no way to start the service.

3. Improve the Service priority

Increase priority in Service registration

< service android:name=" com.dwd.service.LocationService" android:exported=" false" >

< intent-filter android:priority=" 1000" > < /intent-filter>

< /service>

[feasibility] this method is invalid for Service, and service has no such attribute.

4. Front desk service

The front desk is considered to be a running service known to the user. When the system needs to release the memory, it will not kill the process, and the front service must have a notification in the status bar.

NotificationCompat.Builder NB = new NotificationCompat.Builder (this);

Nb.setOngoing (true);

Nb.setContentTitle (getString (R.string.app_name));

Nb.setContentText (getString (R.string.app_name));

Nb.setSmallIcon (R.drawable.icon);

PendingIntent pendingintent = PendingIntent.getActivity (this, 0, new Intent (this, Main.class), 0);

Nb.setContentIntent (pendingIntent);

StartForeground (1423, ());

[feasibility] this method has a certain effect on preventing system recovery and can reduce the probability of recovery, but the system will be dropped by kill in the case of very low memory, and it will not be restarted. And the cleaning tool or manual forced end, the process will be hung up and will not be restarted.

5. Process Guardians

There are two ways to implement this scheme, one is dual service or two processes, starting two services and listening to each other. One is hung, and the other will start up the service. Another way is to pull a sub process from the native layer to the main process in fork.

[feasibility] first way, the two process or the two services will hang up with the application process, so it will not start. When the second ways are killed, it can really wake up, but the Android 5 and above will put the fork out of the process in a process group. When the program master process is hung up, the whole process group will be killed, so it can not be awakened in the Android5.0 and above system by the way of fork.

6, monitoring system broadcasting

By listening to some broadcasts of the system, such as mobile phone boot, Jie Suoping, network connection status change, application status change, and so on, then determine whether Service is alive, if otherwise Service is started.

[feasibility] after the 3.1 version of the Android system, in order to strengthen the system security and optimize the performance of the system broadcast restrictions, the application monitoring mobile phone boot, Jie Suoping, network connection status change and other regular system broadcast after the android3.1, the first installation is not started or the user forced to stop, the application can not be monitored. Hear. In addition, the latest Android N canceled the network switch broadcast, it is really sad, no one can use it.

7. Interoperability between applications

Use the different app processes to use radio to wake up each other, such as Alipay, Taobao, Tmall, and other Ali, such as the app, if open any of the applications, the other Ali app will wake up, in fact, the BAT system is almost all. In addition, a lot of push SDK will also wake up app.

[feasibility] multiple app application wake-up calls need to be related to each other, so that the SDK application wakeup can not be waken up when the user is forced to stop.

8, activity a pixel point

After the application is back to the backstage, another page with only 1 pixels stays on the desktop to keep the front desk and protect himself from the backstage cleaning tools to kill. This scheme is the practice of millet exposure to Tencent QQ.

[feasibility] will still be killed.

9. Install APK to /system/app and transform it to system level application.

[feasibility] this method is only suitable for pre installation applications, and ordinary applications can not be transformed into system level applications.

10, using the account and synchronization mechanism provided by Android system.

Create an account in the application, then open auto synchronization and set the synchronization interval, and use synchronization to wake up app. After the account is established, the account number can be seen in the mobile phone setting – account. The user may delete the account or stop the synchronization, so it is necessary to check whether the account can synchronize regularly.

/ / establish account number

AccountManager accountManager = AccountManager.get (mContext);

Account riderAccount = new Account (mContext.getString (R.string.app_name), Constant.ACCOUNT_TYPE); accountManager.addAccountExplicitly (riderAccount, mContext.getString (R.string.app_name), null); Lver.addPeriodicSync (riderAccount, Constant.ACCOUNT_AUTHORITY, new Bundle (), 60);

/ / open synchronization

ContentResolver.setSyncAutomatically (riderAccount, Constant.ACCOUNT_AUTHORITY, true);

[feasibility] except for Meizu mobile phones, this program can successfully wake up app, no matter how it is killed. In addition, the millet phone needs to close the Shenyin mode. This plan has been put forward for nearly a year, and now many developers are using it.

11, white list

Put the application into the white list of mobile phones or security software to ensure that the process is not reclaimed by the system, such as WeChat and QQ in the white list of millet, so WeChat will not be dried up by the system, but the user can stop.

[feasibility] the success rate of this scheme is good, but users can still manually kill the application. In addition, if the user base is not big enough, the application developers will go to the big manufacturers to talk about it. The domestic Android mobile phone manufacturers are too numerous and too costly. But when the installed capacity and the active users reach WeChat, maybe the manufacturer will take the initiative to add your application to the white list.

I applied 4, 6, 7 and 10 of these four programs to ensure that 90% of the mobile phones were successfully protected. Service is actually a war and defense war, the application in order to demand the need to realize the backstage operation, but the system for performance security and other factors to consider the back of the backstage service. Moreover, Bao Huo is also a protracted war. Maybe the current feasible plan was destroyed by Gordon one day. There is no end to learning, and exploration never stops.

Leave a Reply

Your email address will not be published. Required fields are marked *