如何在Android API24-31实现无法被杀死的后台服务

现有实现问题 #

• 广播触发逻辑错误：Service的onDestroy中发送的广播意图指向服务类而非你注册的PathToReciever，接收器无法收到广播，重启逻辑完全不生效。
• 服务启动方法不兼容高版本：Android 8.0及以上禁止后台场景调用startService，你接收器中的启动逻辑在API 26+会直接抛出异常导致失败。
• 触发时机不可靠：当系统主动销毁进程回收资源时，Service的onDestroy回调不会执行，重启逻辑完全没有触发机会。

可行适配方案 #

首先说明：Android从7.0开始逐步收紧后台权限，普通第三方应用无法实现100%永不被杀死的后台服务，以下方案可以将服务存活率提升到最高水平：

1. 优先实现前台服务（官方合规方案，适配API 24-31完全可行） #

• 权限配置：在Manifest中添加对应权限

  <!-- API 28及以上通用前台服务权限 -->
  <uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
  <!-- 如果你用到位置类型前台服务，额外加位置权限 -->
  <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
  

• 服务启动逻辑适配：启动服务时根据系统版本选择调用方法

  Intent serviceIntent = new Intent(context, PathToService.class);
  if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
      context.startForegroundService(serviceIntent);
  } else {
      context.startService(serviceIntent);
  }
  

• 服务内部绑定前台通知：在Service的onCreate回调中5秒内调用startForeground，否则系统会强制杀死服务并触发ANR

  @Override
  public void onCreate() {
      super.onCreate();
      // 先创建Android O及以上需要的通知渠道
      if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
          NotificationChannel channel = new NotificationChannel("your_channel_id", "后台运行通知", NotificationManager.IMPORTANCE_LOW);
          NotificationManager manager = getSystemService(NotificationManager.class);
          manager.createNotificationChannel(channel);
      }
      // 构建通知
      Notification notification = new NotificationCompat.Builder(this, "your_channel_id")
              .setContentTitle("应用正在后台运行")
              .setContentText("点击返回应用")
              .setSmallIcon(R.mipmap.ic_launcher)
              .build();
      // 绑定前台服务，第一个参数是唯一的通知ID，不能为0
      startForeground(1001, notification);
  }
  

  前台服务会将你的应用进程优先级提升到仅次于用户正在使用的前台应用级别，被系统回收的概率会大幅降低。

2. 补充保活优化 #

• 申请电池优化白名单：跳转系统设置页引导用户将你的应用加入电池优化白名单，避免系统休眠时杀死进程。
• 用JobScheduler做周期检查：配置10分钟左右的周期任务，每次执行时检查服务是否存活，未存活则重新启动，该方案是系统官方推荐的后台任务调度方式，适配全版本系统稳定性远高于自定义广播重启。

3. 废弃原有无效的广播重启逻辑 #

你当前写的广播重启方案对高版本系统已经完全失效，不需要再保留，避免不必要的代码问题。

内容的提问来源于stack exchange，提问作者adam zverina