fix(android): treat null-class password/email fields as English (#200)

[jrywu]

Problem

A single Latin key tap in LINE's Add Friends → ID search field inserts the character twice (j → jj) — but only from the Chinese keyboard, not LIME's English keyboard.

Root cause (confirmed by on-device trace)

Captured the field's real EditorInfo on a Samsung SM-A1760 (Android):

onStartInput inputType=0x90  class=0x0(NULL)  variation=0x90(VISIBLE_PASSWORD)  imeOptions=SEARCH

The field declares a VISIBLE_PASSWORD variation with a null input class (0x90) instead of the well-formed 0x91 (TYPE_CLASS_TEXT | VISIBLE_PASSWORD).

LIME's forced-English handling in initOnStartInput() is gated on TYPE_CLASS_TEXT, so this field fell through to the Chinese composing path: a Latin key went into a composing region (setComposingText) instead of an atomic commit, and LINE's editor duplicated the composed character. The English keyboard forces mEnglishOnly=true (commit-only, no composing region) → no duplication.

The trace also proved LIME dispatches exactly one onKey + one setComposingText per tap — no LIME-side double-dispatch/double-commit. The duplication is entirely tied to the composing region, which only the Chinese keyboard creates. (The earlier TYPE_TEXT_VARIATION_URI / issue-#74 hypothesis is refuted — the field is not URI.)

Fix

Add effectiveInputClass(): a null-class field carrying a forced-English text variation (password / visible-password / web-password / email / web-email) is reinterpreted as TYPE_CLASS_TEXT, so LIME's existing commit-only handling applies. Every other input type is returned unchanged — ordinary Chinese text fields still compose. This extends LIME's existing password/email policy to the malformed null-class shape, not new behavior.

Test

test_200_NullClassForcedEnglishVariationResolvesToText:

• 0x90 → TYPE_CLASS_TEXT (RED without the fix: expected:<1> but was:<0>)
• rest of the forced-English set covered; well-formed fields unchanged
• a true null field stays null → composing preserved (guards against over-forcing)

Verified RED→GREEN on a Pixel 9 Pro API 37 emulator and the Samsung SM-A1760, and the fix confirmed on-device: the jj duplication is gone; the ID field now commits Latin directly like the English keyboard.

Notes / follow-ups

• The investigation doc from PR Investigate confirmed Android LINE ID duplicate input (#200) #201 (docs/#200_ISSUE.md) predates this trace and concluded "need a device trace." That's now done; its URI/記憶中英模式問題 #74 focus should be superseded by this confirmed root cause.
• Scope limit: this keys on the variation, so it fixes fields shaped like LINE's. If another app duplicates in a plain normal-text field, that composing is legitimate for Chinese and would be a separate issue (matching the reporter's vague "another app" hint).
• Behavior note: in this field the user can still tap 中 to switch to Chinese; because forced-English leaves mPredictionOn=false, that yields a candidates-only (no inline composing) state. Optional polish, not the reported bug.

🤖 Generated with Claude Code