Changes

* [Line 4] a "role" field with value "keyboard" declares it's a keyboard an IME app. Homescreen app will ignore some role types when displaying app icons, and "keyboard" is one of them. (see {{bug|892397}})* [Line 6-8] a "permissions" field that requests "keyboard" permission. All keyboard IME apps need this permission for sending input keys and updating the value of a input field.* [Line 9-30] a "entry_points" field specifies supported layouts. Each layout is described in a key-value pair, where the key represents the layout name (will be shown up on Settings app with the app name), and the value describes details the detailed information of the layout, including launch path of the layout and supported input types. (See [[#Layout Matching Algorithm]])

When an input field is focused, if it its <code>type</code> attribute is not an "option"one of the allowed value stated above, its the <code>type</code> attribute will be used to filter a set of candidate layouts (if the input field doesn't provide a <code>type</code> attribute, we will use the default type, which is "text".) A candidate layout means it can handle this input type or is possible to let user input all characters that this input field acceptedcan accept. For example, if the type of a input is "url", then a layout with "url" or "text" listing on listed in the <code>types</code> on of its manifest will be matched. However, if a input field with type "text", then all layouts that support "text" will be matched, but those layouts that only support "url" are will not. This is because we believe layouts that can handle "text" could be a fallback for "url" input type, but not vice versa. A An input type fallback plan is pre-defined as follows:

* "number" is the fallback of "number" and "tel".

The matching algorithm of keyboard manager in System app is as followingfollows:

After step 3, keyboard manager will sort the list and display the first matched layout. The sorting criteria is defined by UX design or users user preferences in Settings.