android 輸入法框架簡介

Architecture Overview

There are three primary parties involved in the input method framework (IMF) architecture:

• The input method manager as expressed by this class is the central point of the system that manages interaction between all other parts. It is expressed as the client-side API here which exists in each application context and communicates with a global system service that manages the interaction across all processes.
• An input method (IME) implements a particular interaction model allowing the user to generate text. The system binds to the current input method that is use, causing it to be created and run, and tells it when to hide and show its UI. Only one IME is running at a time.
• Multiple client applications arbitrate with the input method manager for input focus and control over the state of the IME. Only one such client is ever active (working with the IME) at a time.

Applications

In most cases, applications that are using the standard de>TextViewde> or its subclasses will have little they need to do to work well with soft input methods. The main things you need to be aware of are:

• Properly set the de>inputTypede> if your editable text views, so that the input method will have enough context to help the user in entering text into them.
• Deal well with losing screen space when the input method is displayed. Ideally an application should handle its window being resized smaller, but it can rely on the system performing panning of the window if needed. You should set the de>windowSoftInputModede> attribute on your activity or the corresponding values on windows you create to help the system determine whether to pan or resize (it will try to determine this automatically but may get it wrong).
• You can also control the preferred soft input state (open, closed, etc) for your window using the same de>windowSoftInputModede> attribute.

More finer-grained control is available through the APIs here to directly interact with the IMF and its IME -- either showing or hiding the input area, letting the user pick an input method, etc.

For the rare people amongst us writing their own text editors, you will need to implement de>onCreateInputConnection(EditorInfo)de> to return a new instance of your own de>InputConnectionde> interface allowing the IME to interact with your editor.

Input Methods

An input method (IME) is implemented as a de>Servicede>, typically deriving from de>InputMethodServicede>. It must provide the core de>InputMethodde> interface, though this is normally handled by de>InputMethodServicede> and implementors will only need to deal with the higher-level API there.

See the de>InputMethodServicede> class for more information on implementing IMEs.

Security

There are a lot of security issues associated with input methods, since they essentially have freedom to completely drive the UI and monitor everything the user enters. The Android input method framework also allows arbitrary third party IMEs, so care must be taken to restrict their selection and interactions.

Here are some key points about the security architecture behind the IMF:

• Only the system is allowed to directly access an IME's de>InputMethodde> interface, via the de>BIND_INPUT_METHODde> permission. This is enforced in the system by not binding to an input method service that does not require this permission, so the system can guarantee no other untrusted clients are accessing the current input method outside of its control.

• There may be many client processes of the IMF, but only one may be active at a time. The inactive clients can not interact with key parts of the IMF through the mechanisms described below.

• Clients of an input method are only given access to its de>InputMethodSessionde> interface. One instance of this interface is created for each client, and only calls from the session associated with the active client will be processed by the current IME. This is enforced by de>AbstractInputMethodServicede> for normal IMEs, but must be explicitly handled by an IME that is customizing the raw de>InputMethodSessionde> implementation.

• Only the active client's de>InputConnectionde> will accept operations. The IMF tells each client process whether it is active, and the framework enforces that in inactive processes calls on to the current InputConnection will be ignored. This ensures that the current IME can only deliver events and text edits to the UI that the user sees as being in focus.

• An IME can never interact with an de>InputConnectionde> while the screen is off. This is enforced by making all clients inactive while the screen is off, and prevents bad IMEs from driving the UI when the user can not be aware of its behavior.

• A client application can ask that the system let the user pick a new IME, but can not programmatically switch to one itself. This avoids malicious applications from switching the user to their own IME, which remains running when the user navigates away to another application. An IME, on the other hand, is allowed to programmatically switch the system to another IME, since it already has full control of user input.

• The user must explicitly enable a new IME in settings before they can switch to it, to confirm with the system that they know about it and want to make it available for use.

譯文：
InputMethodManager:
整個輸入法框架（IMF）結構的核心API，處理應用程序和當前輸入法的交互。可以通過Context.getSystemService()來獲取一個InputMethodManager的實例。

