* Add metadata support.
* Add player settings support.
* Add playback support.
A2DP Settings App support.
Bluetooth: A2DP Sink support for Settings App
- add support for A2DP Sink in Settings App. This will enable connection
initiation and updation on Settings App
- add framework Apis to support A2DP Sink. Any third party Apps can access
A2DP Sink priority of device and playing state of device
- add support for key to set priority. This manages priority of device for
A2DP Sink profile
Change-Id: If5f9139f37cdb9d200387877c7801075205c78a0
This is a series of CLs to promote Java Locale object as a primary data
object to represent locale information in Android APIs.
With this CL, developers can get Locale information from SuggestionSpan
without semantically losing the original data. Possible use cases would
be:
- Emoji subtag (CLDR Ticket #9063)
- Stable and reliable 3-letter country codes handling
- Custom attributes based on private extensions.
Note that this CL does not change the current behavior of
SuggestionSpan#getLocale() as is, even if it is created with a malformed
Locale object:
new SuggestionSpan(new Locale(" a ", " b c ", " e"), new String[0], 0)
.getLocale() -> " a b c e".
Bug: 22858221
Change-Id: I96dfd4f819a236ee2e6dbd3e12903d1214223cb0
We have to kill the app and bring it up in a controlled lifecycle mode
in order to do full-data backup, and if it's e.g. playing media, this
is hugely disruptive. Instead, we now check whether an app being
considered for full-data backup is in a user-observable state, and
defer its backup if so. We don't kick it all the way down the
daily-backup cycle in this situation -- we set it up to retry the
backup in just a few hours.
Bug 25960428
Change-Id: I576f25c6fb07545565f59bd685624c612b9c5ffd
This reverts commit e5e59c6da4.
Drawables expect to be able to call invalidateSelf() during
draw() to pump animation frames. We shouldn't break this.
Bug: 26533725
Change-Id: Ibe2871f2622faf836637225fc1e3e6f0ca6def47
Ignores the old, re-appropriated key "idle_duration" which is now
set to a high value in order to force disable app idle on devices
with bug b/26355386
Bug:26355386
Change-Id: Iff9de843ad6e547d29c1583687fc7f7ce7e15090
Keyboard shortcuts are requested via WindowManager, and
the request pipes through to the view root and the window
callback.
Bug: 22405482
Change-Id: Ic0071e91c7b554be3ac9df71e9539ee8a60e822e
Cancel() has apparently never worked. Calling cancel() results
in the startTime being set to Long.MIN_VALUE. In theory, this means that
on the next animation frame (getTransformation()), the elapsed time
(currentTime - startTime) should result in a large positive number, which
is way more than needed to prove that the elapsed fraction is >1 and
therefore that the animation has ended. But in practice, anything subtracting
MIN_VALUE will result in a large negative number due to Long wraparound, so the
end check fails and the animation continues. Forever.
Moreover, event fixing the cancel issue results in a repeating animation
continuing to repeat, because the logic was never there to determine whether
a repeating animation was canceled.
This fix addresses both issues, but in a minimal way. The risk in fixing this
for real is changing the behavior of cancel in a way that existing apps would not
expect. For example, it's weird that cancel causes one more frame to run. And even weirder
that it does so with a negative elapsed duration (resulting in an animation fraction of 0).
But I wouldn't want to change that behavior for fear that I'd break apps who rely on
that weird behavior.
Instead, there's a simple check for for the "expired" check and the "repeat?" check that
sees whether the startTime has the magic value of MIN_VALUE, which should only happen
when an animation has been canceled. If this is the case, it ensures that the animation ends.
For real.
Issue #24984018 canceled animation runs forever
Change-Id: Ia137eb04bd7df3976a4d9cef86fd39a78dc56f39
