Android 16 对后台任务的收紧，不是加了一条限制，而是改掉了配额的计算方式。过去“开一个前台服务，再在里面挂 JobScheduler 做周期任务”的经典保活组合，在 Android 16 上仍然能跑，但 Job 不再因为“有前台服务罩着”就获得豁免——与前台服务同时执行的作业，同样要遵守作业运行时配额。这意味着常驻策略需要从“靠前台服务保活一切”，转向“前台服务负责可见性，Job 负责被配额允许的节奏”，两者分工而非叠加。
下面用一个可落地的工程架构，结合 Trae 的 Chat / Builder 模式，把 Android 16 下的后台常驻从适配要点到代码实现走一遍。
Android 16 改了什么：三条必须正视的规则
第一，Job 配额按“状态”动态收紧。 Android 16 开始，常规作业和加急作业的运行时配额会根据应用所处的 App Standby 分桶、应用是否曾处于顶部状态、以及是否与前台服务并发执行来调整。不同分桶的近似配额差异很大：Active 桶 24 小时内可有约 30 分钟 Job 运行时，Working set 约 15 分钟，Frequent 约 10 分钟，Rare 和 Restricted 进一步压缩。保活代码不能假设“Job 总会跑”，而必须接受“Job 可能被配额叫停”。
第二，setImportantWhileForeground 完全失效。 这个方法自 Android 12 起已被废弃，Android 16 起调用它不再产生任何效果，isImportantWhileForeground() 也恒定返回 false。替代路径是 setExpedited(true)，让 Job 走加急执行队列，但加急同样受配额约束。
第三，前台服务不能从后台随意拉起。 targetSdk 31+ 的应用在后台启动前台服务会抛出 ForegroundServiceStartNotAllowedException，豁免场景包括从可见状态转换、用户对通知/小组件/FCM 高优先级消息做出交互、精确闹钟、设备重启等。常驻架构必须在这些合法时机内启动前台服务，而不是在后台上默默 startForegroundService()。
保活架构选型：前台服务做“壳”，Job 做“心跳”
在 Android 16 的约束下，一套相对稳健的常驻组合是：一个声明了正确 foregroundServiceType 的前台服务作为常驻壳，内部用 JobScheduler 调度加急周期 Job 执行业务逻辑，同时通过 App Standby 分桶感知和停止原因回传做可观测性。前台服务保证进程优先级和用户可见性，Job 则接受配额裁决，被叫停后由 onStopJob 决定是否重新入队。
Trae 在这个架构中的定位很明确：Builder 模式搭项目骨架，Chat 模式逐模块生成和审查代码，Android Studio 负责编译和真机验证。Trae 无法替代 Android Studio 的 Gradle 同步和 APK 安装，但它可以把“写 Manifest、算配额参数、加停止原因日志”这些重复度高的适配工作压缩到 Prompt 里完成。
Trae 实操 Step 1：Builder 模式生成前台服务 + Job 项目骨架
在 Trae 的 Builder 模式中输入：
“用 Kotlin 创建一个 Android 项目，包名
com.example.keepalive16，minSdk 26，targetSdk 36。包含一个KeepAliveService（前台服务），一个HeartbeatJobService（JobService），一个BootReceiver（监听BOOT_COMPLETED）。Manifest 中为KeepAliveService声明foregroundServiceType="dataSync"，为HeartbeatJobService声明android:permission="android.permission.BIND_JOB_SERVICE"，并申请POST_NOTIFICATIONS、RECEIVE_BOOT_COMPLETED、FOREGROUND_SERVICE、FOREGROUND_SERVICE_DATA_SYNC权限。先不要写具体逻辑，生成可编译的骨架即可。”
Builder 会生成项目结构和 Manifest。这一步的关键是让 Trae 把前台服务类型和权限声明一次性对齐 Android 14+ 的要求，避免后续因为 foregroundServiceType 缺失或类型不匹配导致启动失败。
Trae 实操 Step 2：用 Chat 模式生成加急 Job 调度器
选中 HeartbeatJobService，在 Chat 中输入：
“实现
scheduleHeartbeat(context)方法。用JobInfo.Builder创建一个周期 Job，setPeriodic(15 * 60 * 1000)，setRequiredNetworkType(NETWORK_TYPE_ANY)，并调用setExpedited(true)。不要使用setImportantWhileForeground，它已被废弃且无效。 设置setPersisted(true)以支持重启后恢复。用JobScheduler.enqueue提交，Job ID 固定为1001。”
Trae 会生成类似下面的代码。注意 setExpedited(true) 是 Android 16 下表达“这个 Job 需要尽快执行”的正确方式，而 setImportantWhileForeground 已经被完全移除出有效 API 集合。
kotlin
fun scheduleHeartbeat(context: Context) {
val scheduler = context.getSystemService(Context.JOB_SCHEDULER_SERVICE) as JobScheduler
val component = ComponentName(context, HeartbeatJobService::class.java)
val jobInfo = JobInfo.Builder(1001, component)
.setPeriodic(15 * 60 * 1000L)
.setRequiredNetworkType(JobInfo.NETWORK_TYPE_ANY)
.setExpedited(true)
.setPersisted(true)
.build()
scheduler.enqueue(jobInfo)
}
在 HeartbeatJobService.onStartJob 中执行业务逻辑后，必须调用 jobFinished(params, needsReschedule)。如果 Job 被系统因配额叫停，onStopJob(params) 会被回调，返回值决定是否重新调度。
Trae 实操 Step 3：Chat 模式补上停止原因可观测性
这是 Android 16 适配中容易被忽略但调试时不可或缺的一环。继续向 Trae 输入：
“在
HeartbeatJobService的onStopJob(params: JobParameters)中，用params.stopReason读取停止原因，记录到 Logcat，并判断如果原因是STOP_REASON_QUOTA或STOP_REASON_TIMEOUT_ABANDONED，返回true让系统重新调度。在onStartJob结束时也打印一次params.stopReason。”
Android 16 新增了 STOP_REASON_TIMEOUT_ABANDONED，专门标识因为 JobParameters 未被强引用、作业在未知状态下被废弃的情况。同时 JobScheduler#getPendingJobReasonsHistory 可以查询一个 Job 为什么没有执行——是卡在 App Standby 分桶、配额耗尽、设备状态还是显式约束未满足。把这些原因回传打日志，是在真机上判断“保活到底死在哪一步”的最直接手段。
Trae 生成的停止原因判断逻辑大致如下：
kotlin
override fun onStopJob(params: JobParameters): Boolean {
val reason = params.stopReason
Log.w("HeartbeatJob", "stopped, reason=$reason")
return when (reason) {
JobParameters.STOP_REASON_QUOTA,
JobParameters.STOP_REASON_TIMEOUT_ABANDONED -> true
else -> false
}
}
Trae 实操 Step 4：Chat 模式审查前台服务的启动时机与生命周期
把 KeepAliveService 和 BootReceiver 一起交给 Trae 审查：
“检查我的代码：
KeepAliveService是否在onStartCommand中及时调用了startForeground？BootReceiver收到BOOT_COMPLETED后启动前台服务是否在 Android 16 的豁免范围内？如果用户手动强制停止应用，Job 的setPersisted(true)在部分厂商 ROM 上是否仍然有效？给出降级建议。”
设备重启收到 BOOT_COMPLETED 后启动前台服务属于系统豁免场景之一，这一路径在 Android 16 上仍然可用。但 setPersisted(true) 在不同 OEM 上的实际行为差异较大，Trae 的审查会提示这类平台碎片化风险，而真正的结论需要回到真机上看 Logcat 中 JobScheduler 的调度回执。
真机验证与边界
代码生成后回到 Android Studio 编译安装。用以下 adb 命令绕过配额强制执行，对比“合规路径”和“关闭限制路径”的行为差异：
bash
adb shell am compat enable OVERRIDE_QUOTA_ENFORCEMENT_TO_FGS_JOBS com.example.keepalive16
这条命令停用“与前台服务同时执行的作业遵守配额”的强制执行。在开启和关闭该 compat 标志的两种情况下分别观察 HeartbeatJobService 的执行间隔和 stopReason，可以直观看到 Android 16 到底在哪个环节掐断了 Job。
需要明确的边界是：Android 16 的配额收紧方向是让后台执行更可预测、更省电，而不是提供一个“彻底绕过”的窗口。前台服务加加急 Job 的组合，是在规则内把常驻的可预期性做到最大——前台服务保证用户知道应用在运行，加急 Job 在配额允许时尽快执行，停止原因日志让开发者知道系统为什么说不。把这三件事做扎实，比追求一个脆弱的“永久保活”更接近 Android 16 下的工程现实。
