Fix some race conditions (check isTeardownRequested).
Fix the passing of mInterfaceName to subtypes (mms, etc).
Fix the generation of CONNECTED message to already active subtypes.
Fix the enabling of Data in DataConnectionTracker.
bug: 2065037
The gist of it is: Ignore reconnect fail of default APN during boot.
A long path:
1 If wifi is started at boot it starts fast - before the PhoneService is available.
2 Wifi starts by failing - you get DISCONNECTED/Scanning events so CM starts the other default network (mobile).
3 Trying to restart mobile fails because the phone service isn't up yet.
4 The failure is noted and the net is marked as not-enabled.
5 The phone trys to auto-start the mobile network and succeeds, sending state-changed events
6 The CM ignores the state-changed events because the net isn't enabled (see 4).
The long term fix is to remove two-way state tracking from the MobileDataStateTracker and instead just consume the state fed to us in state-change events.
Near term fix is to not mark the default net disabled when we have failure (step 4) if the phone service isn't available.
This also refactors ConnectivityService a bit towards supporting multiple simultaneous connections by making each a seem like a seperate Network with it's own stateTracker, etc.
Also adds tracking of process death to clean orphaned startUsingNetworkFeature features.
Recover the old logic before removing network management. Remove the empty
list for the host after consuming the last entry. As we should never have
an empty list, it is safe to call removeFirst without checking whether it is
empty.
Currently, in getRequest() or removeFrist(), if we found an empty list, we
remove it. Then we return null for the request even there are requests in
another list. So the page stops loading until the next getRequest() or
removeFirst() is called. If they are not called, those requests will never
be accessed.
205 is interpreted by Safari to be like 200 and show the given content. Change
canHaveResponseBody to allow 205 to have a body.
305 is a very rare server response indicating to the client to use the given
Location header as a proxy and reissue the original request. Curl doesn't do
anything with this header and neither does internal networking code. For now,
we will just allow the response body to propagate to webcore.
This does not change the actual thread priority but if the default priority
changes, this will have the desired result of being slightly less favorable.
I tried messing with the priorities to see if a higher or lower priority helped
but it seemed to do more harm than good. It might be worth more investigation to
find out where all the thread time is being spent so we can determine the
correct priority.
Merge commit '7a5738624fa78e328b5f36c687c20b9cf0eb5a60'
* commit '7a5738624fa78e328b5f36c687c20b9cf0eb5a60':
Fix#1876303. Even rfc2616 4.2 says that "Field names are case-insensitive.", servers including Google internal uses case-sensitive checking for "Cookie". So change it.
The default APN can now be requested by calling
ConnectivityManager.startUsingNetworkFeature(Phone.FEATURE_ENABLE_DEFAULT).
Signed-off-by: Mike Lockwood <lockwood@android.com>
Use a class to hold the high priority requests and low priority requests. Each
request is appended to the correct list in the order received. If a request
needs to be requeued after an error, it is placed at the head of the
corresponding list.
Merge commit '1c9a92fd9fbe192f24e53c26cddeab401cefb108'
* commit '1c9a92fd9fbe192f24e53c26cddeab401cefb108':
Rework some code so that it works the way it was supposed to work.
that ought to be exposed. Hid and deprecated the single-arg public
constructor for NetworkInfo, and modified a CTS test that was testing it.
Ran the android.net test package to make sure it still works.
Original author: ers
Merged from: //branches/cupcake/...
Automated import of CL 145980
