Clean up related to new Vibration policy.
The vibrate behavior is now only derived from:
- presence of a vibrator on the device
- current ringer mode selected: NORMAL, VIBRATE or SILENT
If no vibrator is present the ringer mode can only be NORMAL or SILENT.
The control of ringer mode via volume keys when volume keys control the "master"
stream type (RING on phones, MUSIC on tablets) is as follows:
If a vibrator is present:
VOL- and volume equals 1: NORMAL => VIBRATE
VOL- and volume equals 0 and not continuous press: VIBRATE => SILENT
VOL+ and in SILENT mode: SILENT => VIBRATE
VOL+ and in VIBRATE mode: VIBRATE => NORMAL, volume = 1
If no vibrator is present:
VOL- and volume equals 0 and not continuous press: NORMAL => SILENT
VOL+ and in SILENT mode: SILENT => NORMAL, volume = 0
VIBRATE_ON and VIBRATE_IN_SILENT settings are not stored/retreived any more.
AudioService checks and corrects ringer mode and stream volumes if necessary when reading from
DB at boot time.
Also:
Added dump for stream volumes in AudioService.
Added device names missing in AudioSystem for USB accessory and USB device.
Issue: 6036529
Issue: 6414950
Issue: 6448163
Change-Id: I77fb821ec63e4e566320cac2701b4ac466e86aef
Publish information needed to build UI, fix SystemProperties.getLong()
to be able to read this property, fix some issues in
MultiCheckPreference.
Change-Id: I10c8ff84a167fdb42f6c93500201b78b844cfb8b
The deferred invalidation of display list could cause problems with
view like TextureView who destroy resources when detached from the
window but only recreate them later at draw time. This would cause
temporary flashes or other visual glitches on screen.
Change-Id: I018488ba09743df21c6434ea610813014fb80a85
An AssetFileDescriptor with a null fd is pretty useless and should
never happen during normal operation. It can't even be parcelled
without hitting an NPE. To make it easier to find bugs where a null
fd might have been generated, check at construction time.
Bug: 5655036
Change-Id: I1da6dbee0cab9c11e309f3cebe698bf44dc5e27d
The patch to call into libsuspend accidentally dropped the
test for sPowerModule == NULL. Put it back, and fix some
tabs too.
Change-Id: I1f934a41540f3b7be01d6399512482d87acceb94
* Fix layout for small-screen devices in landscape.
* Properly re-enable buttons after restoring instance state.
* Scroll to the currently selected item after restoring instance
state.
* Smooth scroll to the currently selected item if the user changes
selection to an item slightly out of view.
* Place grid scroll bar outside the grid's padding.
* Make the current text read a bit more naturally.
Bug 6460135
Change-Id: Ic60330365cdd815e7517f01b36bcdc9d1c857f30
Move a bunch of dimensions around so that 7" tablets use phone-style
UI but with different margins to reduce the width.
24dp margin for portrait and 48dp margin for landscape.
Existing sw600dp values moved to sw720dp.
New sw600dp values created.
Bug: 6445803
Change-Id: I835c8f4b0423b295dd453161f4e32406e6267515
Allow applications to transition from 0=>1+ visible menu items outside
of onCreatePanelMenu/onPreparePanel. Previously, having 0 visible items
at this point would require an invalidation of the options menu.
Bug 6452605
Change-Id: I6cbfc46d0e5ec42b8d78ee516e9b57fdeaf1a890
1. When a view that has accessibility focus is temporary detached
we try to draw the focus highlight and crash. Since the detached
view will be modified and then either attached or detached from
the window we should not keep accessibility focus on a temporary
detached view. Otherwise, we may have a scenario where the user
thinks he is in one item scroll acound and being in completely
different item because of the view being recycled but the user
has no clue.
2. Clearing accessibility focus when the view is removed from the
parent as opposed as when it is detached from the window. Since
we may have transitioning views for removal we do not want
accessibility focus on such views during the anumation.
bug:6457339
Change-Id: I62287a089ec6850fb1d691ae26dea54e1da39c94
