The placeholder for disconnected networks was setting it to false, but
this technically means that we know an attempt to connect to that
network will fail (which we don't really now). Some applications use
this an decide not to bother trying - an MMS app for example would
never send an MMS because it thinks the network is never available.
This is a L regression.
bug:17669247
Change-Id: Id6041f226da069c267c56418d42c55978c36c66f
Previously the score was not sent out causing other NetworkFactories
to have the lower unvalidated score and to repeatedly try to bring
up a new Network only to have it torn down.
Also, avoid logging an error when tearing down a network with only
listening requests.
bug:17726566
Change-Id: I82ff7c9bd5ec962f62a50ad0042c278622953969
Explicitly selected Networks may never be validated (e.g. Chromecast)
but are still given a high score so they can explicitly become the
default Network. Without this fix they do not become the default
Network if another Network is present. This was an artifact of how
unvalidated Networks were handled, but now that unvalidated Networks
are properly handled, ala 50807d, we can freely rematch even
unvalidated Networks and NetworkRequests.
Also, never linger and teardown unvalidated Networks as the user
might be in the process of signing in. This better matches prior
behavior when unvalidated networks didn't match NetworkRequests,
and thus were never lingered.
Also, don't disconnect networks that may be lingering. The
disconnect logic in rematchNetworkAndReqeuests() is adjusted to only
fire when a network is newly validated.
It is incorrect to consider rematching uncreated Networks and
explicitly selecting created Networks, so this change logs error
messages in those cases.
bug:17647968
bug:17396616
Change-Id: Id6b8a350b8200f484d5bfd14ca0a8f64f08846a0
Most of this logic is simply removed from ConnectivityService.
The captive portal detection is now done by the NetworkMonitor.
The notification logic is still left in ConnectivityService as
it's used by both the NetworkMonitor and telephony's mobile
provisioning logic.
bug:17324098
Change-Id: Ibd1c42b1a75795f90a6483d3d0a5a14f88b193d8
Currently, LegacyTypeTracker sends out connected broadcasts
before updating its internal lists of networks. This creates a
race condition where an app can query LegacyTypeTracker state
(e.g., via getActiveNetworkInfo) as soon as it gets the
broadcast, and get information that has not been updated.
Bug: 17540101
Change-Id: Iefd6d5e9fd0b427c5872166208831f70fcef8b6f
Previously we would restart clatd on every LinkProperties
change, which now happens every time we switch radio technology
(e.g., LTE to HSPA). We also would not stop it if the link got
an IPv4 address.
Bug: 15024258
Bug: 17186694
Bug: 17569702
Change-Id: I65cfcd5e7acec8ea1a12392a59dabd668c58490f
Now that we support unreachable routes, use those to block
address families on VPNs. This is a much more elegant solution.
Also update LinkProperties when IP addresses are added and
removed, fixing a TODO.
Bug: 17462989
Change-Id: Ib749d84710dca70d672350b9f129bb91419ec77e
The locks were added in c006f1 when underlying functions weren't performing
locking. In 21062e7 the underlying functions were changed to perform locking
but the higher level locking wasn't removed. The higher level locking can
now cause deadlocks with the new NetworkAgentInfo locking. This change
removes the needless higher level locking. Now all mRulesLock locking
only guards simple accesses to the appropriate two data strucures so there is
no chance of a deadlock. I verified that all accesses to the appropriate
two data structures are guarded by mRulesLock locking.
bug:17569997
Change-Id: Id9f4e3d19d6895876925ae32f12460db30359368
The BT and Wifi mechanisms for enabling Tethering did their own
permission checks. This set of changes unifies the check into
a ConnectivityManager function so they can be kept in sync.
bug:17435527
Change-Id: I8c157a5acf56ffbddd349cb6a45160ae7be8541b
