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
Network stats are now read out of the kernel in one sweep, instead of
reading per-UID. We now accumulate the delta traffic between each
stats snapshot using the well-tested SamplingCounter pattern.
Since Wi-Fi and mobile traffic have different costs, track each
separately. Avoids counting misc interfaces like loopback and
ethernet under total.
Bug: 5543387
Change-Id: I642004dc530113c27ef79f2abbae51d8af30117f
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
Fixes issues brought in by change to isHostRoute. isHostRoute
was technically correct, but the callers really wanted hasNextHop
behavior.
bug:8597268
Change-Id: I360761ccfa98b2ba34642f717a78fa71ec1bae4f
The Global http proxy shouldn't be used by apps, but can be useful in certain
conditions.
bug:8264794
bug:8557674
Change-Id: Ia3cbe542e448d9e74d0492626a13e9fd34ad797a
Change our order of operations so that secondary route table
adds succeed. Working to understand the why of this too.
bug:8361314
Change-Id: Ie25061eb38c62eaa5e60aa8a488496de49bdbd9d
LinkProperties's equals() method was broken by the addition of
stacked interfaces. The reason was that equals() was checking
the equality of mStackedInterfaces.keys(), which is just an
enumeration, instead of mStackedInterfaces.keySet(), which
actually contains the keys. The test was failing, but I didn't
notice.
Fix the bug and make the test check the objects more in depth
so it can give more detailed error messages when equals() fails.
Bug: 8276725
Change-Id: Ie990bd75f641c28e63e54d953dcd0f4de13f7c9f
