@@ -8,6 +8,12 @@ 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.
+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
 # will use them; the third is not, and stays undeclared until a service reads a position.
 
@@ -30,6 +30,14 @@
     <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. -->
+    <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
          reasoning, the engine choice and the privacy boundary are in
          analysis/CP-043_network_and_location.md, and these two lines are meaningless without
@@ -155,6 +163,19 @@
                 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>
+
         <service
             android:name=".TripRecordingService"
             android:exported="false"
 
@@ -0,0 +1,55 @@
+package com.evsuite.chargepilot
+
+import android.content.BroadcastReceiver
+import android.content.Context
+import android.content.Intent
+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.
+ *
+ * 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.
+ */
+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 (!TripRecordingService.isAutomaticDetectionEnabled(context)) {
+            AppLogger.i(TAG, "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}") }
+    }
+
+    private companion object { const val TAG = "EVChargePilot" }
+}