P3完了時点(P3完了条件と証跡対応表)では、standard運用は前面表示・画面ONを前提とし、Foreground Serviceを「採用しない」と判断していた。この判断は、その後のP5-2(Track #36/#37)で得られた実機事実と製品要件の確定により置き換えられた。現行実装(RtkForegroundService常駐)がbaselineである。
P5-2の段階B実施記録中、WireGuardアプリへ切り替えてトンネルをOFF/ONする試験で、製品アプリが約3分44秒間バックグラウンドとなり、heartbeatと診断ファイルの増加が停止した。トンネル経路自体は約56秒で復帰したが、製品アプリは前面へ戻るまでBluetooth/NTRIP切断を検知しなかった。
これは、現行実装がバックグラウンドで測位・通信・記録を継続できないことを示す実機事実である。詳細な試験記録はP5 RTK通信・記録再生を先行する開発・試験戦略の「WireGuard手動切替時に判明したバックグラウンド停止」節を参照。
製品要件は「バックグラウンドでも測位を記録し続ける」と確定した。前面表示必須という運用制約では受容しない。
測位処理をActivity/ViewModelのライフサイクルから分離し、Android Foreground Service(dev.drogger.tablet.service.RtkForegroundService)が所有する設計へ変更した。
RtkSessionHost(plain Kotlin)がRtkSession/FixRepository/DiagnosticRecorderを1回だけ構築し、start()/stop()を冪等にする。BluetoothGpsViewModelはbindServiceでServiceの状態を中継するだけの薄いproxyへ変更し、onCleared()ではunbindServiceのみ行いセッションは止めない。24075RP89G/MIUI)すべてバックグラウンドのまま実施し(前面へ戻したのは「前面復帰後の表示・二重起動なし」の確認時のみ)、次を確認した。
WireGuardトンネル操作時、低頻度(手動+無人再現試行あわせて18試行中1回、約5.6%)で原因不明の長時間停止(約3分49秒)が発生する。dumpsys activity processesはprocState=FGSを報告していたにも関わらず実行が止まっていた事象で、原因は未特定。既知の低頻度リスクとして記録し、発生時は前面復帰+WireGuardトンネル手動OFF/ONで復旧する。
Foreground Service化を採用する(baseline)。P3完了条件と証跡対応表の「Foreground Service要否」節は本書により置き換えられた判断として扱う。