InputMethodService provides a standard implementation of an InputMethod,
which final implementations can derive from and customize.

Class Overview

AbstractInputMethodService provides a abstract base class for input methods.
Normal input method implementations will not derive from this directly,
instead building on top of InputMethodService or another more
complete base class. Be sure to read InputMethod for more
information on the basics of writing input methods.

This class combines a Service (representing the input method component
to the system with the InputMethod interface that input methods must
implement. This base class takes care of reporting your InputMethod from
the service when clients bind to it, but provides no standard implementation
of the InputMethod interface itself. Derived classes must implement that
interface.

Flag for bindService(Intent, ServiceConnection, int): If binding from an activity, allow the
target service's process importance to be raised based on whether the
activity is visible to the user, regardless whether another flag is
used to reduce the amount that the client process's overall importance
is used to impact it.

This constant was deprecated
in API level 17.
Creating world-readable files is very dangerous, and likely
to cause security holes in applications. It is strongly discouraged;
instead, applications should use more formal mechanism for interactions
such as ContentProvider, BroadcastReceiver, and
Service. There are no guarantees that this
access mode will remain on a file, such as when it goes through a
backup and restore.
File creation mode: allow all other applications to have read access
to the created file.

This constant was deprecated
in API level 17.
Creating world-writable files is very dangerous, and likely
to cause security holes in applications. It is strongly discouraged;
instead, applications should use more formal mechanism for interactions
such as ContentProvider, BroadcastReceiver, and
Service. There are no guarantees that this
access mode will remain on a file, such as when it goes through a
backup and restore.
File creation mode: allow all other applications to have write access
to the created file.

Level for onTrimMemory(int): the process is around the middle
of the background LRU list; freeing memory can help the system keep
other processes running later in the list for better overall performance.

Level for onTrimMemory(int): the process is not an expendable
background process, but the device is running extremely low on memory
and is about to not be able to keep any background processes running.

This method is deprecated.
Sticky broadcasts should not be used. They provide no security (anyone
can access them), no protection (anyone can modify them), and many other problems.
The recommended pattern is to use a non-sticky broadcast to report that something
has changed, with another mechanism for apps to retrieve the current value whenever
desired.

This method is deprecated.
Sticky broadcasts should not be used. They provide no security (anyone
can access them), no protection (anyone can modify them), and many other problems.
The recommended pattern is to use a non-sticky broadcast to report that something
has changed, with another mechanism for apps to retrieve the current value whenever
desired.

Broadcast the given intent to all interested BroadcastReceivers, delivering
them one at a time to allow more preferred receivers to consume the
broadcast before it is delivered to less preferred receivers.

This method is deprecated.
Sticky broadcasts should not be used. They provide no security (anyone
can access them), no protection (anyone can modify them), and many other problems.
The recommended pattern is to use a non-sticky broadcast to report that something
has changed, with another mechanism for apps to retrieve the current value whenever
desired.

This method is deprecated.
Sticky broadcasts should not be used. They provide no security (anyone
can access them), no protection (anyone can modify them), and many other problems.
The recommended pattern is to use a non-sticky broadcast to report that something
has changed, with another mechanism for apps to retrieve the current value whenever
desired.

This method is deprecated.
Sticky broadcasts should not be used. They provide no security (anyone
can access them), no protection (anyone can modify them), and many other problems.
The recommended pattern is to use a non-sticky broadcast to report that something
has changed, with another mechanism for apps to retrieve the current value whenever
desired.

This method is deprecated.
Sticky broadcasts should not be used. They provide no security (anyone
can access them), no protection (anyone can modify them), and many other problems.
The recommended pattern is to use a non-sticky broadcast to report that something
has changed, with another mechanism for apps to retrieve the current value whenever
desired.

This method was deprecated
in API level 21.
Sticky broadcasts should not be used. They provide no security (anyone
can access them), no protection (anyone can modify them), and many other problems.
The recommended pattern is to use a non-sticky broadcast to report that something
has changed, with another mechanism for apps to retrieve the current value whenever
desired.

This method was deprecated
in API level 21.
Sticky broadcasts should not be used. They provide no security (anyone
can access them), no protection (anyone can modify them), and many other problems.
The recommended pattern is to use a non-sticky broadcast to report that something
has changed, with another mechanism for apps to retrieve the current value whenever
desired.

Broadcast the given intent to all interested BroadcastReceivers, delivering
them one at a time to allow more preferred receivers to consume the
broadcast before it is delivered to less preferred receivers.

This method was deprecated
in API level 21.
Sticky broadcasts should not be used. They provide no security (anyone
can access them), no protection (anyone can modify them), and many other problems.
The recommended pattern is to use a non-sticky broadcast to report that something
has changed, with another mechanism for apps to retrieve the current value whenever
desired.

This method was deprecated
in API level 21.
Sticky broadcasts should not be used. They provide no security (anyone
can access them), no protection (anyone can modify them), and many other problems.
The recommended pattern is to use a non-sticky broadcast to report that something
has changed, with another mechanism for apps to retrieve the current value whenever
desired.

This method was deprecated
in API level 21.
Sticky broadcasts should not be used. They provide no security (anyone
can access them), no protection (anyone can modify them), and many other problems.
The recommended pattern is to use a non-sticky broadcast to report that something
has changed, with another mechanism for apps to retrieve the current value whenever
desired.

This method was deprecated
in API level 21.
Sticky broadcasts should not be used. They provide no security (anyone
can access them), no protection (anyone can modify them), and many other problems.
The recommended pattern is to use a non-sticky broadcast to report that something
has changed, with another mechanism for apps to retrieve the current value whenever
desired.

Return the communication channel to the service. May return null if
clients can not bind to the service. The returned
IBinder is usually for a complex interface
that has been described using
aidl.

Note that unlike other application components, calls on to the
IBinder interface returned here may not happen on the main thread
of the process. More information about the main thread can be found in
Processes and
Threads.

Parameters

intent

The Intent that was used to bind to this service,
as given to Context.bindService. Note that any extras that were included with
the Intent at that point will not be seen here.