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
Robert Greenwaltcommited 2014-09-14 07:43:10 -07:00
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
Paul Jensenauthored and Robert Greenwaltcommited 2014-09-12 23:02:28 +00:00
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
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
Robert Greenwaltcommited 2014-09-10 10:39:37 -07:00
When lingering completes ConnectivityService would log an error message
saying the Network still had NetworkRequests. Fixed by ignoring
listening NetworkRequests which aren't a problem.
Change-Id: Ie78a1f91c47b012eae28a377dd77bee2cfcbde3b
Network traffic used to perform the network validation is billed to the UID of
the caller of reportBadNetwork. This change does not change the actions taken
upon validation failing or succeeding: NetworkMonitor will show the sign-in
notification if a captive portal is found. NetworkMonitor will inform
ConnectivityService if a network tests functional. NetworkMonitor will not
take action if a network lacks any connectivity.
Also, remove an unused Thread that was confusing bandwidth billing.
bug:17326268
Change-Id: I7fea23480af54211004a0a1c535a71c2793f21bb
This constructor does nothing, including doing nothing with its
only argument. This causes it to return a NetworkInfo for
TYPE_MOBILE no matter what was passed in.
Bug: 16610051
Change-Id: I4ccd5ec050f7824fb06496c00fcd7901defeb7bd
Lorenzo Colitticommited 2014-08-29 18:34:49 -07:00
This makes tethered clients use the correct DNS servers when
tethering to non-default networks like the DUN APN.
Bug: 16357676
Change-Id: I8933b6de198a92c2aaf0291931ace8966ddba275
Lorenzo Colitticommited 2014-08-29 10:21:58 -07:00
When the NetworkMonitor is told a network disconnected and a sign-in
notification has been shown to the user, the NetworkMonitor requests
the notification be removed. This request goes to the
ConnectivityService who may have already removed the NetworkAgentInfo
from mNetworkForNetId so we cannot look up the NetID in there.
There is no harm in allowing notification hiding for networks that
are disconnected as the notification logic does not effect the
Network state (like the validation message that caused the addition
of the Network liveness check).
bug:17261757
Change-Id: Id0a299e230ae37e641ac2faeebc45550e27c1fa4
https://googleplex-android-review.googlesource.com/#/c/527772/
correctly stopped adding listen requests to the mNetworkForRequestId
sparse array, but when we remove requests, if it's not getting
serviced by a network, we don't remove it from the network. That
means that when we go to send a notification for that network we have
a request affiliated with the network, but don't have data for the
request and hit this NPE.
If it's not a request, don't do the optimization and remove it only
from the network servicing the request, but instead scan all networks
and remove it from each, if found.
bug:17239054
Change-Id: I49165ed08c224ef20f703469f9ce39df5f21b163
Robert Greenwaltcommited 2014-08-25 15:42:10 -07:00
Otherwise attempts to release that are triggered by the binder death
receipient will be rejected.
Bug: 17187437
Change-Id: If3924d82dba69c572708e04c11d17ed25ae6870d
Don't send out NetworkInfos with UNKNOWN state for disconnected
networks - use DISCONNECTED.
bug:17095670
Change-Id: I863bebadc1f9a666572958b49d5e62809f485e5d
Robert Greenwaltcommited 2014-08-21 09:19:46 -07:00
This is used by the VPN to notice when its underlying connection
has gone away. I'm fixing this using network types and not
NetworkCapabilities because
1. I don't know of a way to use the new API to get callbacks for
a specific network. You can get them based on capabilities,
but it's not clear how to construct a NetworkCapabilities
object that will only match a specific network, or only match
the default network.
2. It's a smaller change.
Bug: 15070628
Change-Id: Id6a6a183da83636c0859db4c954093bd684c01ea
Lorenzo Colitticommited 2014-08-20 09:11:14 -07:00
-The ability to launch VPNs is now sticky; once approved by the user,
further approvals are not needed UNLESS the connection is revoked in
Quick Settings.
-The old persistent notification has been removed in favor of the new
Quick Settings UI.
-The name of the VPN app is now pulled from the label of the VPN
service rather than the app itself, if one is set.
Bug: 12878887
Bug: 16578022
Change-Id: I102a14c05db26ee3aef030cda971e5165f078a91
There are only a limited number (65526) of NetIDs so the chance for reusing
one exists. Reusing a currently active NetID will cause problems like netd
failures and overwriting entries in mNetworkForNetId.
bug:16815182
Change-Id: Ib75302beae3179c3f3b90c345cf4d2cf5f4ad2be
If we have a message in flight about a NetworkAgentInfo when it gets disconnected
we are left with a zombie network. Fixes this by verifing the network is still
live before we process the msg.
bug:17142206
Change-Id: I2c94a39b3ea97c1562066571b277280c1f69f71c
Robert Greenwaltcommited 2014-08-20 09:30:15 -07:00
This is a small change but should fix a number of functional problems:
1. When registering a listening NetworkRequest and when a Network is
validated, we should always add the listening NetworkRequest to the
Network's list of NetworkRequests if the Network satisfies the
NetworkRequest. Previously in both cases this was only done for
the highest scoring network. This enables the listening
NetworkRequest to listen for all networks, not just the highest
scoring network.
2. No longer add listening NetworkRequests to mNetworkForRequestId as
it doesn't make sense as it's a 1:1 mapping but listening
NetworkRequests to Networks is a many:many mapping.
3. Don't "keep" a Network that's finished validating when only a
listening NetworkRequest requests it.
4. Don't send updated scores to NetworkFactories from listening
NetworkRequests. NetworkFactories and NetworkAgents shouldn't
concern themselves with listening NetworkRequests.
bug:16680764
Change-Id: Iaba14263227771e4bd84ee4bce488beaef20a8a3
Add logic to obtain the mtu from the network PCO parameter and set it to kernel
when the mobile data connection is established. When there is no PCO mtu configured
from the network, the mtu size defined in the corresponding APN will be used. In case
no mtu size is defined for an APN used for data connection, the MCC/MNC based MTU
defined in the framework overaly will be applied.
bug:17046179
Change-Id: I6465d4b8f2076aaa380ae3617fb3f24adbe136d4
w19976authored and Robert Greenwaltcommited 2014-08-14 20:34:13 -07:00
This was old code I missed in previous inet condition refactor
and caused us to show "not connect" icon any time we connected
to a secondary network (mms/supl/etc).
bug:16896743
Change-Id: I0fa62e09bb0b7c0ee0864bb1f95967eac5f60d3e
Robert Greenwaltcommited 2014-08-12 14:51:48 -07:00
for determining carrier app instead of MCC/MNC.
Related ConnectivityService change: http://ag/374479
Related Aeroshell change to SetupWizard: http://ag/520857
Bug: 16457806
Change-Id: I78eb2a25d578400c2de6bae4af3d6e8e1ee4d0c7
Diego Pontorierocommited 2014-08-12 13:15:20 -07:00
Some devices use clatd for catching raw IPv4 traffic when running on
a pure-IPv6 carrier network. In those situations, the per-UID
stats are accounted against the clat iface, so framework users need
to combine both the "base" and "stacked" iface usage together.
This also means that policy rules (like restricting background data
or battery saver) need to apply to the stacked ifaces.
Finally, we need to massage stats data slightly:
-- Currently xt_qtaguid double-counts the clatd traffic *leaving*
the device; both against the original UID on the clat iface, and
against UID 0 on the final egress interface.
-- All clatd traffic *arriving* at the device is missing the extra
IPv6 packet header overhead when accounted against the final UID.
Bug: 12249687, 15459248, 16296564
Change-Id: I0ee59d96831f52782de7a980e4cce9b061902fff
Switching from GCM-only inet condition reports to using our network
validation (captive portal check).
Note that currently the GCM signal is disconnected. Next step is to
make the bad-network report API trigger a re-evaluation of the network
and get negative reports from the NetworkMonitor.
Change-Id: Ie2ebab1e5c04775e3c4d6738f656a6c8157dba76
Robert Greenwaltcommited 2014-08-07 22:31:05 +00:00
We used to do this but the change got lost in the NetworkAgent
upgrade. This brings it back. ConnectivityService has netd do
the actual flushing.
bug:16549455
Change-Id: I11ddd55fcb9d1ed1d2c6a9be7eb8c57e41bdbdb8
Robert Greenwalt
commited 
Paul Jensen
authored and
Android (Google) Code Review
commited 
Sreeram Ramachandran
commited 
Lorenzo Colitti
commited 
Diego Pontoriero
commited 
Jeff Davidson
commited 
Selim Cinek
commited 
w19976
authored and
Jeff Sharkey
commited