This is useful to ensure cgroup bpf program is attached,
which would lead to hard-debugging uid stats missing problem.
Test: atest ConnectivityServiceIntegrationTest#testBpfProgramAttachStatus
Bug: 292156770
Change-Id: I16370497484aff29ed41cbb0d160e530731e1a4e
This sets up what is necessary for an instrumented
ConnectivityService to run. Users of this class are
meant to inherit CSTest.
This is still relatively basic and does not have all the
instrumentation in ConnectivityServiceTest. Developers
looking to extend CSTest may find some instrumentation
missing ; when they add the missing instrumentation,
they should consider whether it should be generic for all
CSTests (and put it in base/), or whether it's local to
their own test suite. This should enable faster testing
as each CSTest children will only need to set up the
instrumentation it actually needs.
This patch also migrates a basic test to have a first user.
Bug: 272685721
Test: ConnectivityServiceTest
CSBasicMethodsTest
Change-Id: I1c47f616af90629c9cb2a6ae89d992b19863e704
Fix kotlin nullable errors that were exposed by setting the retention
of android.annotation.NonNull and android.annotation.Nullable to
class retention.
Bug: 294110802
Test: builds
Change-Id: Id49e4a2ee0b7b463d99bce6eb22919b84c21443a
Move the test component configuration from subdirectories
to the common OWNERS file. This ensures that all test directories
like unit/ that did not have the component set are covered.
Bug: 288137916
Change-Id: I48fbe846309cace41588c5ff3dfd46e878c38576
Test: TH
The ConnectivityResources class is only usable with QUERY_ALL_PACKAGES
permission, so it is not generally usable in framework-connectivity. It
is also backed by the ServiceConnectivityResources APK, which is
intended as resources for service-connectivity.
Move the class to service-connectivity and update callers. CTS needs a
way to determine the supported keepalive count as it used the
resources from KeepaliveUtils as @hide API, so provide a
ConnectivityManager @hide API for testing.
Bug: 279108992
Test: atest
Change-Id: I3c9a77c580b5ab87c922c32778bce15dc33b4d1d
Instead of NetworkStackApiStableShims, use NetworkStackApiCurrentShims
as this is a development branch.
Use java_defaults in the "merge conflicts expected" section, so that
module release branches can use the same defaults, but set it to
NetworkStackApiStableShims.
The shims are removed from FrameworksNetIntegrationTests, as they are
already available there through service-connectivity-pre-jarjar. Keeping
them as a dependency would make FrameworksNetIntegrationTests use both
Stable shims (directly) and Current shims
(through service-connectivity-pre-jarjar).
Bug: 266205506
Test: m
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:921290b49d109360aae5dc39effaa3b0e691f65a)
Merged-In: I88228152834a1c06830fb51e868fb8e3d8c47519
Change-Id: I88228152834a1c06830fb51e868fb8e3d8c47519
The base method is capable of doing this in a clearer manner,
so this redundant method is no longer needed.
Test: ConnectivityServiceTest FrameworksNetIntegrationTests
Bug: 157405399
Change-Id: I5f801d3c66374096fe7be7be21ee8d80264cd693
Test: FrameworksNetTests
adb shell device_config put connectivity actively_prefer_bad_wifi
+ check that dumpsys updates
Test: at this patchset tests fail with :
Permission denial: reading from settings requires:android.permission.READ_DEVICE_CONFIG
Change-Id: Icfe1e64b8313921ff1dc8e4cbd45f967692e1c4a
This is necessary so that MultinetworkPolicyTracker can see
DeviceConfig. It will also allow removing reflection from
this file to address a long-standing TODO.
Test: build
Change-Id: I968bf67e0e0189b01515242371599c02bc9e2ca2
Rename the service to the com.android.networkstack package, which does
not get jarjared and avoids confusing naming in manifests.
This is not an exported service, so it cannot have dependencies outside
of NetworkStack and its tests.
Test: atest FrameworksNetIntegrationTests
Change-Id: I86c1bbf3e468db1445132f4985a549226dfbae64
ConnectivityServiceTest#testNetworkAgentCallbacks tests the
behaviour of the NetworkAgent callbacks onNetworkCreated,
onNetworkUnwanted, and onNetworkDestroyed. This uses a
NetworkAgentWrapper method that sets the callbacks after the
test agent is constructed.
This infrastructure not sufficient to test an upcoming change
which will make onNetworkCreated be fired as soon as the
registration onNetworkCreated is fired as soon as the agent is
registered. Fix the code so that the callbacks can be specified
at agent registration time. This is also a bit more realistic
since in real usage, the callbacks are methods on the
NetworkAgent subclass and are already set when the agent is
constructed.
Bug: 143158421
Test: test-only change
Change-Id: I53c58e7b6c6ae4abf08e0df5051694cc4568a510
Following CLs will switch previous codepath (JNI) and new codepath
(Java) for bpf map operations based on this flag.
Bug: 217624062
Test: atest BpfNetMapsTest
Change-Id: I74f10d5c97390993acea110f6528ef8980bb2aa4
(This rolls forward part of a previous change, now that jarjar was fixed
to not get very slow when the number of rules increases).
Autogenerate connectivity jarjar rules at build time, to avoid issues
with forgotten jarjar rules or hard-to-diagnose errors introduced by
incorrect rules.
This change causes all classes in framework-connectivity(-t) and
service-connectivity to be jarjared into android.net.connectivity, but
still avoids jarjaring classes in com.android.server as before, to keep
it small.
For many classes this differs from the original jarjar rule.
Notes on implementation:
- connectivity-jarjar-rules now has a subset
framework-connectivity-jarjar-rules containing only the rules
necessary for framework-connectivity. This is necessary because
framework-connectivity cannot depend on rules generated based on
service-connectivity, as there would be a dependency cycle
(service-connectivity depends on framework-connectivity); Soong even
crashes with a stack overflow.
- framework-wifi.stubs.module_lib is added to
framework-connectivity-pre-jarjar as it is necessary to build it (it
is already in impl_only_libs in the defaults).
It is unclear why framework-connectivity-pre-jarjar could build
before that (possibly because it was only used as "lib" ?)
- Fix package-private visibility; for example NattSocketKeepalive,
TcpSocketKeepalive are not API so should be jarjared, but are used
by ConnectivityManager which is not jarjared, so they are not in the
same package after the change. Package-private members in the
former 2 need to be public to be accessible. Changes in this commit
are all that is needed, as demonstrated by followup commits that move
the classes to a different package without further changes, and that
enforce that no class in an API package gets jarjared.
- framework-connectivity-internal-test-defaults is separated from
framework-connectivity-test-defaults, for unit tests that need to
access internal jarjared classes. Such tests need to use the jarjar
rules themselves too, so this is only appropriate for connectivity
internal unit tests.
Test: atest ConnectivityCoverageTests CtsNetTestCases
Bug: 217129444
Change-Id: Ib1bd939b71c0171d945fc01b96195d2f620ff13b
(cherry picked from commit 4ceb8c1f25)
When building against prebuilts some dependencies on
service-connectivity get replaced by the prebuilts which does not have
an implementation library and so it breaks.
If it was a java_sdk_library that would be handled automatically but
it is just a java_library.
Bug: 223592962
Test: m FrameworksNetSmokeTests FrameworksNetTests FrameworksNetIntegrationTests
# Fails when building from prebuilts without this change works with this change.
Merged-In: Ib2fbd3c7703e9ed606650643db6e1977f550d90d
Change-Id: Ib2fbd3c7703e9ed606650643db6e1977f550d90d
This reverts commit 53eb35cd82.
Reason for revert: b/233081774, caused long build times in FrameworkNetTests
Change-Id: Ide01c994f694b55fc0e87bb0e81584ac44196e68
Jarjar rules are hard to keep in sync with code, and hard to maintain
manually as the distinction between what should and should not be
jarjared is not always clear. This results in unsafe binaries that are
manually maintained, and developer frustration when something fails due
to incorrect jarjar rules.
Autogenerate jarjar rules at build time instead. This is achieved by
introducing a jarjar-rules-generator python-based library, which scans
pre-jarjar intermediate artifacts, and outputs jarjar rules for every
class to put it in a package specific to the module. The only exceptions
are:
- Classes that are API (module-lib API is the largest API surface of
the module)
- Classes that have unsupportedappusage symbols
- Classes that are excluded manually (for example, because they have
hardcoded external references, like for
ConnectivityServiceInitializer in SystemServer).
This change causes all classes in framework-connectivity(-t) and
service-connectivity to be jarjared into android.net.connectivity, but
still avoids jarjaring classes in com.android.server as before, to keep
it small.
For many classes this differs from the original jarjar rule.
Notes on implementation:
- connectivity-jarjar-rules now has a subset
framework-connectivity-jarjar-rules containing only the rules
necessary for framework-connectivity. This is necessary because
framework-connectivity cannot depend on rules generated based on
service-connectivity, as there would be a dependency cycle
(service-connectivity depends on framework-connectivity); Soong even
crashes with a stack overflow.
- framework-wifi.stubs.module_lib is added to
framework-connectivity-pre-jarjar as it is necessary to build it (it
is already in impl_only_libs in the defaults).
It is unclear why framework-connectivity-pre-jarjar could build
before that (possibly because it was only used as "lib" ?)
- Fix package-private visibility; for example NattSocketKeepalive,
TcpSocketKeepalive are not API so should be jarjared, but are used
by ConnectivityManager which is not jarjared, so they are not in the
same package after the change. Package-private members in the
former 2 need to be public to be accessible. Changes in this commit
are all that is needed, as demonstrated by followup commits that move
the classes to a different package without further changes, and that
enforce that no class in an API package gets jarjared.
- framework-connectivity-internal-test-defaults is separated from
framework-connectivity-test-defaults, for unit tests that need to
access internal jarjared classes. Such tests need to use the jarjar
rules themselves too, so this is only appropriate for connectivity
internal unit tests.
Test: atest ConnectivityCoverageTests CtsNetTestCases
Bug: 217129444
Change-Id: Ied17c3955ea2fda130089265d02908937ad8af1e
Test: New tests in this patch
also FrameworksNetTests
Test: atest CtsNetTestCases CtsNetTestCasesLatestSdk
Change-Id: I68aa5201ad94531e5a40999816844faef5531525
NetworkStatsFactory is moving from services.core to
service-connectivity-tiramisu. Update FrameworksNetSmokeTests and
FrameworksNetIntegrationTests to depend on the latter instead of the
former.
Test: atest FrameworksNetSmokeTests FrameworksNetIntegrationTests
Ignore-AOSP-First: part of large internal topic to avoid merge conflicts
(cherry-picked from ag/16786005)
Change-Id: Ie48dac421decf83440b7c88adea18152e05f03bb
Merged-In: Ie48dac421decf83440b7c88adea18152e05f03bb
Allow framework-connectivity to depend on framework-connectivity-t
stubs, and framework-connectivity-t to depend on prebuilt (to avoid
circular dependencies) framework-connectivity stubs to compile its own
stubs, and framework-connectivity.impl to compile its implementation.
Also reorganize jarjar rules so that service and framework jar can use
static libraries in framework-connectivity without packaging their own,
reducing duplicate code.
Bug: 204830222
Test: m
Change-Id: I75c34986e7c479de23cdb2e9b360fa1fede018c9
Add libcom_android_connectivity_com_android_net_module_util_jni
to the JNI libraries for FrameworksNetIntegrationTests. This is
needed for service code (e.g., ConnectivityService,
DscpPolicyTracker) to use JNI.
Test: atest FrameworksNetIntegrationTests
Change-Id: Iebe7ef31057c7a3b10bd7bad42ca74a25fe24473
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
When the avoidBadWifi configuration is false and not overridden,
a WiFi network that was validated in the past but becomes
unvalidated needs to outscore a cell network that is validated.
This is happening correctly when the stack compares two networks.
However, when the stack compares an existing network to an offer
for a cellular network, the offer was automatically considered
not to yield. This would mean the stack would be requesting cell
out of the telephony factory, only for that network to lose to
WiFi and be discarded immediately, then recreated again etc.
When there is some other reason cell should be up (such as the
"mobile always on" setting being active), this would not be
visible because the cell network would have another reason not
to be torn down.
Have offers correctly account for the current value of the
configuration and setting. This has the ranking of the offer
lose against WiFi like the actual network loses, meaning the
offer is not needed.
This also requires updating the offers whenever the value of
the setting changes.
Test: new test for this, also ConnectivityServiceTest
Bug: 195441367
Change-Id: I4fe5de98bc15bcf9bbbe25c6c7c8a7ba382f8db7
The resources may have different values depending on devices, and
resources IDs may mismatch if the test was not built at the same time as
the installed module, so mock the resources to allow running the
integration tests on more builds.
Bug: 193847396
Test: atest FrameworksNetIntegrationTests
Merged-In: Ic33d897690a8ea84a78c01dc5f2b2e2c473d57df
Change-Id: Ic33d897690a8ea84a78c01dc5f2b2e2c473d57df
The resources may have different values depending on devices, and
resources IDs may mismatch if the test was not built at the same time as
the installed module, so mock the resources to allow running the
integration tests on more builds.
Bug: 193847396
Test: atest FrameworksNetIntegrationTests
Ignore-AOSP-First: cherry-pick created
Change-Id: Ic33d897690a8ea84a78c01dc5f2b2e2c473d57df
Instead, use a dedicated MockConnection class.
This should improve performance of the test, and works around failures
where mockito crashes when creating mocks when openConnection is called.
The failures are believed to be a bug in mockito-extended, but are not
likely to be fixed soon.
Bug: 185083316
Test: atest FrameworksNetIntegrationTests
Change-Id: I32deaaaaa5ce9876611314c8e8b9d8bdd6325df0
This ensures classes are used from the service-connectivity jar, instead
of using classes from the system_server bootclasspath when there is a
name conflict.
Any developer adding a future class should do so in a subpackage of
com.android.connectivity (such as com.android.connectivity.server).
Otherwise, jarjar rules need to be added manually until b/180995093 is
fixed.
Also update current jarjar rules so that classes are jarjared to
com.android.connectivity.[original name], making it easier to find the
original source. This is consistent with the wifi module.
Bug: 193086215
Test: atest CtsNetTestCases
dexdump on service-connectivity.jar shows no classes outside of
com.android.connectivity and com.android.server
Original-Change: https://android-review.googlesource.com/1759589
Merged-In: I2aadeca32751267b74d4fd2fd93bb3e8c62e46c0
Change-Id: I2aadeca32751267b74d4fd2fd93bb3e8c62e46c0
This ensures classes are used from the service-connectivity jar, instead
of using classes from the system_server bootclasspath when there is a
name conflict.
Any developer adding a future class should do so in a subpackage of
com.android.connectivity (such as com.android.connectivity.server).
Otherwise, jarjar rules need to be added manually until b/180995093 is
fixed.
Also update current jarjar rules so that classes are jarjared to
com.android.connectivity.[original name], making it easier to find the
original source. This is consistent with the wifi module.
Bug: 193086215
Test: atest CtsNetTestCases
dexdump on service-connectivity.jar shows no classes outside of
com.android.connectivity and com.android.server
Change-Id: I2aadeca32751267b74d4fd2fd93bb3e8c62e46c0
Certain network types, like the VCN, have underlying
networks for the purpose of data usage, but do not want to
propagate the underlying network capabilities.
Allow these networks to set underlying networks, but continue
not to propagate the capabilities.
Bug: 190620024
Test: new unit test
Original-Change: https://android-review.googlesource.com/1753619
Merged-In: I53d6080f48707ff3c37fbfbef534284ba77a7432
Change-Id: I53d6080f48707ff3c37fbfbef534284ba77a7432
Certain network types, like the VCN, have underlying
networks for the purpose of data usage, but do not want to
propagate the underlying network capabilities.
Allow these networks to set underlying networks, but continue
not to propagate the capabilities.
Bug: 190620024
Test: new unit test
Change-Id: I53d6080f48707ff3c37fbfbef534284ba77a7432
At this stage, this is turned off. Unit tests will be
in a followup change.
Test: In a followup
Bug: 167544279
Merged-In: I3c2563d4ae4e3715d0c6270344ba8f7ef067872f
Merged-In: I4448a3546fbc1a3dddf757982c031c5f39ba2889
Change-Id: I4448a3546fbc1a3dddf757982c031c5f39ba2889
(cherry-picked from ag/14010222 with fixes)
This exposes a mechanism for network providers to tell
the network stack that a given network must be kept up
for some specific reason. This is meant to be easier
for them than to have to file a request, in particular
because there is no guaranteed way to make sure the
request will be best matched by any given network.
Test: new test for this
Bug: 167544279
Merged-In: I3c2563d4ae4e3715d0c6270344ba8f7ef067872f
Merged-In: I238a3ee5ee9262477a23b897e4141769dd1505d1
Change-Id: I238a3ee5ee9262477a23b897e4141769dd1505d1
(cherry-picked from ag/13929760)
Netd should be obtained via getSystemService, and
ModuleNetworkStackClient must be used instead of NetworkStackClient for
modules.
Original change (project moved):
Ibe703ac56dd70673115cd8b95b44b856a7fc01f3
Bug: 171540887
Test: m
Merged-In: I3c2563d4ae4e3715d0c6270344ba8f7ef067872f
Change-Id: I6c8593712c0e86da139d425ef6240c5004e392e2
