如何让自己的Android程序永不被系统kill

转载自：http://thelostriver.blog.163.com/blog/static/130364744201231385646838/

相关知识：

一般来说，在Android系统中，当某进程较长时间不活动，或系统资源比较紧时，该进程可能被系统kill掉，以此来回收一些资源。Android系统会根据进程的优先级来选择性地杀死一些进程，优先级从高到低依次是：

1. 前台进程（Foreground Process）

2. 可视进程（Visible Process）

3. 服务进程（Service Process）

4. 后台进程（Background Process）

5. 空进程（Empty Process）

1. 前台进程（Foreground Process）是指当前的活动进程，即那些有窗口、控件的，正与用户进行交互的应用程序进程。Android会努力尝试从其它进程回收系统资源来保持其响应。

2. 可见进程（Visible Process）是指那些可见的活动进程，但是当前它不在前台运行，不能对用户事件作出反映。比如一个程序A正在前台运行，接着又启动了另一个程序B，程序B的窗口把程序A的窗口完全或部分遮挡，那么，程序A现在就属于可见进程了。一般来说，只有在系统资源十分缺乏的情况下，为了保证活动进程的运行，系统才会终止它。

3. 服务进程（Service Process）是指那些没有可见界面的进程，它们不能直接与用户进行交互。前台进程（通常是一个Activity）变为非活动时，会暂停运行；但服务进程可在后台保持运行，因此如果要保持进程在转到后台后也能运行，就必需启动一个Service。但是一旦前台进程需要资源时，Service就很容易被系统给kill掉。通常，默认情况下Service被kill掉后会自动重启，但是重启后并不能保证恢复先前的环境；如果不需要Service自动重启，调用stopSelf()函数即可。

4. 后台进程（Background Process）是指不可见的，且没有任何正在运行的服务的活动的进程。通常后台进程会比较多，Android将按“最后一个被看到，第一个终止”的方式来终止它们，从而为前台进程提供资源。

5. 对于空进程，Android为了提高系统的整体性能，经常在在应用程序的生存期结束后仍然把它们保存在内存中，当该程序被再次启动时，可以加快启动速度。这类进程会根据需要被定期终止。

由上可知，要想自己所写的Service不轻易被系统在回收资源时kill掉，正常的做法是尽量提高程序的优先级，如调用startForeground(true)。因为Service启动时默认被标记为Background，当前运行的Activity被标记为Foreground，当将Service设置为Foreground后，它的优先级就与正在运行的Activity类似，但是这也不能保证它不被系统kill。

如果我们要写一个监控程序，监测其它程序的运行，那么该怎么办呢？我们必需保证我们的程序不会因回收资源而kill。显然，优先级为2-5的进程都不可靠，作为监控程序，其优先级也不可能为1。

这样看上去，貌似没有办法了……别急，继续看下面……

解决方法：

简单地说，就是将自己写的Service变成Core Service，即将自己写的程序提升为系统级别的程序，这样在任何情况下它都不会被kill掉。

要想自己写的Service提升为Core Service，应用程序需要设置两个标志：FLAG_PERSISTENT和FLAG_SYSTEM。

具体做法如下：

1. 设置FLAG_PERSISTENT：在AndroidManifest.xml文件中，加入android:persistent="true" ；

2. 设置FLAG_SYSTEM：将你写的应用程序放到/system/app/目录下即可。具体操作如下：

A. 使用Cygwin或cmd进入你工程所在的bin目录中，然后执行如下两条命令：

adb remount

adb push yourpackage.apk /system/app/

命令adb remount是为了获取系统目录的临时操作权限，然后使用push命令将自己写的程序包上传到系统应用程序目录中。

B. 重启手机。开机后，在应用列表中就可以看到你写的程序了。

需要说明的是：系统程序不能像非系统程序那样使用adb install yourpackage.apk来安装apk包，我们只需要将apk包拷贝到/system/app/目录下重启即可。如果使用adb install的方式，那么FLAG_SYSTEM标志不会被设置，FLAG_PERSISTENT标志也将不起任何作用。

C. 如果需要卸载自己写的系统应用程序，可执行如下命令：

adb remount

adb shell rm /system/app/yourpackage.apk