結構概覽：
一個IMF結構中包含三個主要的部分：
input method manager：管理各部分的交互。它是一個客戶端API，存在於各個應用程序的context中，用來溝通管理所有進程間交互的全局系統服務。
input method(IME)：實現一個允許用戶生成文本的獨立交互模塊。系統綁定一個當前的輸入法。使其創建和生成，決定輸入法何時隱藏或者顯示它的UI。同一時間只能有一個IME運行。
client application：通過輸入法管理器控制輸入焦點和IME的狀態。一次只能有一個客戶端使用IME。

applications:
大多數情況下，使用標准的TextView或者它的子類的應用很少能很好的使用soft input methods。你需要主要的主要事情如下：
當你的可編輯區域顯示的時候，正確設置inputType，以便於input method能找到足夠的context，這樣input method才能更好的輸入文本。
正確處理輸入法顯示的時候覆蓋的區域。理想情況下，應用應該處理窗口縮小帶來的影響。但是這依賴系統在需要的情況下對窗口重置的操作。你應該在activity中設置windowSoftInputMode屬性或者在創建的窗口設置適當的值，這能幫助系統判斷是否重置大小。系統自動嘗試判斷是否重置大小，但是這可能帶來錯誤。
你也可以通過windowSoftInputMode屬性對你的窗體設置最喜歡的soft input狀態。

你可以通過InputMethodManager這個API來實現更精細的控制。

當你自己謝自己的文本編輯域的時候，你必須實現onCreateInputConnection(EditInfo)來返回一個InputConnection的實例，用來允許IME和你的文本編輯域來交互。

input methods:
一個IME實現為一個Service，典型的是繼承InputMethodService。IME提供核心的InputMethod接口，盡管提供InputMethod通常是由InputMethodService來處理，而IME的實現只需要處理更高層的API。
更多信息參考InputMethodService

Security:
由於輸入法必須有自由去完全掌控UI，和監聽所有用戶輸入，所以這會導致很多安全問題。由於Android輸入法框架允許任何第三方軟件，所以注意限制IME的選中和交互。

以下是IMF背後的安全架構的關鍵點：
只允許系統通過BIND_INPUT_METHOD權限直接訪問IME的InputMethod接口。通過綁定到要求這個權限的服務來強制實現這一點。所以系統可以保證沒有不被信任的客戶端在它的控制之外訪問到當前的輸入法。
IMF框架中有很多客戶端進程，但僅有一個是活動的。不活動的客戶端不能和IMF的鍵部分交互。這是通過下述機制實現的。
輸入法的客戶端只被授予訪問輸入法的InputMethodSession接口的權限。每一個客戶端實現一個InputMethodSession接口的實例。當前IMF只處理和活動activity關聯的那個InputMethodSession。普通IME（繼承自InputMethodService)是通過AbstractInputMethodService強制實現的。但是自定義InputMethodSession實現的IME必須顯示處理這一點。
只有活動的客戶端的InputConnection可以采取操作。IMF判斷每一個客戶端是否活動，強制要求不活動的客戶端調用InputConnection會被忽略。這確保了IME傳遞事件和文本輸入到當前有焦點的UI。
屏幕關閉狀態下IME永遠不能和InputConnection交互。這一點通過使屏幕關閉狀態下所有的客戶端不活動來實現。這一點阻止了有問題的IME在用戶無法看到它的行為情況下操作用戶UI。
客戶端應用程序可以請求選擇一個新的IME，但是不能自己編程切換。這防止了惡意程序切換到自帶的IME，當用戶運行到另一個程序時，這個IME會保持運行。另一方面，IME程序可以編程實現切換到系統的另一個IME，這是因為IME本身已經擁有了用戶輸入的全部控制。
用戶使用新的IME之前，必須顯式地在設置裡面允許一個新的IME。這就是對系統說，我（用戶）已經知道了這個IME，可以用。出了問題用戶負責怪不了系統。