fix(veteran-lock): split the 25-byte LdAp frame across two ATT writes

A fresh Lynx S btsnoop showed the LeaperKim app writes the lock frame
in TWO ATT writes — first 20 bytes, then 5 bytes (valueByte + CRC32-BE
trailer) — back to back. Sending the same 25-byte buffer as a single
ATT write delivers only 20 bytes to the wheel because the negotiated
MTU is the default ~23; the CRC check fails on the wheel side and the
lock silently no-ops. This is the same MTU constraint that already
forced the horn into an LkAp + LdAp pair.

WheelAdapter gets a new setLockFollowup() mirroring hornFollowup. The
Veteran adapter caches the full 25-byte frame at setLock() so the
followup returns a CRC-consistent tail (both halves must come from the
same wall-clock build or the CRC drifts). WheelRepository writes both
halves in order on both the no-auth path (Veteran) and the auth path
(unused by Veteran today, kept symmetric for future families).

Test verifies the split sizes, that the concatenated bytes form a
CRC-valid 25-byte LdAp frame, and that the followup is locked to the
preceding setLock build.

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

Author: eried

app/src/main/java/com/eried/eucplanet/ble/CompositeWheelAdapter.kt

@@ -117,6 +117,7 @@ class CompositeWheelAdapter @Inject constructor(
     override fun setVolume(percent: Int): ByteArray? = active.setVolume(percent)
     override fun setDRL(on: Boolean): ByteArray? = active.setDRL(on)
     override fun setLock(locked: Boolean): ByteArray? = active.setLock(locked)
+    override fun setLockFollowup(locked: Boolean): ByteArray? = active.setLockFollowup(locked)
     override fun resetTripMeter(): ByteArray? = active.resetTripMeter()
 
     override fun requestAuthKey(): ByteArray? = active.requestAuthKey()

app/src/main/java/com/eried/eucplanet/ble/VeteranAdapter.kt

@@ -131,14 +131,38 @@ class VeteranAdapter @Inject constructor() : WheelAdapter {
     override fun setVolume(percent: Int): ByteArray? = null
     override fun setDRL(on: Boolean): ByteArray? = null
     // Software lock decoded from a Lynx S btsnoop, June 2026 (see
-    // VeteranCommands.setLock). Bytes 4..7 of the payload are the rider's
-    // wall clock at the moment of writing; the wheel rejects frames whose
-    // timestamp doesn't match, which is why the earlier session-counter
-    // version of this never actually locked the wheel. Wheel CRC-validates
-    // the frame, so older models that don't recognise the opcode silently
-    // ignore it — safe to expose on every Veteran-family wheel without
-    // per-model gating.
-    override fun setLock(locked: Boolean): ByteArray = VeteranCommands.setLock(locked)
+    // VeteranCommands.setLock). 25-byte LdAp vendor frame split across TWO
+    // ATT writes because Lynx-class firmware doesn't negotiate an MTU big
+    // enough for the full frame:
+    //   - setLock: first 20 bytes (magic + length + first 14 payload bytes)
+    //   - setLockFollowup: trailing 5 bytes (valueByte + CRC32-BE)
+    // The LeaperKim official app does the same split; sending the full 25
+    // bytes as one ATT write delivers only the first 20 bytes and the wheel
+    // rejects the truncated frame on CRC check, which is exactly what the
+    // earlier single-write build hit on every toggle.
+    //
+    // The full frame is cached after [setLock] so [setLockFollowup] returns
+    // the tail of THAT exact frame: bytes 4..7 of the payload are the rider's
+    // wall clock at the moment of writing, and the trailing CRC32 is computed
+    // over the whole frame, so the two halves MUST come from a single build
+    // or the wheel's CRC check fails. authMutex in WheelRepository serialises
+    // setLock+setLockFollowup pairs so the cache is safe.
+    @Volatile private var pendingLockFrame: ByteArray? = null
+
+    override fun setLock(locked: Boolean): ByteArray {
+        val full = VeteranCommands.setLock(locked)
+        pendingLockFrame = full
+        return full.copyOfRange(0, VeteranCommands.LOCK_FIRST_WRITE_SIZE)
+    }
+
+    override fun setLockFollowup(locked: Boolean): ByteArray? {
+        val full = pendingLockFrame ?: return null
+        pendingLockFrame = null
+        return full.copyOfRange(
+            VeteranCommands.LOCK_FIRST_WRITE_SIZE,
+            VeteranCommands.LOCK_TOTAL_SIZE,
+        )
+    }
 
     // CLEARMETER zeroes offset 8..11 (trip) on the next frame; see
     // VeteranCommands.resetTrip and spec section 6.

app/src/main/java/com/eried/eucplanet/ble/VeteranCommands.kt

@@ -266,4 +266,10 @@ object VeteranCommands {
     private val LDAP = byteArrayOf(0x4C, 0x64, 0x41, 0x70)  // "LdAp"
     private const val SUBOP_TILTBACK: Byte = 0x02
     private const val SUBOP_ALARM: Byte = 0x80.toByte()
+
+    /** Total bytes in a built lock LdAp frame. */
+    internal const val LOCK_TOTAL_SIZE = 25
+    /** First-write boundary for the lock frame: matches the LeaperKim app's
+     *  20-byte ATT split. Anything beyond this goes in the followup write. */
+    internal const val LOCK_FIRST_WRITE_SIZE = 20
 }

app/src/main/java/com/eried/eucplanet/ble/WheelAdapter.kt

@@ -184,6 +184,18 @@ interface WheelAdapter {
     fun setDRL(on: Boolean): ByteArray?
     fun setLock(locked: Boolean): ByteArray?
 
+    /**
+     * Tail bytes to write immediately after [setLock], on wheels whose lock
+     * frame exceeds the default ATT MTU and must be sent as two writes. The
+     * caller writes [setLock] first, then this. Default null for families
+     * whose lock fits in one packet. Veteran (Lynx-class, 25-byte LdAp lock
+     * frame) returns the trailing 5 bytes (valueByte + CRC32) here; without
+     * the split the wheel only receives the first 20 bytes and the CRC check
+     * fails on the wheel side, so the lock silently no-ops — the exact
+     * symptom users reported.
+     */
+    fun setLockFollowup(locked: Boolean): ByteArray? = null
+
     /**
      * Resets the wheel's onboard trip meter (the field reported as
      * [com.eried.eucplanet.data.model.WheelData.tripDistance]) by sending the

app/src/main/java/com/eried/eucplanet/data/repository/WheelRepository.kt

@@ -997,9 +997,15 @@ class WheelRepository @Inject constructor(
      */
     private suspend fun authenticateAndLock(locked: Boolean): Boolean = authMutex.withLock {
         val lockPacket = wheelAdapter.setLock(locked) ?: return@withLock false
+        // Lynx-class Veteran returns a second 5-byte tail because its 25-byte
+        // lock frame is split across two writes; pulled IMMEDIATELY after
+        // setLock so the cached full-frame in the adapter is still valid.
+        // Null on every other family (single-write lock).
+        val lockTail = wheelAdapter.setLockFollowup(locked)
 
         if (!wheelAdapter.capabilities.needsAuthForLock) {
             bleManager.writeCommand(lockPacket)
+            lockTail?.let { bleManager.writeCommand(it) }
             return@withLock true
         }
 
@@ -1049,6 +1055,7 @@ class WheelRepository @Inject constructor(
         // Step 3: Send lock/unlock command
         Log.i(TAG, "Lock packet (${lockPacket.size} bytes): ${lockPacket.joinToString(" ") { "%02X".format(it) }}")
         bleManager.writeCommand(lockPacket)
+        lockTail?.let { bleManager.writeCommand(it) }
         true
     }
 

app/src/test/java/com/eried/eucplanet/ble/VeteranLockTest.kt

@@ -88,4 +88,53 @@ class VeteranLockTest {
         assertEquals(23, frame[11].toInt() and 0xFF)
         assertEquals(42, frame[12].toInt() and 0xFF)
     }
+
+    /**
+     * The wheel only accepts the lock frame when it's written as two
+     * separate ATT writes (20 + 5 bytes), matching the LeaperKim app's
+     * btsnoop. A single 25-byte write is truncated to 20 bytes by the
+     * default ATT MTU and the wheel rejects it on CRC check — the bug
+     * that made the previous "wall-clock only" fix still appear broken.
+     */
+    @Test
+    fun `adapter splits lock frame into 20 plus 5 byte writes`() {
+        val adapter = VeteranAdapter()
+        val first = adapter.setLock(true)
+        val tail = adapter.setLockFollowup(true)
+        assertEquals("first ATT write is 20 bytes", 20, first.size)
+        assertEquals("followup ATT write is 5 bytes", 5, tail!!.size)
+        // The two halves concatenated must be a CRC-valid 25-byte LdAp frame.
+        val full = first + tail
+        assertEquals(25, full.size)
+        // Magic + length
+        assertEquals(0x4C.toByte(), full[0])
+        assertEquals(0x64.toByte(), full[1])
+        assertEquals(0x41.toByte(), full[2])
+        assertEquals(0x70.toByte(), full[3])
+        assertEquals(25.toByte(), full[4])
+        // CRC32-BE over bytes 0..20 must equal the trailer in bytes 21..24
+        val want = CRC32().apply { update(full, 0, 21) }.value.toInt()
+        val got = ((full[21].toInt() and 0xFF) shl 24) or
+                  ((full[22].toInt() and 0xFF) shl 16) or
+                  ((full[23].toInt() and 0xFF) shl 8) or
+                  (full[24].toInt() and 0xFF)
+        assertEquals(want, got)
+    }
+
+    /**
+     * setLockFollowup MUST come from the same build as the preceding setLock
+     * (the CRC covers the wall-clock bytes; a fresh build at the next second
+     * would produce a different CRC and split halves wouldn't agree).
+     */
+    @Test
+    fun `followup tail matches the preceding setLock build`() {
+        val adapter = VeteranAdapter()
+        val first = adapter.setLock(false)
+        // Simulate the WheelRepository call order: setLock immediately, then
+        // followup. The cache in the adapter holds the full frame.
+        val tail = adapter.setLockFollowup(false)!!
+        val full = first + tail
+        // Repeat: state == 0 (UNLOCK) at payload byte 12 (offset 17 in frame).
+        assertEquals(0x00.toByte(), full[17])
+    }
 }