Investigate confirmed Android LINE ID duplicate input (#200)

docs/#200_ISSUE.md

@@ -0,0 +1,103 @@
+# Issue #200 Analysis: LINE ID Search Duplicates Typed Characters on Android
+
+## Problem Statement
+
+On Android, typing one Latin character into LINE's Add Friends ID-search field can insert the character twice. The reported example is one `j` key tap producing `jj`.
+
+The reporter later recalled seeing the same duplicate-input symptom in another infrequently used app or input context, but could not identify it. This suggests the scope may be broader than LINE's ID-search field, but it is not yet a second reproducible environment.
+
+Reporter-supplied environment:
+
+- Android 14
+- Device model `ASUS_AI2202`
+- Host app: LINE
+- Field: Add Friends → ID search
+- LIME version: 6.1.36
+- LINE version: 26.11.0
+- Keyboard-mode boundary: reproduces when entering Latin characters from the Chinese keyboard; does not reproduce from LIME's English keyboard
+
+Independent maintainer reproduction:
+
+- Physical Samsung phone
+- Same LINE Add Friends → ID-search symptom
+- Exact Samsung model, Android version, LIME version, and LINE version were not recorded
+
+The exact Android `EditorInfo.inputType`, IME options, and whether all characters are affected are not yet known.
+
+## Reproduction Status
+
+The defect is confirmed. A maintainer independently reproduced the same #200 behavior on a physical Samsung phone. This establishes that the duplicate-input symptom is not limited to the reporter's ASUS device.
+
+The unidentified second context is supplementary scope evidence only. Until its app, field type, and reproduction steps are known, keep LINE Add Friends → ID search as the sole concrete reproduction path and investigate common Android editor conditions rather than assuming a LINE-only defect.
+
+The exact runtime boundary remains unknown. The Samsung reproduction confirms the user-visible defect, but no privacy-safe dispatch/commit trace has yet shown whether one tap is duplicated before `handleCharacter()`, inside LIME's composition/commit path, or by LINE's editor handling.
+
+Before changing code, collect privacy-safe diagnostics on the reproduced device path that identify:
+
+1. The field's `EditorInfo.inputType`, variation flags, and `imeOptions`.
+2. Whether one tap invokes `LIMEService.onKey()` once or twice.
+3. Whether LIME calls `InputConnection.commitText()` once or twice.
+4. Whether LINE renders one `commitText()` call twice, or whether duplication happens earlier in LIME.
+5. What differs in dispatch/composition/commit traces between the reproducing Chinese-keyboard path and the non-reproducing English-keyboard path.
+
+Do not log the user's actual LINE ID or surrounding field contents.
+
+## Current Source Findings
+
+`LIMEService.initOnStartInput()` classifies password, visible-password, email, and web-email text variations as forced-English fields. In that mode prediction is disabled and the email-style keyboard is selected.
+
+For an ordinary software-key tap in English-only mode, `handleCharacter()` reaches a single direct call:
+
+```java
+ic.commitText(String.valueOf((char) primaryCode), 1);
+```
+
+Source inspection therefore does not establish an unconditional double-commit in the normal English soft-key path. If the affected LINE field reaches that path and `onKey()` is called once, LIME should issue one commit for `j`.
+
+Issue #74 changed URL and search fields from forced English handling to normal text handling. That change is relevant chronology, but it is not yet evidence for this defect because LINE's exact field variation is unknown and the current forced-English helper still handles password/email variations separately.
+
+## Root-Cause Assessment
+
+Root cause is not yet confirmed. The failure must first be isolated to one boundary:
+
+- duplicate key dispatch before `handleCharacter()`
+- duplicate LIME `InputConnection` calls
+- a composing/commit transition caused by the field restarting input
+- host-editor handling that duplicates a single LIME commit
+
+A source-only fix based on the field name or an assumed Android variation would be speculative and could regress password, email, URL, search, or normal text fields.
+
+## Proposed Solution
+
+No production change should be selected until the device trace identifies the failing boundary.
+
+After capturing the reproduced runtime boundary:
+
+1. Add the smallest RED regression test using the captured `EditorInfo` flags and the real affected LIME key path.
+2. Make one focused correction at the proven duplicate-dispatch, composition, or commit boundary.
+3. Preserve one-tap/one-character behavior in password, email, URL/search, and ordinary text fields.
+4. Keep logs and tests free of user identifiers and entered LINE IDs.
+
+## Follow-up Questions
+
+- Does every Latin letter duplicate, or only `j`?
+- Can a second app and input-field purpose be identified if the symptom recurs?
+- Does another keyboard enter one character correctly in the same field?
+
+## Verification Plan
+
+### Android
+
+1. Preserve the confirmed physical Samsung reproduction and record its model/Android version when available.
+2. Repeat on `ASUS_AI2202` if available to compare the original environment.
+3. Capture privacy-safe `EditorInfo`, key-dispatch count, and `InputConnection` call count on the reproduced path.
+4. Add a failing automated test that proves one key tap currently produces two insertions at the isolated boundary.
+5. Verify the focused test turns GREEN after the correction.
+6. Run the relevant Android unit and instrumentation suites.
+7. Runtime-check the confirmed Chinese-keyboard path, the non-reproducing English-keyboard path, and password, email, URL/search, and ordinary text fields.
+8. If a second app/field becomes identifiable, verify it against the same isolated boundary.
+9. Ask the original reporter to retest a publicly available build containing the fix before closing the issue.
+
+### iOS
+
+No iOS impact is reported. The iOS keyboard extension uses a separate input path, so this Android-specific report does not establish an iOS defect. No iOS code change is planned unless independent iOS runtime evidence reproduces the same behavior.

docs/BACKLOG.md

@@ -5,6 +5,7 @@ Public backlog for confirmed unresolved fixes and product work. Issue-specific i
 Last reviewed: 2026-07-25
 
 ## Pending fixes
+- fix#200 Android: the LINE Add Friends ID-search duplication is independently confirmed on a physical Samsung phone, whose exact environment was not recorded. The reporter supplied LIME 6.1.36 and LINE 26.11.0 on Android 14 `ASUS_AI2202`, with one Latin tap duplicating (`j` becomes `jj`) from the Chinese keyboard while LIME's English keyboard does not reproduce it. The reporter also recalls the same symptom in another unidentified app or input context, so LINE remains the sole concrete reproduction while common Android editor conditions stay in scope. Capture the privacy-safe `EditorInfo`, key-dispatch count, and `InputConnection` call boundary on the reproduced path, add a RED regression for the exact field path, then make the smallest root-cause correction and verify both keyboard modes plus password, email, URL/search, and ordinary text fields. No iOS defect is reported. See `docs/#200_ISSUE.md`.
 - fix#196 Android release QA: PR #198 merged the reporter-path routing fix as `a96dcef659aa20796f6cab2edefe091de24823de`; follow-up PR #206 merged the unresolved declared-root candidate refresh and synchronous stale-selection reset as `7ccc47a821e2e6bfe1c68189b875769e2cd75117`. Focused instrumentation passed on a Pixel 9 Pro API 37 emulator. Public v6.1.36 predates both merges. Deliver and verify a newer Android build, complete the interactive enabled/cleared-end-key checks, then ask the reporter to confirm that enabled `limeendkey=,.` makes `v` then `,` commit `好，`. Issue #196 remains maintainer-closed. See `docs/#196_ISSUE.md`.
 - fix#196 iOS release QA: PR #206 merged the declared-root consume-once, candidate refresh, and synchronous stale-selection reset as `7ccc47a821e2e6bfe1c68189b875769e2cd75117`. Focused behavioral and routing/policy tests passed on the iPhone 17 Pro Max simulator. Deliver a newer iOS build and verify the declared-root path on iPhone, full iPad, and narrow iPad. See `docs/#196_ISSUE.md`.
 - fix#194 Android release QA: PR #195 merged the reporter-authoritative `20260723_082459` source and corrected 33,044-row `hahacj.limedb` archive as `722dcbf095fe2f8da2c00923bfe1eca467446ad0`; source/archive and exact Android runtime verification pass with sorting disabled at `j → 都, 十`. Public v6.1.36 predates the merge. Deliver a newer Android build, verify clean and existing-install paths, tell existing users to remove/re-download 哈哈倉頡, and request reporter confirmation. See `docs/#194_ISSUE.md`.