android防止被kill_怎么让Android程序一直后台运行像QQ一样不被杀死

① android怎么让activity不被杀死

② Android防止杀进程

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来触发。

③ android后台服务保持，不被杀死

作者：闭关写代码
链接：https://www.hu.com/question/29826231/answer/71207109
来源：知乎
着作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

强烈建议不要这么做，不仅仅从用户角度考虑，作为Android开发者也有责任去维护Android的生态环境。现在很多Android开发工程师，主力机居然是iPhone而不是Android设备，感到相当悲哀。
从技术角度概括一下现在普遍的防杀方法

Service设置成START_STICKY，kill 后会被重启（等待5秒左右），重传Intent，保持与重启前一样
通过 startForeground将进程设置为前台进程，做前台服务，优先级和前台应用一个级别，除非在系统内存非常缺，否则此进程不会被 kill

双进程Service：让2个进程互相保护，其中一个Service被清理后，另外没被清理的进程可以立即重启进程
QQ黑科技:在应用退到后台后，另起一个只有 1 像素的页面停留在桌面上，让自己保持前台状态，保护自己不被后台清理工具杀死
在已经root的设备下，修改相应的权限文件，将App伪装成系统级的应用（Android4.0系列的一个漏洞，已经确认可行）
Android系统中当前进程(Process)fork出来的子进程，被系统认为是两个不同的进程。当父进程被杀死的时候，子进程仍然可以存活，并不受影响。鉴于目前提到的在Android-Service层做双守护都会失败，我们可以fork出c进程，多进程守护。死循环在那检查是否还存在，具体的思路如下（Android5.0以下可行）
用C编写守护进程(即子进程)，守护进程做的事情就是循环检查目标进程是否存在，不存在则启动它。
在NDK环境中将1中编写的C代码编译打包成可执行文件(BUILD_EXECUTABLE)。
主进程启动时将守护进程放入私有目录下，赋予可执行权限，启动它即可。
联系厂商，加入白名单
------------------------------------------------------
TIP: 面对各种流氓软件后台常驻问题，建议使用“绿色守护”来解决，可是杀掉那些第三方清理工具难以清除的后台程序

④ 怎么让Android程序一直后台运行，像QQ一样不被杀死

