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
1. AccessibilityNodeInfos for visible views should always
be reported and the clients should be able to check
whether that node info is shown to the user. For example,
focus search may return a node that is not on the screen
and the accessibility layer may decide to give it focus
which scroll the source view in the screen.
bug:6421991
Change-Id: Idc1fd8512dda767abe802aacedb0c69582e6fc2a
1. Since we are using a stateless proxy accessibility service to
perform default accessibility gesture handling it shuld not
operate against not important views.
bug:6422069
Change-Id: I74df9c2415ab3b164d9ac5873f7004c0459e2bfa
Propagate the return value from onNavigateUp as the result of
onMenuItemSelected. This fixes a bug where the action bar Up nav
button clicks would not be propagated to support lib FragmentActivity
or other activity subclasses that rely on processing otherwise
unhandled onMenuItemSelected events.
Change-Id: Id879dd1756ed06b8a7b720ebf0eae2a8ddc66ca8
1. Implementing text content navigation at various granularities.
For views that have content description but no text the
content description is the traversed at character and word
granularities. For views that inherit from TextView the
supported granularities are character, word, line, and page.
bug:5932640
Conflicts:
core/java/android/view/View.java
Conflicts:
core/java/android/view/View.java
Change-Id: I66d1e16ce9ac5d6b49f036b17c087b2a7075e4c0
Detect when a vsync message was significantly delayed which may
indicate that a frame was skipped. When this happens, update
the frame time to reflect the approximate start time of the
current frame instead of the start time of the frame that was
skipped a long time ago.
Removed an unnecessary call to getCurrentPlayTime() in the
animator framework. The result was always zero and the call
just made the code confusing.
Bug: 6443611
Change-Id: I92b24f7ffd74c59b75a727b6bfc0bb51fc92a73a
