入力欄に基づく Enter 判定を修正し、Gboard 比較の網羅テストを追加

[KazumaProject]

不具合と原因

入力欄から渡された EditorInfo と、キーボードのレイアウト・プライバシー・変換のための入力種類分類が混在していたため、Enter の送出が Gboard と異なる場合がありました。

• Google マップの写真コメント相当 (inputType=0x264001, imeOptions=0x40000006) では NO_ENTER_ACTION があるのに DONE を送出していました。
• 数値欄は SEARCH などの指定があっても DONE に固定されていました。
• 既定 TYPE_NULL は直接入力の経路で Enter キーイベントに固定され、GO などのアクションを扱えませんでした。
• SHORT_MESSAGE の改行では、文字列が同じでも Gboard の commitText("\n") と送出方式が異なるケースがありました。

起点の dev (bbdc7414746adeffc815d5158631e415a1167007) を別 APK にビルドして、上記 4 ケースの差を実機で確認しました。

判定・表示・送出の変更

EditorEnterPolicy を追加し、空入力での通常 Enter を最新の EditorInfo から決定します。

• NO_ENTER_ACTION がなければ標準の GO / SEARCH / SEND / NEXT / DONE / PREVIOUS を送出します。
• NONE / UNSPECIFIED または NO_ENTER_ACTION がある場合は Enter の DOWN/UP を送出します。Gboard の観測で異なっていた SHORT_MESSAGE は直接改行をコミットします。
• 宣言した条件で actionLabel / actionId によるキー送出変更は観測されなかったため、標準アクションと抑制フラグを使用します。
• 通常／フローティングのかなキーアイコン、QWERTY ラベル、数値／すみれの動的キー表示を共通の判定に接続します。動的キーの既存 0〜5 のアクション割り当てを維持し、PREVIOUS / GO / SEND の表示状態を追加します。
• アクションが拒否された場合に別の Enter を再送するフォールバックは設けず、二重送出を防ぎます。

入力種類の分類自体は変更しません。変換中の確定、文節処理、変換設定、強制改行、物理キーのショートカットは既存の経路を維持します。TYPE_NULL の明示的な直接入力設定やカスタム直接入力・ショートカットの上書きも維持します。

検証画面と網羅条件

-PenterParityLab を付けた場合だけ有効な独立モジュール enter-parity-lab を追加しました。製品 APK には入りません。

• raw EditText: 指定した EditorInfo をそのまま渡し、InputConnection のキーイベント、コミット、アクション、変換関連呼び出しを記録します。
• 実 EditText / Compose BasicTextField / WebView: フレームワークが実際に生成した EditorInfo で比較します。
• ローカルの受け口で文字列とフォーカス移動を確認します。送信・検索などが外部サービスに送られることはありません。
• 手動用の全ケース選択画面と、実際のソフトウェア Enter をタッチする Instrumentation を共用します。検証結果を作るための KEYCODE_ENTER 注入や判定関数の直接呼び出しは行いません。

条件群	ケース数
22 入力種類／variation × 8 アクション × 4 MULTI_LINE/IME_MULTI_LINE 状態 × 2 NO_ENTER_ACTION 状態 × 4 actionLabel/actionId 状態	5,632
その他のフラグ・数値フラグ・hintText/fieldName/privateImeOptions の 33 プローブ × 8 アクション × 2 抑制状態	528
マップ条件の回帰ケース	1
EditText / Compose / WebView × 8 アクション × 単行／複数行	48
合計	6,209

全 public text variation、数値の variation、電話、日時、TYPE_NULL を含みます。非テキストへの複数行フラグも非標準条件として明示して保持しています。マップだけに検証範囲を限定していません。

Gboard 期待値と回帰テスト

Gboard の画面上の Enter から得た全 6,209 ケースの観測を保存し、うち raw 6,161 行を TSV にして JVM テストで照合します。期待値生成器はプロダクションの判定関数を参照しません。完全な観測、正しい EditorInfo、Gboard の IME ID、単一の送出を検査してから書き出します。

比較器は全宣言ケースを走査し、一致・不一致・未実行・実行不能・EditorInfo 不一致・IME 不一致を区別します。欠測同士、違う IME、二重送出、同じ文字列でも違う送出方式を成功扱いにしません。再接続は raw フィールドの restartInput、入力欄切り替えはフォーカス移動と widget の交換で実行します。

テスト環境と結果

Pixel 6 / Android 17 / ja-JP、Gboard 18.1.3.962075747-release-arm64-v8a。修正版と起点 dev は別 application ID の liteStandardDebug を使用しました。

検証	結果
Gboard 参照取得	全 6,209 ケース観測済み
通常表示	6,209 / 6,209 一致
フローティング表示	6,209 / 6,209 一致
上記の不一致・未実行・実行不能・入力情報／IME 不一致	いずれも 0 件
レイアウト・表示の補助検証	5 レイアウト × 2 表示 × 8 アクション、80 ケース一致。ラベル／アイコン確認済み
変換・文節の維持	通常／フローティング × 文節区切り OFF／ON、計 30 段階が dev と一致
関連 JVM テスト	app 45 件 + custom_keyboard 51 件、すべて成功。6,161 行の Gboard 期待値照合を含む
比較器・期待値生成器の Python テスト	13 件成功
その他	明示的 TYPE_NULL 直接入力、手動検証画面、画面／IME 切り替え時の中断を確認

フローティングの Compose で初期値の EditorInfo が取得された 3 件は合格扱いにせず、安定した値の取得を待つよう修正して 16 件すべてを再取得しました。変換の比較でも、入力開始時の取りこぼしで Enter 前の状態が異なる試行を除外し、入力コールバックを確認して再実行しました。変換コードは変更していません。除外ログは採用した期待値・成功件数と分離して保存しています。

実装後レビュー

dev との差分をレビューし、判定条件、表示との整合、二重送出、入力欄切り替え時の状態、変換／文節への影響を確認しました。共通の直接入力処理から強制改行にも新しい判定が入る箇所を修正し、空入力の通常 Enter に限定しました。

検証側も、実行中の IME 切り替えで停止すること、終了処理が外部の IME 選択を上書きしないこと、フローティング window の探索、WebView 初期カーソルと古い非同期コールバック、Compose の実 EditorInfo 取得を確認・修正しました。

検証上の制限

• 全件一致の対象は宣言した 6,209 ケースと記録した Gboard バージョンです。任意の全アプリ・全ビット列・任意の privateImeOptions・将来の Gboard の一致を保証するものではありません。
• Gboard の日本語 QWERTY・左寄せ片手表示を参照し、本アプリの通常／フローティング表示を比較しています。Gboard の全言語・全表示モードを実行したという意味ではありません。
• Compose は実 EditorInfo・アクションコールバック・文字列・フォーカスを比較し、InputConnection 生イベントは直接捕捉していません。
• キーイベントは action / keyCode に正規化して比較しています。時刻・device ID・flags・modifier state の一致は対象外です。
• キーの意味と送出を確認し、テーマやアイコンのピクセル一致は要求していません。
• 元の dev の数値キーはアクセシビリティのラベルが空だったため、その 1 ケースだけ実画面で確認した座標を指定し、押下直前のスクリーンショットも保存しました。全件比較ではこの手動座標モードを使っていません。

詳細な構造・再実行手順・実測ログ・レビュー結果は docs/enter-editor-parity.md、docs/enter-editor-parity-results.md、tools/enter_parity/results/ に保存しています。