Turning off animations in the Developer options creates a ValueAnimator
duration scale of 0. This is used as the denominator in RampAnimator
which, if the numerator is also 0, sets mAnimatedValue to NaN. Rounding
NaN to the nearest int produces 0 which is then assigned to
mScreenBrightness in DisplayPowerState.
A copy mistake which assigned mTransitionAnimationScale as the default
value for mAnimatorDurationScale in WindowManagerService is also
fixed here.
Bug 7515609 fixed.
Change-Id: I39f8d0a7abdd5a1fe70d757fe95fbddaf7a0ed51
Hotplug events say which display they're for and whether the display
was connected or disconnected. Before, this info was ignored, and the
event just triggered a rescan of all displays. If a display was
disconnected and then reconnected quickly, the rescan would treat this
as a no-op or a device property change and wouldn't turn the display
on.
Now the display manager attempts to update its state with the change
the event describes. So a quick disconnect/connect cycle will cause
the display to be turned on since the display manager will have
updated its internal state to reflect the disconnect event, and will
treat the connect event as a new display rather than a device property
change.
Bug: 7491120
Change-Id: If16268fbd0708683f6401ea72fbee9fb2c3c8d19
(This relates to the new vibration fallback behavior, where
notifications that expect to make a sound should always
vibrate in vibrate mode. We should not vibrate if the
notification's sound is silent, but we should also not
vibrate if the notification uses the default sound and the
default is silent.)
Bug: 7537077
Change-Id: I08e149c8c00ef2d2f61e418d88a086cb5e9cf241
- When notifications vibrate as a fallback (that is,
because they want to play a sound but the device is in
vibrate mode), this no longer requires the VIBRATE
permission.
- As a bonus, if your notifications use DEFAULT_VIBRATE,
you don't need the VIBRATE permission either.
- If you specify a custom vibration pattern, you'll still
need the VIBRATE permission for that.
- Notifications vibrating in fallback mode use a different
vibration pattern.
- The DEFAULT_VIBRATE and fallback vibrate patterns are now
specified in config.xml.
Bug: 7531442
Change-Id: I7a2d8413d1becc53b9d31f0d1abbc2acc3f650c6
LocationManagerService was serially stuffing the same Location into
multiple Intents, which it would immediately hand off to
ActivityManagerService, running as a different thread in the same
process. LocationManager would continue to work with that Location
while ActivityManagerService worked with a Parceled version of it.
However, Location.mExtras is also a Bundle, and both
ActivityManagerService and LocationManagerService ended up working
with references to the same Bundle. ActivityManagerService needs
it in Parceled form (ie mParceledData != null), but
LocationManagerService was triggering Bundle.unparcel() when
referencing the data contained within.
As a result, LocationManagerService was able to trigger NPE (or
worse) in ActivityManagerService by manipulating the mExtras
member of a Location that was in the process of being reported to
listeners.
To resolve this issue, I copy-construct a new Location to report to
each listener. This should prevent ActivityManagerService and
LocationManagerService from referencing the same Bundle data, as
Location's copy constructor also copyconstructs the mExtras member,
rather than simply share references.
Bug: 7518371
Change-Id: I1a92615cba361831494447d5de085a8d910b6b2c
(Unless the notification specifies no ringtone AND no
vibration, in which case it will remain silent.)
Change-Id: I926d0fe0165b9622cd117e6c3ef6e3637772b444
