refactor(chargepilot): CP-080 says each thing once

A ponytail review of c97170d: 27 lines of KDoc over 14 lines of code, and the
same fact — 148 km driven, 32 km recorded — written five times across the
commit, the KDoc, the manifest, the allowlist and the ticket.

The KDoc keeps only what a reader of the file cannot derive from it: why
exported is safe on a protected broadcast, why the action is checked anyway,
why failures are caught. The measurement and the cost live in CP-080, which
is where a reviewer looks for them. The manifest comment defers to the
allowlist, which is the artefact the blocking CI gate actually reads.

MY_PACKAGE_REPLACED is dropped. An update is a manual act — the user is in
front of the screen and opens the app afterwards, which already restarts the
monitor — so it closed a gap bounded by one boot cycle at the cost of a
second action and a longer guard. BOOT_COMPLETED alone covers the case that
was measured.

The success log goes with it: the service logs "service created" and
"telemetry sampler started" one second later. The refusal log stays, because
"automatic detection is off" is the one outcome nothing else explains, and
this car has no ADB.

Net 31 lines removed, behaviour unchanged on the path that was measured.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: malys

.github/security/permission-allowlist.txt

@@ -8,11 +8,11 @@ android.car.permission.CAR_VENDOR_EXTENSION
 # Install-time permissions, no vehicle access, no network.
 android.permission.FOREGROUND_SERVICE
 android.permission.FOREGROUND_SERVICE_SPECIAL_USE
-# CP-080, 2026-09-24. The monitor is restarted after a head-unit boot and after this app is
-# updated, because the process dies with the car and until now only opening the app brought
-# recording back — 116 of 148 km driven in one measured week were never recorded. Install-time,
-# no vehicle access, no network, no data. It starts the same monitor the dashboard starts, and
-# that monitor suspends itself after ten consecutive reads with no usable speed.
+# CP-080, 2026-09-24. The monitor is restarted after a head-unit boot, because the process dies
+# with the car and until now only opening the app brought recording back — 116 of 148 km driven
+# in one measured week were never recorded. Install-time, no vehicle access, no network, no data.
+# It starts the same monitor the dashboard starts, and that monitor suspends itself after ten
+# consecutive reads with no usable speed.
 android.permission.RECEIVE_BOOT_COMPLETED
 # Reviewed and approved 2026-09-04 (CP-043). The first two are declared in the main
 # manifest as of the same day, by the owner's decision, ahead of the routing client that

app/src/main/AndroidManifest.xml

@@ -30,12 +30,7 @@
     <uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
     <uses-permission android:name="android.permission.FOREGROUND_SERVICE_SPECIAL_USE" />
 
-    <!-- CP-080. Automatic trip detection is worth nothing if it only starts when somebody opens
-         the app: the head unit shuts this process down with the car, and 116 of 148 km driven
-         between two probe bundles were never recorded for exactly that reason. This is an
-         install-time permission, it reaches no vehicle interface and it carries no data; what it
-         starts is the same monitor the dashboard starts, which suspends itself after ten reads
-         with no usable speed. -->
+    <!-- CP-080; reviewed in .github/security/permission-allowlist.txt. -->
     <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
 
     <!-- Route planning. Reviewed and accepted by the owner under CP-043 on 2026-09-04; the
@@ -163,16 +158,11 @@
                 android:resource="@xml/file_paths" />
         </provider>
 
-        <!-- exported, because a manifest receiver is not handed a system broadcast otherwise.
-             Both actions are protected broadcasts — only the platform may send them — and the
-             receiver checks the action regardless. -->
         <receiver
             android:name=".TripMonitorBootReceiver"
-            android:enabled="true"
             android:exported="true">
             <intent-filter>
                 <action android:name="android.intent.action.BOOT_COMPLETED" />
-                <action android:name="android.intent.action.MY_PACKAGE_REPLACED" />
             </intent-filter>
         </receiver>
 

