It is not safe to call into vold with a lock held on mVolumeStates
since we will receive events back from vold on a different thread.
So in the boot completed handler we make a copy of the volume list and
then call vold to mount volumes after releasing the lock
Change-Id: Iaadfb1b8be5567c8e228a8fbc69d4d483c8dc987
Signed-off-by: Mike Lockwood <lockwood@android.com>
Settable per network so you can have not timeout for some and some for others.
If you set the old NETWORK_RESTORE_DELAY_PROP_NAME system property
(android.telephony.apn-restore) it will override this value.
Change-Id: Icca706fdc74245dce679209116660e5dc4b05d23
It is not safe to call into vold with a lock held on mVolumeStates
since we will receive events back from vold on a different thread.
So in the boot completed handler we make a copy of the volume list and
then call vold to mount volumes after releasing the lock
Change-Id: Ic9836c2e1e8a5677d0c4e33476a72081f69823a0
Signed-off-by: Mike Lockwood <lockwood@android.com>
* commit '4ec33c2aad59b2a745ee891c9b7246b9533d95e0':
Do not merge. Cherry-pick of Idc802af57fb9926a69ed52d4e776ef57d8b647c6 (package manager fix) to gingerbread.
* commit '75c664582c5ce5d94826f37cb725b447a4d62c50':
Backporting I57c58c4083bd59f45095c184d6ca5a302f79ff6e to HC-MR1. New change since file was renamed, making cherry-pick impossible.
* commit '8325c3a89197e47cfc2eeb4117c927fb8cb91630':
Backporting I57c58c4083bd59f45095c184d6ca5a302f79ff6e to HC-MR1. New change since file was renamed, making cherry-pick impossible.
To avoid blowing past the Binder IPC limit, change the
PackageManagerService to have a DB-like interaction where the client
tells the service the last "row" that it read.
The fact that we use a HashMap instead of a TreeMap makes this
problematic. For now we're just making a new ArrayList for the keys and
then sorting them for each call. This can make the API slower for callers
of this, but it's probably greatly overshadowed by the cost of the data
transfer itself.
Bug: 4064282
Change-Id: Ic370fd148d4c3813ae4f2daffa1a7c28d63d5a09
Without that lock, there is a chance of race condition
where while composing a specific index, requestBuf with
the same index can be executed and touch the
same data that is being used in initEglImage.
(e.g. dirty flag in texture)
Sometimes the virtual keyboard was not hidden when switching between
applications. An example of this was when launching the browser from
the Google Search widget:
1) Tap the Google Search widget and enter some text, e.g. "google"
2) Select one search items, e.g. "google maps"
3) Browser opens. Press back button.
4) Select an item again, e.g. "google maps" - Keyboard does not
close.
When switching application, the virtual keyboard needs to find a new
Z position (window index) among the other windows. Normally it is
placed on top of the first window that is visible and can get focus
(canBeImeTarget()).
With a new application being launched, there is
an exception: a special "starting window" is placed on top of the
Activity window while the application is starting up. Since this
window should not get input, we need to look below that window.
When doing this, the previous implementation assumed that the
first window below always was focusable. If it wasn't, the
input method was placed above the "starting window", which
caused confusion that led to the keyboard not being closed
automatically.
In the case of the Browser, it sometimes has a "fake TitleBar"
window that can not get focus and that is placed above the
Activity window.
With this fix, we now keep looking through the windows below
the "starting window" until we find a window that can receive
input.
Change-Id: I1117846eb0f57603e64329bd955e28182f98f226
