Moves this out of ConnectivityService and into each NetworkMonitor
(where it's more self-contained).
Test: as follows
- builds, flashes, boots
- runtest frameworks-net passes
- manual testing with working and non-working hostnames behaves
somewhat (but not entirely) as expected, and not always quickly
Bug: 64133961
Bug: 72345192
Bug: 73872000
Bug: 77140445
Change-Id: Ic4322af3cb49149f2d975cb31f54b2ac7927f907
This change comprises the following parts:
[1] android.net.dns.ResolvUtil, containing methods that encapsulate the
use of the high bit in netids used in DNS resolution contexts.
[2] Updates to captive portal apps to call the ResolvUtil method that
enables DNS-over-TLS bypass for the captive portal app process.
Test: as follows
- builds
- flashes
- boots
- runtest frameworks-net passes
Bug: 64133961
Bug: 72345192
Change-Id: I2072c1f68d6978fa0d7e9d8693135a2c51bb0f87
Tethering currently wants access to complex isTetheringSupported
logic that is only available in ConnectivityService. Instead of
trying to access that via ConnectivityManager, pass this capability
in to Tethering directly, in the TetheringDependencies object.
Also:
- ConnectivityManager is only a source of static constants now,
so "import static" all the constants that are actually used.
Test: as follows
- built
- flashed
- booted
- runtest frameworks-net works
- manual USB towards WiFi tethering works
Bug: 68951715
Change-Id: Ia64faaadefb4a5d84a50da98bdebd544b6fda101
This will let ConnectivityService send the right callbacks to the
relevant apps.
Test: manual with apps
runtest frameworks-net
cts
new tests for this functionality
Bug: 67408339
Change-Id: I6f08efd9e73c7e191f833d7f307a3bf4c9e2f0b4
This will let ConnectivityService send the right callbacks to the
relevant apps.
Test: manual with apps
runtest frameworks-net
cts
new tests for this functionality
Bug: 67408339
Change-Id: I6f08efd9e73c7e191f833d7f307a3bf4c9e2f0b4
Useful for clients such as BatteryStats which currently rely
on NetworkStatsFactory. Data at that stage is incomplete as
it does not account for tethering, VT data and corresponding
464xlat corrections.
Test: runtest frameworks-net, CTS tests pass.
Change-Id: I763b77f601c827fd2963204694fb5b45425cc791
Currently, when a network goes into CONNECTED state, we call
updateLinkProperties and then notifyIfacesChangedForNetworkStats.
The latter is unnecessary, as there are exactly two cases:
1. networkAgent.linkProperties != null: updateLinkProperties will
call notifyIfacesChangedForNetworkStats, because oldLp is null
and networkAgent.linkProperties is not null.
2. networkAgent.linkProperties is null: there is no need to call
notifyIfacesChangedForNetworkStats, because no interfaces were
added or removed. When they are, updateLinkProperties will be
called again.
Removing the call to notifyIfacesChangedForNetworkStats avoids
a stats poll, which is a minor performance improvement.
Also, remove the NetworkStatsService code to do asynchronous
interface updates, since it has no callers.
Bug: 72107146
Test: builds, boots
Test: runtest frameworks-net
Change-Id: I9337ea26c0505a1c66ceda01254b68e25cd7972c
Fix test breakages I caused when adding cell
support for NATT keepalives.
-Make the minimum keepalive interval a constant in
ConnectivityManager and use it in tests.
-Re-Disallow IPv6 Keepalives
Bug: 73327535
Test: 'runtest -x ConnectivityServiceTest' now passes
Change-Id: I5ec4367d250ee371014e65c897c3897a25a05e2d
This has no concrete impact on the behavior of ConnectivityService,
but in principle TRACK_DEFAULT requests should not be counted toward
requests that make a network foreground. It does not have an impact
because only VPNs could be affected by this, and VPNs are always in
the foreground by definition.
Test: runtest frameworks-net
Test: cts
Change-Id: Id2ae6b5c9d542fe168e64ed713b6ec0a04062c82
NOT_SUSPENDED and FOREGROUND are capabilities that need to
be public so as to reach feature parity with what information
can be gotten through the use of CONNECTIVITY_ACTION and
synchronous calls to ConnectivityManager. This change makes
them public, and wires up the NOT_SUSPENDED capability.
This deprecates in effect the old onSuspended and onResumed
callbacks, but these have never been public.
This also converts the onAvailable path from a multiple
binder call design to a simpler, single binder call. This
is only for internal convenience
Test: runtest frameworks-net
Test: cts
Test: also manual testing
Change-Id: I6ea524bb361ecef0569ea2f9006c1e516378bc25
Prior to this change ConnectivityManager used to patch in the UID
of the requesting app inside the NetworkCapabilities sent to it.
The rationale was that the app may not know what other apps may
use the network, so the view it should have of the network should
always say the network only applies to that app.
But this has an unfortunate side effect : apps can't match the
received network against a default NetworkCapabilities. Ostensibly
this only applies to the system because all involved calls are
@hide, but still : system code would get some NetworkCapabilities,
for example using networkCapabilitiesForType, and then try to
match the capabilities of an available network using
satisfiedByNetworkCapabilities. Because the passed network is
declared to only apply to one's own UID and the UIDs of the
NetworkCapabilities are set to null meaning "I need this network
to apply to all UIDs", the answer will be "false".
While this is WAI in a sense, it is very counter-intuitive that
code trying to match a network would be required to patch in its
own UIDs.
There are three ways of fixing this :
1. Require all apps to do the above. It's correct, but it's
cumbersome and counterintuitive. Multiple places in existing
code needs to be fixed, Tethering is an example.
2. Write the UIDs of the caller in any NetworkCapabilities object
that is created. This is not very practical, because it imposes
the converse requirement on all NetworkAgents, which would then
have to clear the UIDs before they send the capabilities to
ConnectivityService. All NetworkAgents need to be fixed.
3. Instead of sending an object with a list of one UID to apps,
send a null list. The drawback is that the networks nominally
look to apps like they apply to all apps. I argue this does
not matter ; what matters is that the UID lists do not leak.
Clients just see a null list of UIDs (and third party can't
even access them without using reflection). No other changes
are required besides this two-line patch.
This patch implements 3. I believe it is the saner approach, with
both the most intuitive behavior and the best backward compatibility
characteristics, as well as the easiest change.
This does not encroach on the future plans to make the actual
UID list available to apps with NETWORK_SETTINGS.
Test: runtest frameworks-net
Change-Id: I978d91197668119e051c24e1d04aafe1644a41cf
