I needed to test the result of startUsingNetworkFeature, otherwise
on mobile networks that are slow to come up, we won't detect
warm SIMs after booting.
Bug: 9962943
Change-Id: Ib638a4e43867ecaa85d6abff65643b77a63526b6
After detecting there is a captive portal the url used in the
notification for mobile networks should be updateable via gservices.
These urls will be the same as used by CheckMp and is needed for
carriers that have specific provisioning urls such as AT&T and Verizon.
Bug: 9622647
Change-Id: Idcf4dabc72ece1dbbe1d5e5a21e550dd06fe16c7
Various applications such as Skype and our legacy VPN code
do not understand routes pointed directly at point-to-point
interfaces and require a default gateway IPv4 address in
order to function.
Grudgingly accept that routes without default gateways Are Hard
and use gatewayed routes instead. This causes routing to go from:
default dev clat4 scope link
to:
default via 192.0.0.4 dev clat4 scope link
192.0.0.4 dev clat4 scope link
and those apps now work.
Bug: 9597256
Bug: 9597516
Change-Id: I7b7890873802d3cb99affd6eb70b8ab75e7a2cf6
It used to be set at boot, but that was too quick to pick up carrier
specific resources. With this change even if you switch sims subequent
checks get the new values.
bug:9865616
Change-Id: I8c270c6b02fc6bdd3c3d76ceea58172df25e058d
A simple mechanism for doing this is to take advantage of the fact
that we require the device to reboot after a sim has been changed.
Thus when connectivity service is started we wait to get a connection
then call checkMobileProvisioning once. We also add a check that
the DEVICE_PROVISIONED is true, i.e. SetupWizard has been run.
Bug: 9784024
Change-Id: I5c1936744f6fc55a447ae44cd36eec3849d27e21
A simple mechanism for doing this is to take advantage of the fact
that we require the device to reboot after a sim has been changed.
Thus when connectivity service is started we wait to get a connection
then call checkMobileProvisioning once. We also add a check that
the DEVICE_PROVISIONED is true, i.e. SetupWizard has been run.
Bug: 9784024
Change-Id: I5c1936744f6fc55a447ae44cd36eec3849d27e21
The new one is often null when disconnected, so using the new fails.
In other situations, it's the connections on the old network we want
to reset anyway, so the old code when it would work would also do
the wrong thing (unless new iface == old iface).
bug:9112928
Change-Id: I1fcae89cc3aa9d712e516e7c97cece0b89869bd9
The new one is often null when disconnected, so using the new fails.
In other situations, it's the connections on the old network we want
to reset anyway, so the old code when it would work would also do
the wrong thing (unless new iface == old iface).
bug:9112928
Change-Id: I1fcae89cc3aa9d712e516e7c97cece0b89869bd9
To date WiFi only devices were defined by the list of networkAttributes
in config.xml overriden in on a per-device basis. This change is the
simplest change needed to determine this at runtime and therefore allowing
a single build to support the two different configurations.
Bug: 8562845
Change-Id: I34de5c6accc718b199c13815537de1debfe3dc91
VPN used to just watch the interface, but that is insufficient. There
is no promise that the interface will go down when we're done with it.
Now that wifi stays on in scan-only mode despite user turning it off
it seems that the interface is left up, even in AP mode.
Now listening for ConnectivityService broadcast that the network we were on
has disconnected and tearing down the VPN then or when the interface
goes away.
bug:8550083
Change-Id: Icf414497bc55bead69de04e91f39f90ac2e6578a
