Cached views would, in some situations, not update if they contained an
animating child. This was caused by clearing the dirty cache flag too
early in View.buildDrawingCache().
Approved by Dr. No mcleron.
Change-Id: I8c5f2fc3e6605657e0da625d60d50b55bb133666
Part of a fix for bug b/2300622 (Proximity sensor always blows up the lock screen while in call)
Change-Id: I9ef888638b19540a78a34507d52ff522f505102f
Signed-off-by: Mike Lockwood <lockwood@android.com>
1. PRIORITY_OFF is when user unchecks A2DP connection profile box.
2. By default, when you bond, it will be PRIORITY_ON.
3. When the profile gets connected, the priority gets set to
PRIORITY_AUTO_CONNECT. This means that we will connect
automatically to this profile.
4. When the user disconnects, we downgrade the priority to PRIORITY_ON,
which means we won't reconnect automatically.
a) We need to make a similar change to Handsfree profile.
b) We need to rework the profile management design and code which
will fix the 6 second timer that we have for A2DP reconnection.
Add AUTO_CONNECT priority for Headset profile.
Also, don't set priority to ON while disconnecting.
This logic has been pushed up to the Settings app.
Dr No: Eastham
Bug: 2133530
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
* 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.
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
This change applies the fix -- originally by phanna in
https://android-git.corp.google.com/g/#change,33669 -- to
the com.android.internal.widget version of DigitalClock,
which is used by the keyguard and pattern lock screens.
Change-Id: I43f72dd144423e55f73ba52903d52163c8f65591
The detach of the wallpaper engine was coming in after the containing
service was destroyed. This was possible because these are different
IPC interfaces so will not be serialized. The fix is to keep track
of all of the active engines in the serice, and detach any remaining
ones when the service is destroyed.
Change-Id: I8810786a777dd4f7b15cfbd2e0da25866a4f3ec5
Binary XML file line #37: Error inflating class <unknown> after adding a secondary account
Now that I have these debug logs, I want to keep them since they will make
debugging these kinds of issues a lot easier in the future. (Note in this
case there was no problem in the framework.)
Change-Id: If2b0bbeda4706b7c5dc1ba4a5db04b74f40e1543
Merge commit '6d95fc0a2ca910212a43c4547c0ef000659b72dc' into eclair
* commit '6d95fc0a2ca910212a43c4547c0ef000659b72dc':
docs for ESR: add docs to bluetooth explainin that discovery should
Add optional flag to Wakelock.release() to specify whether we should wait for proximity sensor to go negative before turning on the screen.
Clear the "waiting for proximity sensor to go negative" state when the power key is pressed.
Part of the fix for b/2243198 (Black screen lockup after ending call)
Change-Id: I813fdb7aa4192cd3384a25be9e59d7d4b90da53a
Signed-off-by: Mike Lockwood <lockwood@android.com>
