Currently, mSubscriberIdMatchRule is only used in NetworkTemplate
and it depends on if mMatchSubscriberIds is empty or not. Thus,
remove it since is not really necessary and replace it with
checking matchSubscriberIds if needed.
Bug: 238843364
Test: build, FrameworksNetTests
CtsNetTestCases
Change-Id: Ic66d2ff2826846778b004bb15a4718a62fa1f470
Add VpnTransportInfo.areLongLivedTcpConnectionsExpensive() in API
surface to allow privileged apps to know whether the long-lived
TCP connections should be expensive in the VPN network.
This is expected to be used combined with getBypassable()
because connections should always go through a VPN that is not
bypassable.
Bug: 259000745
Test: atest FrameworksNetTests
Change-Id: Ic9bcdf43f252f22d12a1136902cc8bbf9cc731f5
In current design, mMatchSubscriberIds can be null which has the
same meaning with empty set, and is not easy to maintain since it
need more checks for this variable when mSubscriberId is null.
Thus make mMatchSubscriberIds NonNull for the maintenance.
Bug: 238843364
Test: build, FrameworksNetTests
Change-Id: I6cfc529b5f4a39ded8598283ff968f2f4d1bc89f
Move VpnTransportInfoTest to common test to add the cts
coverage.
Annotate @ConnectivityModuleTest so that the test will
not fail with module that is not up-to-date, and use
assertParcelingIsLossless to prevent similar order module
in device case.
Bug: 256775913
Test: atest CtsNetTestCases:android.net.VpnTransportInfoTest
Change-Id: I1c40a4fc42468748d71c3df5c18b2ceb5b3769e1
(these are never called, but must exist for API reasons)
Bug: 257393783
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I2f1cb29c5176539abe25bf767997ab4ed5eca6de
Maciej Żenczykowskicommited 2022-11-04 11:43:22 +00:00
This will be useful for diagnosing default network changes.
Logs may look like, for example :
Update capabilities for net 100 : -NET_CAPABILITY_OEM_PAID+NET_CAPABILITY_TRUSTED
Or :
Update score for net 100 : -POLICY_EVER_EVALUATED+POLICY_IS_VPN+POLICY_IS_DESTROYED
Test: FrameworksNetTests
manual
Change-Id: Ic4788c599573aae9daeca995b8853800aaaba0b8
The test does not wait for sending all log events done, just
check the total received event number after 200ms. If one of
thread is running slowly, the test would be flaky. Thus, use
the Thread#join() to ensure the log events sending out
completely.
Bug: 245005401
Test: atest CtsNetTestCases
Change-Id: I90ad6960453c4639b6429a2e36e35d2d53148131
Currently these tests run as hostside tests and require a lot of
boilerplate, including their own CtsHostsideNetworkTestsApp3
build target.
Move the coverage to LinkPropertiesTest using the new-ish
@CtsNetTestCasesMaxTargetSdk31 annotation, and remove the
hostside tests.
The only test that is not being moved is one that checks the
behaviour of disabling the compat change on T. This test is not
very useful because it can only run on userdebug builds and not
on production builds, because CtsHostsideNetworkTestsApp3 targets
SDK 33. We do have test coverage for disabling the compat change
on an app targeting SDK 31, where it is allowed.
Fix: 236087258
Test: atest CtsNetTestCasesMaxTargetSdk31
Test: atest CtsNetTestCasesLatestSdk:android.net.LinkPropertiesTest
Change-Id: I6d4b1ba40f6cb63b30a600c227e9628858c03d73
Lorenzo Colitticommited 2022-07-22 17:53:55 +09:00
Currently, ConnectivityCoverageTests is manually set to target
SDK 31. This is different from CtsNetTestCasesLatestSdk, and
CtsTetheringTestLatestSdk, which are set to 33 and 31
respectively. Set all of them to 33 via a defaults clause.
ConnectivityCoverageTests must have the same target SDK as CTS
because it includes many of the CTS tests (e.g., everything in
common/).
Bug: 236087258
Test: atest ConnectivityCoverageTests
Test: atest CtsNetTestCasesLatestSdk
Test: atest CtsTetheringTestLatestSdk
Change-Id: I88c16dc28d9b73557def25d7f669ed14ae9d360a
Lorenzo Colitticommited 2022-07-22 13:08:39 +09:00
(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
Revert the previous change to filter out all non-RTN_THROW routes when
EXCLUDED_ROUTES is disabled, as that behavior is CTS tested for T, and
has been used by T for a while. The previous change already ensured that
there is no behavior change on S, so this is the safest approach.
This fixes HostsideLinkPropertiesGatingTests.
Bug: 239046959
Test: atest LinkPropertiesTest CtsHostsideNetworkTests
Change-Id: I55e078cdc06341f4957fe7bc743c0022b2c7d3da
Starting from T, VpnService supports exclude routes, which will
make the caller to get both of include routes and exclude routes
from LinkProperties#getRoutes(), and it's not expected to get the
exclude routes before T in production code even though the code
returns all routes.
But there is a CTS - LinkPropertiesTest#testRouteAddWithSameKey()
will try to add an exclude route and check if the result of
LinkProperties#getRoutes() contains that exclude route or not.
And the test is failed now since LinkProperties#getRoutes() will
only return include route if compat feature - EXCLUDED_ROUTES is
disabled. (EXCLUDED_ROUTES is enabled starting from target SDK T)
To fix this test failure, let LinkProperties#getRoutes() keeps
returning all routes if SDK is before T. This avoids changing
behavior on S, and even though there is still a behavior change
when upgrading to T, apps are unlikely to be relying on such
behavior, especially outside of tests.
Bug: 238061814
Test: Run "atest CtsNetTestCases:LinkPropertiesTest" on S build
with mainline module which contains this patch.
Change-Id: Iac4362c4fe347ee3f06d5b21b0325fa69a7f27b6
The tests fail on user builds because they target T and attempt
to override the compat change, which is not allowed on user
builds because the change defaults to on for apps targeting T+.
Fix this by marking the tests max target SDK 31.
Also improve the tests a bit:
- Use a RuleChain to make it explicit that
CtsNetTestCasesMaxTargetSdk31 should be evaluated before
EnableCompatChanges (otherwise the compat change rule would
crash on user builds even if the max target SDK rule was going
to skip the test anyway).
- Fix the IgnoreUpTo for all exclude route tests to say S+.
Currently:
- One says R+, which is incorrect because the updated
LinkProperties code is in the connectivity module, which only
goes back to S, not R.
- The others say T+, which is incorrect because the update code
is present on S.
Fix: 233553525
Test: LinkProperties test in CtsNetTestCasesLatestSdk passes on T user build
Test: LinkProperties test in CtsNetTestCasesMaxTargetSdk31 passes on T user build
Change-Id: Ie0e2f6761b90a65813ed3610c7b5e930a9fdc982
Lorenzo Colitticommited 2022-06-13 02:01:35 +00:00
NetworkStatsHistory internally assumes that bucketStart is
sorted at all times. However, in the fields, we've found there
are some buckets of NetworkStatsHistory do not preserve the
order of timestamp, which is caught by the IAE when addEntry
is called.
In order to provide backward compatibility, return sorted items
instead of throwing IAE when adding entry into
NetworkStatsHistory instance.
Test: atest android.net.netstats.NetworkStatsHistoryTest#testBuilder
Bug: 233825704
Change-Id: If3187384bd1e90770ca5873b8ec73e852fff543d
Merged-In: If3187384bd1e90770ca5873b8ec73e852fff543d
(pure cherry-picked from ag/18581718)
* changes:
Skip PersistentIntTest on S- device
Don't clobber existing history entries.
Ensure NetworkStats migrated snapshot is identical
[MS82.1] Support network stats data migration process
Add a PersistentInt class.
Natasha Leeauthored and Gerrit Code Reviewcommited 2022-06-01 03:03:02 +00:00
Tethering downstreams do not have NetworkAgents, and although they have
a netid of 99, Networks with netId 99 are not usable by apps for most
connectivity APIs.
Recent refactoring in NsdService adds the Network of a found service
into its NsdServiceInfo, and uses that network to resolve the service.
In that case the Network has netId 99 and resolving the service fails.
Avoid that problem by:
- Keeping the Network field null when a service is found on a tethering
downstream; this avoids giving apps a confusing and unusable Network
with netId 99
- Using the interface index found during discovery to resolve the
service, if the app uses the NsdServiceInfo that was obtained from
discovery to resolve. If not, all interfaces will be used to resolve,
as per legacy APIs.
Bug: 233979892
Test: atest NsdServiceTest
Also manual test with 2 devices connected via hotspot
Change-Id: Idd176153b67ccbd1d4f1b1fd66dafaa2f3a9e27a
This test crashes if run from an APK that has target SDK 33 or
above because it tries to disable a compat change that on those
SDK versions is enabled by default.
Run it only in CtsNetTestCasesMaxTargetSdk31 and skip it in our
regular CTS modules.
Bug: 233553525
Test: test-only change
Change-Id: Iaf9c46591c13505c9d2a2a09994b9ee22a22390c
Lorenzo Colitticommited 2022-05-30 23:36:23 +09:00
Currently, adding a history to a NetworkStatsCollection.Builder
will overwrite any history that was previously passed in with the
same key. This breaks the importer (which is the primary/only
caller of this code), because the importer re-uses the same
NetworkStatsCollection object to import multiple files.
Instead, simply add any passed-in entries after the ones that
were already there. Require the caller to pass in entries in
order, because NetworkStatsHistory internally assumes that
entris are always sorted.
Bug: 230289468
Test: manually verified this unbreaks the importer
Change-Id: Ic8647ff28fca78d579d5f759f96a864877f8158b
Merged-In: Ic8647ff28fca78d579d5f759f96a864877f8158b
(pure cherry-picked from ag/18453213)
Lorenzo Colittiauthored and Junyu Laicommited 2022-05-24 11:37:42 +08:00
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 update for renaming InternalNetworkManagementException to
EthernetNetworkManagementException.
Bug: 210485380
Test: atest FrameworksNetTests
Change-Id: I8b48655dc090eecda1dfd0542092308036fe6da7
NetworkIdentitySet is hidden API and may change on subsequent module
updates.
Use the module_lib NetworkStatsCollection.Key constructor that uses a
set of NetworkIdentity instead.
Bug: 217129444
Test: atest NetworkStatsCollectionTest
Change-Id: Icd1160ae920059306c3319f7298707f1e14cbb48
TestOnly flag allows the test to read restricted @Readable setting
ALWAYS_ON_VPN_LOCKDOWN_WHITELIST.
BUG: 177239688
Test: atest com.android.server.ConnectivityServiceTest
Change-Id: If41708ad31de9cec3a102b4de4d237e96a448ef1
- Skip NetworkCapabilitiesTest on Q. The test covers code that is very
localized in NetworkCapabilities.java, and is only updatable on S+,
so does not need to be in MTS before that.
- Fix ConnectivityManagerTest to remove external references to
CaptivePortalData instances in the lambdas, as this is compiled into
a method taking CaptivePortalData as argument, and because the class
does not exist on Q, the test runner would crash enumerating method
arguments.
- Remove call to getSystemService(ETHERNET_SERVICE) on Q from the test
thread, as it will crash when called from a thread that does not have
a Looper.
Test: atest CtsNetTestCases
Bug: 227253613
Change-Id: I97c64b24c767e874dfba00aa1f46be2c4972f917
Gate presence of excluded routes in LinkProperties on target sdk T.
Bug: 186082280
Test: atest LinkPropertiesTest
Change-Id: If8fdb468a0a4968c5f2a878b7aacfeb4f7d9a9e5
Add Sdk30ModuleController to ConnectivityCoverageTests and
connectivity_native_test, as they cover code in the Tethering module,
which is R+.
Test: atest ConnectivityCoverageTests connectivity_native_test
Change-Id: Ida573d4e231bf29989f699a9fef77d3a677425c8
ConnectivityCoverageTests is a combination of several test libs, which
are jarjared differently. It causes duplicated classes not to be counted
for coverage properly. Build the test suite directly and apply jarjar
only once on top of everything.
Bug: 227694415
Test: atest ConnectivityCoverageTests
Change-Id: I4350ebdbf98030944ec3857e1ef67d76f26c3b16
markchienauthored and Remi NGUYEN VANcommited 2022-04-06 19:35:28 +09:00
Aaron Huang
commited 
chiachangwang
authored and
Maciej Żenczykowski
commited 
Chalard Jean
commited 
Paul Hu
commited 
Lorenzo Colitti
authored and
Gerrit Code Review
commited 
Treehugger Robot
authored and
Remi NGUYEN VAN
commited 
Junyu Lai
commited 
Natasha Lee
authored and
Colin Cross
commited 
preranap
authored and
James Mattis
authored and
Songchun Fan
commited 
Taras Antoshchuk
authored and
markchien
authored and
Sooraj Sasindran
commited