Android中的保活机制

Android中的保活是一个永不过时的话题，因为每一个APP都希望能在后台不停的运行去搜集用户数据，在Android 系统处于较低版本的时候（目前最新版本为12，较低版本指的是8以下），很多APP借助于系统层面的漏洞研发出了各种保活的方法，但是随着Android 版本的不断更新，过往的保活方法渐渐失效，Android中的保活成为了一个越来越难办到的事情，但是我认为这是一个好事，如非这样你永远不知道你的手机后台到底有多少APP背着你干了多少事情。当然，系统的事情不是我们能掌控的了的。那么，我们先来看看以前为了保活都有哪些手段。

手段一：在Service的onStartCommand方法中返回START_STICKY（亲测无效）

在Service的onStartCommand方法中返回键有下面几种可供选择：

（1）START_STICKY：如果Service所在的进程，在执行了onStartCommand方法后，被清理了，那么这个Service会被保留在已开始的状态，但是不保留传入的Intent，随后系统会尝试重新创建此Service。

（2）START_NOT_STICKY：如果Service所在的进程，在执行了onStartCommand方法后，被清理了，则系统不会重新启动此Service。

（3）START_REDELIVER_INTENT：如果Service所在的进程，在执行了onStartCommand方法后，被清理了，则结果和START_STICKY一样，也会重新创建此Service并调用onStartCommand方法。不同之处在于，如果是返回的是START_REDELIVER_INTENT ，则重新创建Service时onStartCommand方法会传入之前的intent。

手段二：在清单文件里面设置优先级（亲测无效）

手段三：在Service即将销毁的时候重新启动（亲测无效）

手段四：借助AIDL使用双进程保活（亲测无效）

首先创建一个AIDL文件

package com.steven.activitydemo;

// Declare any non-default types here with import statements

interface ProcessConnection {
   

 String getServiceName();

}

创建本地服务

public class LocalService extends Service {
   
    private MyBinder mBinder;

    private ServiceConnection connection = new ServiceConnection() {
   
        @Override
        public void onServiceConnected(ComponentName name, IBinder service) {
   
            ProcessConnection iMyAidlInterface = ProcessConnection.Stub.asInterface(service);
            try {
   
                Log.i("LocalService", "connected with " + iMyAidlInterface.getServiceName());
            } catch (RemoteException e) {
   
                e.printStackTrace();
            }
        }

        @Override
        public void onServiceDisconnected(ComponentName name) {
   
            Log.i(