Service的粘性表现为其所在进程被意外中止后,该Service是否可以自动重新被启动。
默认情况下,使用startService()方法激活的Service组件时粘性的,
则即使所在进程被意外中止了,稍后该Service依然会被自动创建出来。
设置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); // 销毁时重新启动Service
this.startService(localIntent);
}
3.创建一个广播
public class myReceiver extends BroadcastReceiver
{
@Override
public 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提升为系统核心级别
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); // 销毁时重新启动Service
this.startService(localIntent);
}
3.创建一个广播
public class myReceiver extends BroadcastReceiver
{
@Override
public 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提升为系统核心级别