In an effort to make reviewing easier, this implements most of
the infra but only a mostly trivial test.
Bug: 184037351
Test: this
Merged-In: Ibb9139798ce44d748e87bae79a1e23311ec8d9b6
Change-Id: Ibb9139798ce44d748e87bae79a1e23311ec8d9b6
(cherry-picked from ag/14452537)
This is supported by:
1. Utilize the new API from both NetworkStatsProvider
and IOffloadControl to send data warning quota to hardware.
And pass the warning reached notification back to NPMS.
2. Disable software solution introduced in R release for
V1.1+ hardware, since now we can fully offload data warning
and limit notification to hardware.
Test: atest TetheringTests
Fix: 149467454
Merged-In: Ie49461694d77ab7f25a549433b01b5b0167bd489
Change-Id: Ie49461694d77ab7f25a549433b01b5b0167bd489
(cherry-picked from ag/13981692)
This is a no-op change that just adapt new API from
NetworkStatsProvider to get warning and limit bytes at the same
time. This change also stores them locally for subsequent
patches to set warning bytes to hardware.
Test: Will be included in the subsequent patch.
Bug: 149467454
Merged-In: Iec01cb01fd1ce481ce0bd736762baddde1e38084
Change-Id: Iec01cb01fd1ce481ce0bd736762baddde1e38084
(cherry-picked from ag/13981691)
This is a no-op change that redirect both V1.0 and V1.1 callback
events to the same handling function. Since the V1.1 callback
is extended from V1.0 callback, we can safely use V1.1
callback for both V1.0 and V1.1 control.
The change also provides interface for subsequent
OffloadController changes to set warning and limit at the
same time.
Test: atest TetheringTests
Bug: 149467454
Merged-In: I6505a04de8c57357dd1fa9ce898c13395e497816
Change-Id: I6505a04de8c57357dd1fa9ce898c13395e497816
(cherry-picked from ag/13973147)
Yielding cell wins to exiting wifi (whether good or bad).
It loses to bad wifi that's not exiting.
In R, yielding to bad wifi only affects wifis that are
unvalidated, but a wifi that is exiting should still be
dropped in favor of a cell that yields to bad wifi.
I had misunderstood the policy and implemented it wrong.
Now it's implemented right, and has careful tests.
Test: new tests for this
Bug: 186458024
Merged-In: I3c2563d4ae4e3715d0c6270344ba8f7ef067872f
Merged-In: Ib8637100d491e72a2edb837584ce55b7dda58524
Change-Id: Ib8637100d491e72a2edb837584ce55b7dda58524
(cherry-picked from ag/14486203)
The test simply verify the constructor. They only apply on S+ as
InvalidPacketException is not updatable before S.
Bug: 187935317
Test: atest InvalidPacketExceptionTest
Change-Id: I33f1ee1702672204a46063e6e75c3880d5e7600b
Tests for the newly added QosCallback functionality
Bug: 155176305
Test: Added to cts/NetworkAgentTest
Change-Id: I29769fc8be074a5105bfe4ac34e30980c5f8744a
Add tests for requestNetwork and registerNetworkCallback with
PendingIntents that are equal as per PendingIntent.intentFilterEquals.
In such situations, the first request is documented to be automatically
unregistered. This means that the PendingIntent should only be fired
once, instead of being fired for both requests.
Currently this behavior is broken for network callbacks (not for network
requests).
Test: atest ConnectivityManagerTest
Bug: 174237997
Change-Id: Ic636c731c71474ef09043d7a26ccfd6e2bb5c39f
ConnectivityManager.setAvoidUnvalidated only works if the
config_networkAvoidBadWifi configuration is set to 0 and the
NETWORK_AVOID_BAD_WIFI setting is unset. There is no easy way
for a testing app to temporary set a test value to verify the
behavior of the API. Thus, add a mechanism to allow test app
to set a period of time to temporary unstrict the resource
configuration, i.e. Temporary simulate config_networkAvoidBadWifi
configured to 0.
Bug: 186061922
Test: atest CtsNetTestCases FrameworksNetTests
Change-Id: If772078c61a9b12926f104d5dfc9c9071e844732
The tests are also useful in CTS to ensure that the
ConnectivityDiagnosticsManager class API is implemented properly
(including behavior of the DataStallReport class for example).
Bug: 187935317
Test: atest ConnectivityDiagnosticsManagerTest
Change-Id: I86f39238054f43403f9a1e383dd2a935de84f06f
ConnectivitySettingsManager and CtsNetUtils are doing the same
thing to set/get private DNS related settings.
To prevent making the duplication code in two places, move the
body to frameworks/libs/net and call it.
Bug: 185311744
Test: atest CtsNetTestCases CtsNetTestCasesLatestSdk
Change-Id: I3272c825b86ec30c3d0bf4097088c653e668461b
Many applications use ConnectivityManager without needing
TetheringManager (or without calling legacy ConnectivityManager methods
that delegate to TetheringManager), so initializing TetheringManager
when ConnectivityManager is created wastes resources.
This is especially true considering that TetheringManager is not trivial
to initialize (worst case scenario it starts a thread and does multiple
Binder requests), and ConnectivityManager is created in ActivityThread
when setting up the app proxy on startup.
Bug: 190556328
Test: atest FrameworksNetTests CtsNetTestCases TetheringTests
Change-Id: I2ba7b8f2b9e1c934cfb082776b8d643f2f2c17e5
BYPASS_INCLUSIVE_LANGUAGE_REASON=To make the change more clear,
fix the inclusive problem in a follow-up commit.
Bug: 176289731
Test: atest CtsHostsideNetworkTests:HostsideNetworkPolicyManagerTests
Change-Id: Ie6bda8570979b10a28dbeb20f6db7a9c44735964
