In the case where a previous AF completion was outstanding but before the completion
notification reached the application, the application cancelled this AF request, and
then started a new AF request. Right after the new AF request, the AF completion
notification for earlier AF request reached the application. The application
could not tell the AF completion notification was meant for the cancelled AF, but
thought the new AF was successfully completed. Subsequently, the application trid to
take a picture, which failed as a result.
The fix is to add an explicit lock in the Camera.java class to fix the race condition to
synchornize autoFocus(), cancelAutoFocus() and the callback of the pending AF
completion message.
o related-to-bug: 6026480
Change-Id: I33d244d908ac066698e792f641ba88fe228b14a9
1. The checks for action arguments are not needed since they
may cause trouble for developers if we add more args to
an action.
bug:6414006
Change-Id: Ia4212b52be183b1ef1cfd2561ce618cef2b015e4
We shouldn't tell people we're not connected due to roaming if it's really because
of data-disabled.
Use the data-disabled setting to decide if we should inform people about
data-discon due to roaming. Note this doesn't effect other notifications about roaming.
Also fix the data-enable/disable code to take roaming into account and clear/set the
roaming notification as needed (if data is enabled while we can't get on due to roaming
we should put up the roaming notifcation.. if data is disabled while that notification is
up we should take it down).
bug:5805666
Change-Id: I5c925dfdca4abc27e0034b113508df5719f04fae
If turning the power off while FUL was closing (due to a timeout or a
cancel for example), it would be possible for unbind() to get called
twice due to a race condition. Turning the phone off calls unbind()
from the UI thread, while the other close comes from a binder thread
since it is coming from the service.
PATCH SET 1 attempted to solve the problem by adding a lock, but
having a lock around the bind is a bit scary.
PATCH SET 2 takes a new approach by having all calls coming from a
binder thread to be sent as messages to be handled on the UI thread.
Having all events occur on the UI thread removes the possibility of
race conditions and makes the code stronger by making everything
happen in a deterministic order.
This commit also cleans up the logcat logging a bit. A couple of the
log messages are now printing without DEBUG being set to true. This
is by no means spamming the log and they of course are only logged
when FUL is being used. But it serves to give us some meaningful
information from bug reports that are currently showing nothing. The
statements that are now logged would have made this particular bug
easy to track down.
Change-Id: I25a65c0808d88cb941439e5bf1f989dba8608be4
Two parts to this:
1. We were looking at the measured height of the close view
for a lot of our computations, which---particularly with
recent changes that dispense with the old 3-window
implementation---is increasingly unreliable
2. We were overestimating the minY that the panel must be
pulled down before animation starts. It was enforced
jankiness!
Bug: 5359178
Change-Id: Ie09b62226b7b0977527348b5527478665ece1df8
1. The system does not allow performing an accessibility action
on an accessibility node info unless it explicitly states it
supports that action. Adding the new accessibility actions
to the info emitted by a view.
bug:6407647
Change-Id: I8dad1dc60ec68b4da5ed2349a1366a88820175a1
1. There was a double call to recycle of a pooled instance
which was causing an exception. Removed an unnecessary call.
bug:6408689
Change-Id: Ic74b743c6be28ca95ab84b15f28edb5bc95f0a88
1. Added a lacking null check for the accessibility node
info returned by an accessibility node provider. If
the provider implementation is not correct this may
happen.
2. Added clearing of the current accessibility focused
node when the window focus changes. Now it is cleared
in every case and if it happens that accessibility is
enabled when the window gets focus, the accessibility
focus will be properly set.
bug:6381296
Change-Id: Ieea1b07762745e6d932fc4ed4febfe77760b25b7
1. Make the feature opt-in (ViewGroup::layoutMode defaults to CLIP_BOUNDS) without inheritance.
2. Rename COMPONENT_BOUNDS to CLIP_BOUNDS.
3. Rename LAYOUT_BOUNDS to OPTICAL_BOUNDS.
4. Complete GridLayout implementation.
5. Change the default_gap between components to 8dp, to align with the Style Guide.
Change-Id: I8d40dfc5f4ca469f6424eb3ff60d07bec56e3a9f
Match behavior of removeViewLocked(), where InputMethodManager clears
any strong references to Views, and also clear mCurRootView. Without
this, IMM can leak a DecorView instance after the user has left the
application.
Bug: 6413553
Change-Id: Iad09cf5dbb7f6f156fd39ed243431432e00f8945
o made all the member variables in helper classes for TimedText to be public and final
since they are read-only
o removed Text and TextPos helper classes
o added two public methods in TimedText class: getText() and getBounds()
o cleaned up the javadoc of related methods in MediaPlayer.java and TimedText.java classes
o make the inner classes of TimedText static and final
o change invoke and let it throw RuntimeException on failure (thus a test class needs to be
modified also).
o related-to-bug: 6110705,5542712
Change-Id: Ia1dd1fd5eb8e9fd1b61c6c0d67405edb627a3002
