(a) Fix a null pointer exception, caused by a race condition
between stop / start calls.
(b) Fix a deadlock observed when multiple apps call stop() when
an item from one of those apps is currently being processed.
bug:5253061
Change-Id: I78533aecfda028588ce6aedb041009bc0a6f4620
For the purpose of exposing the class as a storage for Wps
info with p2p, it is better to just call it Wps
Bug: 5247957
Change-Id: Iaebef958dd8f08fdbeb4b9d7fa5ad5527400710d
There's a problem with how LayoutTransition cleans up after itself
when the target view is in a Window that is not on the screen.
The quick fix is to always start (and therefore properly end and clear)
transitions, regardless of whether the window is in the tree.
Change-Id: I23f4f4f04176f3943e5c6e1d78acba0190a96930
Add API support for supplying content descriptions on action bar tabs.
This helps accessibility in cases where no title text is shown.
Change-Id: I8fdc4c2f2b279871b9f24b0b16e5167879b22741
This patch parallels the previous one that fixed backup timeouts.
It establishes the same sort of state-machine process for walking
through the restore steps solely as events posted to the backup
manager's HandlerThread.
Fixes the rest of bug 5074923
Change-Id: I122a021cb1e9bb1342de0b71e5d4bc84cc630c58
In the past we were overly cautious about not recreating the lockscreen
under steady state conditions. However, that allowed lockscreen
to get into weird states where the screen orientation and the
loaded layout disagree. Once in this state, the user could not
recover because we would never reload the layout due to the fixed
orientation of lock screen.
This avoids the problem by being more aggressive about reloading
the layout. It now recreates the lockscreen (for reals) whenever
a view requests it via recreateMe().
In addition it serializes recreateMe() requests to ensure a pending
configuration change event has a chance to propagate and be handled
by the lockscreen looper.
Change-Id: I86a54abba899eb314f7cc8dbf6cbb98266bc548a
(Only applies to high-end devices. In situations where
memory budget or GPU/overlay support are lacking these will
still be done in software.)
Bug: 5233443
Change-Id: I668def10598f6a818d8011ba6dd8d1dd5440ae5e
the media extractor failed to initialize (malformed or unsupported content)
Change-Id: Icfad4e9eeb8d6713ad12eee7979ab30b696c06e0
related-to-bug: 5263840
- The easy edit span was displayed twice when in extracted mode. The orignal TextView now checks if it is in extra mode, and if so it does not display any pop-up
- The easy edit span was displayed before the view was layout causing the application to crash.
New feature:
- the span is automatically hidden after a timeout
I also renamed all the fields and classes to "EasyEdit...". There were still some field/class using an old name.
Bug: 5255363
Bug: 5247453
Bug: 5246997
Change-Id: Ic9bf05d2525e2df9017c91344a687e8cb9105417
Change the behavior of the highlight marking the "suggested text" and not the differences.
Bug: 5252699
Change-Id: I4c7e9fc9bac81da8b5f643990b86a336363d7968
The problem occurs when activating or deactivating A2DP connection
while SoudPool has a channel active. This can happen quite frequently now
that the UI sound effects are enabled by default.
If PCM data is remaining in the AudioTrack buffer when it is restroyed and
re-created on the new AudioFlinger output thread, this data is flushed.
As a consequence, no underrun or request for new data callback is sent to
SoundPool and the sound channel remains active for ever as the end of the
sample is never detected.
Change-Id: I13e0c11e4ce3f83bff7f58d347ca814b6a86712b
Two problems fixed here:
- The docs for AnimationSet were too vague and incorrect: some properties of
Animation (such as duration) are pushed from the AnimationSet down to its children, as
the current docs say. Some other properties (such as repeatCount) are ignored. Other
properties (such as startOffset) apply to the Set itself, but not to the children.
Fix: clarify this behavior for each of the properties.
- The behavior for XML resources was just busted. We would set the various properties
(e.g., duration) and then forget that we did so, since we reset the flags that marked
their existence after we loaded the resource. In fact, the duration property was
always being reset to 0, regardless of what it was set to in the xml resource.
Fix: Make it work they way it always should have: respect the values read from the XML
resource and make them behave the same way they do when set at runtime.
Change-Id: I07d68876d2259105dc5a359501d5c656ecfaa8e5
