- InputMethodManager
- Class Overview
- Architecture Overview
- Applications
- Input Methods
- Security
- Summary
- Constants
- public static final int HIDE_IMPLICIT_ONLY
- public static final int HIDE_NOT_ALWAYS
- public static final int RESULT_HIDDEN
- public static final int RESULT_SHOWN
- public static final int RESULT_UNCHANGED_HIDDEN
- public static final int RESULT_UNCHANGED_SHOWN
- public static final int SHOW_FORCED
- public static final int SHOW_IMPLICIT
- Public Methods
- public void displayCompletions (View view, CompletionInfo[] completions)
- public InputMethodSubtype getCurrentInputMethodSubtype ()
- public List getEnabledInputMethodList ()
- public List getEnabledInputMethodSubtypeList (InputMethodInfo imi, boolean allowsImplicitlySelectedSubtypes)
- InputMethodService
- Class Overview
- Soft Input View
- Candidates View
- Fullscreen Mode
- Generating Text
- Summary
- XML Attributes
- android:imeExtractEnterAnimation
- android:imeExtractExitAnimation
- android:imeFullscreenBackground
InputMethodManager
java.lang.Object | |
↳ | android.view.inputmethod.InputMethodManager |
Class Overview
Central system API to the overall input method framework (IMF) architecture, which arbitrates interaction between applications and the current input method. You can retrieve an instance of this interface with Context.getSystemService() .
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 TextView 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 inputType in 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 windowSoftInputMode 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 windowSoftInputMode 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 onCreateInputConnection(EditorInfo) to return a new instance of your own InputConnection interface allowing the IME to interact with your editor.
Input Methods
An input method (IME) is implemented as a Service , typically deriving from InputMethodService . It must provide the core InputMethod interface, though this is normally handled by InputMethodService and implementors will only need to deal with the higher-level API there.
See the InputMethodService 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 InputMethod interface, via the BIND_INPUT_METHOD 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 InputMethodSession 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 AbstractInputMethodService for normal IMEs, but must be explicitly handled by an IME that is customizing the raw InputMethodSession implementation.
Only the active client’s InputConnection 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 InputConnection 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.
Summary
Constants | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
int | HIDE_IMPLICIT_ONLY | Flag for hideSoftInputFromWindow(IBinder, int) to indicate that the soft input window should only be hidden if it was not explicitly shown by the user. | |||||||||
int | HIDE_NOT_ALWAYS | Flag for hideSoftInputFromWindow(IBinder, int) to indicate that the soft input window should normally be hidden, unless it was originally shown with SHOW_FORCED . | |||||||||
int | RESULT_HIDDEN | Flag for the ResultReceiver result code from showSoftInput(View, int, ResultReceiver) and hideSoftInputFromWindow(IBinder, int, ResultReceiver) : the state of the soft input window changed from shown to hidden. | |||||||||
int | RESULT_SHOWN | Flag for the ResultReceiver result code from showSoftInput(View, int, ResultReceiver) and hideSoftInputFromWindow(IBinder, int, ResultReceiver) : the state of the soft input window changed from hidden to shown. | |||||||||
int | RESULT_UNCHANGED_HIDDEN | Flag for the ResultReceiver result code from showSoftInput(View, int, ResultReceiver) and hideSoftInputFromWindow(IBinder, int, ResultReceiver) : the state of the soft input window was unchanged and remains hidden. | |||||||||
int | RESULT_UNCHANGED_SHOWN | Flag for the ResultReceiver result code from showSoftInput(View, int, ResultReceiver) and hideSoftInputFromWindow(IBinder, int, ResultReceiver) : the state of the soft input window was unchanged and remains shown. | |||||||||
int | SHOW_FORCED | Flag for showSoftInput(View, int) to indicate that the user has forced the input method open (such as by long-pressing menu) so it should not be closed until they explicitly do so. | |||||||||
int | SHOW_IMPLICIT | Flag for showSoftInput(View, int) to indicate that this is an implicit request to show the input window, not as the result of a direct request by the user. |
Public Methods | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Constantspublic static final int HIDE_IMPLICIT_ONLYFlag for hideSoftInputFromWindow(IBinder, int) to indicate that the soft input window should only be hidden if it was not explicitly shown by the user. public static final int HIDE_NOT_ALWAYSFlag for hideSoftInputFromWindow(IBinder, int) to indicate that the soft input window should normally be hidden, unless it was originally shown with SHOW_FORCED . public static final int RESULT_HIDDENFlag for the ResultReceiver result code from showSoftInput(View, int, ResultReceiver) and hideSoftInputFromWindow(IBinder, int, ResultReceiver) : the state of the soft input window changed from shown to hidden. public static final int RESULT_SHOWNFlag for the ResultReceiver result code from showSoftInput(View, int, ResultReceiver) and hideSoftInputFromWindow(IBinder, int, ResultReceiver) : the state of the soft input window changed from hidden to shown. public static final int RESULT_UNCHANGED_HIDDENFlag for the ResultReceiver result code from showSoftInput(View, int, ResultReceiver) and hideSoftInputFromWindow(IBinder, int, ResultReceiver) : the state of the soft input window was unchanged and remains hidden. public static final int RESULT_UNCHANGED_SHOWNFlag for the ResultReceiver result code from showSoftInput(View, int, ResultReceiver) and hideSoftInputFromWindow(IBinder, int, ResultReceiver) : the state of the soft input window was unchanged and remains shown. public static final int SHOW_FORCEDFlag for showSoftInput(View, int) to indicate that the user has forced the input method open (such as by long-pressing menu) so it should not be closed until they explicitly do so. public static final int SHOW_IMPLICITFlag for showSoftInput(View, int) to indicate that this is an implicit request to show the input window, not as the result of a direct request by the user. The window may not be shown in this case. Public Methodspublic void displayCompletions (View view, CompletionInfo[] completions)public InputMethodSubtype getCurrentInputMethodSubtype ()Returns the current input method subtype. This subtype is one of the subtypes in the current input method. This method returns null when the current input method doesn’t have any input method subtype. public List getEnabledInputMethodList ()public List getEnabledInputMethodSubtypeList (InputMethodInfo imi, boolean allowsImplicitlySelectedSubtypes)Returns a list of enabled input method subtypes for the specified input method info. Источник InputMethodService
Class OverviewInputMethodService provides a standard implementation of an InputMethod, which final implementations can derive from and customize. See the base class AbstractInputMethodService and the InputMethod interface for more information on the basics of writing input methods. In addition to the normal Service lifecycle methods, this class introduces some new specific callbacks that most subclasses will want to make use of:
An input method has significant discretion in how it goes about its work: the InputMethodService provides a basic framework for standard UI elements (input view, candidates view, and running in fullscreen mode), but it is up to a particular implementor to decide how to use them. For example, one input method could implement an input area with a keyboard, another could allow the user to draw text, while a third could have no input area (and thus not be visible to the user) but instead listen to audio and perform text to speech conversion. In the implementation provided here, all of these elements are placed together in a single window managed by the InputMethodService. It will execute callbacks as it needs information about them, and provides APIs for programmatic control over them. They layout of these elements is explicitly defined:
Soft Input ViewCentral to most input methods is the soft input view. This is where most user interaction occurs: pressing on soft keys, drawing characters, or however else your input method wants to generate text. Most implementations will simply have their own view doing all of this work, and return a new instance of it when onCreateInputView() is called. At that point, as long as the input view is visible, you will see user interaction in that view and can call back on the InputMethodService to interact with the application as appropriate. There are some situations where you want to decide whether or not your soft input view should be shown to the user. This is done by implementing the onEvaluateInputViewShown() to return true or false based on whether it should be shown in the current environment. If any of your state has changed that may impact this, call updateInputViewShown() to have it re-evaluated. The default implementation always shows the input view unless there is a hard keyboard available, which is the appropriate behavior for most input methods. Candidates ViewOften while the user is generating raw text, an input method wants to provide them with a list of possible interpretations of that text that can be selected for use. This is accomplished with the candidates view, and like the soft input view you implement onCreateCandidatesView() to instantiate your own view implementing your candidates UI. Management of the candidates view is a little different than the input view, because the candidates view tends to be more transient, being shown only when there are possible candidates for the current text being entered by the user. To control whether the candidates view is shown, you use setCandidatesViewShown(boolean) . Note that because the candidate view tends to be shown and hidden a lot, it does not impact the application UI in the same way as the soft input view: it will never cause application windows to resize, only cause them to be panned if needed for the user to see the current focus. Fullscreen ModeSometimes your input method UI is too large to integrate with the application UI, so you just want to take over the screen. This is accomplished by switching to full-screen mode, causing the input method window to fill the entire screen and add its own «extracted text» editor showing the user the text that is being typed. Unlike the other UI elements, there is a standard implementation for the extract editor that you should not need to change. The editor is placed at the top of the IME, above the input and candidates views. Similar to the input view, you control whether the IME is running in fullscreen mode by implementing onEvaluateFullscreenMode() to return true or false based on whether it should be fullscreen in the current environment. If any of your state has changed that may impact this, call updateFullscreenMode() to have it re-evaluated. The default implementation selects fullscreen mode when the screen is in a landscape orientation, which is appropriate behavior for most input methods that have a significant input area. When in fullscreen mode, you have some special requirements because the user can not see the application UI. In particular, you should implement onDisplayCompletions(CompletionInfo[]) to show completions generated by your application, typically in your candidates view like you would normally show candidates. Generating TextThe key part of an IME is of course generating text for the application. This is done through calls to the InputConnection interface to the application, which can be retrieved from getCurrentInputConnection() . This interface allows you to generate raw key events or, if the target supports it, directly edit in strings of candidates and committed text. Information about what the target is expected and supports can be found through the EditorInfo class, which is retrieved with getCurrentInputEditorInfo() method. The most important part of this is EditorInfo.inputType ; in particular, if this is EditorInfo.TYPE_NULL , then the target does not support complex edits and you need to only deliver raw key events to it. An input method will also want to look at other values here, to for example detect password mode, auto complete text views, phone number entry, etc. When the user switches between input targets, you will receive calls to onFinishInput() and onStartInput(EditorInfo, boolean) . You can use these to reset and initialize your input state for the current target. For example, you will often want to clear any input state, and update a soft keyboard to be appropriate for the new inputType. Summary
|