The pingtest have been disabled since petit-four and ping's use is
being deprecated. Removing the ping test code, if needed use
InetAddress.isReachable instead.
bug: 1824738
Change-Id: I42b3de85b67b82dc6389e7a2234afa7b1d687209
Initial state should be unknown or we miss the first connected change.
Don't send a disconnected msg when changing network types.
Filter out redundent disconnects.
Add some logging.
bug:3060742
Change-Id: Idc797c1276b7417337a91ed60b12b1bf392d57c0
Since we have NetworkProperties we can remove the individual accessors
from Phone and its subclasses.
Change-Id: Id9969a880405900a63051b3ae4019d889afb1fe8
Used as a bag to hold ipaddr, gateway, dns, proxy info.
addr's are InetAddresses for v4/v6 use. Cleaning up some old v4-only code
bug:2655015
Change-Id: I7ac886fe5c519e8bab42f49cd82a5189d9c9ab59
Add APNType info to notifications so you can tell what's happening. Now, even if a new APN
shares a connection with an already-connected-to- apn type, the new type will get all
the connecting and connected messages on connect and disconnecting/disconnected on disconnect
even though the shared connection remains connected.
Cleaning out the hacks MobileDataStateTracker needed to deal with the old situation.
bug:2226092
Change-Id: Iddd7421d6b91cda7c8405f9c3d5404ac04ef8e42
Also change phone's ConnectionStateTrackers to use it directly,
rather than through the INetStat binder interface.
Bug: 2578938
Change-Id: I8858e2609cbec3be845a0ce5178cb03f67e01b41
Fix a bug in DataConnection state machine where the notification
of disconnection completion was sent before we actually transitioned
to the in active state. Also, change conn.reset to send a response
so the user can know when the transition to the in active state
completes for that also.
bug: 2471897
Change-Id: I5776324ac89a607925d07f4a600bc5b34c3f3ed6
This is independent of whether or not the ConnectivityManager wanted any particular APN on
and allows us to track the two seperately - so when data is re-enabled we don't turn
things on that CM wants off.
bug: 2158290
It was clearing the interfacename when it was needed later in the process - the prevented us
from clearing the route to private dns servers and clearing the flag that this was set.
Consequently future uses would not set the private dns servers (since it thought they were already
set) and our lookups would fail.
bug: 2146929
Without this we'd only try a secondary APN once and the stop silently, leaving
no APN connected.
Adds a second retry manager with configuration strings to do a more approriate
retry. Don't retry secondary apn forever.
On permanent failure or retry count hit, we send a Phone.REASON_APN_FAILED
disconnect status.
bug: 2112114
We need to leave the phone in a connectable state so that it connects whenever it's able
(reception or just timing). If we mark it disabled on failure it wont try again. The retry
comes from the phone layer, not from ConnectivityService.
Also Fix the Phone layer so it retries even if it disconnected by request (DATA_DISABLED).
This was a bug from long ago that didn't become visible until recently with fast wifi and slow
mobile teardown.
Change-Id: I04bf39fba0cb578c87d5fc6ea5d220820ff9f364
Another way to fix this problem. Notice the failures of dataSetup and mark the requesting
apn as unenabled so future attempts can be made.
bug: 2069221
Fixes a problem where mms apn was on when we lost the network (airplane mode) but mms was
off when airplane mode was turned off so it kept thinking we didn't have access and
future mms always failed.
bug: 2075145
Issue to be addressed:
In radioRestart() method in CdmaDataConnectionTracker, if the radio is
restarted right after cleaning up connection, it is possible that the
connection setup request triggered by radio-on may happen before the
connection cleanup has been completed so that the connection may not
be set up correctly after the radio is restarted. The end result could
be that the phone lost the data capability.
The patch includes the following changes:
1) Add EVENT_RESTART_RADIO in DataConnectionTracker.
2) In CdmaDataConnectionTracker, method restartRadio(), send a message
delayed by 20s, the purpose of which is to wait for connection cleanup
to be completed, then to restart radio.
3) In CdmaDataConnectionTracker, method trySetupData(), don't try to setup
data if there is pending message to restart radio.
Addtional notes:
A system property is not used to config the delayed timer because we
think this fix is to address the unusual error case and waiting for
long time should not impact user experience much. 12s is the longest
time to complete the data cleanup as we have seen so far, so we are
using a 20s timer.
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
and when data roaming is enabled reset the retry manager.
This change also refactors mRetryMgr to DataConnectionTracker
removing it from Cdma and Gsm data connection trackers child classes.
All the methods in DataConnectionTracker should be called only through
the handler. Fix this as trySetupData was being called in the broadcast receiver.
Tested: Airplane mode and GPRS retry.
CL 144717: Correctly set user data payload length for non-7-bit encoded payload.
CL 149058: Check for null TP-OA in SmsMessage.parseMessageBody().
CL 138094: Make sure call state (and other updates) have a chance to get processed between data setup attempts.
CL 132624: Added a comment for a way to save a message to the SIM.
