DUAL_POINTER produces nonsense: the research measured the in-repo AOSP decoder, not the user-supplied library that actually runs

[AsafMah]

The finding

DUAL_POINTER produces nonsense words in real use. Reported after typing "ambulance" repeatedly on the experimental build with the mode enabled and multi-part composition armed.

Why — the research tested a different binary than the one that runs

This is the important part, and it invalidates the applicability (not the correctness) of the work in #141.

The research measured app/src/main/jni/ — the AOSP-derived native source in this repo. That's where MAX_POINTER_COUNT_G == 2 lives, and where updateTouchPoints partitions points by pointer id. The host harness (jni/tests/replay/two_pointer_track_test.cpp) drives that code, and its conclusions about it are sound.

But on a device with glide typing actually working, that is not the decoder doing the work. JniUtils loads a user-supplied library and it takes precedence:

System.load(userSuppliedLibrary.getAbsolutePath());
sHaveGestureLib = true;
sHaveNativeGestureLib = true;    // <-- only true for the user-supplied or system lib

The bundled in-repo library sets sHaveNativeGestureLib = false ("standard dictionary only, no gesture engine"). So sHaveNativeGestureLib being true by definition means a closed third-party binary is decoding, not the AOSP source we measured.

DUAL_POINTER splits the trail across pointer ids according to how the AOSP code partitions them. The library that actually receives that input is a proprietary Google build whose handling of a second pointer track is unknown to us. If it scores only track 0, or treats track 1 as the start of a second word, the result is exactly what was observed: a valid word split across two tracks decodes to garbage.

What this does and doesn't invalidate

Still valid:

• The pointer-id normalisation bug fix in Two-thumb experimental build (upstream v4.1.2 merged, installs side by side) #141 — a stroke whose points never carry id 0 returned zero suggestions. That's a real defect on the Java side and is unaffected.
• The falsification of temporal re-timing in B7c: Adaptive connector bridge + distance-based re-timing #100. Timestamps don't move points between tracks in the AOSP code, and overlapping them corrupts speed features.
• The host harness itself, as a tool for reasoning about the in-repo decoder.

Now unsupported:

• That feeding two tracks improves recognition on a device using a user-supplied library, which is every device where the setting is even visible.
• The premise of Two-thumb: drop the word-joining layer if thumbs are genuinely simultaneous #143 as written, since it assumed the decoder we measured is the decoder that runs.

Suggested next steps

1. Default DUAL_POINTER off and mark it as producing incorrect results with a user-supplied library, or gate it behind a debug flag until there's evidence it helps.
2. Establish what the loaded library actually does with a second track before building further on it. Options: compare suggestion output for the same trail submitted as one track vs two, directly on device; or accept that the closed binary is unmeasurable and drop the direction.
3. Re-scope Two-thumb: drop the word-joining layer if thumbs are genuinely simultaneous #143. The simplification argument rested on "the decoder natively models two tracks". That's true of the AOSP source and unverified for the binary in use.

Immediate

The reporter's experimental install has been returned to defaults (connector mode, no forced combining grace, no debug overlay) so it types normally again.