When an application wishes to do low-priority background work when the
device is otherwise idle (e.g. in a desk dock overnight), it declares
a service in its manifest that requires this permission:
android:permission="android.permission.BIND_IDLE_SERVICE
to launch, and which publishes this intent filter:
<intent-filter>
<action android:name="android.service.idle.IdleService" />
</intent-filter>
This string is declared in the API as IdleService.SERVICE_INTERFACE.
The service must be implemented by extending the new "IdleService"
class, which provides the API through which the system will communicate
with the app.
IdleService declares three methods, two of which are lifecycle callbacks
to the service, and the third of which is for the service itself to
invoke when appropriate. The lifecycle callbacks are
public abstract boolean onIdleStart();
public abstract void onIdleStop();
The first of these is a notification to the service that an idle
maintenance interval has begun. The service can then spin off
whatever non-UI work it wishes. When the interval is over, or if
the OS determines that idle services should be shut down immediately,
the onIdleStop() method will be invoked. The service must shut down
any background processing immediately when this method is called.
Both of these methods must return immediately. However, the OS
holds a wakelock on the application's behalf for the entire period
between the onIdleStart() and onIdleStop() callbacks. This means
that for system-arbitrated idle-time operation, the application does
not need to do any of its own wakelock management, and does not need
to hold any wakelock permissions.
The third method in IdleService is
public final void finishIdle();
Calling this method notifies the OS that the application has finished
whatever idle-time operation it needed to perform, and the OS is thus
free to release the wakelock and return to normal operation (or to
allow other apps to run their own idle services).
Currently the idle window granted to each idle service is ten minutes.
The OS is rather conservative about when these services are run; low
battery or any user activity will suppress them, and the OS will not
choose to run them particularly often.
Idle services are granted their execution windows in round-robin
fashion.
Bug 9680213
Change-Id: Idd6f35940c938c31b94aa4269a67870abf7125b6
The new visibility property allows an application to signal
to SystemUI whether a notification's contents are safe to
show in "public" situations, i.e. outside of a secure
lockscreen, or whether they should be treated as "private"
(where only the icon is revealed).
Apps that post information that includes no personal or
sensitive information (e.g. a weather alert) can use
VISIBILITY_PUBLIC to allow users to see (and potentially
even dismiss) this kind of notification without unlocking
their devices.
The historical treatment of Android notifications
corresponds to VISIBILITY_PRIVATE, which is the default
visibility setting for all notifications, including apps
that are not aware of this API.
VISIBILITY_PRIVATE notifications may optionally specify a
publicVersion, which is a whole other Notification object
whose contentView will be shown in public contexts. This
allows an app to provide a "redacted" public version of its
notification that is more useful than the system-supplied
version (showing just the icon and app name) but still
conceals private information. For example, a messaging app
that today posts a Notification including the sender and
contents of each message could additionally specify a
publicVersion that says, simply, "N new messages".
There's also VISIBILITY_SECRET for notifications that should
be totally concealed (that is, no icon) in public contexts.
To reveal any hint of this kind of notification would
require the user to unlock the device.
Change-Id: I1552db36c469954d27d3c92ba21ac5c703d47ae1
While implementing the new TTS API, I found out that it's very difficult
to create an SynthesisRequestV2 instance for testing purposes - it's
a final class, with no publicly visible constructors.
Bug: 8259486
Change-Id: I88b84fd8ad1ac6960f3932863ca758657f9547ff
This change allows TTS clients to create (and use) classes derived from the
UtteranceId class. This allows to attach a custom data and methods that
can be reached later in callbacks that take the UtteranceId instance as
parameter.
Also, since we can't depend on the identityHashCode results being unique,
this change adds AtomicInteger to generate unique identifiers for UtteranceId
instances.
Bug: 8259486
Change-Id: Id1e9eabc890ec585a7f8570fd20e287dcda9a11d
IsContainedVolume -> hasIsolatedZVolume conveys that this affects Z
ordering of views
ProjectToContainedBackground -> ProjectBackwards, since it ended up
using its own projection target, separate from the 3d volume bit
Change-Id: Ia2cde838cc4da134366fe6ff623290fbd65e50c3
This will break on 64 bit because 64 bit pointers are
wider than java int.
Also, this method technically isn't a public API because
it's a protected method on a final class. It shows up in
our api.txt files because of a quirk in the API generation
system.
Change-Id: I2b574943008ed34696b048195c0cac6af1aa0a3b
Change PowerManagerService to start the pre-recovery service rather
than rebooting directly, when requested to reboot into recovery. Add
a new RECOVERY permission which a caller needs (in addition to REBOOT)
in order to go to recovery.
Bug: 12188746
Change-Id: I39121b701c4724558fe751adfbad79f8567faa43
Also rename existing secondary storage API to match naming
convention in rest of class.
Bug: 11536709
Change-Id: I2684c817de4982b414893d2d9927a21e3f171d53
It returns a pointer to a private data structure, so there's
no sensible use for it. Also, the emergence of 64 bit processors
means that the return value isn't wide enough to represent
values in the native heap.
(cherry picked from commit f8f09a15a409f373f22aa475bb0defd264088e4f)
Change-Id: I9c9b5bae6db8638e65dda60f924aa3dddd06813a
It returns a pointer to a private data structure, so there's
no sensible use for it. Also, the emergence of 64 bit processors
means that the return value isn't wide enough to represent
values in the native heap.
Change-Id: If02d42a528b9d90f11cb25c3342404b7d5f7b625
Unhide android.control.aeMode and android.control.availableAeModes,
which were supposed to be public all along.
This matches up to system/media commit #9fa0d90ff
Change-Id: Ibba2756dd5889344b5d0531dc6f066566776cdc1
