2 lp1994122 LP1994122 于 2016.09.20 15:33 提问

android中的service服务被第三方杀毒软件加速球杀死重启,不要手动加入杀毒软件的白名单中 9C

android手机后台让一个service,在后台常驻。360、手机管家加速球杀死后,重启这个服务。

2个回答

zy567210
zy567210   2016.09.22 15:50

创建前台Service或者设置服务监听

windboy2014
windboy2014   2016.09.23 15:52

在自己应用中启动了一个service,这个service用来监听服务器发过来的推送信息并弹出一个对话框显示信息,所以需要保证这个service时时运行着,且不能被任务管理或是系统的设置等工具杀掉,如果services是被杀死,则需要自动重启这service,笔者在网上查询一下,找到一些类似的问题文章,现在把它在www.androidkaifa.com总结记录下来,以方便需要实现像我这样的要求的朋友有帮助,希望大家都能写永远不会被KILL掉的进程/服务,也就是不受系统垃圾回收机制(内存管理)影响。
网络对此问题的解决建议:
(1)
在service中重写onStartCommand方法,这个方法有三个返回值, START_STICKY是service被kill掉后自动重写创建@Override public int onStartCommand(Intent intent, int flags, int startId) { return START_STICKY; }
(2)
在Service的onDestroy()中重启Service.
public void onDestroy() {

Intent localIntent = new Intent();
localIntent.setClass(this, MyService.class); //销毁时重新启动Service
this.startService(localIntent);
}
对于(2)此解决方案,笔者自己写了一个代码测试了一下,1:如果是在系统的settings中的DOWNLOADED关闭整个应用(Force stop),则这个services类中的onDestory方法没有监听到(services类的onDestory方法的log没有打印日志),如果是在系统里的setting中的RUNNING杀掉项目services,则onDestory方法则会监听到(services类的onDestory方法的log有打印日志),所以对于此解决方案并不是一定适用,2:或是通过别的应用,直接kill掉我的应用时,也是不会调用services类的onDestory方法的,
(3)
再写另外一个apk,用一个广播来监听这个APK是否被关闭,如果是关闭了则重启这个APK,而这里我们为什么要用另外一个APK?因为被关闭的应用程序不能检测到自己被关闭的事件,只能接收到其他应用被关闭的广播。这个action的recever
public class ProtectorHelperReceiver extends BroadcastReceiver {
@Override
public void onReceive(Context context, Intent intent) {
String pkg = "com.innofidei.myprotector";// 被kill的应用的包名
String action = pkg + ".action.START_SERVICE";// 重启service的acition
String str = intent.getData().toString().toLowerCase().replace("package:", "");
String data = intent.getAction();

if (str != null && str.equals(pkg)) {
if (data != null && data.equals("android.intent.action.PACKAGE_REMOVED")) {
File file = new File("/sdcard/" + context.getPackageName() + "/ProtectorHelper.apk");
file.delete();
file.getParentFile().delete();
Intent intent2 = new Intent(context, UninstallActivity.class);
intent2.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
context.startActivity(intent2);
} else {
context.sendBroadcast(new Intent(action));// 通知应用重启service
}
}
}
}
(4)
android:sharedUserId="android.uid.system">
android:allowClearUserData="false" android:process="system"
android:killAfterRestore="false">

  这样应该可以了,我也是仿照那些不能被杀死的系统应用的AndroidManifest.xml写的,但是若要这样写,则需要源码环境编译能通过,eclipse是没有这权限编译的这项目的,