另外，还需要说明的是，如果想在模拟器中加入自己写的系统级应用程序，好像不行，因为将apk复制到/system/app/下后，还必需重启，但模拟器一重启，系统目录也将恢复初始状态。不过网上好像有人做到了，方法也很简单，就是将Android源码相应地方稍改下，然后重新编译……

现在，我们就可以让我们的程序为所欲为了～ 

——by T.L.R.

转载自：http://my.oschina.net/f839903061/blog/146709

1.在service中重写下面的方法，这个方法有三个返回值， START_STICKY是service被kill掉后自动重写创建
[代码]java代码：
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
return START_STICKY;
}----------------
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
// TODO Auto-generated method stub
Log.v("TrafficService","startCommand");


flags = START_STICKY;
return super.onStartCommand(intent, flags, startId);
// return START_REDELIVER_INTENT;
}
2.在Service的onDestroy()中重启Service.
public void onDestroy() { 
Intent localIntent = new Intent();
localIntent.setClass(this, MyService.class); //销毁时重新启动Service
this.startService(localIntent);
}


用qq管家杀掉进程的时候，调用的是系统自带的强制kill功能（即settings里的），在kill时，会将应用的整个进程停掉，当然包括service在内，如果在running里将service强制kill掉，显示进程还在。不管是kill整个进程还是只kill掉进应用的 service，都不会重新启动service。不知道你是怎么实现重启的，实在是不解。 在eclipse中，用stop按钮kill掉进程的时候，倒是会重启service
KILL问题：
1. settings 中stop service
onDestroy方法中，调用startService进行Service的重启。
2.settings中force stop 应用
捕捉系统进行广播（action为android.intent.action.PACKAGE_RESTARTED）
3. 借助第三方应用kill掉running task
提升service的优先级
service开机启动
今天我们主要来探讨android怎么让一个service开机自动启动功能的实现。Android手机在启动的过程中会触发一个Standard Broadcast Action，名字叫android.intent.action.BOOT_COMPLETED(记得只会触发一次呀),在这里我们可以通过构建一个广播接收者来接收这个这个action.下面我就来简单写以下实现的步骤： 
第一步：首先创建一个广播接收者,重构其抽象方法 onReceive(Context context, Intent intent)，在其中启动你想要启动的Service或app。
[代码]java代码：
import android.content.BroadcastReceiver; 
import android.content.Context; 
import android.content.Intent; 
import android.util.Log; 


public class BootBroadcastReceiver extends BroadcastReceiver { 
//重写onReceive方法 
@Override 
public void onReceive(Context context, Intent intent) { 
//后边的XXX.class就是要启动的服务 
Intent service = new Intent(context,XXXclass); 
context.startService(service); 
Log.v("TAG", "开机自动服务自动启动....."); 
//启动应用，参数为需要自动启动的应用的包名
Intent intent = getPackageManager().getLaunchIntentForPackage(packageName);
context.startActivity(intent ); 
} 


} 
第二步：配置xml文件，在re
ceiver接收这种添加intent-filter配置 
[代码]java代码：
<receiver android:name="BootBroadcastReceiver"> 
<intent-filter> 
<action android:name="android.intent.action.BOOT_COMPLETED"></action> 
<category android:name="android.intent.category.LAUNCHER" /> 
</intent-filter> 
</receiver>


