前台服务适配与线上排查：通知权限、启动限制和任务保活

前台服务并不是“永远不会被杀”的后台线程，而是一种需要向用户持续可见、同时受系统严格约束的任务执行方式。本文从基本规则出发，逐步梳理系统版本适配、工程实现、异常排查和架构边界，帮助你把定位、运动记录、音视频播放等长任务做得更稳定。

前台服务解决什么问题

普通 Service 的进程优先级有限，应用退到后台后，系统可能为了回收资源终止进程。前台服务通过常驻通知告诉用户“应用正在执行一项可感知的任务”，系统也会相应提高进程的重要性。

适合前台服务的场景通常同时满足两个条件：

• 任务需要在用户离开页面后继续执行；
• 用户能够明确感知任务正在运行。

常见例子包括导航、运动轨迹记录、通话、媒体播放、文件传输和已连接设备通信。数据同步、日志上传、定期刷新等延迟任务通常更适合 WorkManager，不应为了所谓“保活”滥用前台服务。

从启动到进入前台的完整链路

启动前台服务通常分为两个动作：应用请求创建服务，服务创建通知并进入前台状态。

val intent = Intent(context, LocationTrackingService::class.java).apply {
    action = LocationTrackingService.ACTION_START
}
ContextCompat.startForegroundService(context, intent)

服务收到请求后应尽快调用 startForeground()。如果启动后长时间没有进入前台状态，系统会终止服务并抛出异常。

class LocationTrackingService : Service() {

    override fun onCreate() {
        super.onCreate()
        createNotificationChannel()
    }

    override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
        if (intent?.action == ACTION_STOP) {
            stopTracking()
            stopForeground(STOP_FOREGROUND_REMOVE)
            stopSelf()
            return START_NOT_STICKY
        }

        val notification = buildNotification("正在记录运动轨迹")
        ServiceCompat.startForeground(
            this,
            NOTIFICATION_ID,
            notification,
            ServiceInfo.FOREGROUND_SERVICE_TYPE_LOCATION
        )
        startTracking()
        return START_STICKY
    }

    override fun onBind(intent: Intent?): IBinder? = null

    companion object {
        const val ACTION_START = "tracking.start"
        const val ACTION_STOP = "tracking.stop"
        const val NOTIFICATION_ID = 1001
    }
}

关键点不是简单调用 API，而是先把通知准备好，再启动耗时任务。不要在 startForeground() 之前执行网络请求、数据库迁移或复杂初始化。

Manifest 中声明服务类型

较新的 Android 版本要求前台服务声明用途。定位场景可以这样配置：

<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

<application>
    <service
        android:name=".LocationTrackingService"
        android:exported="false"
        android:foregroundServiceType="location" />
</application>

foregroundServiceType 必须与真实业务匹配，也要与 startForeground() 传入的类型一致。常见类型包括 location、mediaPlayback、camera、microphone、dataSync 和 connectedDevice。不同类型有不同的权限和后台启动条件，不能统一套用一个模板。

通知权限与前台服务不是同一件事

Android 13 引入通知运行时权限 POST_NOTIFICATIONS。用户拒绝通知权限，并不等于应用可以省略前台服务通知，也不代表 startForeground() 可以不调用。系统仍会记录前台服务，只是通知的展示位置和可见性会受到权限状态影响。

<uses-permission android:name="android.permission.POST_NOTIFICATIONS" />

val notificationPermission =
    Manifest.permission.POST_NOTIFICATIONS

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU &&
    ContextCompat.checkSelfPermission(this, notificationPermission) !=
    PackageManager.PERMISSION_GRANTED
) {
    permissionLauncher.launch(notificationPermission)
} else {
    startTrackingService()
}

产品流程上应在用户主动开启相关功能时说明通知用途。即使用户拒绝，也要根据业务和系统规则决定是否允许继续，而不是把通知权限结果直接当作所有服务权限的总开关。

后台启动限制是最常见的崩溃来源

应用处于后台时，系统不会允许它随意启动前台服务。推送回调、广播接收器和后台任务中直接调用 startForegroundService()，在新系统上可能触发 ForegroundServiceStartNotAllowedException。

可靠的设计原则是让用户可见操作成为启动入口，例如：

• 用户在页面点击“开始导航”或“开始记录”；
• 用户点击通知中的操作按钮；
• 满足系统明确规定的豁免场景。

对于不需要立即执行的后台工作，应改用 WorkManager。需要提醒用户回来继续操作时，可以发送通知，让用户点击后进入页面，再由前台页面启动服务。

fun startSafely(context: Context) {
    try {
        ContextCompat.startForegroundService(
            context,
            Intent(context, LocationTrackingService::class.java)
        )
    } catch (error: ForegroundServiceStartNotAllowedException) {
        scheduleDeferredWork(context)
        reportStartFailure(error)
    }
}

捕获异常只是兜底，不能替代正确的启动时机。真正需要修复的是调用链和业务入口。

Android 14 之后要在启动前检查权限

目标版本较高时，系统会在创建特定类型的前台服务时检查对应权限。定位服务不仅要声明前台服务权限，还要在启动前获得位置权限。摄像头和麦克风等“使用时权限”对应用可见状态也有额外约束。

建议把启动条件集中为一个可测试的检查器：

class TrackingStartPolicy(private val context: Context) {