(5)
项目的功能配置文件AndroidManifest.xml 中添加:
android:persistent="true" //在节点下面
(6)提高Android Service 优先级的方法:
我们先看一下系统一些的进程级别:
进入 $SDK/tools 运行命令:# adb shell dumpsys activity|grep oom_adj 代码: Running Norm Proc # 6: oom_adj= 0ProcessRecord{43635cf0 12689:com.roiding.netraffic/10028} Running Norm Proc # 5: oom_adj= 7 ProcessRecord{436feda012729:com.android.browser/10006} Running Norm Proc # 4: oom_adj= 8 ProcessRecord{4367e83812761:android.process.acore/10016} Running Norm Proc # 3: oom_adj= 8 ProcessRecord{43691cd812754:com.google.process.gapps/10000} Running PERS Proc # 1: oom_adj=-12 ProcessRecord{435067505941: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 系统对于内存管理有自己的一套方法,为了保障系统有序稳定的运信,系统内部会自动分配,控制程序的内存使用。
当系统觉得当前的资源非常有限的时候,为了保 证一些优先级高的程序能运行,就会杀掉一些他认为不重要的程序或者
服务来释放内存。这样就能保证真正对用户有用的程序仍然再运行。如果你的 Service 碰上了这种情况,多半会先被杀掉。
但如果你增加 Service 的优先级就能让他多留一会,我们可以用 setForeground(true) 来设置 Service 的优先级。为什么是 foreground ? 默认启动的 Service 是被标记为 background,当前运行的 Activity 一般被标记为 foreground,
也就是说你给 Service 设置了 foreground 那么他就和正在运行的 Activity 类似优先级得到了一定的提高。
当让这并不能保证你得 Service 永远不被杀掉,只是提高了他的优先级。
(7)
请参看我的另一篇文章《怎样使一个Android应用不被系统或第三方应用杀死》,
(8)
@Override
public IBinder onBind(Intent arg0) {
// TODO Auto-generated method stub
Log.v("TrafficService", "Bind");

state = BINLD;
//使用线程,该线程不会被销毁
return myBinder;
}

    class TrafficBinder extends Binder {  
            public float his = history;
            TrafficService getService(){
                    return TrafficService.this;
             }
    }

     @Override
     public void onCreate() {
             // TODO Auto-generated method stub
             receiver = new NetReceiver();
             IntentFilter nfilter=new IntentFilter();        
             nfilter.addAction("android.net.conn.CONNECTIVITY_CHANGE");
             this.registerReceiver(receiver, nfilter);
             dealBuffer();
             handler.post(createBrod);
             Log.v("TrafficService", "Create "+history+" "+todayTraffic+" "+tempTraffic);
             super.onCreate();

     }
     @Override
     public boolean onUnbind(Intent intent) {
             // TODO Auto-generated method stub
             state = UNBINLD;
             Log.v("TrafficService", "Unbind");
             return true;
     }

     @Override
     public void onRebind(Intent intent) {
             // TODO Auto-generated method stub
             Log.v("TrafficService", "Rebind");
             state = BINLD;;
             super.onRebind(intent);

     }

     @Override
    public void onDestroy() {
            // TODO Auto-generated method stub
             handler.removeCallbacks(updateBrod);
             momorybuffer();
             nManger.cancel(R.layout.notifi);
             unregisterReceiver(receiver);

             Log.v("TrafficService", "destroy "+history+" "+todayTraffic+" "+tempTraffic);
             super.onDestroy();
    }

    @Override
    public boolean stopService(Intent name) {
            // TODO Auto-generated method stub
            momorybuffer();
            nManger.cancel(R.layout.notifi);
            Log.v("TrafficService",name.getAction());
            Log.v("TrafficService", "stop "+history+" "+todayTraffic+" "+tempTraffic);
            return super.stopService(name);
    }



    @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;
}
//在以上代码中的onstartCommand返回START_STICKY,同时在destory的最后重启了服务,这样就OK了,

