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>TextView de> 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>inputType de> 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>windowSoftInputMode de> 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>windowSoftInputMode de> 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>InputConnection de> interface allowing the IME to interact with your editor.

Input Methods

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

See the

de> InputMethodService de> 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>InputMethod de> interface, via the de>BIND_INPUT_METHOD de> 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>InputMethodSession de> 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>AbstractInputMethodService de> for normal IMEs, but must be explicitly handled by an IME that is customizing the raw de>InputMethodSession de> implementation.
Only the active client's de>InputConnection de> 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>InputConnection de> 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，可以用。出了问题用户负责怪不了系统。

Architecture Overview

Applications

Input Methods

Security

更多相关文章

随机推荐