We now try to have a better label for the first wake lock
that is acquired in the log. This is done in two ways:
- The alarm manager now sorts the alarms it is going to
execute so that wakeup alarms are first, which are more
important w.r.t. which one should be logged.
- There is a new power manager facility to make a wake lock
as "unimportant for logging," which just means in battery
stats that a wake lock acquired after that can be considered
the actual one to log. This is only used by the alarm manager
to mark its TIME_TICK alarms as unimportant for logging.
Also reworked the battery history code to be cleaner and a bit
smaller. There is no longer a separate EVENT command, instead
the event code and tag are just another thing that can be included
in an UPDATE command.
The bits used in the first history int are also re-arrange, so
that only the ones that really change a fair amount in the state
bits are up at the top and there is no longer space used for
the command code (since now it is always just UPDATE). This
allows us to have more room for the time delta at the bottom,
to better avoid situations where we need to write an int delta.
Change-Id: I1bb860ae5b558a248800b090b03a84fbf7acd68a
- Better batching of history items. Fixed problems where empty
entries would be created because state toggles got lost.
- The string pool is now a HistoryTag pool, containing both a string
and uid; now an entry only requires 16 bits in the history data.
- Acquiring the first wake lock also now includes a HistoryTag
identifying who did the aquisition.
- Cleaned up printing of signal strengths and cell radio types.
- There was code that tried to allow you to add new history entries
while iterating the history... but these should never happen
together, so turned that into a failure... and fixed an issue
where we could leave the battery stats in a state where it
thinks it is continually iterating.
Change-Id: I1afa57ee2d66b186932c502dbdd633cdd4aed353
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
Following changes have been done:
[x] Long is used to store native pointers as pointers can be
64-bit.
[x] AssetManager openAsset native function returned -1 if
file name was empty and java function considered any
non-zero value as success. This has been fixed by native
function throwing Illegal Argument Exception as well.
[x] AssetManager incRefsLocked and decRefsLocked now accept
long as input to support 64-bit native references.
[x] AssetManager incRefsLocked method incorrecly used
'this.hashCode()' instead of the passed parameter id.
This has been fixed.
[x] Some minor changes have been done to conform with
standard JNI practice (e.g. use of jint instead of int
in JNI function prototypes)
Change-Id: I095b9f900d49e51f43ad6afc47cbc23116a6a64a
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Craig Barber <craig.barber@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
In this implementation, DISABLE_NOTIFICATION_TICKER (which was never
really used on its own and can be safely subsumed by
DISABLE_NOTIFICATION_ICONS) is now DISABLE_PRIVATE_NOTIFICATIONS;
when this SystemUI bit is set by the keyguard, SystemUI knows to switch
its presentation into "public" mode, in which
VISIBILITY_PRIVATE notifications are replaced with their
publicVersion's contentView (or a placeholder view,
synthesized by SystemUI, that leaks no additional
information about the notification). VISIBILITY_SECRET
notifications are suppressed altogether in this mode.
This behavior is enabled but not activated by default. To
turn it on, run:
$ adb shell settings put secure lock_screen_allow_notifications 1
and restart SystemUI.
Change-Id: Id660bef7737580e16a83f60567c22b53ee81c602
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
The method handleMessage(Message msg) from mHandler variable was
not checking if the timer was cancelled, so
sendMessageDelayed(obtainMessage(MSG), delay) was keeping the
timer alive. The patch simply adds a boolean and checks if the
CountDownTimer was cancelled before calling
sendMessageDelayed(obtainMessage(MSG), delay)
bug: https://code.google.com/p/android/issues/detail?id=58668
Change-Id: Ic6bbb9d33a3616f8503db222513cc14ad2270cb8
Signed-off-by: jl1990 <jlcarrasco1990@gmail.com>
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
