- This will be visible only to apps with the NETWORK_SETTINGS
permissions (signature), and will be redacted for all other callers.
- This string is expected to be the same as set by
VpnService#setSession, and in general, VpnConfig.session. But it
will be a general API that Vpn.java can call when setting the
VpnTransportInfo.
- This string cannot be updated once the VPN NetworkAgent is connected.
Bug: 171872481
Ignore-AOSP-First: needed to prevent automerger race breaking build
Test: atest ConnectivityServiceTest
atest VpnTransportInfoTest
atest NetworkAgentTest
Change-Id: I883035262465238c35c5a931d89707f3e84feef8
Merged-In: I883035262465238c35c5a931d89707f3e84feef8
(cherry-picked from ag/14008230)
- This will be visible only to apps with the NETWORK_SETTINGS
permissions (signature), and will be redacted for all other callers.
- This string is expected to be the same as set by
VpnService#setSession, and in general, VpnConfig.session. But it
will be a general API that Vpn.java can call when setting the
VpnTransportInfo.
- This string cannot be updated once the VPN NetworkAgent is connected.
Bug: 171872481
Test: atest ConnectivityServiceTest
atest VpnTransportInfoTest
atest android.net.cts.NetworkAgentTest
Change-Id: I8d09e25b83f7ee8be21ec9c9bd3c72a251f1370d
Merged-In: I8d09e25b83f7ee8be21ec9c9bd3c72a251f1370d
(cherry-picked from ag/14011912)
The tests have been building against hidden APIs to provide additional
coverage.
Test: m TetheringCoverageTests CtsNetTestCases
Bug: 182859030
Ignore-AOSP-First: needs manual cherry-picks
Change-Id: I37d748411a34f25834214a2412c49aed1423e526
Update test to:
1. verify onNetworkCreated callback called when network is
created.
2. Verify onNetworkDestroyed callback called when agent
updates its connection state to disconnect and native
network is destroyed.
Bug: 178725261
Test: atest android.net.cts.NetworkAgentTest
Change-Id: Icd30440e0f553d0f97b860d0e69b4f3d4f0a2a1d
At this stage, this is turned off. Unit tests will be
in a followup change.
Test: In a followup
Bug: 167544279
Change-Id: I4448a3546fbc1a3dddf757982c031c5f39ba2889
These members are public mutable and their names are confusing.
Make them package-private and final.
Bug: 173068192
Test: test-only change
Change-Id: I87131c48f67b6614c25aa99e1cbc53196f49aa7c
Currently, TestConnectivityManager immediately sends all
callbacks and broadcasts to the Tethering code as soon as the
test code makes any change.
This makes it impossible to affect the order in which those
events are delivered to the Tethering code, so it is not possible
to test for races.
Fix some of this as follows:
1. Make TestConnectivityManager post all its callbacks to the
handlers that Tethering registered them with.
2. In TetheringTest, use the existing TestLooper object to
advance time manually. Also use setUseRegisteredHandlers to
ensure that the broadcasts are sent in order. This requires
calling dispatchAll() after sending the broadcast to preserve
the existing synchronous behaviour. Take advantage of that to
remove lots of existing dispatchAll calls.
3. Add a TestLooper to UpstreamNetworkMonitorTest and use it.
Keep the test passing by adding lots of mLooper.dispatchAll(),
which is a bit ugly but probably acceptable given the
additional coverage it provides.
This exposes an existing bug in the code where if upstream
selection is in automatic mode, and all CONNECTIVITY_ACTION
broadcasts are received before all NetworkCallbacks, the code
does not switch upstream.
In order to make the tests pass, re-order the CONNECTIVITY_ACTION
broadcasts with the NetworkCallbacks in TestConnectivityManager
so as not to trigger the bug. A future CL will make the order
configurable.
While I'm at it, switch TestConnectivityManager from HashMap to
ArrayMap, which is generally preferred for maps that do not
contain too many elements.
Bug: 173068192
Test: test-only change
Change-Id: I964f365c691fbc396ab0a87f292bd32b123011fe
Currently, Tethering files NetworkRequests even when
config_tether_upstream_automatic is enabled. This is incorrect:
when the automatic upstream selection is enabled, the tethering
upstream should always follow the default network and there is
no need to file any requests.
These requests are harmful when tethering is not using cellular
as its upstream, because:
- If the device does not use mobile data always on, the request
causes the cellular network to be brought up, causing power
draw.
- Even if the device does use mobile data always on, the request
causes the cellular network to come to the foreground, which
allows all apps to access it, causing potential data usage.
Amend the existing testGetCurrentPreferredUpstream to cover these
changes, by making that test case always set automatic upstream
mode. This does not result in any loss of meaningful test
coverage, because getCurrentPreferredUpstream is only ever called
when chooseUpstreamAutomatically is enabled.
Bug: 173068192
Test: atest TetheringTests
Change-Id: I068a5338699a3ed04f24f97f785ea89ff5890e50
UpstreamNetworkMonitor is the part of tethering that files
NetworkRequests for upstream netwoks, but it currently does not
know all the requirements for upstream selection. For example, it
does not know whether automatic upstream selection is in use.
This forces the upstream selection code to be split between
UpstreamNetworkMonitor and Tethering. This makes it difficult to
follow.
This CL ensures that all information about upstream requirements
(DUN required, automatic upstream selection, tryCell) is passed
to UpstreamNetworkMonitor so it can be aware of it.
This CL also removes the ability for UpstreamNetworkMonitor's
callers to call registerMobileNetworkRequest or
releaseMobileNetworkRequest. In a future CL, this will be
automatically done by UpstreamNetworkMonitor depending on the
upstream requirements.
This CL is a no-op refactoring with no behaviour changes.
Bug: 173068192
Test: atest TetheringTests
Change-Id: I174f765c616e0dbe2aa493c12613e6131cff0666
The defaults follow the same pattern as framework-wifi-test-defaults
to allow unit tests to build against hidden API in Connectivity.
Bug: 171540887
Test: m
Change-Id: I1a77278aa458e309d2772dd6ad84f4412b6e9387
Ignore-AOSP-First: Necessary code in internal only now
The defaults follow the same pattern as framework-wifi-test-defaults to
allow unit tests to build against hidden API in Connectivity.
Bug: 171540887
Test: m
Change-Id: I58bb6574f7e95053e4a95f76d1025506749ec2b8
This exposes the two bits settable by the network agents in
Android S on NetworkScore. This is meant to be extensible in
future releases, or possibly for OEM upstreams.
Test: builds
CTS-Coverage-Bug: 184037351
Bug: 167544279
Change-Id: Id7ee1bd3e2679f0bd5200d5c299f18a33b87847c
The Connectivity service will become the mainline module.
Therefore, remove the caller of using Connectivity's
hidden API outside the module and expose the required
connectivity API used in Jobscheduler.
Bug: 183456204
CTS-Coverage-Bug: 170598012
Test: atest JobStoreTest
Change-Id: Ie6bc81ff382fb242b98f35d28a96defc207c7987
Merged-In: Ie6bc81ff382fb242b98f35d28a96defc207c7987
(cherry-picked from ag/13946348)
- This will be visible only to apps with the NETWORK_SETTINGS
permissions (signature), and will be redacted for all other callers.
- This string is expected to be the same as set by
VpnService#setSession, and in general, VpnConfig.session. But it
will be a general API that Vpn.java can call when setting the
VpnTransportInfo.
- This string cannot be updated once the VPN NetworkAgent is connected.
Bug: 171872481
Ignore-AOSP-First: needed to prevent automerger race breaking build
Test: atest ConnectivityServiceTest
atest VpnTransportInfoTest
atest NetworkAgentTest
Change-Id: I883035262465238c35c5a931d89707f3e84feef8