app/src/main/java/com/evsuite/chargepilot/TripMonitorBootReceiver.kt

@@ -8,48 +8,27 @@ import com.evsuite.hardware.AppLogger
 /**
  * Restores automatic trip monitoring after a head-unit start, so recording is automatic in fact.
  *
- * [TripRecordingService] already outlives the dashboard — it is a *started* foreground service,
- * which is the whole reason a trip survives the driver switching to the media app. What it does
- * not survive is the car being switched off: the head unit shuts the process down with
- * everything else, and until CP-074 nothing started it again. The monitor therefore came back
- * only when somebody opened the app, and a drive begun without opening it was a drive nobody
- * recorded.
+ * Three things a reader of this file cannot work out from it, and nothing else — the measurement
+ * that motivated it and the cost it carries are in CP-080:
  *
- * CP-080. Measured, which is why this exists: the odometer moved 148 km between the 2026-09-17 and
- * 2026-09-24 bundles while the trip history recorded 32 km of it. Every threshold downstream is
- * paid for in recorded kilometres — the consumption fit needs a span of speeds, the health
- * estimate needs complete discharges the app watched, and eco-driving needs the drive it is
- * scoring — so coverage is upstream of all of them.
- *
- * **What it costs is bounded by the service, not by a promise here.** With automatic detection
- * off, nothing starts. With it on, the service samples at 1 Hz and suspends itself after ten
- * consecutive reads with no usable speed, which is what a head unit that booted without the
- * vehicle interfaces looks like. It writes to disk only when a completed trip is stored.
- *
- * `exported` is true because a manifest receiver does not hear a system broadcast otherwise,
- * and it is safe here for the reason the steering-wheel receiver elsewhere in this suite is
- * not: `BOOT_COMPLETED` and `MY_PACKAGE_REPLACED` are protected broadcasts, which only the
- * platform may send. The action is checked anyway — a receiver that acts on whatever arrives is
- * a receiver that trusted its manifest.
+ * - `exported` is true because a manifest receiver is not handed a system broadcast otherwise,
+ *   and it is safe here for the reason the steering-wheel receivers in this suite are not:
+ *   `BOOT_COMPLETED` is a protected broadcast, which only the platform may send.
+ * - The action is checked regardless, because a receiver that acts on whatever arrives is a
+ *   receiver that trusted its manifest.
+ * - Failures are caught because a crash in a boot receiver is the kind of instability this suite
+ *   may not introduce on a head unit, and the service is legitimately unreachable on a device
+ *   still unlocking.
  */
 class TripMonitorBootReceiver : BroadcastReceiver() {
 
     override fun onReceive(context: Context, intent: Intent?) {
-        val action = intent?.action
-        if (action != Intent.ACTION_BOOT_COMPLETED && action != Intent.ACTION_MY_PACKAGE_REPLACED) {
-            return
-        }
+        if (intent?.action != Intent.ACTION_BOOT_COMPLETED) return
         if (!TripRecordingService.isAutomaticDetectionEnabled(context)) {
-            AppLogger.i(TAG, "boot: automatic trip detection is off, nothing started")
+            AppLogger.i("EVChargePilot", "boot: automatic trip detection is off, nothing started")
             return
         }
-        // A failure here must not take the platform's boot broadcast down with it: the service
-        // is unavailable on a device still unlocking, and a crash in a boot receiver is the
-        // kind of instability this app is not permitted to introduce on a head unit.
         runCatching { TripRecordingService.monitorAutomaticTrips(context) }
-            .onSuccess { AppLogger.i(TAG, "boot: automatic trip monitor started; action=$action") }
-            .onFailure { AppLogger.w(TAG, "boot: monitor could not start: ${it.message}") }
+            .onFailure { AppLogger.w("EVChargePilot", "boot: monitor failed: ${it.message}") }
     }
-
-    private companion object { const val TAG = "EVChargePilot" }
 }