Drop the minimums back down to their old values.
Revert what I think was a mistake in bumping up the last two
maximums to the same value as was being forced for 64 bit.
Smarten the 64 bit adjustment to be relative to the values picked,
rather than hard-coded.
Change-Id: Ibee9625073469ad4722a1b6684c9fb2b9f0a4681
Incorrect implementation that broke the Brightness dialog slider. Reverting
to the previous behavior.
This reverts commit c5c9d0af764f590ae0031b5470192a0a08ca42d1.
BUG: 18510040
Change-Id: I201b1da46be964fcf6f041bb92ef79c335c2d23d
This change is to start Mountservice before starting
performBootDexOpt, as in one case, in performBootDexOpt
when system upgrade happens, StorageManager will be started to
get the low threshold of DataDir. But, at this point, as
Mountservice is still not up, StorageManager will end up
having a null object of Mountservice.
Change-Id: If2b5e1b58e7d2a72c6313f196e98a68738295ec6
When exiting doze mode during pulsing and the reason for the wakeup
is a touch event, we calculate the delay of the animations to animate
the notification from black/white to color depending on the point
where the touch happened to wake up the screen.
Bug: 18146441
Change-Id: Ica76b235d629acfc2b09b5f56027c688502f89d8
This change is to start Mountservice before starting
performBootDexOpt, as in one case, in performBootDexOpt
when system upgrade happens, StorageManager will be started to
get the low threshold of DataDir. But, at this point, as
Mountservice is still not up, StorageManager will end up
having a null object of Mountservice.
Change-Id: I6dec474266faa5de67449c1bbe6ef30791e5ecaa
Previously, a new state would only be created on newDrawable(), which
caused the first drawable loaded for a resource to share constant state
with the cached version. Even if mutate() was called, the constant
state was still shared and any changes were applied to the cached copy.
BUG: 18504919
Change-Id: I40d257867eb0a092ce580b9c4338ddc7406a031d
Stabilize mapping between ringer-mode=silent and zen=priority
by keeping track of two ringer modes:
- Internal ringer mode: Used for underlying stream muting
- External ringer mode: Reported to clients
The mapping between external ringer mode + zen is:
- normal = all
- vibrate = all
- silent = priority (read-write) or none (read)
Changes include:
- Remove "zen check" from audio service, back to audio
service having no knowledge of zen.
- Maintain a new external ringer mode in audio service,
this is the ringer mode reported through AudioManager
to callers, also mapped to the change intent.
- Introduce a "ringer mode delegate" to the local
audio manager interface, responsible for observing
external / internal mode changes, and making changes
if necessary.
- Internal ringer mode changes are still interesting
to the volume dialog, wire up a callback through
the existing IVolumeController interface.
- On devices without vibration, the mapping is the same
but since no ringer mode change is possible, disable
the icon toggle and remove the mute icon when volume=0.
- On devices with vibration, volume down presses should
pulse the vibrate icon (and vibrate) as a hint that this
is as low as the device can go using the keys. Since
the mechanics are similar to the existing zen=none hint,
pull into shared helper.
- Log ringer mode changes to the zen log, include calling
package information for issue diagnosis.
- Include whether vibration is supported in the audio service
dump.
- Update the status bar icon policy to use the internal ringer
mode, not the external mode (for vibrate icon).
- Update the "Muted by <x>" logic, include current suppressor
in dumpsys, ensure suppression icon is enabled & !clickable,
regardless of zen mode.
Bug: 17884168
Bug: 15471679
Bug: 16824970
Change-Id: Ia7d3bb23ce6d1e37b24fb6521d1c1ab9bb8f60c0
Bug: 18518580
If CanvasContext is being destroyed() the Surface
is probably no longer valid as well, so make sure to
makeCurrent() to the pbuffer surface so that the
subsequent GL operations are not using an invalid
EGLSurface
Change-Id: Ica5d6a065841772c47e00ad65aa7894c7e27e043
Allows ManagedProvisioning to determine whether there's a
challenge and thus whether to disable NFC provisioning.
Other implementation option: new hidden boolean API method.
Can't think of benefit of new API method "isBlockInUse", other
than doesn't leak PDB size and is more explicitly tied to the
use case. Open to either impl if anyone has opinions on the matter.
Bug: 18508767
Change-Id: I28d2eb5a0837ff85cb91f140b17ce1dd843fe9d6
Setting up a managed profile should have included a step to warn about
this sort of thing already. As the user should trust the profile owner
anyway it's hard to argue this warning is needed.
Bug: 18224038
Change-Id: Ie86ba26851af726c0dec30eb9c32894ed6bb4a00
* commit '65e51fcda25c33cdfa73e8ca3a4f71cf987bd0d2':
Fixed NullPointerException due to null Bundle, changed time interval from ms to seconds as per method documentation
* commit 'd7c7d275e77ffcae7498df7f75142e68e1b5123c':
Fixed NullPointerException due to null Bundle, changed time interval from ms to seconds as per method documentation
* commit '77283ec981fc022cd26ced1e44ad21cdc0b2e4ae':
Fixed NullPointerException due to null Bundle, changed time interval from ms to seconds as per method documentation
A recent change sets the active path ahead of calling
updateActiveInput. Removes the check between new and active
path as it is always successful thus stops the flow.
Bug: 18506537
Change-Id: I29471ffc6194baa1fad62063f1d192caa9000afd
