If any data set change is pending when a smooth scroll is requested,
post it for later - not just if the list is currently empty.
Fix a bug in relative smooth scrolling where the last view was being
determined incorrectly.
Bug 6434713
Change-Id: Ic249eefc594151a414a6a8758074a9a60888e2b4
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
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
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
1. Added some clarification how a developer can use the
same provide with different historical files in a
context dependent manner.
Change-Id: I2a3390ade7e4b8b1170d381668e1439e52c17b7e
