适配Android12限制：如何通过WorkManager实现秒级后台位置更新

WorkManager从设计上就不适配你的需求——它是为可延迟、有执行保证的低频次后台任务设计的，系统强卡15分钟最小周期的规则，本质就是不允许开发者用它跑高频长耗时任务，所有试图hack WorkManager实现秒级任务的方案在Android 12+上都会被系统拦截，完全没必要在这个方向浪费时间。

核心实现方案：带位置类型声明的前台服务 #

Android 12的前台服务启动限制不是禁止使用前台服务，只是不允许App在完全退到后台、无任何可见界面的状态下凭空启动前台服务，对于轨迹追踪这类长时高频位置采集场景，官方支持的标准实现就是前台服务，按以下步骤配置即可：

• 第一步：补全权限和服务声明
  在AndroidManifest中声明所需权限：ACCESS_FINE_LOCATION（高精度GPS权限）、ACCESS_COARSE_LOCATION（模糊位置权限），如果要在App退后台后持续采集，还要申请ACCESS_BACKGROUND_LOCATION（后台位置权限）；Android 13（API33）及以上额外申请POST_NOTIFICATIONS权限，否则前台服务的常驻通知无法弹出，服务会直接崩溃。
  给你的轨迹采集服务添加前台服务类型声明，Android 12（API31）及以上必须指定android:foregroundServiceType="location"，否则启动服务直接抛异常。
• 第二步：在合规时机启动服务
  不要在后台偷偷启动服务，在用户主动点击「开始记录轨迹」按钮时启动服务——此时App处于前台状态，完全符合Android 12的前台服务启动规则，启动后立刻调用startForeground()传入常驻通知，只要服务不主动停止，哪怕App退到后台、退到锁屏状态，系统都不会拦截服务的运行。
• 第三步：在服务内注册系统位置回调，不要自己做轮询
  不需要自己写定时器每秒请求位置，直接用系统融合位置客户端FusedLocationProviderClient注册位置监听：构造LocationRequest时把采集间隔设为你需要的秒级参数（比如setInterval(1000)设置1秒间隔、setFastestInterval(500)设置最快回调间隔、setPriority(PRIORITY_HIGH_ACCURACY)开高精度模式），注册回调后系统会按你配置的频率主动推送位置更新，全程不需要自己做轮询逻辑，功耗和稳定性都比自己写定时任务好很多。
• 第四步：配置服务保活兜底
  把服务的onStartCommand返回值设为START_STICKY，如果服务因为内存不足被系统异常回收，系统会在内存充足时自动重启服务，重启后你只需要重新注册位置监听、重新拉起前台通知即可恢复采集。

常见踩坑说明 #

• 不要试图绕过前台服务拿高频后台位置：Android 10之后，没有前台服务的后台App，系统只会给每小时最多几次的位置回调，根本不可能达到秒级更新频率，所有无服务后台采集的方案现在都已经被系统封堵。
• 针对国产ROM的后台限制：部分厂商定制ROM会默认限制App后台活动，就算你按规范实现了前台服务，也可能被ROM的电池优化策略杀掉，这种情况没有系统级的绕开方案，只能在App内引导用户手动关闭电池优化、把App加入后台白名单，这也是所有运动、轨迹类App的通用做法。
• 合规注意：前台服务的常驻通知必须明确告知用户当前正在采集轨迹，不要隐藏通知、不要伪造通知用途，否则不仅可能被系统判定为恶意应用拦截，也会违反应用商店的隐私合规要求。

补充：如果你有轨迹数据定期上传的需求，可以在前台服务运行的同时，搭配WorkManager做15分钟以上周期的上传任务，但核心的位置采集逻辑必须放在前台服务里，不要交给WorkManager处理。

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