自 2025 年 3 月 27 日起,我們建議您使用 android-latest-release
而非 aosp-main
建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
輸入法編輯器支援
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
以下是針對這些特定顯示區域所做的更新:
Android 10 支援在非預設螢幕上執行的應用程式使用的軟體鍵盤。
在非預設顯示器上執行的應用程式
就顯示哪個畫面顯示輸入法編輯器 (IME) 的軟體鍵盤而言,有不同的模式。軟體鍵盤會顯示在以下位置:
- 焦點應用程式顯示的相同螢幕。
- 預設:當焦點應用程式在非預設顯示器上執行時,系統會顯示此畫面。
- 完全沒有顯示。
系統會根據顯示畫面 (即焦點應用程式所在畫面) 的設定,決定要使用的模式。詳情請參閱:
WindowManager#setDisplayImePolicy()
WindowManager#getDisplayImePolicy()

圖 1. IME 軟體鍵盤在次要螢幕上顯示的樣子,包括目標應用程式
系統會使用單一輸入法編輯器,但可在螢幕之間切換,以便追蹤使用者的焦點。Android 10 會自動預期所有第一方和第三方 IME 會在建立時,根據新的顯示大小修改版面配置和調整大小。
如果螢幕 A 上有有效連線,且輸入欄位要求在螢幕 B 上取得輸入焦點,就會發生下列流程:
- 新的輸入連線來自螢幕 B 的輸入欄位。
InputMethodManagerService
會檢查是否應核准連線。
- 選取輸入法編輯器的顯示畫面。如果顯示器 B 支援顯示 IME 且允許顯示 IME,系統就會使用 B。否則系統會選取主要裝置螢幕。
- 如果所選顯示器不是來自顯示器 A,則會重新建立連線。
InputMethodService
會先刪除,然後再重新建立。
安全性限制
系統不會在非系統所擁有的虛擬螢幕上顯示 IME。這是因為惡意應用程式可能會建立虛擬顯示畫面,並啟用系統裝飾支援功能,從途徑讀取使用者敏感資訊,例如輸入預測內容和自訂背景。
實作
在 Android 9 (和以下版本) 中,輸入法編輯器僅適用於預設畫面,如「螢幕輸入法」一節所述。在 Android 10 (及以上版本) 中,使用者可以透過切換焦點,在不同螢幕上切換不同的輸入文字欄位,而輸入法編輯器視窗會移至次要螢幕。
WindowManager
中的實作項目會追蹤輸入法視窗 (繪製螢幕鍵盤的 IME 視窗) 和輸入法目標 (IME 輸入的視窗),以管理 IME 狀態。
對於 InputMethodManagerService
(IMMS),沒有其他內建機制可將顯示變更傳播至 InputMethodService
(IMS),並在將焦點移至其他螢幕時重新設定鍵盤配置。
為了在不同螢幕之間切換 IME 視窗,Android 10 實作了以下功能:
- IME 和輸入目標視窗現在會在
DisplayContent#mInputMethodWindow
和 DisplayContent#mInputMethodTarget
中依顯示器追蹤,讓 WindowManager (WM) 能夠獨立管理每個顯示器的 IME 焦點狀態。
- 在 IMMS 方面,當應用程式用戶端從外部螢幕接收焦點要求時,系統會先解除目前輸入法服務的繫結,然後重新繫結服務,以便在
onServiceConnected()
中重新附加外部螢幕的新 IME 視窗符記。ViewRootImpl#handleWindowFocusChanged ->
InputMethodManager#onPostWindowFocus ->
IMMS#startInputOrWindowGainedFocus
- 在 IMS 端,收到
IMS#attachToken
後,會發生以下流程:
- 系統會呼叫
ContextImpl#updateDisplay
,以便在 InputMethodService#attachToken()
中更新服務情境的顯示畫面。這會呼叫 ViewGroup#addView()
來修訂鍵盤的版面配置,並配合檢查目前情境的目標螢幕進行調整。
- 呼叫
DisplayContent#setInputMethodWindowLocked()
後,實作會使用 WindowProcessController
將程序層級顯示設定變更傳送至 IME 程序,以便覆寫資源和顯示指標。
onConfigurationChanged()
和 ViewGroup#addView()
呼叫重新初始化輸入檢視畫面後,InputMethodService
用戶端會取得正確的設定,並顯示正確的顯示指標。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-07-27 (世界標準時間)。
[null,null,["上次更新時間:2025-07-27 (世界標準時間)。"],[],[],null,["# Input method editor support\n\nUpdates made to these display-specific areas are provided below:\n\n- [Apps running on a non-default display](/docs/core/display/multi_display/ime-support#non-default)\n- [Multi-session input method editor support](/docs/core/display/multi_display/ime-support#ime-multi)\n\nAndroid 10 supports\n[software keyboard](https://developer.android.com/guide/topics/text/creating-input-method)\nfor apps running on a non-default display.\n\nApps running on a non-default display\n-------------------------------------\n\nIn terms of which display shows the software keyboard of the Input Method Editor\n(IME), there are different modes. The software keyboard is shown on the:\n\n- *Same* display on which the focused app appears.\n- *Default* display while the focused app is running on a non-default display.\n- *No* display at all.\n\nThe system determines which mode to use based on the settings of the display\non which the focused app appears. For more details, see:\n\n- `WindowManager#setDisplayImePolicy()`\n- `WindowManager#getDisplayImePolicy()`\n\n**Figure 1.** IME software keyboard as it appears on secondary display,\nincluding target app\n\nThe system uses a single IME, but can shift between displays to follow\nuser focus. Android 10 automatically expects all first- and third-party IMEs to\nrevise the layout and resize according to the new display size when created.\n\nIf there's an active connection on display A, and an input field requests\ninput focus on display B, then the following flow occurs:\n\n1. A new input connection comes from the input field on display B.\n2. `InputMethodManagerService` checks if the connection should be approved.\n3. A display is selected for the IME. If display B supports showing the IME and is allowed to show it, then B is used. Otherwise, the primary device display is selected.\n4. If the selected display is not from display A, then the connection is re-established. `InputMethodService` is destroyed and then created again.\n\n### Security restriction\n\nThe system won't show an IME on virtual displays that aren't owned by the\nsystem. This is due to a security concern that a malicious app could create a\nvirtual display with enabled\n[system decorations support](/docs/core/display/multi_display/system-decorations)\nand read user-sensitive information from the surface, such as typing predictions\nand custom backgrounds.\n\n### Implementation\n\nIn Android 9 (and lower), the IME was only available on the default screen, as\ndescribed in [On-Screen\nInput methods](https://android-developers.googleblog.com/2009/04/updating-applications-for-on-screen.html). In Android 10 (and higher), a user can switch\nbetween different input text fields on different displays by switching focus,\nand the IME window moves to the secondary displays.\n\nThe implementation in `WindowManager` tracks the input method\nwindow (the IME window where the soft keyboard is drawn) and the input method\ntarget (the window where the IME input goes) to manage the IME state.\n\nFor `InputMethodManagerService` (IMMS), no other built-in mechanism can\npropagate the display change to `InputMethodService` (IMS) and\nreconfigure the keyboard layout at runtime when moving focus to another display.\n\nTo achieve the IME window switch between displays, Android\n10 implements the following:\n\n- The IME and input target window are now tracked per display in `DisplayContent#mInputMethodWindow` and `DisplayContent#mInputMethodTarget`, so that the WindowManager (WM) can manage the IME focus state independently of each display.\n- On the IMMS side, when an app client's focus request from the external display is received through `ViewRootImpl#handleWindowFocusChanged -\u003e\n InputMethodManager#onPostWindowFocus -\u003e\n IMMS#startInputOrWindowGainedFocus`, it first unbinds the current input method service and then rebinds the service to reattach the new IME window token for the external display in `onServiceConnected()`.\n- On the IMS side, after the `IMS#attachToken` is received, the following flow occurs:\n - `ContextImpl#updateDisplay` is called to update the service context's display in `InputMethodService#attachToken()`. This calls `ViewGroup#addView()` to revise the layout of the keyboard and adapt to the target display checking the current context.\n - After `DisplayContent#setInputMethodWindowLocked()` is called, the implementation sends process-level display configuration changes using the `WindowProcessController` to IME process to override resources and display metrics.\n - The `InputMethodService` client gets the correct configuration with the correct display metrics after `onConfigurationChanged()` and the `ViewGroup#addView()` call to reinitialize the input view."]]