Service粘性启动方式

转载自：https://blog.csdn.net/wei_chong_chong/article/details/50463593

Service的粘性表现为其所在进程被意外中止后，该Service是否可以自动重新被启动。

默认情况下，使用 startService() 方法激活的Service组件时粘性的，则即使所在进程被意外中止了，稍后该Service依然会被自动创建出来。

设置Service的粘性:

在Service生命周期中onStartCommand()方法的返回值决定了Service的粘性。
该方法的返回值可以被设置为：

START_STICKY: 粘性的，被意外中止后自动重启，但丢失原来激活它的Intent
START_NO_STICKY: 非粘性的，被意外中止后不会重新启动
START_REDELIVER_INTENT: 粘性的且重新发送Intent,即被意外中止后自动重启，且该Service组件将得到原来用于激活它的Intent对象
START_STICKY_COMPATIBILITY:START_STICKY的兼容版本，并不担保onStartCommand()会被重新调用

如何保证Service一直运行，不被杀死?

Android 开发的过程中，每次调用startService(Intent)的时候，都会调用该Service对象的onStartCommand(Intent,int,int)方法，然后在onStartCommand方法中做一些处理。

从Android官方文档中，我们知道onStartCommand有4种int返回值，首先简单地讲讲int返回值的作用。

一、onStartCommand有4种返回值：

START_STICKY：如果service进程被kill掉，保留service的状态为开始状态，但不保留递送的intent对象。随后系统会尝试重新创建service，由于服务状态为开始状态，所以创建服务后一定会调用onStartCommand(Intent,int,int)方法。如果在此期间没有任何启动命令被传递到service，那么参数Intent将为null。
START_NOT_STICKY：“非粘性的”。使用这个返回值时，如果在执行完onStartCommand后，服务被异常kill掉，系统不会自动重启该服务。
START_REDELIVER_INTENT：重传Intent。使用这个返回值时，如果在执行完onStartCommand后，服务被异常kill掉，系统会自动重启该服务，并将Intent的值传入。
START_STICKY_COMPATIBILITY：START_STICKY的兼容版本，但不保证服务被kill后一定能重启。

二、创建不被杀死的service

1.在service中重写下面的方法，这个方法有三个返回值， START_STICKY（或START_STICKY_COMPATIBILITY）是service被kill掉后自动重写创建

@Override
public int onStartCommand(Intent intent, int flags, int startId){return START_STICKY_COMPATIBILITY;//return super.onStartCommand(intent, flags, startId);
}

或

@Override
public int onStartCommand(Intent intent, int flags, int startId){flags = START_STICKY;return super.onStartCommand(intent, flags, startId);// return START_REDELIVER_INTENT;
}@Override
public void onStart(Intent intent, int startId){// 再次动态注册广播IntentFilter localIntentFilter = new IntentFilter("android.intent.action.USER_PRESENT");localIntentFilter.setPriority(Integer.MAX_VALUE);// 整形最大值myReceiver searchReceiver = new myReceiver();registerReceiver(searchReceiver, localIntentFilter);super.onStart(intent, startId);
}

2.在Service的onDestroy()中重启Service.

public void onDestroy(){Intent localIntent = new Intent();localIntent.setClass(this, MyService.class); // 销毁时重新启动Servicethis.startService(localIntent);
}

3.创建一个广播

public class myReceiver extends BroadcastReceiver{@Overridepublic void onReceive(Context context, Intent intent){context.startService(new Intent(context, Google.class));}
}

4.AndroidManifest.xml中注册广播myReceiver及MyService服务

<receiver android:name=".myReceiver" ><intent-filter android:priority="2147483647" ><!–优先级加最高–><!– 系统启动完成后会调用 –><action android:name="android.intent.action.BOOT_COMPLETED" />              <!– 解锁完成后会调用 –><action android:name="android.intent.action.USER_PRESENT" /><!– 监听情景切换 –><action android:name="android.media.RINGER_MODE_CHANGED" />              </intent-filter>
</receiver><service android:name=".MyService" >

注：解锁，启动，切换场景激活广播需加权限，如启动完成，及手机机状态等。

<uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
<uses-permission android:name="android.permission.READ_PHONE_STATE" />

亲测ZTE U795手机Android 4.0.4版本adb push到system\app下android:persistent=“true”

变成核心程序，在360杀掉进程的时候，myReceiver照样有效，保证service重生。呃

KILL问题：
    1. settings 中 stop service
onDestroy方法中，调用startService进行Service的重启。
    2. settings中force stop 应用
捕捉系统进行广播（action为android.intent.action.PACKAGE_RESTARTED）
    3. 借助第三方应用kill掉running task
提升service的优先级，程序签名，或adb push到system\app下等

相较于/data/app下的应用，放在/system/app下的应用享受更多的特权，比如若在其Manifest.xml文件中设置persistent属性为true，则可使其免受out-of-memory killer的影响。如应用程序’Phone’的AndroidManifest.xml文件：

<application android:name="PhoneApp"android:persistent="true"android:label="@string/dialerIconLabel"android:icon="@drawable/ic_launcher_phone">…
</application>

设置后app提升为系统核心级别