Android常驻后台获取location updates与Activity Transition的问题排查及实现

• 前台服务运行状态排查
  • 给两个前台服务全生命周期加本地埋点，逐次记录onCreate、onStartCommand、onDestroy、onTaskRemoved的触发时间戳，写入本地持久化存储，静置测试1天后导出日志，直接定位服务是否被系统终止、终止的时间点
  • 核对Android 12+版本的前台服务启动约束：确认运行时权限（位置、活动识别）是否真的被用户授予，不存在用户勾选“仅使用期间允许”导致服务在后台启动失败的问题
  • 不要把Doze白名单等同于万能保活：优先检查厂商定制系统（小米、华为、OPPO、vivo）的电源管理规则，手动开启应用的自启动、锁屏后后台运行、无限制电池使用权限——这类系统的杀后台优先级远高于原生Doze机制，是绝大多数静置后服务失效的核心原因
• FusedLocation定位有效性排查
  • 给每一次onLocationChanged回调加埋点，记录回调时间、坐标值、定位精度，重点验证Doze模式下定位回调的实际频率：很多时候系统会在闲置状态下自动拉长定位间隔到数小时，甚至停止回调
  • 核对定位请求参数：持续场景下的定位请求应该用PRIORITY_HIGH_ACCURACY，如果误设为PRIORITY_BALANCED_POWER_ACCURACY，系统会在闲置时直接切断定位供数
  • 排查定位匹配逻辑：确认代码有没有因为拿不到新位置，直接复用几小时前的缓存位置做判断，导致永远触发不了“到达指定位置”的逻辑
• Activity Recognition运行状态排查
  • 给所有活动切换回调加埋点，记录IN_VEHICLE、步行、跑步状态的实际触发时间，验证Doze模式下的回调延迟：原生系统在闲置状态下，活动识别的检测延迟最高可达2小时，完全达不到实时触发的要求
  • 检查RecognitionClient的绑定逻辑，避免在服务销毁时错误解绑客户端，导致后续所有活动回调丢失
• Doze模式下的业务逻辑排查
  • 不要靠主观判断测试Doze效果，直接用开发者选项模拟原生Doze场景：连接设备后执行adb shell dumpsys deviceidle force-idle，在强制Doze状态下验证服务运行、定位获取、后端请求、DB写入的全链路是否正常
  • 检查后端请求的异常捕获逻辑，确认Doze下网络受限导致的请求失败、主线程网络异常有没有被捕获，避免请求静默失败时无任何报错，最终导致DB无写入

• 不要设计24小时长期运行的前台服务：Android 8.0之后，即使是带通知的前台服务，在低内存机型、长期闲置场景下依然有极高的被系统回收概率，长期驻留不仅费电，还会被系统判定为高耗电应用主动限制
• 优先用系统级事件替代应用内部轮询：
  • 活动识别的切换逻辑，不要靠前台服务持续检测，而是通过ActivityTransition的PendingIntent直接绑定系统事件，当检测到IN_VEHICLE等状态变化时，由系统直接唤醒应用的处理逻辑，这个唤醒路径不受Doze模式影响，也不需要应用保持前台服务运行
  • 指定位置的触发逻辑，不要靠自己持续拉位置做匹配，而是用系统侧的Geofence地理围栏能力，当用户进入预设范围时，由系统定位服务主动唤醒应用执行后续逻辑，比应用内部轮询的稳定性高几个量级，也更省电
• 前台服务只做短期激活：当系统事件唤醒应用时，再临时启动前台服务执行短时间的定位采集、请求发送、DB写入逻辑，逻辑执行完成后及时销毁服务，不要长期占用前台服务名额

• 方案的可取之处：WorkManager是系统级任务调度，不受应用进程被杀的影响，到点系统会自动唤醒应用进程，比应用内部自实现的轮询可靠性高
• 方案的核心缺陷：
  • 原生Doze模式下，WorkManager的任务执行间隔会被系统自动拉长，非维护窗口内的任务会被批量延迟，根本做不到每15分钟准时执行，实际执行间隔可能达到数小时
  • Android 12+版本严格限制后台应用启动前台服务，从WorkManager的后台上下文直接拉起前台服务会直接触发权限异常，导致应用崩溃，除非应用拿到特殊豁免权限
• 优化后的可行落地方式：
  不要靠WorkManager做高频拉起，而是把WorkManager作为兜底校验手段：当系统事件（活动识别、地理围栏）正常唤醒应用时，先检查业务对应的前台服务是否在运行，缺失时再补启动；WorkManager的执行周期设为1小时一次做全链路状态校验即可，高频执行不仅会大幅增加耗电，还容易被系统判定为恶意滥用后台，直接封禁应用的后台权限

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