The change is specific to AT&T as they want no signaling from device during provisioning.
I've tested following cases:
- expired AT&T SIM to make sure provisioning flow works as expected.
- airplane mode on/off with both active and expired AT&T SIM.
- wifi <-> mobile transitions work okay.
- LTE with Verizon SIM (basic sanity).
bug: 13190133
Change-Id: I215963174ae6000ae71d1dda693f95413f3d6e81
This is a start and two tests succeed:
Tested expired AT&T SIM and waiting 15min for alarm to fire.
Tested a provisioned Verizon SIM and works normally.
I've NOT tested AT&T where I've properly completed the provisioning.
I've NOT tested T-Mobile SIM either provisioned or not-provisioned.
I've NOT tested provisioning over WiFi.
I've NOT tested that WiFi <-> Mobile works
I've NOT tested voice calls, SMS, MMS
...
The current bug is below, but it is poorly named either it should be
renamed or a new bug created.
Bug: 13190133
Change-Id: I0a09f642614cd27a8655e9dae764b8999ce485b8
With netd allowing overlapping rules for uid range rules the interface
name is needed to make sure only the correct rule is removed.
Bug: 12134439
Change-Id: I94f77f154f49ca8d5f6cf49683a4473cc92c3eb7
The value for the TCP initial receive window comes from,
in order,
kernel
/proc/sys/net/ipv4/tcp_default_init_rwnd
init.rc (via properties)
net.tcp.default_init_rwnd
properties
net.tcp.default_init_rwnd
gservices
Settings.Global.TCP_DEFAULT_INIT_RWND
Bug: 12020135
Change-Id: I0e271be19472900fa9f3bab037d53383ec014a9e
SO_BINDTODEVICE is not needed with policy routing.
SO_BINDTODEVICE was also used on the default iface which causes problems
when the default iface is IPv6 only and the socket tries to connect to a
IPv4 address.
Bug: 12940882
Change-Id: I5b2bde0ac5459433fc5749f509072a548532f730
requestRouteToHost will only allow system applications to make routes
exempt from the VPN's routing rules.
If a VPN is currently running and a non-system app requests a route it
will only succeed if that host is currently covered by a VPN exempt
routing rule. Otherwise it will fail.
For example, if a VPN is running and the MMS network is brought online
those routes will be added as VPN exempt. If an application then tries
to request a route to a MMS endpoint it will succeed because the routes
already exist. If an application tries to request a route to a host
covered by the VPN the call will fail.
Bug: 12937545
Change-Id: If7bcec91bbb96c62c8fb69748c975847e6c00b6f
The calling package name will be used to check if an application is a
system application when deciding if a route should be exempt from VPN
routing rules.
Bug: 12937545
Change-Id: I2c09c875fe9bb9685871a0a801ddcbb32fc17405
This may mean that secondary networks have bad network settings,
but currently default settings are overriden by secondary nets
which seems worse.
bug:13211589
Change-Id: I08d56e618208781bf6b21a88663c2b8503a4f226
Adding validation for Global Proxy setting before it is
being set.
Proxy is validated at the boot time also to make sure
the value set is valid.
Signed-off-by: Raj Mamadgi <rmamadgi@sta.samsung.com>
bug:11598568
Change-Id: Idff5ae81119d8143da096b5291ecbfbc5875cbd4
In isMobileOk attempting to connect to clients3.google.com/generate_204 we
sometimes see a proxy server will not let the connection go to our
server and instead returns 200 instead of 204. By using Https we by pass
proxy servers and we will always connected to our server.
The number of loops is increased from 3 to 4 and half the the retires
will use Http and half will use Https.
I also, added mTestingFailures which can be set to true by setting
persist.checkmp.testfailures to 1. This will cause checkMobileProvisiong
to always fail so we can test https & http.
Bug: 9972012
Change-Id: I870606037dcffe5250843980517ac52218266e02
Needed to do an http post instead of a get for one carrier.
Do this by putting an auto-submitting form in the data to be
interpreted as a html doc by the browser. The ACTION_VIEW
intent only works on http uri, but by specifying ACTION_MAIN/
CATEGORY_APP_BROWSER we could use data:text/html.
bug:11168810
Change-Id: Ifd33e1c3c7f9f40b6add39e446e6a7d7cde22549
We're getting some false positive results on this check and
while it was coded to try 3 times given sufficient independent addrs
the default url resolves to a single address so we'd just try once.
Rework to try again even with fewer urls to try to reduce the false
positives.
Also adds a random query param to fool proxies into not caching.
bug:9972012
Change-Id: Ib719f40ec612065ca6bcd919549fc1164506d35a
Changes the PacManager to report message back to ConnectivityService
to send a broadcast once the download has completed. This allows the
ConnectivityService to store the correct proxy info for getProxy().
This made the problem arise that ProxyProperties was not handling port
while it had PAC. Added small fix for equals() and parcelization.
The combination of these fixes seems to resolve Bug: 11028616.
Bug: 11168706
Change-Id: I92d1343a8e804391ab77596b8167a2ef8d76b378
Currently the captive portal check URL is generated by
concatenating scheme, "://", IP address, and port. This breaks
for IPv6 because IPv6 addresses in URLs must be enclosed in
square brackets (e.g., http://2001:db8::1/generate_204 is
invalid; should he http://[2001:db8::1]/generate_204 instead).
The resulting MalformedURLException causes isMobileOk to report
that there is no captive portal, even if there is one.
Fortunately the three-arg URL constructor already knows how to
construct URLs with IPv6 addresses. Use that instead of
generating the URL ourselves.
Bug: 10801896
Change-Id: I02605ef62f493a34f25bb405ef02b111543a76fd
There are two bugs one is I was clearing the notification in
CaptivePortalTracker when entering the ActivateState. (double check
according to bug 5021626 we should be calling enter)
Second is we could have the need to display both icons but can't
because we only allow one.
The solution I'm proposing here is to allow two notifications and
have then controlled separately.
Bug: 10886908
Change-Id: I30e7130bc542535492d175640a4990c592f32806
Add the condition that the connected network needs to be TYPE_MOBILE.
This eliminates checking on connecting to secondary networks like
FOTA, MMS, SUPL ...
This reduces unnecessary attempts to bring up multiple connections at
the same time. Especially in the light of the trouble we're having with HFA
on Sprint, where we don't want to connect to any other network until HFA
has completed.
Bug: 10758001
Change-Id: Id294536b70304a51de4752bc1a4ffac734f10f1a
In checkMobileProvisioning the call to mdst.isProvisioningNetwork() is
a blocking call and during monkey testing without SIM this is causing
ANR's. Move the initial test for provisioning into isMobileOk so
checkMobileProvisioning doesn't block.
If mobile is not supported return CMP_RESULT_NO_CONNECTION.
Cleaned up some debug.
Bug: 10674404
Change-Id: I10a0e922cd6ea9790f66e2083f37e68cb0a8861f
This changes the PAC support to not broadcast the Proxy information until
the Local Proxy has started up and successfully bound to a port so that
the local proxy information can be guaranteed to be owned by the proxy.
Bug: 10459877
Change-Id: I175cd3388c758c55e341115e4a8241884b90d633
netd now tracks statistics for tethered interfaces across tethering
sessions, so switch to asking for all tethering stats. (Currently
we're double-counting all tethering data, ever since it started
tracking across sessions.)
Also catch OOME to handle corrupt stats files, which we then dump to
DropBox and then start over.
Bug: 5868832, 9796109
Change-Id: I2eb2a1bf01b993dd198597d770fe0e022466c6b9
Added a hidden API under ConnectivityManager to toggle airplane mode.
This may be a temp solution for b/10653570.
bug:10653570
Change-Id: I0b2b42230073289eb8dc6891317d62b84e26c133
Able to config network specific MTU size. Normally, the default size of MTU is 1500.
US - ATT 1410, TMUS 1440, SPRINT 1422
KR - SKT 1440, KT 1450, LGU+ 1428
JP - KDDI 1420, SoftBank 1340
CA - RGS 1430, FIDO 1430, MTS 1430, BELL 1358, SaskTel 1358
AU - TEL 1400
Bug: 10195070
Change-Id: Ie18650b37a3d44af944f2dae4aa97c04fb12cd5e
- Require a non-204 response multiple times before declaring a
redirected error and hence a warm sim.
- If there is no connection or dns don't declare its a warm-sim.
- Add printing of the http headers to try to get more information
if we still get a false positive result.
Bug: 9972012
Change-Id: Ic115685cdbbe39c2b4de88b128eaf8d2ea96b45c
I'd changed DetailedState to force ConnectivityService to treat
provisioning apn's specially. In particular so that they wouldn't
be identified they were fully connected until the provisioning
actually started. The problem is that DetailedState is a public enum
that has a CTS test and just changing the CTS to allow for the new
state (CONNECTED_TO_PROVISIONING_NETWORK) was inappropriate.
Instead I've added a new mIsConnectedToProvisioningNetwork variable
and used the DetailedState.SUSPENDED as the intermediate state.
Bug: 10620248
Change-Id: Id4a842398cad67455541ce629959351c27d83639
This change renames the LinkInfo objects to LinkQuailtyInfo. The API is
still hidden; but it can be accessed via reflection.
Bug: 10342372
Change-Id: Ieccea87c467ceae5d7f76298b137573f67396cd6
When a sim is new or it has expired it needs to be provisioned
with the carrier. Basically provisioning is associating a sim with
a user account. When a sim isn't provisioned then operators will
restrict access to the network and only allow certain addresses
or services to be used.
This set of changes allows two types of provisioning networks to be
recognized. The first is a network that causes all DNS lookups to be
redirected to a different address than was intended. This is exemplified
by how T-Mobile works.
The second technique uses a special apn for provisioning. An example is
AT&T where lwaactivate is the provisioning apn and broadband is the
normal apn. We first try broadband and if we are unable to connect we
try lwaactivate. When we see the activate we identify it as special and
the ApnContext.isProvisioningApn will return true.
In the future our plan is to create a new network type that can be added
to the apn list, but for now it identified by name.
Here is a list of significant changes:
- CaptivePortalTracker now only test WiFi networks instead of all networks
- checkMobileProvisioning checks for provisioning networks and doesn't
try to ping.
- IConnectivityManager.aidl changes:
* getProvisioningOrActiveNetworkInfo was added to and used by Manage
mobile plan in WirelessSettings so even when there is no active
network it will still allow provisioning. Otherwise it would report
no internet connection.
* setSignInErrorNotificationVisible is used by both
CaptiviePortalTracker and checkMobileProvisioning so they use the
same code for the notifications.
* checkMobileProvisioning was simplified to have only a timeout as
returning the result is now harder as we abort simultaneous call
otherwise we'd could get into loops because we now check every time
we connect to mobile.
- Enhanced MDST to handle the provisioning network.
- Added CONNECTED_TO_PROVISIONING_NETWORK to NetworkInfo to make a new
state so we don't announce to the world we're connected.
- TelephonyIntents.ACTION_DATA_CONNECTION_CONNECTED_TO_PROVISIONING_APN
is sent by the low level data connection code to notify Connectivity
Service that a provisioning apn has connected. This allows CS to
handle the connection differently than a normal connection.
Bug: 10328264
Change-Id: I3925004011bb1243793c4c1b963d923dc2b00cb5
Doesn't clear the global proxy when a deprecated one is not found because
there still may be a non-deprecated global proxy present.
Bug: 10457179
Change-Id: I68e6d5aee7b4940f9315484060c7d82cb8ccfa70
This change starts tracking traffic quality data for WiFi and mobile
networks. The quality is tracked based on incidental traffic, and not
on specific measurements. Theoretical bandwidths are hard-coded, as
well as sampling interval; although sampling interval can be changed
by setting a system policy.
Bugs filed to remove shortcomings of this change -
10342372 Change LinkInfo name to something better
10342318 Move hardcoded values of MobileLinkInfo to resources
so they can be updated without changing code
Bug: 10006249
Change-Id: I83d8c7594da20fe53abbd5e1f909b1f606b035bb