方法：
对于一个service，可以首先把它设为在前台运行：
public void MyService.onCreate() {
super.onCreate();
Notification notification = new Notification(android.R.drawable.my_service_icon,
"my_service_name",
System.currentTimeMillis());
PendingIntent p_intent = PendingIntent.getActivity(this, 0,
new Intent(this, MyMainActivity.class), 0);
notification.setLatestEventInfo(this, "MyServiceNotification, "MyServiceNotification is Running!", p_intent);
Log.d(TAG, String.format("notification = %s", notification));
startForeground(0x1982, notification); // notification ID: 0x1982, you can name it as you will.
}

重要设置-------------------------------
相较于/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提升为系统核心级别，任何情况下不会被kill掉, settings->applications里面也会屏蔽掉stop操作。

这样设置前的log: Proc #19: adj=svc /B 4067b028 255:com.xxx.xxx/10001 (started-services)
# cat /proc/255/oom_adj

设置后的log: PERS #19: adj=core /F 406291f0 155:com.xxx.xxx/10001 (fixed)
# cat /proc/155/oom_adj
-12 # 这是CORE_SERVER_ADJ
注：init进程的oom_adj为-16（即SYSTEM_ADJ）： cat /proc/1/oom_adj

Android相关部分分析：
在文件frameworks/base/services/java/com/android/server/am/ActivityManagerService.java中有以下的代码：
final ProcessRecord addAppLocked(ApplicationInfo info) {
ProcessRecord app = getProcessRecordLocked(info.processName, info.uid);

if (app == null) {
app = newProcessRecordLocked(null, info, null);
mProcessNames.put(info.processName, info.uid, app);
updateLruProcessLocked(app, true, true);
}

if ((info.flags&(ApplicationInfo.FLAG_SYSTEM|ApplicationInfo.FLAG_PERSISTENT))
== (ApplicationInfo.FLAG_SYSTEM|ApplicationInfo.FLAG_PERSISTENT)) {
app.persistent = true;
app.maxAdj = CORE_SERVER_ADJ; // 这个常数值为-12。
}
if (app.thread == null && mPersistentStartingProcesses.indexOf(app) < 0) {
mPersistentStartingProcesses.add(app);
startProcessLocked(app, "added application", app.processName);
}

return app;
}

可见要想成为core service （即app.maxAdj = CORE_SERVER_ADJ(-12)），应用程序需要FLAG_SYSTEM和FLAG_PERSISTENT两个标志，FLAG_SYSTEM指的是应用位于/system/app下，FLAG_PERSISTENT就是指persistent属性。

而对于frameworks/base/services/java/com/android/server/SystemServer.java，则调用
ActivityManagerService.setSystemProcess();
把自己的 app.maxAdj 设置成SYSTEM_ADJ，即-16。

原理：
Android中的进程是托管的，当系统进程空间紧张的时候，会依照优先级自动进行进程的回收。由此带来三个问题：
1）回收规则: 什么时候回收与回收哪一个？
2）避免误杀: 如何阻止被回收？
3）数据恢复与保存: 被回收了怎么办？

Android将进程分为6个等级,它们按优先级顺序由高到低依次是:
1.前台进程( FOREGROUND_APP)
2.可视进程(VISIBLE_APP )
3. 次要服务进程(SECONDARY_SERVER )
4.后台进程 (HIDDEN_APP)
5.内容供应节点(CONTENT_PROVIDER)
6.空进程(EMPTY_APP)

特征：
1.如果一个进程里面同时包含service和可视的activity，那么这个进程应该归于可视进程，而不是service进程。
2.另外，如果其他进程依赖于它的话，一个进程的等级可以提高。例如，一个A进程里的service被绑定到B进程里的组件上，进程A将总被认为至少和B进程一样重要。
3.系统中的phone服务被划分到前台进程而不是次要服务进程.

在android中，进程的oom_adj值也就代表了它的优先级。oom_adj值越高代表该进程优先级越低。文件/init.rc中有以下属性设置：
setprop ro.FOREGROUND_APP_ADJ 0
setprop ro.VISIBLE_APP_ADJ 1
setprop ro.SECONDARY_SERVER_ADJ 2
setprop ro.HIDDEN_APP_MIN_ADJ 7
setprop ro.CONTENT_PROVIDER_ADJ 14
setprop ro.EMPTY_APP_ADJ 15
/init.rc中，将PID为1的进程(init进程)的oom_adj设置为SYSTEM_ADJ(-16):
# Set init its forked children's oom_adj.
write /proc/1/oom_adj -16

查看本机设置：
cat /sys/mole/lowmemorykiller/parameters/adj
0,1,2,7,14,15

回收时机：
文件/init.rc中:
setprop ro.FOREGROUND_APP_MEM 1536 // 6M
setprop ro.VISIBLE_APP_MEM 2048 // 8M
setprop ro.SECONDARY_SERVER_MEM 4096 // 16M
setprop ro.HIDDEN_APP_MEM 5120 // 20M
setprop ro.CONTENT_PROVIDER_MEM 5632 // 22.4M
setprop ro.EMPTY_APP_MEM 6144 // 24M
这些数字也就是对应的内存阈值，一旦低于该值，Android便开始按顺序关闭相应等级的进程。
注意这些数字的单位是page： 1 page = 4 kB。所以上面的六个数字对应的就是(MB): 6,8,16,20,22,24。

查看现在的内存阈值设置：
cat /sys/mole/lowmemorykiller/parameters/minfree

要想重新设置该值（对应不同的需求）:
echo "1536,2048,4096,5120,15360,23040">/sys/mole/lowmemorykiller/parameters/minfree
这样当可用内存低于90MB的时候便开始杀死"空进程"，而当可用内存低于60MB的时候才开始杀死"内容供应节点"类进程。

具体的回收实现在ActivityManagerService.java中的函数trimApplications()：
1.首先移除package已被卸载的无用进程；
2.基于进程当前状态，更新oom_adj值，然后进行以下操作：
1) 移除没有activity在运行的进程;
2) 如果AP已经保存了所有的activity状态，结束这个AP。
3. 最后，如果目前还是有很多activities 在运行，那么移除那些activity状态已经保存好的activity。

更新oom_adj的值：
在ActivityManagerService.java文件的ComputeOomAdjLocked() 中计算出进程的oom_adj，例如:
if (app == TOP_APP) {
// The last app on the list is the foreground app.
adj = FOREGROUND_APP_ADJ;
app.adjType = "top-activity";
}

Android kernel中的low memory killer
Android的Low Memory Killer根据需要（当系统内存短缺时）杀死进程释放其内存，源代码在kernel/drivers/misc/lowmemorykiller.c中。简单说，就是寻找一个最合适的进程杀死，从而释放它占用的内存。
最合适的进程是:
• oom_adj越大
• 占用物理内存越多

一旦一个进程被选中，内核会发送SIGKILL信号将之杀死：
for_each_process(p) {
……
if(selected == NULL || p->oomkilladj > selected->oomkilladj ||
(p->oomkilladj == selected->oomkilladj && tasksize > selected_tasksize))
{
selected = p;
}
}
if(selected != NULL) {
force_sig(SIGKILL, selected);
}

查看LRU列表：adb shell mpsys activity
当activitydemo在前台时：
包含Service的进程的优先级比较高，在computeOomAdjLocked中将其分为了两小类:
static final int MAX_SERVICE_INACTIVITY = 30*60*1000;
if (now < (s.lastActivity+MAX_SERVICE_INACTIVITY)) {
if (adj > SECONDARY_SERVER_ADJ) {
adj = SECONDARY_SERVER_ADJ;
app.adjType = "started-services";
app.hidden = false;
}
}
if (adj > SECONDARY_SERVER_ADJ) {
app.adjType = "started-bg-services";
}
完全让进程不被kill是不可能的，我们可以通过一些操作，使进程被kill的几率变小：
1) 提高进程的优先级:
* 后台操作采用运行于前台的Service形式，因为一个运行着service的进程比一个运行着后台activity的等级高；
* 按back键使得进程中的activity在后台运行而不是destory，需重载back按键(没有任何activity在运行的进程优先被杀).
* 依赖于其他优先级高的进程；

