Handle canceled key events correctly and don't synthesize
key events in that case.
Unfortunately, the state machine was confused by some sequences
of key events that it might receive from the input dispatcher
when new activities take focus during a long-press on the headset key.
The audio service may receive a cancel event intended for the old
window, followed by a repeated down and finally an up for the new window.
Simplified this down to just two booleans.
Bug: 6484717
Change-Id: I9587d0a5e282419ef4d7c17665940682aacea96a
Add functionality in AudioManager/AudioService to register a
media button receiver for telephony that, when registered, gets
priority for media button key events during a phone call or
when ringing.
Bug 6484717
Change-Id: I0835fc02cb24d06ca59af5a32c3ba0ae93e54442
On wifi-only devices we now show the null wifi RSSI if wifi
is enabled but not connected.
Bug: 6449811
Change-Id: Ib0cb11bcbef86d44ec633690806cff38796ffc3e
Make the WebCoreWatchdog aware of the WebViews it is monitoring
(rather than the Activity context which may become stale) and
ensure that the code for the prompt dialog is run on the UI
thread.
Bug: 6420310
Change-Id: Ied003938edb04858c85bcc2491c4b2c4c0ede6eb
Also move the shade up and forward to overlap the (now
empty) status bar.
As a side effect, DISABLE_SYSTEM_INFO now works for phones.
Bug: 6418617
Change-Id: I3b129e4bb26d3aba55403bf03baf8f4c8ad0ff46
The sample was doing something dumb: instead of binding the texture unit
to the shader's sampler, it was binding the texture name. Oops.
Change-Id: I13450dacbbd2dad362a2573aebb95e8eb87b25f0
After the bind to the FUL service is complete, an
onServiceConnected() callback is received. This callback is
asynchronous - bindService() does not block while we are waiting for
the service to finish binding. Therefore, when rapidly turning the
screen on and off, it is possible to call bindService() and then call
unbindService() before the onServiceConnected() callback is received.
When onServiceConnected() is received, startUi() is called. If the
service is no longer bound, a runtime restart occurs when calling
startUi().
Note that onServiceConnected() actually has its work done via a
handler. The delay of calling the handler increases the possibility
of unbindService() being called before trying to call startUi(). But
since this problem still happens without using the handler,
eliminating using the handler would not solve the problem and would
just create the problems that come with performing operations on
different threads since onServiceConnected() is not called on the main
thread.
Also note that a new instance of FaceUnlock is created in
LockPatternKeyguardView with each iteration. So, if we bind/stop/bind
before getting onServiceConnected(), the second bind happens in a new
instance of FaceUnlock and therefore does not lead to a problem when
onServiceConnected() returns as a result of the first bind.
This fixes some occurrences of bug 6409767. However, this fixes the
problem when turned the device on and off rapidly. It seems there
are some reports of bug 6409767 where this is not the case, so I
can't be sure this has any affect on those cases.
This change also cleans up some debugging and modifies other
debugging to try to get just the information that is useful for
tracking down the bug.
Change-Id: Ifa59107b9974acaa8a18b74b5d47e4cf3a794b8e
This fixes a glitch caused by clearing the array of chevrons before
stopping the associated animations. The old animations were allowed to
complete which caused chevrons to move around erratically because they
were being controlled by multiple animators.
Change-Id: Iec1450dd83077a721930eb3cac19a621e7356980
1. Some accessibility actions should not be performed on disabled
views. For example, scrolling should not be permitted while
accessibility focus should be. Made a quick pass over the
actions we expose now.
Change-Id: I36626dfbc0d2f480309a910f58f1de64e9e05675
This cl ensures that we immediately route the user to the add account
activity if they don't have an account and their is only one relevant
account type. Also reordered the setContent logic to reduce flicker.
Note that as of this CL there is still some flicker remaining when
launching G+ without an account. But it appears to be fixed in other
apps.
Bug: 6455975
Change-Id: I91e33b4fb9618a31765b4a8651334b1c52640828
