Per-app APIs in ConnectivityService will now have their fallback
request which tracks the system default be of type TRACK_DEFAULT
as opposed to REQUEST. Existing tests which expect this fallback request
to be sent to network factories need to be updated to validate this
change.
Bug: 180452284
Bug: 176494815
Test: atest FrameworksNetTests
Change-Id: I5125755b3ed1ec535494e2d7a48c0860710ed056
Changing the per-app default request flows to fallback to a request of
type TRACK_DEFAULT as opposed to type REQUEST. The main benefit of this
change is that these requests will no longer be sent to the factories
which is desired.
Bug: 180452284
Bug: 176494815
Test: atest FrameworksNetTests
atest FrameworksNetIntegrationTests
atest CtsNetTestCasesLatestSdk
Change-Id: I312e55a54f70aa82953a32ab9369d5afc02b75e5
Address API review feedback, add getters to UnderlyingNetworkInfo
instead of exposing fields.
Instead of wasting memory by converting this into an array, have
migrateTun take a List<String>. In turn, tunAdjustmentInit should
also take a List<String>.
Bug: 183972554
Test: atest android.net.UnderlyingNetworkInfoTest
Change-Id: Id59744097208d91298a25ef110ade91a9cf291a1
Correctly count nri uid request counts in the per-app functionality in
connectivity currently used by set profile and set oem network
preference APIs. Previously, upon creation, nris would be created prior
to removing them. This would cause the uid request counts to
artificially increase and incorrectly throw an error if the request
count limit was hit even though in actuality an apps request count was
valid.
E.g., if there was an existing request for per-app functionality and
its owning app made a change to the per-app requests, it would double
count the existing requests. If the current count was say, one under the
limit, an error would be thrown even though it was being replaced which
should have resulted in no net change to the request count limit if
working correctly.
This patch will allow for the requests to be removed prior to creation
so that request counts are tabulated correctly.
Bug: 185849563
Bug: 183785319
Test: atest FrameworksNetTests
Change-Id: I13da0c81256cc02bea6aff2fe1ef99d6f6b0e764
Address API review feedback, ConnectivityManager#getAllNetworkStateSnapshot
should be pluralized so rename the method to getAllNetworkStateSnapshots
Bug: 183972554
Test: make, FrameworksNetTests
FrameworksServicesTests
Change-Id: Ic18d17d05984fa2466c962c7843c0ef7183ce77c
Note that this requires removing part of a test, because
that part is testing that the a 50 bonus of the legacy
int is stronger than the validation penalty, which is
not a mechanic we want to have. When WiFi is unvalidated
and cell is unvalidated, cell should be kept in case it
validates, like is described in comments in
isNetworkPotentialSatisfier ; however this test is
checking that it *IS* reaped off if the wifi score is
strong enough. This should be incorrect, and should not
be tested, so this patch removes the check.
Test: ConnectivityServiceTest
Bug: 184834350
Change-Id: I8966abee59fea2d9f10f082aba87df6588b72762
Adding historical logging for the setOemNetworkPreference() calls. This
will last across reboots.
Bug: 177257940
Bug: 176494815
Test: atest FrameworksNetTests
Change-Id: I4fc35fd58ff741830aa292adc1c559b4279ad8f9
By design, the nascent timer will be removed after a network
satisfied first request. However, this never happens.
Because the mInactive is false when that happens, so isNascent
is never true.
Furthermore, when removing a nascent timer, the inactivity
state can never be updated since no condition in the
updateInactivityState will be met to update the state correctly.
Thus, update inactive state accordingly when adding/removing the
nascent timer.
Test: TH
Bug: 184227264
Ignore-AOSP-First: prevent merge conflict
Change-Id: I4c1521b6e0ef68ac489771a2ab6b09ef3e381577
The value should be assigned as a long to do the bit calculation
as the mNetworkCapabilities is intended to be a long. Otherwise,
the value will be temporary assigned into an integer then
assigned to the target long. When the bit shift calculation
is out of the integer scope, the calculation will overflow and
result in unexpected bebavior.
Without assigning to a long, ConnectivityServiceTest will get
Out-Of-Memory in StringBuilder while generating toString() in
NetworkCapabilities after updating tests to verify
NET_CAPABILITY_VSIM and NET_CAPABILITY_BIP.
Bug: 130869457
Test: atest FrameworksNetTests
Change-Id: I4d34c1215c7efb6dc352c314107792e3fa512ad7
UserManager#isManagedProfile() is not aware of the user
handle of the context the UM instance is created on.
Instead, call isManagedProfile(int).
Bug: 183625645
Test: ConnectivityServiceTest
Change-Id: I1fef22d67d75df25a8c2d0694f857c3e1c1a1306
This change downgrades API visibility for the list-of-subIds in the
NetworkCapabilities to SystemApi
Bug: 175662146
Test: atest NetworkCapabilitiesTest#testSubIds
Test: atest FrameworksNetTests
Change-Id: I372fa9eaa7585aefd1710948ca007456feedd578
- 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)
When WiFi disconnects, the VPN disconnects immediately. The
broadcast can therefore be sent before the broadcast receiver is
registered, which causes the receiver to not see the broadcast.
The puzzling part is that CONNECTIVITY_ACTION is a sticky
broadcast, so one would expect the broadcast to still be
received, even if the registration is done after the broadcast
is sent. The reason this doesn't happen is that the context used
by the test is a BroadcastInterceptingContext, which does not
treat sticky broadcasts as sticky.
Bug: 184115648
Test: atest --iterations 1000 'ConnectivityServiceTest#testLegacyLockdownVpn'
Change-Id: Ib44c92839d25951cc7d2db0f923e1b104690e1e0
At this stage, this is turned off. Unit tests will be
in a followup change.
Test: In a followup
Bug: 167544279
Change-Id: I4448a3546fbc1a3dddf757982c031c5f39ba2889
Give anyone with PERMISSION_MAINLINE_NETWORK_STACK (i.e.,
either the system or the networkstack process) a separate limit
of 250 callbacks per UID.
Bug: 183921387
Test: new unit tests
Change-Id: I24580ea48e3ad502ef584efc5fde0b5d22e392b4
* changes:
Add test coverage for NetworkAgent callbacks.
Add a setTeardownDelayMs API to NetworkAgent.
Address comments on onBlockedStatusChanged(Network, int) CL.
It isn't used by ConnectivityService any more and even if
it needs such utility method in the future, we could create
one which is part of connectivity module and doesn't need
to be exposed as part of NetworkPolicyManager API surface.
Bug: 183696103
Test: atest ./tests/net/java/com/android/server/ConnectivityServiceTest.java
Change-Id: Ie3c681f88e4b2b9bb92d2224c5ea96b074f155d5
