Connectivity's metalava invocation does not depend on framework-wifi,
so these references fail to resolve, and as a result metalava currently
removes the import.
Fully qualify the references instead, to avoid both metalava trying
to resolve the dependency, and having to depend on framework-wifi just
for javadoc.
Bug: 186197911
Test: build the sdk (with connectivity module stubs as input)
Change-Id: I7129821b9a0d08d06f8e977a3c17fa5f5f6f9cee
Instead of crashing when parceling the NetworkInfo object,
crash at the time the bad call is made.
Bug: 145972387
Test: FrameworksNetTests
Change-Id: If8b5fd3d7b800c97211bcd16c9a8c5812708d4ab
Chalard Jeanauthored and paulhucommited 2021-10-19 16:43:50 +08:00
Now, VPN will set underlying networks into NetworkCapabilities
directly. So the declaredUnderlyingNetworks can also be set
directly when creating a NetworkAgentInfo.
Bug: 191918368
Test: atest FrameworksNetTests:ConnectivityServiceTest
Change-Id: I507072d00ae1eb0c391e5261ab93e359b9c4cb5c
Previously, the caller can only know about the transport type of
the underlying network. The information might not be enough if
the device support WiFi STA+STA.
Thus, provide an API for the caller to get the correct underlying
network.
Bug: 191918368
Test: atest FrameworksNetTests:NetworkCapabilitiesTest
Change-Id: I7752b2356770f4572f6ca4cbaecaa45c09d6d72f
The registered listeners are added into internal ArrayMap as a
reference but are not removed when the listeners are
unregistered. The actions for registration should be done in
pairs.
Test: atest FrameworksNetTests
Change-Id: Id9e674f5104d1471dd81224b6a271a8a92172e34
Upon changing the default SIM card, the radio will create a
new connection to the new subscription. If that subscription
works correctly, the stack will prefer it to the old one as
the new subscription will be marked with a Primary policy
flag it its score.
Normally, at this point the old network lingers to give apps
an opportunity to gracefully migrate their connections. But
with some radios, this may have a dramatic effect on the
performance of the new connection.
This patch introduces a flag so that devices with such radios
can be marked. In this case the stack will move to a degraded
mode and eschew the grace delay for apps and give them a hard
break instead, so that the new network can reach a good
performance immediately. Apps with existing connections will
suffer a worse experience.
If there is a request that can only be served by the old
connection, still keep it, as arguably the user still
expects their MMS be sent on the old connection, even if the
new connection doesn't work well until it's done.
Test: new test in this patch, and add relevant tests in both modes
also manually change the value of the flag and run
FrameworksNetTests and CtsNetTestCasesLatestSdk
Bug: 200226979
Change-Id: I4ace82f90e873bf06298cc689bb1d794ed5124bd
The removeDefaultNetworkActiveListener should do the
unregisteration but it's incorrectly calling
registerNetworkActivityListener into the ConnectivityService.
Bug: 199753782
Test: atest FrameworksNetTests CtsNetTestCases
Change-Id: I65a2ddc82989d736316d51f5058e707f5b261a82
The test actually verifies multiple behaviors and mutates the
networkCapabilities. Thus, refactor the method to keep the
tests easier to follow up.
Bug: 191918212
Test: atest android.net.NetworkCapabilitiesTest
Change-Id: Ibad1a0569d26d92f94153bee323cef5a1c30d8d4
restrictCapabilitiesForTestNetwork was renamed after S release to be
included in a mainline release, but this causes the MTS test to fail on
S if the Connectivity module is not updated, and CTS to fail if the
connectivity module is updated.
Mark the test as @ConnectivityModuleTest so it can be skipped on
non-connectivity module MTS tests (such as NetworkStack tests), and add
back the previous method name to keep CTS passing.
Bug: 196755836
Test: atest NetworkCapabilitiesTest
Change-Id: Ibd6c2e62e5949ec6d93e9f6e4fc05129c29b94f8
The check intends to do the bit & operation. The net cap value
should be shifted against the original capabilities.
Also fix the typo in the method name.
Bug: 191918212
Test: atest FrameworksNetTests
Change-Id: I98396b2538f36fe8b29d27a544a2dfb3060bc9c5
Log should print the taken parameter instead of the value of
current variable
Test: m
Bug: 192149168
Change-Id: Ia3b9e607fe8b661a7faea3b46b9697fa85016440
In order to make ConnectivityService the mainline module in ANDROID 12,
The earliest ConnectivityService API getActiveNetworkForUid was exposed.
But after that public api getActiveNetworkForUid and all callers
(Outside the module) has been deleted or replaced in android 12
version. So we should delete the public API in AOSP to keep the APIs
of Android 12 & AOSP consistent and also avoid using it again in AOSP.
The commit is equivalent to ag/14029494, but done in a different repo.
Bug: 183465229
Test: atest ConnectivityControllerTest
Merged-In: I3c2563d4ae4e3715d0c6270344ba8f7ef067872f
Change-Id: I50a39d6391c88bbb914a63fdb17bae6851591c01
- Add a new transport type for USB and a new network capability
to support automotive head unit.
- In order to pass DnsManagerTest#testTransportTypesEqual, Android.bp
needs to link to dnsresolver_aidl_interface-V8-java. That test checks
whether the TRANSPORT types defined in NetworkCapabilities are the
same as IDnsResolver.aidl.
(clean cherry-pick of change in downstream branch history, original
change ID before project move:
Iec2df09a776d779108f95098e01b7ffdf6f8867a)
Bug: 181742019
Test: atest FrameworksNetTests
Merged-In: I3c2563d4ae4e3715d0c6270344ba8f7ef067872f
Change-Id: Ie438ec68577ebdaaf990795fa27f1169b0105411
lucaslinauthored and Remi NGUYEN VANcommited 2021-07-08 09:44:39 +09:00
Core platform API stubs are now correctly included in module_current and
system_server_current, so workarounds used to use such APIs can be
removed.
OsCompat and InetAddressCompat were only necessary because manually
adding the stubs did not resolve the problem for classes that had
public API stubs, which shadowed the module API stubs.
The manual stubs dependency was already removed in another change. Also
remove the service jar dependency on android_system_server_stubs_current
as it is already included in sdk_version system_server_current.
Bug: 183097033
Test: atest CtsNetTestCases
Original-Change: https://android-review.googlesource.com/1754889
Merged-In: Id448be03b679f832edb24f1b77f471227faf5268
Change-Id: Id448be03b679f832edb24f1b77f471227faf5268
Core platform API stubs are now correctly included in module_current and
system_server_current, so workarounds used to use such APIs can be
removed.
OsCompat and InetAddressCompat were only necessary because manually
adding the stubs did not resolve the problem for classes that had
public API stubs, which shadowed the module API stubs.
The manual stubs dependency was already removed in another change. Also
remove the service jar dependency on android_system_server_stubs_current
as it is already included in sdk_version system_server_current.
Bug: 183097033
Test: atest CtsNetTestCases
Change-Id: Id448be03b679f832edb24f1b77f471227faf5268
Avoid bad wifi design has to apply in both wifi and cellular
networks. Cellular network should contain POLICY_YIELD_TO_BAD_WIFI
policy, then system default network could stay in the wifi after
wifi becomes unvalidated.
The testing API only update the value but not trigger the avoid
bad wifi callback to update the score in the existing cellular
network. Thus, if the cellular network is connected before
setting the overridden value, the yield to bad wifi policy will
not updated to cellular network. The system default network will
still switch from unvalidated wifi network to cellular network
even wifi network is connected with the avoid bad wifi policy.
Update to trigger a reevaluation to update the score in each
NetworkAgent in the ConnectivityService.
Bug: 192149168
Test: atest CtsNetTestCases:android.net.cts.ConnectivityManagerTest\
#testSetAvoidUnvalidated --rerun-until-failure 100
Original-Change: https://android-review.googlesource.com/1751588
Merged-In: Ie0f777d0030b66dd306332496192c74f6c183284
Change-Id: Ie0f777d0030b66dd306332496192c74f6c183284
Avoid bad wifi design has to apply in both wifi and cellular
networks. Cellular network should contain POLICY_YIELD_TO_BAD_WIFI
policy, then system default network could stay in the wifi after
wifi becomes unvalidated.
The testing API only update the value but not trigger the avoid
bad wifi callback to update the score in the existing cellular
network. Thus, if the cellular network is connected before
setting the overridden value, the yield to bad wifi policy will
not updated to cellular network. The system default network will
still switch from unvalidated wifi network to cellular network
even wifi network is connected with the avoid bad wifi policy.
Update to trigger a reevaluation to update the score in each
NetworkAgent in the ConnectivityService.
Bug: 192149168
Test: atest CtsNetTestCases:android.net.cts.ConnectivityManagerTest\
#testSetAvoidUnvalidated --rerun-until-failure 100
Change-Id: Ie0f777d0030b66dd306332496192c74f6c183284
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
Original-Change: https://android-review.googlesource.com/1733788
Merged-In: If772078c61a9b12926f104d5dfc9c9071e844732
Change-Id: If772078c61a9b12926f104d5dfc9c9071e844732
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
Original-Change: https://android-review.googlesource.com/1719017
Merged-In: I3272c825b86ec30c3d0bf4097088c653e668461b
Change-Id: I3272c825b86ec30c3d0bf4097088c653e668461b
Lucas Linauthored and Remi NGUYEN VANcommited 2021-06-22 09:24:37 +00:00
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
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
Original-Change: https://android-review.googlesource.com/1736505
Merged-In: I2ba7b8f2b9e1c934cfb082776b8d643f2f2c17e5
Change-Id: I2ba7b8f2b9e1c934cfb082776b8d643f2f2c17e5
Anton Hansson
authored and
Gerrit Code Review
commited 
Lucas Lin
authored and
Chalard Jean
authored and
paulhu
commited 
Automerger Merge Worker
commited 
Chiachang Wang
authored and
Xin Li
authored and
Android (Google) Code Review
commited 
Remi NGUYEN VAN
commited 
Treehugger Robot
authored and
lifr
commited 
Orion Hodson
authored and
Victor Chang
commited