    fun evaluate(): StartResult {
        val locationGranted = ContextCompat.checkSelfPermission(
            context,
            Manifest.permission.ACCESS_FINE_LOCATION
        ) == PackageManager.PERMISSION_GRANTED

        if (!locationGranted) return StartResult.MissingLocationPermission

        val notificationsGranted = Build.VERSION.SDK_INT < 33 ||
            ContextCompat.checkSelfPermission(
                context,
                Manifest.permission.POST_NOTIFICATIONS
            ) == PackageManager.PERMISSION_GRANTED

        return if (notificationsGranted) {
            StartResult.Ready
        } else {
            StartResult.NotificationPermissionDenied
        }
    }
}

这样可以把权限申请、降级提示和服务启动分开，避免 Activity、ViewModel 和 Service 各写一套判断。

通知渠道和操作按钮要真正可用

Android 8.0 及以上必须创建通知渠道。渠道创建后，重要程度由用户控制，应用后续修改 importance 不一定生效。

private fun createNotificationChannel() {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
        val channel = NotificationChannel(
            CHANNEL_ID,
            "运动记录",
            NotificationManager.IMPORTANCE_LOW
        ).apply {
            description = "显示运动轨迹记录状态"
            setShowBadge(false)
        }
        getSystemService(NotificationManager::class.java)
            .createNotificationChannel(channel)
    }
}

停止按钮应使用不可变且唯一的 PendingIntent，避免被错误复用：

val stopIntent = Intent(this, LocationTrackingService::class.java).apply {
    action = ACTION_STOP
}
val stopPendingIntent = PendingIntent.getService(
    this,
    2001,
    stopIntent,
    PendingIntent.FLAG_UPDATE_CURRENT or PendingIntent.FLAG_IMMUTABLE
)

通知内容也应随任务进度更新，但不要高频刷新。轨迹点每秒变化，并不意味着通知也要每秒更新；过度更新会增加系统负担和耗电。

正确理解 START_STICKY

START_STICKY 表示服务因资源压力被系统回收后，系统可以尝试重建服务。它不是重启承诺，更不能恢复内存里的业务状态。

需要恢复的最小状态应持久化，例如任务 ID、开始时间和当前阶段。服务重建时从数据库恢复，而不是依赖单例或静态变量。

用户主动停止后，必须清除恢复标记并调用 stopSelf()，否则下次进程启动时可能错误恢复。任务是否应该恢复是一条业务规则，应显式建模。

线上问题的排查顺序

遇到“服务没启动”“运行一会儿消失”或“只在某些手机失败”，可以按下面的顺序定位。

检查启动入口

记录应用前后台状态、触发来源、系统版本和目标 SDK。重点确认启动是否来自后台广播、推送或延迟回调。

检查异常类型

关注以下异常和日志关键词：

• ForegroundServiceStartNotAllowedException：后台启动受限；
• RemoteServiceException：启动后未及时进入前台；
• SecurityException：服务类型、声明或运行时权限不满足；
• MissingForegroundServiceTypeException：未声明或未传入服务类型。

检查通知状态

确认通知渠道存在、通知 ID 稳定、小图标有效，并检查用户是否关闭了通知权限或渠道。通知构建失败可能让服务无法及时进入前台。

区分系统回收与厂商限制

使用 adb shell dumpsys activity services <package> 查看服务状态，结合 logcat、进程退出原因和电池优化设置判断。不要一看到服务消失就归因于厂商系统，也不要把引导用户关闭电池优化作为默认方案。

观察业务自身是否停止

很多问题并非系统杀进程，而是代码调用了 stopSelf()、协程异常取消了根作用域，或状态机误判任务结束。为启动、进入前台、任务开始、异常、停止原因建立结构化埋点，通常比增加重启逻辑更有效。

一个更稳的工程结构

前台服务只负责系统生命周期适配，不应承载全部业务逻辑。可以拆分为：

• TrackingStartPolicy：判断权限、可见状态和启动条件；
• TrackingRepository：采集并持久化轨迹；
• TrackingNotification：创建渠道和构建通知；
• LocationTrackingService：连接系统回调与业务组件；
• TrackingStateStore：保存可恢复状态；
• TrackingTelemetry：记录启动和停止原因。

服务中的协程也要有明确的生命周期：

private val serviceJob = SupervisorJob()
private val serviceScope = CoroutineScope(
    serviceJob + Dispatchers.Default + CoroutineExceptionHandler { _, error ->
        telemetry.recordFailure(error)
        stopSelf()
    }
)

override fun onDestroy() {
    serviceJob.cancel()
    repository.stopTracking()
    super.onDestroy()
}

SupervisorJob 可以避免一个子任务失败后无条件取消所有并行任务，但异常仍需记录和处理。只创建不会取消的全局协程，会让资源泄漏和重复采集更难排查。

测试清单

前台服务的测试不能只覆盖一台开发机。至少应验证：

• 首次安装后允许和拒绝通知权限；
• 定位等业务权限被拒绝、仅本次允许和之后撤销；
• 应用在前台、后台和进程被回收后的行为；
• 通知渠道被关闭后的提示和降级路径；
• 用户从通知停止任务后不会自动恢复；
• 系统版本和目标 SDK 升级后的启动限制；
• 弱网、定位不可用和业务协程异常时能正确收尾；
• 多次点击启动按钮不会创建重复任务。

自动化测试可以覆盖启动策略和状态恢复，真实设备测试则用于验证系统权限、通知展示和进程行为。两者缺一不可。

总结

前台服务的稳定性来自遵守系统契约，而不是不断尝试拉活进程。实现时要明确服务类型，在正确的可见时机启动，及时展示通知，并把权限、恢复状态和停止原因纳入业务设计。

当任务不需要立即执行或用户无法感知时，优先考虑 WorkManager；当任务确实需要持续运行时，把前台服务做成轻量的系统适配层。这样既能通过新版本限制，也更容易定位真实的线上故障。