When the system becomes loaded the PhoneApp can be delayed
significantly and a call to setEnableFailFastMobileData may not
occur because the channel between the MobileDataStateTracker (MDST)
and DcTracker (DCT) is not connected.
Solution: Add a isReady to MDST and isMobileDataStateTrackerReady to
ConnectivityService and call it from isMobileOk.
Bug: 10351868
Change-Id: I92f9d58121b88186b636cd71c2fd2ef9a28f7cf6
Move the early return outside the try {} finally so we don't call
setEnableFailFastMobileData(DctContants.DISABLED). Otherwise
referencing counting is wrong and an exception is thrown in DcTrackerBase.
Bug: 10304904
Change-Id: I5ba5121e473bada9f3daa8d6f3d3577cec8212fc
When captive portal checking completes pass back the result.
This is used to enable/disable failing fast for mobile. When
failing fast is enabled we don't check for data stalls and thus
won't be continually trying to do recovery operations, such as
restarting the radio.
Bug: 9462512
Change-Id: I0dea0eee519f8ee7f94e79d40e82c18f30d7fe2e
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
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
When captive portal checking completes pass back the result.
This is used to enable/disable failing fast for mobile. When
failing fast is enabled we don't check for data stalls and thus
won't be continually trying to do recovery operations, such as
restarting the radio.
Bug: 9462512
Change-Id: I0dea0eee519f8ee7f94e79d40e82c18f30d7fe2e
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