第三步：添加权限 <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" /> 
如何实现一个不会被杀死的进程
看Android的文档知道，当进程长期不活动，或系统需要资源时，会自动清理门户，杀死一些Service，和不可见的Activity等所在的进程。
但是如果某个进程不想被杀死（如数据缓存进程，或状态监控进程，或远程服务进程），应该怎么做，才能使进程不被杀死。
add android:persistent="true" into the <application> section in your AndroidManifest.xml
切记，这个 不可滥用，系统中用这个的service，app一多，整个系统就完蛋了。
目前系统中有phone等非常有限的，必须一直活着的应用在试用。
提升service优先级的方法
Android 系统对于内存管理有自己的一套方法，为了保障系统有序稳定的运信，系统内部会自动分配，控制程序的内存使用。当系统觉得当前的资源非常有限的时候，为了保 证一些优先级高的程序能运行，就会杀掉一些他认为不重要的程序或者服务来释放内存。这样就能保证真正对用户有用的程序仍然再运行。如果你的 Service 碰上了这种情况，多半会先被杀掉。但如果你增加 Service 的优先级就能让他多留一会，我们可以用 setForeground(true) 来设置 Service 的优先级。 
　　为什么是 foreground ? 默认启动的 Service 是被标记为 background，当前运行的 Activity 一般被标记为 foreground，也就是说你给 Service 设置了 foreground 那么他就和正在运行的 Activity 类似优先级得到了一定的提高。当让这并不能保证你得 Service 永远不被杀掉，只是提高了他的优先级。 
　　从Android 1.5开始，一个已启动的service可以调用startForeground(int, Notification)将service置为foreground状态，调用stopForeground(boolean)将service置为 background状态。 
　　我们会在调用startForeground(int, Notification)传入参数notification，它会在状态栏里显示正在进行的foreground service。background service不会在状态栏里显示。
　　在Android 1.0中，将一个service置为foreground状态： 
　　setForeground(true); 
　　mNM.notify(id, notification); 
　　将一个service置为background状态： 
　　mNM.cancel(id); 
　　setForeground(false); 
　　对比看出，在1.0 API中调用setForeground(boolean)只是简单的改变service的状态，用户不会有任何觉察。新API中强制将 notification和改变service状态的动作绑定起来，foreground service会在状态栏显示，而background service不会。 
　　Remote service controller & binding 
　　跨进程调用Service。暂时不研究。 
如何防止Android应用中的Service被系统回收? 很多朋友都在问，如何防止Android应用中的Service被系统回收？下面简单解答一下。
对于Service被系统回收，一般做法是通过提高优先级可以解决，在AndroidManifest.xml文件中对于intent-filter可以通过 android:priority = "1000"这个属性设置最高优先级，1000是最高值，如果数字越小则优先级越低，同时实用于广播，推荐大家如果你的应用很重要，可以考虑通过系统常用intent action来触发。

下面这是从另外的网页上看到的，一并转过来了：http://goo.gl/eEfBup

为了提高 我们的Activity中的线程的
线程优先级（Thread-Priority），我们需要在AndroidManifest.xml 中使用 'uses-permission' 这样做:
XML: 
          <uses-permission id="android.permission.RAISED_THREAD_PRIORITY"/>

　　现在你可以在你的Activity中使用以下代码改变或提高任何线程的优先级:
Java: 
          import android.os.Process;
// ...

// -----------------------------------
// Set the priority of the calling thread, based on Linux priorities:
// -----------------------------------

// Changes the Priority of the calling Thread!
Process.setThreadPriority(12);
// Changes the Priority of passed Thread (first param)
Process.setThreadPriority(Process.myTid(), 12);

　　这里 range 的范围是 -20 (高) 到 +19 (低). 不要选得 太高  

　　最好使用预先定义在 android.os.Process 的constants :
Java: 
          // Lower is 'more impotant'
Process.THREAD_PRIORITY_LOWEST = 19
Process.THREAD_PRIORITY_BACKGROUND = 5
Process.THREAD_PRIORITY_DEFAULT = 0
Process.THREAD_PRIORITY_FOREGROUND = -5
Process.THREAD_PRIORITY_DISPLAY = -10
Process.THREAD_PRIORITY_URGENT_DISPLAY = -15

Android-如何让service 不会被第三方kill，有需要的朋友可以参考下。

最近写service的时候，用360等第三方安全任务管理软件清理缓存的时候总是会kil掉服务，于是找了解决方案

Notification notification = new Notification(R.drawable.icon, "服务开启", System.currentTimeMillis());notification.flags|= Notification.FLAG_NO_CLEAR; notification.flags=Notification.FLAG_ONGOING_EVENT;Intent notificationIntent = new Intent(this, MainActivity.class);PendingIntent pendingIntent = PendingIntent.getActivity(this, 0, notificationIntent, 0);notification.setLatestEventInfo(this, "service", "防止服务被任务管理器所杀", pendingIntent);startForeground(ONGOING_NOTIFICATION, notification);这样就能显示一个前台服务，通知栏正在运行有一个显示，清除不了，如果不想显示通知栏又想服务不被杀死呢？

Notification notification = new Notification();startForeground(1, notification);

这样就可以！谷歌上说其实在极端环境下，服务也是会被杀死的，但是这种情况很小，基本不是问题

It is still theoretically possible for the service to be killed under extreme memory pressure from the current foreground application, but in practice this should not be a concern.