Two-thumb: use the native decoder's second pointer track (research + pointer-id normalisation)

[AsafMah]

Research + implementation for "make two-thumb typing work with the native gesture decoder, via temporal alignment". Full write-up: docs/TWO_THUMB_TEMPORAL_ALIGNMENT.md. Fixes #135.

Verdict on the hypothesis

Claim	Verdict
The AOSP library can handle two simultaneous strokes	✅ Confirmed — it models exactly two pointer tracks and can spell a word by alternating between them
Temporally shift strokes so it accepts them as simultaneous	❌ Falsified — membership is decided purely by pointer id; shifting/overlapping moves zero points, and overlap actively corrupts the decoder's speed features
Promote taps into micro-swipes	✅ Sound — and already built on a stranded branch (#99); now ported and shipped opt-in
There's a better lever than the connector hack	✅ Pointer-id attribution — necessary to reach the second track

Directionally right, mechanically wrong. The goal is achievable and natively supported; the knob is pointerIds[], not the clock. Time still matters, but only to keep the concatenated array globally monotonic.

The measurement

A new harness drives the real AOSP ProximityInfoState on the host — the same preprocessing compiled into libjni_latinimegoogle.so — so this is measured, not inferred:

config                         | t0.used t0.n [raw range] minSpeed | t1.used t1.n [raw range] minSpeed
today  (all id 0, monotonic)   |   1     28 [  0.. 33]    0.491 |   0      0 [ -1.. -1]    0.000
split  (0/1, monotonic)        |   1     13 [  0.. 12]    0.884 |   1     15 [ 13.. 33]    0.521
split  (0/1, overlap 50%)      |   1     13 [  0.. 12]   -1.037 |   1     15 [ 13.. 33]  -1.247
all id 1                       |   0      0 [ -1.. -1]    0.000 |   1     28 [  0.. 33]    0.491
all id 2                       |   0      0 [ -1.. -1]    0.000 |   0      0 [ -1.. -1]    0.000

• Today the second track is dead. InputPointers.appendAll hardcoded pointer id 0, so both fragments landed in track 0 as one glide with a connector jump.
• Splitting ids partitions cleanly, with better speed rates than the merged trail.
• Negative minSpeed is impossible from real input (speed = length / duration) ⇒ garbage features. Overlap is the worst configuration tested.

What ships

Everything defaults to today's behaviour — nothing changes until a knob moves.

1. Bug fix (on by default). If no point carries id 0, Suggest::initializeSearch early-returns ⇒ zero suggestions. Reachable in ordinary two-thumb use: thumb A down (id 0), thumb B down (id 1), thumb A lifts, thumb B swipes on still carrying id 1. Ids ≥ 2 reach no track at all. PointerIdNormalizer renumbers raw MotionEvent ids in first-seen order at the BatchInputArbiter seam — identity mapping for normal input, repairs only the broken cases.

2. StrokeAligner — the multi-part merge seam, extracted from WordComposer.setBatchInputPointers. CONNECTOR (default) reproduces the old behaviour byte-for-byte; DUAL_POINTER puts prior fragments on track 0 and the in-flight stroke on track 1. It enforces all four constraints the research established (non-empty track 0, ids ∈ {0,1}, monotonic time, stable ids across incremental recognition).

3. IdealPrefixTrailBuilder — ported from the stranded #99/B7b branch, now runtime-toggleable instead of needing a side-by-side build type. Traces the prefix through key centres; a one-letter prefix becomes a 4-point micro-stroke.

Two-Thumb Typing → Recognition	Default
Joining word parts (one joined trail ↔ two separate thumb tracks)	one joined trail
Redraw earlier word parts cleanly	off
Word-part trail speed / Pause before the new part	25 ms / 60 ms

Prior art found in-repo

Epic #97 (B7 fake-track synthesis) is open; #98 and #99 are built but stranded on b7a-prefix-aware-stripping, never merged to dev. #100 is this hypothesis, specified months ago and never built. All of them treat the problem as a single track — "fake-track" is ironic, since the decoder has a real second track sitting unused. #97 also classifies #29 (per-thumb attribution) as a "different problem"; that separation looks wrong — it's the same lever.

Review fixes folded in

An adversarial cross-model review found three real issues, all fixed:

• CONNECTOR now pins the timing knobs to 25/60, so tuning them in dual mode and switching back can't silently change "one joined trail".
• A current stroke that is itself multi-pointer keeps its own ids instead of being flattened onto track 1 — preserving genuine simultaneous two-thumb structure.
• IdealPrefixTrailBuilder iterates code points and returns null on any unmappable letter, rather than silently producing a holed path.

Validation

• Native host suite 83/83 (+6 new); runs in CI via the existing native-tests.yml.
• JVM suite 356 tests, only the 4 documented Windows-only ParserTest failures — verified against a stashed baseline, by failing test name.
• assembleOfflineliteDebugNoMinify builds (validates Compose settings + resources).
• A test proves DUAL_POINTER changes pointer ids only — never geometry or timing — so the Java fallback engine (which ignores ids) provably cannot regress. The mode picker is hidden when no native lib is present.
• Two InputLogicTest flakes were seen during development; both were non-reproducible (3/3 clean on this branch and on baseline, different test each time, in looper/message-timing paths).

Not verified

On-device. Whether two tracks score better than one merged trail is decided by the closed weighting policy — no host test can produce a decoded word, since this tree has no gesture suggest policy. §6a of the doc has the A/B to run before considering any default change. The pointer-id fix also touches the live gesture path and deserves a real two-thumb check.

[AsafMah]

Superseded by #141, which contains every commit from this branch plus the upstream v4.1.2 merge and the side-by-side experimental build type (com.asafmah.leantypedual.exp, shown as LeanTypeDual EXP in the input-method picker) so it can be A/B'd against a working daily driver.

Both APKs are built and installed on the device. Closing in favour of #141.