SettingInjectorService

Dynamically specifies the enabled status of a preference injected into
the list of app settings displayed by the system settings app

For use only by apps that are included in the system image, for preferences that affect multiple
apps. Location settings that apply only to one app should be shown within that app,
rather than in the system settings.

title: The getTitle() value. The title should make
it clear which apps are affected by the setting, typically by including the name of the
developer. For example, "Acme Corp. ads preferences."

icon: The getIcon() value. Typically this will be a
generic icon for the developer rather than the icon for an individual app.

settingsActivity: the activity which is launched to allow the user to modify the setting
value. The activity must be in the same package as the subclass of
SettingInjectorService. The activity should use your own branding to help emphasize
to the user that it is not part of the system settings.

To ensure a good user experience, your onCreate(),
and onGetEnabled() methods must all be fast. If either is slow,
it can delay the display of settings values for other apps as well. Note further that these
methods are called on your app's UI thread.

For compactness, only one copy of a given setting should be injected. If each account has a
distinct value for the setting, then only settingsActivity should display the value for
each account.

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 23.
MODE_MULTI_PROCESS does not work reliably in
some versions of Android, and furthermore does not provide any
mechanism for reconciling concurrent modifications across
processes. Applications should not attempt to use it. Instead,
they should use an explicit cross-process data management
approach such as ContentProvider.

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.

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.

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 was deprecated
in API level 23.
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 23.
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 23.
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 23.
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 23.
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 23.
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.

Causes the current thread to wait until another thread invokes the
notify() method or the
notifyAll() method for this object, or
some other thread interrupts the current thread, or a certain
amount of real time has elapsed.

Public methods

onBind

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

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.

onStartCommand

Called by the system every time a client explicitly starts the service by calling
startService(Intent), providing the arguments it supplied and a
unique integer token representing the start request. Do not call this method directly.

Note that the system calls this on your
service's main thread. A service's main thread is the same
thread where UI operations take place for Activities running in the
same process. You should always avoid stalling the main
thread's event loop. When doing long-running operations,
network calls, or heavy disk I/O, you should kick off a new
thread, or use AsyncTask.

Protected methods

onGetEnabled

Returns the isEnabled() value. Should not perform
unpredictably-long operations such as network access--see the running-time comments in the
class-level javadoc.

Note that to prevent churn in the settings list, there is no support for dynamically choosing
to hide a setting. Instead you should have this method return false, which will disable the
setting and its link to your setting activity. One reason why you might choose to do this is
if LOCATION_MODE is LOCATION_MODE_OFF.

It is possible that the user may click on the setting before this method returns, so your
settings activity must handle the case where it is invoked even though the setting is
disabled. The simplest approach may be to simply call finish()
when disabled.