This doesn't really fix the problem being brought up here, but fixes a
related issue I found while investigating it -- if you tap a text view
enough to cause it to try to scroll, this will cause the touch to become
a scroll instead of a click, even if there is nothing to scroll. So
often quick taps to bring up the IME would be canceled because they
became a non-scroll.
Unfortuntately after syncing the latest build, I was having a lot of
trouble reproducing the original problem. I think I need to punt it to
MR2 at this point.
Change-Id: If1f0bf33de1b4d71c9f677cdad07639b7a3fb772
There is a delay between registering the two profiles,
and handsfree profile is a superset of the headset profile.
So some devices do an SDP and get the headset profile record
before we have registered the handsfree profile.
a) We can reject all incoming connections till all profiles are
registered, but then this would mean we connect later in some cases.
Registering profiles in this order seems fine to me.
Note: There is a also the need to fix forking sdptool to register
profiles, which would obliviate the need to wait 500 msecs between
profile registrations.
Bug: 2293792
Dr No: Eastham
This fixes another case where the screen would turn on when the keyguard is open but hidden by another activity.
Change-Id: I2b7c8a329036401709e96ded4f4c138041192a71
Signed-off-by: Mike Lockwood <lockwood@android.com>
This is needed since its no longer copied to /data/dontpanic by init.
Change-Id: I5217da73ec470653824b7fb9a31e093e263a8dc9
Signed-off-by: Dima Zavin <dima@android.com>
* changes:
Rename WebChromeClient.addMessageToConsole to WebChromeClient.onConsoleMessage. Do not merge.
Update JavaDoc for CacheManger.CacheResult, WebChromeClient.getDefaultVideoPoster and WebChromeClient.getVideoLoadingProgressView. Do not merge.
Improves documentation for GeolocationPermissions class. Do not merge.
In this case, as opposed to what was happening in 1977685, the focused view wasn't the one that was
directly removed, it was a child of the removed view.
...Binary XML file line #37: Error inflating class <unknown> after adding a secondary account
The problem was that we weren't dealing well with the situation where we start a transition
from activity A to B, then transition back to A before B is shown (it finishes before being
shown), then transition from A to C. At this point we had some state showing that we
were in the process of showing A from it being hidden (due to the middle transition from
B to A), which would cause the layout pass to ensure its window is hidden before the
transition starts.
The solution is to detect the case where we are showing a token and it is already actually
shown, and in this case not do all of the token setup for it to wait for its windows to
be displayed before it is shown. This isn't needed, the windows are already displayed
or the token is already set up to wait for them to be displayed.
Change-Id: I16925b91e1e2449dd65ade162a5758173c6e2695
Also sets an explicit type for GeolocationPermissions.getOrigins.
This is a partial fix for bug http://b/issue?id=2271636
This has already been submitted to eclair-mr2.
Change-Id: I0c77eca94eb56d16c2a9a29a72eb221e4a7a52a6
