Waits 15sec after getting a DISCONNECTED or INACTIVE state. Also tracks
the number of supplicant state transitions. After the period is up
if we haven't received any more supplicant state transitions, it requests a scan.
bug: 2168081
Since we cannot tell how long it'll take until surface flinger
has displayed the data onscreen, we'll just have to guess...
We must not return the buffer to the decoder before it's been displayed.
In LocationManagerService if a LocationListener is removed while it has
a pending broadcast the wake lock held while pending broadcasts are
outstanding do not get cleared properly.
There are 2 cases of this race that are fixed:
1. locationCallbackFinished was changed to check the mReceivers HashMap
directly instead of calling getReceiver. getReceiver would add the
ILocationListener as a new Receiver if it did not exist which caused
a receiver that was removed when it still had a broadcast pending to
be added back in a bad state when the pending broadcast completed.
2. removeUpdatesLocked was changed to decrement the pending broadcasts
when a Receiver is removed that has pending broadcasts.
Fixes bug b/2163871
Change-Id: I50a321c9b3359bf69845236dc4a4b9e38e847335
Signed-off-by: Mike Lockwood <lockwood@android.com>
Merge commit 'f81ecc1fb7cad523b62c7f2662f4aab3ea0dee54' into eclair-mr2
* commit 'f81ecc1fb7cad523b62c7f2662f4aab3ea0dee54':
Only dismiss search dialog after launching intent.
Merge commit '8bd04b2000f418c8c6f4f628abc215bb5a688244' into eclair-mr2
* commit '8bd04b2000f418c8c6f4f628abc215bb5a688244':
fix an NPE on a race condition that occurs when unbinding from an authenticator at the samer time that its process dies: bug 2171204
Merge commit 'b134b2038ecabcbec3f9b657834d45de27707068' into eclair-mr2
* commit 'b134b2038ecabcbec3f9b657834d45de27707068':
More fix#2163209: alarm clock rings but is hidden behind lock screen
There was another way we could ignore the application windows flags
while the lock screen was displayed. This is the infrastructure to
deal with that.
Change-Id: Id8c9cb2f7081df6757ccb797a7cde618e82f7b38
Occasionally we see references to the overlay hanging around long
enough to cause problems in applications when they tried to destroy
the overlay and re-create it. This patch causes the camera HAL to
retry the overlay creation call if it fails every 20ms up to 50
times before it gives up.
Merge commit '7c12540f09659dec0a4222831ed7e5ab8d7b0cdf' into eclair-mr2
* commit '7c12540f09659dec0a4222831ed7e5ab8d7b0cdf':
Add script to script call support. Add exception to catch out of bound index data when added to TriangleMeshBuilder.
Merge commit '9af53ea6ef9a986bc65bcd11deb7994f1f4ba8ec' into eclair-mr2
* commit '9af53ea6ef9a986bc65bcd11deb7994f1f4ba8ec':
when logging free space on /data, log /system and /cache as well
Merge commit '4ff6d01d42fce2dc52b2dec8f59b625b18770bb0' into eclair-mr2
* commit '4ff6d01d42fce2dc52b2dec8f59b625b18770bb0':
fix [2164183] sometimes device just wants to stay asleep
Merge commit '3161795b2353171bb0636fb3ea6dab7dec80a4f4' into eclair
* commit '3161795b2353171bb0636fb3ea6dab7dec80a4f4':
when logging free space on /data, log /system and /cache as well
when running out of memory, a null handle is returned but the error code may not be set.
In that case we need to return NO_MEMORY instead of NO_ERROR, so that the calling code
won't try to dereference the null pointer.
When switching rapidily orientation back and forth, surfaces end-up
acquiring the freeze-lock when the first orientation change happens,
but never release it because by the time the 2nd orientation change
comes in, the surface size is back to its original size and
doesn't appear to have resized.
we now always release the freeze-lock when we receive a buffer of the
expected size.
Merge commit '568cae571a3d74d1992176a21722e07b44e9a3c4' into eclair-mr2
* commit '568cae571a3d74d1992176a21722e07b44e9a3c4':
Fix issue #2171460: Turn off background blurring of power dialog
This also fixes [2152536] ANR in browser
When SF is enqueuing buffers faster than SF dequeues them.
The update flag in SF is not counted and under some situations SF will only
dequeue the first buffer. The state at this point is not technically
corrupted, it's valid, but just delayed by one buffer.
In the case of the Browser ANR, because the last enqueued buffer was delayed
the resizing of the current buffer couldn't happen.
The system would always fall back onto its feet if anything -else- in
tried to draw, because the "late" buffer would be picked up then.
This is the main entry point to the Bluetooth APIs, and returns the default
local Bluetooth adapter.
It replaces context.getSystemService(Context.BLUETOOTH_SERVICE). This was
never in a public SDK release.
DrNo: eastham
Bug: 2158765
Joke: Why can't you play cards in the jungle? Because there's too many cheetas!
Change-Id: Ieed8be009ee5aba621cb69090ee8c8a9c19c840d