Csdn user default icon
上传中...
上传图片
插入图片
准确详细的回答,更有利于被提问者采纳,从而获得C币。复制、灌水、广告等回答会被删除,是时候展现真正的技术了!
其他相关推荐
电脑黑屏但光标、杀毒软件加速球可见
今天,重装了Win10,并格式化掉D盘(之前没有管理文件的好习惯,感觉文件一团糟),还移动了桌面位置(到D盘)但是安装SQLserver重启时,电脑黑屏了(可能是我一开始操作不当),只看得到光标和360加速球,重新开机也不行。解决:打开任务管理器(Ctrl+Shift+Esc或者ctrl+alt+delete)———》在打开的任务管理器窗口点击文件——》运行新任务——》在对话框中的“打开”栏中输入...
Android 开发之Service 探索如何保证Service不被杀死或被kill之后自动重启
前言: 在我司项目1.0版本的时候消息是使用的环信、用了之后发现各种bug,各种机型不支持导致app崩溃,于是在2.0版本果断去掉环信,使用了公众号用的那套消息系统(老大自己写的)并做了扩展升级。搞了近半个月终于是搞完了,项目也顺利上线......
三种方法让你的Service不被“一键加速”和系统杀掉
基本上大家都知道提高service优先级可以在很大程度上让你的service免于因为内存不足而被kill,当然系统只是在此时先把优先级低的kill掉,如果内存还是不够,也会把你的service干掉的. 1.android:persistent="true" 常驻内存属性对第三方app无效,下面是官方说明 android:persistent     Whether or not t
Android Service服务被杀死后重启
第一个问题:程序进入后台,系统可能会销毁应用。PUSH服务不能重启,收不到消息。 可以理解为android端监听推送消息的服务在启动后是一直在后台运行的,但是当内存不足时,或者第三方应用清理内存时会杀死后台服务,此时该服务需要自动重启。 该问题只需要在推送服务的onStartCommand方法返回类型设置成START_STICKY,官方文档对此的解释是:      public stati
Android如何降低service被杀死概率
让app 的service常驻其实是很流氓的做法,但是需求摆在那里。。。 但是要清除一点:想百分百保活service在当前是无法做到的,只能降低service被杀死的概率,曾经看了多少篇网上大神的牛逼博客,从各个层面分析如何让service不被杀死或者被杀死后重启,特别是从android系统底层分析,觉得特别牛逼,但是尝试之后没有啥用,以前做service保活总是一个劲的钻研android系统层的
Android应对进程被杀死--Service(四) 通过JNI实现守护进程,使Service服务不被杀死
开发一个需要常住后台的App其实是一件非常头疼的事情,不仅要应对国内各大厂商的ROM,还需要应对各类的安全管家...虽然不断的研究各式各样的方法,但是效果并不好,比如任务管理器把App干掉,服务就起不来了... 网上搜寻一番后,主要的方法有以下几种方法,但都是治标不治本: 1、提高Service的优先级:这个,也只能说在系统内存不足需要回收资源的时候,优先级较高,不容易被回收,然并卵.
如何让service被管理器杀死后自动重启
欢迎转载,转载请注明出自:www.androidkaifa.com    安卓开发网     笔者最近在一项目开发中遇到这样一个需求,要在自己应用中启动了一个service,这个service用来监听服务器发过来的推送信息并弹出一个对话框显示信息,所以需要保证这个service时时运行着,且不能被任务管理或是系统的设置等工具杀掉,如果services是被杀死,则需要自动重启这service,
Android面试题-service被kill之后怎么让它重启
Android面试题-service被kill之后怎么让它重启
性能优化二十三之Service进程防杀死
前言        Service作为四大组件之一很多安卓开发者对他肯定是又爱又恨,爱在它可以帮助我们去处理常驻后台的任务操作,比如说推送服务,心跳传输等,恨在当Servcie遇到360、腾讯管家之类的杀毒软件,变得脆弱,很容易被杀死,或者当用户手机锁屏会导致服务暂时停止运行。         我们常用的进程守护的套路无外乎以下几种: 一、提高进程的优先级数值         对于Service被系
服务的生命周期,被杀死后后可自行恢复
android2.0以后服务的onstar方法便废弃不用了,取而代之的是onStartCommand方法,onStartCommand方法返回一个int类型,这个返回值决定服务是否恢复。 START_NOT_STICKY 不重启  START_STICKY     杀死后重启,并传递一个空的intent给onStartCommand  START_REDELIVER_INTE