2) 强制修改进程属性：
* 在进程中设置：setPersistent(true);
* 在Manifest文件中设置（如上）。

⑤ 想让android应用常驻后台，不被杀死，各位大神有什么高招

方法：对于一个service，可以首先把它设为在前台运行： public void MyService.onCreate() { super.onCreate(); Notification notification = new Notification(android.R.drawable.my_service_icon, "my_service_name", System.currentTimeMillis()); PendingIntent p_intent = PendingIntent.getActivity(this, 0, new Intent(this, MyMainActivity.class), 0); notification.setLatestEventInfo(this, "MyServiceNotification, "MyServiceNotification is Running!", p_intent); Log.d(TAG, String.format("notification = %s", notification)); startForeground(0x1982, notification); // notification ID: 0x1982, you can name it as you will. } 重要设置------------------------------- 相较于/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提升为系统核心级别，任何情况下不会被kill掉, settings->applications里面也会屏蔽掉stop操作。这样设置前的log: Proc #19: adj=svc /B 4067b028 255:com.xxx.xxx/10001 (started-services) # cat /proc/255/oom_adj 设置后的log: PERS #19: adj=core /F 406291f0 155:com.xxx.xxx/10001 (fixed) # cat /proc/155/oom_adj -12 # 这是CORE_SERVER_ADJ 注：init进程的oom_adj为-16（即SYSTEM_ADJ）： cat /proc/1/oom_adj Android相关部分分析：在文件frameworks/base/services/java/com/android/server/am/ActivityManagerService.java中有以下的代码： final ProcessRecord addAppLocked(ApplicationInfo info) { ProcessRecord app = getProcessRecordLocked(info.processName, info.uid); if (app == null) { app = newProcessRecordLocked(null, info, null); mProcessNames.put(info.processName, info.uid, app); updateLruProcessLocked(app, true, true); } if ((info.flags&(ApplicationInfo.FLAG_SYSTEMApplicationInfo.FLAG_PERSISTENT)) == (ApplicationInfo.FLAG_SYSTEMApplicationInfo.FLAG_PERSISTENT)) { app.persistent = true; app.maxAdj = CORE_SERVER_ADJ; // 这个常数值为-12。 } if (app.thread == null && mPersistentStartingProcesses.indexOf(app) < 0) { mPersistentStartingProcesses.add(app); startProcessLocked(app, "added application", app.processName); } return app; } 可见要想成为core service （即app.maxAdj = CORE_SERVER_ADJ(-12)），应用程序需要FLAG_SYSTEM和FLAG_PERSISTENT两个标志，FLAG_SYSTEM指的是应用位于/system/app下，FLAG_PERSISTENT就是指persistent属性。而对于frameworks/base/services/java/com/android/server/SystemServer.java，则调用 ActivityManagerService.setSystemProcess(); 把自己的 app.maxAdj 设置成SYSTEM_ADJ，即-16。原理： Android中的进程是托管的，当系统进程空间紧张的时候，会依照优先级自动进行进程的回收。由此带来三个问题： 1）回收规则: 什么时候回收与回收哪一个？ 2）避免误杀: 如何阻止被回收？ 3）数据恢复与保存: 被回收了怎么办？ Android将进程分为6个等级,它们按优先级顺序由高到低依次是: 1.前台进程( FOREGROUND_APP) 2.可视进程(VISIBLE_APP ) 3. 次要服务进程(SECONDARY_SERVER ) 4.后台进程 (HIDDEN_APP) 5.内容供应节点(CONTENT_PROVIDER) 6.空进程(EMPTY_APP) 特征： 1.如果一个进程里面同时包含service和可视的activity，那么这个进程应该归于可视进程，而不是service进程。 2.另外，如果其他进程依赖于它的话，一个进程的等级可以提高。例如，一个A进程里的service被绑定到B进程里的组件上，进程A将总被认为至少和B进程一样重要。 3.系统中的phone服务被划分到前台进程而不是次要服务进程. 在android中，进程的oom_adj值也就代表了它的优先级。oom_adj值越高代表该进程优先级越低。文件/init.rc中有以下属性设置： setprop ro.FOREGROUND_APP_ADJ 0 setprop ro.VISIBLE_APP_ADJ 1 setprop ro.SECONDARY_SERVER_ADJ 2 setprop ro.HIDDEN_APP_MIN_ADJ 7 setprop ro.CONTENT_PROVIDER_ADJ 14 setprop ro.EMPTY_APP_ADJ 15 /init.rc中，将PID为1的进程(init进程)的oom_adj设置为SYSTEM_ADJ(-16): # Set init its forked children's oom_adj. write /proc/1/oom_adj -16 查看本机设置： cat /sys/mole/lowmemorykiller/parameters/adj 0,1,2,7,14,15 回收时机：文件/init.rc中: setprop ro.FOREGROUND_APP_MEM 1536 // 6M setprop ro.VISIBLE_APP_MEM 2048 // 8M setprop ro.SECONDARY_SERVER_MEM 4096 // 16M setprop ro.HIDDEN_APP_MEM 5120 // 20M setprop ro.CONTENT_PROVIDER_MEM 5632 // 22.4M setprop ro.EMPTY_APP_MEM 6144 // 24M 这些数字也就是对应的内存阈值，一旦低于该值，Android便开始按顺序关闭相应等级的进程。注意这些数字的单位是page： 1 page = 4 kB。所以上面的六个数字对应的就是(MB): 6,8,16,20,22,24。查看现在的内存阈值设置： cat /sys/mole/lowmemorykiller/parameters/minfree 要想重新设置该值（对应不同的需求）: echo "1536,2048,4096,5120,15360,23040">/sys/mole/lowmemorykiller/parameters/minfree 这样当可用内存低于90MB的时候便开始杀死"空进程"，而当可用内存低于60MB的时候才开始杀死"内容供应节点"类进程。具体的回收实现在ActivityManagerService.java中的函数trimApplications()： 1.首先移除package已被卸载的无用进程； 2.基于进程当前状态，更新oom_adj值，然后进行以下操作： 1) 移除没有activity在运行的进程; 2) 如果AP已经保存了所有的activity状态，结束这个AP。 3. 最后，如果目前还是有很多activities 在运行，那么移除那些activity状态已经保存好的activity。更新oom_adj的值：在ActivityManagerService.java文件的ComputeOomAdjLocked() 中计算出进程的oom_adj，例如: if (app == TOP_APP) { // The last app on the list is the foreground app. adj = FOREGROUND_APP_ADJ; app.adjType = "top-activity"; } Android kernel中的low memory killer Android的Low Memory Killer根据需要（当系统内存短缺时）杀死进程释放其内存，源代码在kernel/drivers/misc/lowmemorykiller.c中。简单说，就是寻找一个最合适的进程杀死，从而释放它占用的内存。最合适的进程是: • oom_adj越大 • 占用物理内存越多一旦一个进程被选中，内核会发送SIGKILL信号将之杀死： for_each_process(p) { …… if(selected == NULL p->oomkilladj > selected->oomkilladj (p->oomkilladj == selected->oomkilladj && tasksize > selected_tasksize)) { selected = p; } } if(selected != NULL) { force_sig(SIGKILL, selected); } 查看LRU列表：adb shell mpsys activity 当activitydemo在前台时：包含Service的进程的优先级比较高，在computeOomAdjLocked中将其分为了两小类: static final int MAX_SERVICE_INACTIVITY = 30*60*1000; if (now < (s.lastActivity+MAX_SERVICE_INACTIVITY)) { if (adj > SECONDARY_SERVER_ADJ) { adj = SECONDARY_SERVER_ADJ; app.adjType = "started-services"; app.hidden = false; } } if (adj > SECONDARY_SERVER_ADJ) { app.adjType = "started-bg-services"; } 完全让进程不被kill是不可能的，我们可以通过一些操作，使进程被kill的几率变小： 1) 提高进程的优先级: * 后台操作采用运行于前台的Service形式，因为一个运行着service的进程比一个运行着后台activity的等级高； * 按back键使得进程中的activity在后台运行而不是destory，需重载back按键(没有任何activity在运行的进程优先被杀). * 依赖于其他优先级高的进程； 2) 强制修改进程属性： * 在进程中设置：setPersistent(true); * 在Manifest文件中设置（如上）。

⑥ android开发怎么让个推服务不被手机系统杀掉

1.在service中重写下面的方法，这个方法有三个返回值，START_STICKY是service被kill掉后自动重写创建[代码]java代码：@(Intentintent,intflags,intstartId){returnSTART_STICKY;}----------------@(Intentintent,intflags,intstartId){//TODOAuto-generatedmethodstubLog.v("TrafficService","startCommand");flags=START_STICKY;returnsuper.onStartCommand(intent,flags,startId);//returnSTART_REDELIVER_INTENT;}2.在Service的onDestroy()中重启Service.publicvoidonDestroy(){IntentlocalIntent=newIntent();localIntent.setClass(this,MyService.class);//销毁时重新启动Servicethis.startService(localIntent);}用管家杀掉进程的时候，调用的是系统自带的强制kill功能（即settings里的），在kill时，会将应用的整个进程停掉，当然包括service在内，如果在running里将service强制kill掉，显示进程还在。不管是kill整个进程还是只kill掉进应用的service，都不会重新启动service。不知道你是怎么实现重启的，实在是不解。在eclipse中，用stop按钮kill掉进程的时候，倒是会重启serviceKILL问题：1.settings中stopserviceonDestroy方法中，调用startService进行Service的重启。2.settings中forcestop应用捕捉系统进行广播（action为android.intent.action.PACKAGE_RESTARTED）3.借助第三方应用kill掉runningtask提升service的优先级service开机启动今天我们主要来探讨android怎么让一个service开机自动启动功能的实现。Android手机在启动的过程中会触发一个StandardBroadcastAction，名字叫android.intent.action.BOOT_COMPLETED(记得只会触发一次呀),在这里我们可以通过构建一个广播接收者来接收这个这个action.下面我就来简单写以下实现的步骤：第一步：首先创建一个广播接收者,重构其抽象方法onReceive(Contextcontext,Intentintent)，在其中启动你想要启动的Service或app。[代码]java代码：importandroid.content.BroadcastReceiver;importandroid.content.Context;importandroid.content.Intent;importandroid.util.Log;{//重写onReceive方法@OverridepublicvoidonReceive(Contextcontext,Intentintent){//后边的XXX.class就是要启动的服务Intentservice=newIntent(context,XXXclass);context.startService(service);Log.v("TAG","开机自动服务自动启动..");//启动应用，参数为需要自动启动的应用的包名Intentintent=getPackageManager().getLaunchIntentForPackage(packageName);context.startActivity(intent);}}第二步：配置xml文件，在receiver接收这种添加intent-filter配置[代码]java代码：第三步：添加权限如何实现一个不会被杀死的进程看Android的文档知道，当进程长期不活动，或系统需要资源时，会自动清理门户，杀死一些Service，和不可见的Activity等所在的进程。但是如果某个进程不想被杀死（如数据缓存进程，或状态监控进程，或远程服务进程），应该怎么做，才能使进程不被杀死。addandroid:persistent="true".xml切记，这个不可滥用，系统中用这个的service，app一多，整个系统就完蛋了。目前系统中有phone等非常有限的，必须一直活着的应用在试用。提升service优先级的方法Android系统对于内存管理有自己的一套方法，为了保障系统有序稳定的运信，系统内部会自动分配，控制程序的内存使用。当系统觉得当前的资源非常有限的时候，为了保证一些优先级高的程序能运行，就会杀掉一些他认为不重要的程序或者服务来释放内存。这样就能保证真正对用户有用的程序仍然再运行。如果你的Service碰上了这种情况，多半会先被杀掉。但如果你增加Service的优先级就能让他多留一会，我们可以用setForeground(true)来设置Service的优先级。为什么是foreground?默认启动的Service是被标记为background，当前运行的Activity一般被标记为foreground，也就是说你给Service设置了foreground那么他就和正在运行的Activity类似优先级得到了一定的提高。当让这并不能保证你得Service永远不被杀掉，只是提高了他的优先级。从Android1.5开始，一个已启动的service可以调用startForeground(int,Notification)将service置为foreground状态，调用stopForeground(boolean)将service置为background状态。我们会在调用startForeground(int,Notification)传入参数notification，它会在状态栏里显示正在进行的foregroundservice。backgroundservice不会在状态栏里显示。在Android1.0中，将一个service置为foreground状态：setForeground(true);mNM.notify(id,notification);将一个service置为background状态：mNM.cancel(id);setForeground(false);对比看出，在1.0API中调用setForeground(boolean)只是简单的改变service的状态，用户不会有任何觉察。新API中强制将notification和改变service状态的动作绑定起来，foregroundservice会在状态栏显示，而backgroundservice不会。Remoteservicecontroller&binding跨进程调用Service。暂时不研究。如何防止Android应用中的Service被系统回收?很多朋友都在问，如何防止Android应用中的Service被系统回收？下面简单解答一下。对于Service被系统回收，一般做法是通过提高优先级可以解决，在AndroidManifest.xml文件中对于intent-filter可以通过android:priority="1000"这个属性设置最高优先级，1000是最高值，如果数字越小则优先级越低，同时实用于广播，推荐大家如果你的应用很重要，可以考虑通过系统常用intentaction来触发。

⑦ Android下怎么写一个永远不会被KILL掉的进程/服务

Android 系统对于内存管理有自己的一套方法，为了保障系统有序稳定的运信，系统内部会自动分配，控制程序的内存使用。当系统觉得当前的资源非常有限的时候，为了保证一些优先级高的程序能运行，就会杀掉一些他认为不重要的程序或者服务来释放内存。这样就能保证真正对用户有用的程序仍然再运行。如果你的 Service 碰上了这种情况，多半会先被杀掉。但如果你增加 Service 的优先级就能让他多留一会，我们可以用 setForeground(true) 来设置 Service 的优先级。

为什么是 foreground ? 默认启动的 Service 是被标记为 background，当前运行的 Activity 一般被标记为 foreground，也就是说你给 Service 设置了 foreground 那么他就和正在运行的 Activity 类似优先级得到了一定的提高。当让这并不能保证你得 Service 永远不被杀掉，只是提高了他的优先级。

有一个方法可以给你更清晰的演示，进入 $SDK/tools 运行命令

代码如下:

# adb shell mpsys activity|grep oom_adj

Running Norm Proc # 6: oom_adj= 0 ProcessRecord{43635cf0 12689:com.roiding.netraffic/10028}

Running Norm Proc # 5: oom_adj= 7 ProcessRecord{436feda0 12729:com.android.browser/10006}

Running Norm Proc # 4: oom_adj= 8 ProcessRecord{4367e838 12761:android.process.acore/10016}

Running Norm Proc # 3: oom_adj= 8 ProcessRecord{43691cd8 12754:com.google.process.gapps/10000}

Running PERS Proc # 1: oom_adj=-12 ProcessRecord{43506750 5941:com.android.phone/1001}

Running PERS Proc # 0: oom_adj=-100 ProcessRecord{4348fde0 5908:system/1000}

代码如下:

返回的一大堆东西，观察 oom_adj 的值，如果是大于 8 一般就是属于 backgroud 随时可能被干掉，数值越小证明优先级越高，被干掉的时间越晚。你看phone的程序是 -12 说明电话就是电话，其他什么都干了了，也的能接电话对吧。另外还有一个 -100 的，更邪乎因为是 system 如果他也完蛋了，你得系统也就挂了。

我是天王盖地虎的分割线

从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不会。

通过在androidmanifest.xml中的application标签中加入android:persistent="true"属性后的确就能够达到保证该应用程序所在进程不会被LMK杀死。但有个前提就是应用程序必须是系统应用，也就是说应用程序不能采用通常的安装方式。必须将应用程序的apk包直接放到/system/app目录下。而且必须重启系统后才能生效。

除了一般的几种优先级外，还存在着coreserver，system这样的永远不会被LMK回收的优先级。系统中的电话应用就是coreserver优先级的。

通过查看源代码可以知道，只有应用程序的flag同时为FLAG_SYSTEM和FLAG_PERSISTENT时，才会被设置为coreserver优先级

if ((info.flags&(ApplicationInfo.FLAG_SYSTEM|ApplicationInfo.FLAG_PERSISTENT))

== (ApplicationInfo.FLAG_SYSTEM|ApplicationInfo.FLAG_PERSISTENT)) {

app.persistent = true;

app.maxAdj = CORE_SERVER_ADJ;

}

FLAG_SYSTEM在应用程序apk放在/system/app下时会被设置。所以才会出现只设置android:persistent="true"仍然会被杀死的情况。

测试时发现，将应用程序放到/system/app后不重启系统，仍然会被识别为普通的进程。当系统重新启动时，会在一开始就启动该进程并把它优先级设置为coreserver。

通过mpsys activity命令能够很明显的看出其中差别。

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

一般来说，在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源码相应地方稍改下，然后重新编译……

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

⑨ 安卓怎么保证service不被杀死

Service简介 Service是在一段不定的时间运行在后台，不和用户交互应用组件。每个Service必须在manifest中通过<service>来声明。可以通过contect.startservice和contect.bindserverice来启动。和其他的应用组件一样，运行在进程的主线程中。这就是说如果service需要很多耗时或者阻塞的操作，需要在其子线程中实现（或者用系统提供的IntentService，它继承了Service，它处理数据是用自身新开的线程）。【当然你也可以在新的线程中startService，这样Service就不是在MainThread了】本地服务 Local Service 用于应用程序内部它可以启动并运行，直至有人停止了它或它自己停止。在这种方式下，它以调用Context.startService()启动，而以调用Context.stopService()结束。它可以调用Service.stopSelf() 或 Service.stopSelfResult()来自己停止。不论调用了多少次startService()方法，你只需要调用一次stopService()来停止服务。【用于实现应用程序自己的一些耗时任务，比如查询升级信息，并不占用应用程序比如Activity所属线程，而是单开线程后台执行，这样用户体验比较好】远程服务 Remote Service 用于android系统内部的应用程序之间它可以通过自己定义并暴露出来的接口进行程序操作。客户端建立一个到服务对象的连接，并通过那个连接来调用服务。连接以调用Context.bindService()方法建立，以调用 Context.unbindService()关闭。多个客户端可以绑定至同一个服务。如果服务此时还没有加载，bindService()会先加载它。【可被其他应用程序复用，比如天气预报服务，其他应用程序不需要再写这样的服务，调用已有的即可】 1，Service的生命周期 2，Service运行方式以startService()启动服务，系统将通过传入的Intent在底层搜索相关符合Intent里面信息的service。如果服务没有启动则先运行onCreate，然后运行onStartCommand （可在里面处理启动时传过来的Intent和其他参数），直到明显调用stopService或者stopSelf才将停止Service。无论运行startService多少次，只要调用一次stopService或者stopSelf，Service都会停止。使用stopSelf(int)方法可以保证在处理好intent后再停止。onStartCommand ，在2.0后被引入用于service的启动函数，2.0之前为public void onStart(Intent intent, int startId) 。以bindService()方法启用服务，调用者与服务绑定在了一起，调用者一旦退出，服务也就终止。onBind()只有采用Context.bindService()方法启动服务时才会回调该方法。该方法在调用者与服务绑定时被调用，当调用者与服务已经绑定，多次调用Context.bindService()方法并不会导致该方法被多次调用。采用Context.bindService()方法启动服务时只能调用onUnbind()方法解除调用者与服务解除，服务结束时会调用onDestroy()方法。 3，拥有service的进程具有较高的优先级官方文档告诉我们，Android系统会尽量保持拥有service的进程运行，只要在该service已经被启动(start)或者客户端连接(bindService)到它。当内存不足时，需要保持，拥有service的进程具有较高的优先级。 1．如果service正在调用onCreate,onStartCommand或者onDestory方法，那么用于当前service的进程则变为前台进程以避免被killed。 2．如果当前service已经被启动(start)，拥有它的进程则比那些用户可见的进程优先级低一些，但是比那些不可见的进程更重要，这就意味着service一般不会被killed. 3．如果客户端已经连接到service (bindService),那么拥有Service的进程则拥有最高的优先级，可以认为service是可见的。 4．如果service可以使用startForeground(int, Notification)方法来将service设置为前台状态，那么系统就认为是对用户可见的，并不会在内存不足时killed。 5．如果有其他的应用组件作为Service,Activity等运行在相同的进程中，那么将会增加该进程的重要性。保证service不被杀掉 onStartCommand方法，返回START_STICKY StartCommond几个常量参数简介： 1、START_STICKY 在运行onStartCommand后service进程被kill后，那将保留在开始状态，但是不保留那些传入的intent。不久后service就会再次尝试重新创建，因为保留在开始状态，在创建 service后将保证调用onstartCommand。如果没有传递任何开始命令给service，那将获取到null的intent。 2、START_NOT_STICKY 在运行onStartCommand后service进程被kill后，并且没有新的intent传递给它。Service将移出开始状态，并且直到新的明显的方法（startService）调用才重新创建。因为如果没有传递任何未决定的intent那么service是不会启动，也就是期间onstartCommand不会接收到任何null的intent。 3、START_REDELIVER_INTENT 在运行onStartCommand后service进程被kill后，系统将会再次启动service，并传入最后一个intent给onstartCommand。直到调用stopSelf(int)才停止传递intent。如果在被kill后还有未处理好的intent，那被kill后服务还是会自动启动。因此onstartCommand不会接收到任何null的intent。 [java] view plain @Override public int onStartCommand(Intent intent, int flags, int startId) { flags = START_STICKY; return super.onStartCommand(intent, flags, startId); } 【结论】手动返回START_STICKY，亲测当service因内存不足被kill，当内存又有的时候，service又被重新创建，比较不错，但是不能保证任何情况下都被重建，比如进程被干掉了.... 提升service优先级在AndroidManifest.xml文件中对于intent-filter可以通过android:priority = "1000"这个属性设置最高优先级，1000是最高值，如果数字越小则优先级越低，同时适用于广播。 [java] view plain <service android:name="com.dbjtech.acbxt.waiqin.UploadService" android:enabled="true" > <intent-filter android:priority="1000" > <action android:name="com.dbjtech.myservice" /> </intent-filter> </service> 【结论】目前看来，priority这个属性貌似只适用于broadcast，对于Service来说可能无效提升service进程优先级 Android中的进程是托管的，当系统进程空间紧张的时候，会依照优先级自动进行进程的回收。Android将进程分为6个等级,它们按优先级顺序由高到低依次是: 1.前台进程( FOREGROUND_APP) 2.可视进程(VISIBLE_APP ) 3. 次要服务进程(SECONDARY_SERVER ) 4.后台进程 (HIDDEN_APP) 5.内容供应节点(CONTENT_PROVIDER) 6.空进程(EMPTY_APP) 当service运行在低内存的环境时，将会kill掉一些存在的进程。因此进程的优先级将会很重要，可以使用startForeground 将service放到前台状态。这样在低内存时被kill的几率会低一些。在onStartCommand方法内添加如下代码： [java] view plain Notification notification = new Notification(R.drawable.ic_launcher, getString(R.string.app_name), System.currentTimeMillis()); PendingIntent pendingintent = PendingIntent.getActivity(this, 0, new Intent(this, AppMain.class), 0); notification.setLatestEventInfo(this, "uploadservice", "请保持程序在后台运行", pendingintent); <span style="color:#ff0000;"> startForeground(0x111, notification);</span> 注意在onDestroy里还需要stopForeground(true)，运行时在下拉列表会看到自己的APP在：【结论】如果在极度极度低内存的压力下，该service还是会被kill掉，并且不一定会restart onDestroy方法里重启service service +broadcast 方式，就是当service走ondestory的时候，发送一个自定义的广播，当收到广播的时候，重新启动service； [java] view plain <receiver android:name="com.dbjtech.acbxt.waiqin.BootReceiver" > <intent-filter> <action android:name="android.intent.action.BOOT_COMPLETED" /> <action android:name="android.intent.action.USER_PRESENT" /> <action android:name="com.dbjtech.waiqin.destroy" />//这个就是自定义的action </intent-filter> </receiver> 在onDestroy时： [java] view plain @Override public void onDestroy() { stopForeground(true); Intent intent = new Intent("com.dbjtech.waiqin.destroy"); sendBroadcast(intent); super.onDestroy(); } 在BootReceiver里 [java] view plain public class BootReceiver extends BroadcastReceiver { @Override public void onReceive(Context context, Intent intent) { if (intent.getAction().equals("com.dbjtech.waiqin.destroy")) { //TODO //在这里写重新启动service的相关操作 startUploadService(context); } } } 也可以直接在onDestroy（）里startService [java] view plain @Override public void onDestroy() { Intent sevice = new Intent(this, MainService.class); this.startService(sevice); super.onDestroy(); } 【结论】当使用类似口口管家等第三方应用或是在setting里-应用-强制停止时，APP进程可能就直接被干掉了，onDestroy方法都进不来，所以还是无法保证~.~ Application加上Persistent属性看Android的文档知道，当进程长期不活动，或系统需要资源时，会自动清理门户，杀死一些Service，和不可见的Activity等所在的进程。但是如果某个进程不想被杀死（如数据缓存进程，或状态监控进程，或远程服务进程），可以这么做： [java] view plain <application android:name="com.test.Application" android:allowBackup="true" android:icon="@drawable/ic_launcher" android:label="@string/app_name" <span style="color:#ff0000;"> android:persistent="true"</span> android:theme="@style/AppTheme" > </application> 【结论】据说这个属性不能乱设置，不过设置后，的确发现优先级提高不少，或许是相当于系统级的进程，但是还是无法保证存活监听系统广播判断Service状态通过系统的一些广播，比如：手机重启、界面唤醒、应用状态改变等等监听并捕获到，然后判断我们的Service是否还存活，别忘记加权限啊。 [java] view plain <receiver android:name="com.dbjtech.acbxt.waiqin.BootReceiver" > <intent-filter> <action android:name="android.intent.action.BOOT_COMPLETED" /> <action android:name="android.intent.action.USER_PRESENT" /> <action android:name="android.intent.action.PACKAGE_RESTARTED" /> <action android:name="com.dbjtech.waiqin.destroy" /> </intent-filter> </receiver> BroadcastReceiver中： [java] view plain @Override public void onReceive(Context context, Intent intent) { if (Intent.ACTION_BOOT_COMPLETED.equals(intent.getAction())) { System.out.println("手机开机了...."); startUploadService(context); } if (Intent.ACTION_USER_PRESENT.equals(intent.getAction())) { startUploadService(context); } } 【结论】这也能算是一种措施，不过感觉监听多了会导致Service很混乱，带来诸多不便将APK安装到/system/app，变身系统级应用这个办法不推荐使用，因为如果你的APP如果是给用户使用的，那就不合适了，我是为了给测试的妹子来用，这个APP的目的也是很简单，打开后开启Service并且能保证一直在后台驻留，开机自启动。但是昨天发现如果她的HuaWei手机长时间关闭，再重新打开时，我们应用的Service不会自启动，貌似广播收不到了~一怒之下，打算搞成系统应用。前提： ROOT过的手机 1，把代码编写好后，打包导出apk，到手机SD卡根目录下。 2，手机连接eclipse，cmd： adb shell 3，切换root模式，输入：su （如果root过就不会有错误） 4，设置System为读写权限：mount –o remount rw /system （System默认为只读，无法写入，这一步很关键） 5，cd到sd卡跟目录下，确认是否有我们拷贝到sd卡根目录下的apk（一般都是 storage/sdcard0） shell@android:/ # cd storage/sdcard0 6，最关键的一步，我们要把apk拷贝到 /System/app中：发现命令无效~那么我们就用push把：如果有错误：device not found，那么手机下载一个Root Explorer把，找到apk，到System/app下，通过这个APP要更容易一些。 7，system/app 确定拥有我们的APK后，重启手机把：设置-应用程序管理，查看一下：可以看到我们的APP已经无法卸载了，只能停用这个时候，就算强制停止，或是关闭Service，重启手机后照样可以起来Service~！系统级的APP，这样一些第三方的管家软件，就无法杀掉我们，除非自己把APP停用掉，或是强制停止（但是我的APP可以开机自启动）。【结论】这种方式适合调试来用，并不算是一种解决办法，大家可以尝试在正在运行的界面：强制关闭搜狐视频的两个进程，重启手机，发现他又可以自启动，但是如果换成我们的APP，强制停止，进程挂了，再重启手机，无法自启动了~

导航:首页 > 操作系统 > android防止被kill

android防止被kill

与android防止被kill相关的资料