我之前帮不少开发者处理过这类Android版本升级带来的后台管控问题，你的情况是典型的未适配Android 8.0+后台执行规则导致的。下面给你几个针对性的解决方案，亲测有效：

1. 改用支持Doze模式的精确闹钟API #

Android 6.0+引入了Doze模式，普通的AlarmManager.set()或setRepeating()会被系统延迟甚至忽略，更别说Android 8+的后台限制了。你需要切换到精确且能突破Doze限制的API：

• 使用setExactAndAllowWhileIdle()：这个方法可以在Doze模式、App Standby状态下触发精确闹钟，完全满足定时提醒的需求。注意系统对它的调用频率有轻度限制（约15分钟一次），但日常提醒场景完全够用。
• 重复提醒不要依赖系统的重复闹钟API，而是在每次闹钟触发后，手动计算下一次触发时间，重新调用setExactAndAllowWhileIdle()设置。

示例代码片段：

AlarmManager alarmManager = (AlarmManager) getSystemService(Context.ALARM_SERVICE);
Intent intent = new Intent(this, AlarmReceiver.class);
// Android 12+必须添加FLAG_IMMUTABLE，避免安全异常
int flags = PendingIntent.FLAG_UPDATE_CURRENT;
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) {
    flags |= PendingIntent.FLAG_IMMUTABLE;
}
PendingIntent pendingIntent = PendingIntent.getBroadcast(this, requestCode, intent, flags);

// 根据系统版本选择对应的闹钟设置方式
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) {
    alarmManager.setExactAndAllowWhileIdle(AlarmManager.RTC_WAKEUP, triggerTimeMillis, pendingIntent);
} else {
    alarmManager.setExact(AlarmManager.RTC_WAKEUP, triggerTimeMillis, pendingIntent);
}

2. 严格遵守前台服务的新规则 #

Android 8+对前台服务的要求非常严格，稍有不慎就会被系统杀死：

• 必须创建通知渠道（API 26+强制），且渠道重要性设为IMPORTANCE_HIGH，这样通知会弹出提醒，系统也会认定该服务是高优先级的。
• 调用startForegroundService()启动服务后，必须在5秒内调用startForeground()显示有效通知，超时系统会直接终止服务。

示例代码：

// 初始化通知渠道（App启动时执行一次即可）
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
    NotificationChannel channel = new NotificationChannel(
        "reminder_service_channel", 
        "提醒服务", 
        NotificationManager.IMPORTANCE_HIGH
    );
    channel.setDescription("用于维持提醒服务的前台通知");
    NotificationManager notificationManager = getSystemService(NotificationManager.class);
    notificationManager.createNotificationChannel(channel);
}

// 在服务的onCreate/onStartCommand中启动前台
Notification notification = new NotificationCompat.Builder(this, "reminder_service_channel")
        .setContentTitle("提醒服务运行中")
        .setContentText("等待你的定时提醒触发")
        .setSmallIcon(R.drawable.ic_notification)
        .build();
startForeground(1001, notification);

3. 优化服务生命周期，减少后台占用 #

不要让前台服务一直挂着，只有在处理提醒任务时才启动：

• 闹钟触发后，通过BroadcastReceiver调用startForegroundService()启动服务；
• 处理完提醒逻辑后，立即调用stopForeground(true)和stopSelf()停止服务，降低系统资源占用，减少被杀死的概率。

4. 完善服务被杀死后的恢复逻辑 #

除了返回START_REDELIVER_INTENT，还要补充这些恢复手段：

• 注册ACTION_BOOT_COMPLETED广播接收器，设备重启后重新加载所有未触发的提醒，重新设置闹钟；
• 监听ACTION_POWER_CONNECTED（充电）、ACTION_USER_PRESENT（屏幕解锁）广播，在这些系统放宽限制的时机，重新校验并补设闹钟，避免提醒遗漏；
• 在广播接收器中优先检查本地存储的提醒任务，确保系统杀死服务后，闹钟配置不会丢失。

5. 为什么WorkManager不适合你的场景？ #

WorkManager的设计目标是延迟任务的可靠执行，它会根据系统电池、资源情况自动调整执行时间，无法保证精确触发——即使是OneTimeWorkRequest，系统也可能延迟十几分钟执行，完全不符合定时提醒的需求。

最后：测试Doze模式验证效果 #

用adb命令模拟Doze模式，验证你的闹钟是否能正常触发：

# 强制进入Doze模式
adb shell dumpsys deviceidle force-idle
# 查看当前闹钟状态，确认你的提醒已注册
adb shell dumpsys alarm
# 退出Doze模式
adb shell dumpsys deviceidle unforce

按照这些步骤优化后，你的应用应该能和Play Store上的同类提醒应用一样，在Android 9/10上稳定运行了。

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