A recent change to seeking behavior altered the logic of
setCurrentPlayTime() (which is called when animations are first
started) to set the current animated fraction to 0 for 0-duration
animations. This fix ensures that 0-duration animations snap to
their end value (fraction == 1) instead, matching the behavior
prior to the seeking fix.
Issue #18542543 Animations with 0 duration stay in initial state when calling setCurrentPlayTime(0)
Change-Id: I9916d962cf46453a9e3e1207f58baf16f4a5830a
- Decouple condition requests from expansion, now
pre-request when zen panel unhidden.
- Animate zen mode panel expansion.
- Improve default selection logic, ensure something
is selected as soon as we are in the expanded state.
- Tweak visual spacing.
- Map null condition to Indef properly when we start
out in zen.
- Avoid unnecessary condition teardown when the conditions
are updated but unchanged from current.
- Cap number of optional conditions to display, default=3.
Bug: 18335618
Change-Id: I007b7c3b2e75e2b42805af240684aa8581e9951a
- Make the system internal ringer mode change signal available to
other system components via a standard intent, instead of a
volume-controller-only binder call.
- Update sysui to use new intent for icon policy.
- Add proper muting state to the volumizer, to look more like
the associated volume panel slider.
- Add basic ringer mode state tracking for the notification-ring
slider setting.
Bug: 17899613
Change-Id: Ie2df52edb070055ef59c74039162a0e785d2fdbb
These strings only ever end up in logcat (at best), so there's no
point having them translated. Also, rename the ErrorStrings class
and move it android.webkit where the last remaining caller lives.
(congrats webview people, this is now your mess to maintain.)
Change-Id: I04dae37c34191b26a69282970318c1b782af1edf
Move the code to the only point of use. Preparatory work for
decoupling apache-http from the frameworks.
Change-Id: Ieee54bb725cbac19d0c7513867635df6fbcf2b49
Currently, every CameraManager instance adds itself as a camera service
listener, which has the unfortunate side effect of keeping them all alive
indefinitely.
This is doubly unfortunate since every CameraManager keeps the Context it
was constructed with, and therefore may be leaking whole Activities along
with the CameraManager itself.
Break out a global per-process CameraManager which handles service
connection keepalive and availability listeners, so that local camera
manager instances can go out of scope as expected.
Bug: 18077200
Change-Id: I1be5fb8d3492131e98bb4a84121400d4abb2b9e1
Incorrect implementation that broke the Brightness dialog slider. Reverting
to the previous behavior.
This reverts commit c5c9d0af764f590ae0031b5470192a0a08ca42d1.
BUG: 18510040
Change-Id: I201b1da46be964fcf6f041bb92ef79c335c2d23d
The current heuristics depend on devices being alive at midnight+ in
order to run periodic background fstrim operations. This unfortunately
means that people who routinely turn their devices off overnight wind
up with their devices *never* running fstrim, and this causes major
performance and disk-life problems.
We now backstop this very-friendly schedule with an increasingly
aggressive one. If the device goes a defined time without a background
fstrim, we then force the fstrim at the next reboot. Once the
device hits the midnight+ idle fstrim request time, then we already
aggressively attempt to fstrim at the first available moment
thereafter, even if it's days/weeks later without a reboot.
'Available' here means charging + device idle. If the device never
becomes idle then we can't do much without rendering an in-use device
inoperable for some number of minutes -- but we have no evidence of
devices ever failing to run fstrim due to this usage pattern.
A new Settings.Global element (type 'long', called
"fstrim_mandatory_interval") is the source of the backstop time. If
this element is zero or negative, no mandatory boot-time fstrim will
ever be performed. If the element is not supplied on a given device,
the default backstop is 3 days.
Adds a new string to display in the upgrading dialog when doing
the fstrim. Note it is too late for this to be localized, but since
this operation can take a long time it is probably better to have
it show *something* even if not localized, rather than just sit there.
Bug 18486922
Change-Id: I5b265ca0a65570fb8931251aa1ac37b530635a2c