Should call SipSessionGroup.close() instead of closeNotToReceiveCalls() to stop
the SIP stack (which will stop the MessageProcessor thread and close its socket).
Might be related to ANR's reported by:
http://b/issue?id=3021924http://b/issue?id=3021927
Change-Id: I4ead1d81fc9abac983f5753b825d20bc1cc79866
When an entity (NLP for example) acquires
a WifiLock and initiates a scan, scan can
get blocked until driver starts.
scan returns no useful info, scan results
are broadcast when obtained.
Bug: 2964633
Change-Id: Iaefc32bb6b82f0718285a18ac600e6bbbb096e77
Don't wipe out the connected status every time we get a cellular status change.
Don't filter out disconnect event for wifi - we need them.
bug:3009923
Change-Id: I68cadac5f44d6eb4e0fe711fda7c5d218abb45bd
Merge commit '51aaab3d6ba01263c3e1d81ca0567e0ad5cddb2d' into gingerbread-plus-aosp
* commit '51aaab3d6ba01263c3e1d81ca0567e0ad5cddb2d':
Fix#2999258: ANR in Settings after every reboot
The main problem here was in the error recovery when we are waiting
for a process to start but it has failed for some reason. The code
was just setting mPendingBroadcast to null, but this would cause
an eventual ANR because the state was not set back to IDLE so we
would continue waiting for the broadcast without trying to restart
its process.
Now we set it to idle. We also need to reset the "nextReceiver"
index, so there is a new mPendingBroadcastRecvIndex variable holding
what it should be set back to.
While digging into this, I found a number of other lesser problems:
- There is a race when booting the system where we set mSystemReady
to true before restarting the upgrade processes. This could allow
a broadcast to happen between those two and its process to immediately
be removed. To fix this, there is a new mProcessesReady that is set
once we are truly ready to start launching processes.
- There were various places where we were calling sendBroadcastLocked()
without the flag to send only to receivers... if this is called before
mProcessesReady is set, then we would end up sticking any process for
the broadcast on the holding list to not get launched until later
(and hang up all broadcasts as they want for it). Now we always make
sure to set this appropriately.
- sendBroadcastInPackage() was not doing all of the validation that
sendBroadcast() does.
And of course a bunch of new debugging logs that were done in the
course of tracking this down.
Change-Id: I6134bbd94fdb73db8b693507b29499eae012d543
Also rename Geocoder.isImplemented() to Geocoder.isPresent()
BUG: 3000738
BUG: 3001413
Change-Id: I56bb4e9a9c59f8b79de585eeb168f74c3ff1a853
Signed-off-by: Mike Lockwood <lockwood@android.com>
Merge commit 'e25a264c4e3739913798d9b7d91af5dc964b0f15' into gingerbread-plus-aosp
* commit 'e25a264c4e3739913798d9b7d91af5dc964b0f15':
DO NOT MERGE. Wifi service now blames apps for its wake lock use.
Merge commit '4db643eb8430d063b1adc4ba164bfa1c1281bdf3' into gingerbread-plus-aosp
* commit '4db643eb8430d063b1adc4ba164bfa1c1281bdf3':
In theory the package manager now scans /vendor/app
- New API for iterating over history that will allow a better implementation
in the future.
- Now do writes asynchronously.
Also improve the documentation for Activity.onRetainNonInstanceState().
Change-Id: Idf67f2796a8868eb62f288bcbb2bad29876c8554
Merge commit 'b17eae9e227475a323f61519abc8a7d35ddf8828' into gingerbread-plus-aosp
* commit 'b17eae9e227475a323f61519abc8a7d35ddf8828':
SipService: move event handling out of system server's main thread
Merge commit '97963794af1e18674dd111e3ad344d90b16c922c' into gingerbread-plus-aosp
* commit '97963794af1e18674dd111e3ad344d90b16c922c':
SIP: convert enum to static final int.
Merge commit '5b930c49b12bdb1461a18491db768c642c38d498' into gingerbread-plus-aosp
* commit '5b930c49b12bdb1461a18491db768c642c38d498':
SIP: add config flag for wifi-only configuration.
Merge commit 'ba56dfce7c751081f2289aa33533dcf4822dc12b' into gingerbread-plus-aosp
* commit 'ba56dfce7c751081f2289aa33533dcf4822dc12b':
DO NOT MERGE Tethering: Delay 1000ms before processing USB disconnect events
This change is already in master
On some devices, switching the USB configuration to enable RNDIS can
result in multiple USB disconnect/reconnect events being generated.
Change-Id: I14b02aaca11bb708f6b3334e41a2f4d4fa7b7296
Signed-off-by: Mike Lockwood <lockwood@android.com>
Merge commit '58e0eefeb5e2e270e2b04369bbf29fc22abda8d5' into gingerbread-plus-aosp
* commit '58e0eefeb5e2e270e2b04369bbf29fc22abda8d5':
Improve power tracking of WIFI use.
We now distribute "wifi started" time across all apps that are
holding WIFI locks that cause it to be started. But only when
WIFI would not normally be running. Also have a mechanism to
distribute other WIFI work that has happened across those processes
based on their use.
Also fixed a bug where we were not retaining the CPU speed step
stats across boots...!
Change-Id: I00e3153b98429166273750512cc37e7975211ab9
+ add timer parameter to ISipSession.make/changeCall(),
+ add timer paramter to SipAudioCall.make/answer/hold/continueCall()'s,
+ add timer parameter to SipManager.makeAudioCall(),
+ modify implementation in SipSessionGroup, SipAudioCallImpl accordingly,
+ make SipPhone to use it with 8-second timeout.
http://b/issue?id=2994748
Change-Id: I661a887e5810087ddc5e2318335e2fa427f80ec6
Merge commit 'f4d788c9309bc5480100d980608472e4cb04f309' into gingerbread-plus-aosp
* commit 'f4d788c9309bc5480100d980608472e4cb04f309':
Make input dispatcher only ANR for foreground windows.
Redesigned the input dispatcher's ANR timeout mechanism so it is much
closer to Froyo's policy. ANR is only ever signalled if the dispatcher
is waiting on a window to finish processing its previous event(s) and
there is new pending input.
In the old code, we tracked the dispatch timeout separately for each
input channel. This was somewhat complicated and also resulted in the
situation where applications could ANR long after the user had pushed
them into the background.
Change-Id: I666ecada0952d4b95f1d67b9f733842b745c7f4b
Cellular signal strength should also be green - these assets aren't, but
the art guys are working on that.
Also using a new intent so we don't overload the CONNECTIVITY_ACTION and
confuse the apps.
bug:2994024
Change-Id: I6fe8f65dd6e9869d9724064c4fae45340491a4d8
