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
Internal logic relies on Arrays.copyOf(), so always give ourselves
valid arrays, using shared empty objects to save overhead.
Bug: 17502649
Change-Id: I5dbb00545bdfe45bbd48144ab505ea08cc92cbcd
Currently just valid/invalid based on NetworkMonitor findings.
Changed NetworkMonitor to start out in default state since starting in Offline causes
a spurious invalid report at creation time.
Added some logging.
bug:17395269
Change-Id: I9ae650b561834d8f8979033744d97df852e76df9
Previously the Inet state (the little exclamation mark beside the WiFi
and Cellular bars) only transitioned from bad to good once. With this
change it can transition back to bad (and later to good again) if a network
re-evaluation is triggered, say by ConnectivityManager.reportBadNetwork.
Also, avoid triggering re-evaluation in two unwanted cases.
bug:16214361
Change-Id: I7856724249ffcbb0945276dcf45019876231fdaf
Give unvalidated networks penalized scores and allow them to satisfy
requests.
Previously unvalidated networks were never allowed to satisfy
NetworkRequests and so never caused CONNECTIVITY_ACTION broadcasts.
Previously if there were no other networks present an unvalidated
network would still be made the default. This change formalizes
this behavior using our existing network score logic by assigning
unvalidated networks a highly penalized score.
bug:16358003
bug:17364306
Change-Id: I28fcd6f5ac4b52a4d1c234c472cfa8ba998bcc6f
HttpHandler and HttpsHandler classes have a lot of bug fixes baked into
them that the Network.openConnection() API should be using, for example
disabling SPDY support.
bug:17420465
Change-Id: I9f1472753a542d1dd6bffde3a60c37a9145098aa
Future HTTP requests could use an old socket that's bound to a different Network
causing unexpected results. DNS results could also not be appropriate.
bug:17283566
bug:17432215
Change-Id: I88b40b723c7b442000cafe8ce8b9d989d8995991
Network Factories are allowed to go below, but networks need to be
constrained. Allowing the network to go below 0 meant that -1 could
sometimes leak through and foul the logic.
The core of 17361330 will be fixed when we stop sending scores for
listens to NetworkFactories, but it exposed this issue too. Summary:
1 - add a network listener. This isn't a request so it's not sent
to networks.
2 - alter your score (ethernet sets score to -1 when the link goes
down) (16:07:39.782)
3 - a bug in ConnectivityService causes score changes to get sent for
all network requests and network listeners causing NetworkFactories
to no see 2 entities. This bug will be fixed by a pending change
(https://googleplex-android-review.googlesource.com/#/c/540840/).
This causes the ethernet NetworkFactory to see two entities, both
served by networks of score -1. (16:07:39.989)
4 - disconnect Ethernet - this only sends 0 scores for known
requests, not network listeners. Had it been sent for both entities
they both would have evaluated that the networkfactory score (-1)
was lower than the request score (0) and both released their
refcount. (16:08:03.147)
5 - this means the listener is tracked by the EthernetNetworkFactory
with a score of -1 while the factory itself has a score of -1 so the
network release isn't called.
bug:17361330
Change-Id: Ife34ca0f9c233dd3c3df80f6fea580af43afcdeb
