NsdManagerTest need to be updated because the older check was incorrect,
the new behavior should be observed on T when the compat flag is enabled
as well.
Test: m
Change-Id: I5d2e87b1ab5a114005a223e7ccd865540c0fdb78
Jarjar com.android.server* and adjust the test by jarjar
FrameworksNetTestsLib to make sure the test cases still can access
package sope fields. Don't auto-jarjar non-connectivity module tests
in FrameworksNetTests because some non-connectivity module test cases
rely on service.core and service.net. The reason why not auto-jarjar
whole ConnectivityCoverageTests because tethering doesn't adopt
auto-jarjar-gen yet. The coverage test must jarjar the same as module so
that test coverage can calculate correctly.
Remove com.android.server* from proguard becasue it already be covered
by android.net* after jarjar'ed.
Move MetricsTestUtil to non connectivity module test group because it
only be used for IpConnectivityEventBuilderTest which is non connectivity
module test. Only jarjar the util without jarjar the caller make the test
failure.
Bug: 248001529
Test: atest ConnectivityCoverageTests FrameworksNetTests
Change-Id: I8439341ef4c03f29697fdf34557ea8ef2825d691
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
(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
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 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
Gate presence of excluded routes in LinkProperties on target sdk T.
Bug: 186082280
Test: atest LinkPropertiesTest
Change-Id: If8fdb468a0a4968c5f2a878b7aacfeb4f7d9a9e5
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
The pre-jarjar variant is necessary so that service-t can depend on
hidden symbols in framework-t that reference (for example as parameter)
classes that are jarjared.
Without this, when depending on framework-connectivity-tiramisu.impl,
service-connectivity-t would see post-jarjar symbols that do not match
the classnames it uses in its code.
Also split FrameworksNetTestsLib so that the same jarjar rules can be
applied between the tests and the module, avoiding different errors
between FrameworksNetTests and ConnectivityCoverageTests.
Ignore-AOSP-First: Avoiding conflicts; cherry-pick will follow
Bug: 204830222
Test: m
Change-Id: I3d0c081c4a7422e128beee11c0156f01b0377c96
Merged-In: I3d0c081c4a7422e128beee11c0156f01b0377c96
The TEST_MAPPING file already contains a mainline-postsubmit
stanza, but according to go/test-mapping-mainline-user-guide
this information also needs to be in AndroidTest.xml (or in
Android.bp, for tests that are not covered by an AndroidTest.xml
and where soong autogenerates the test config).
Test: m bpf_existence_test
Change-Id: I103f5fefbfefa6fd2b59ab6c209fbf1dceada4ba
Apply their respective jarjar rules on tethering and general
connectivity tests, then merge both into the coverage tests suite.
This is necessary to ensure that classes covered by tests have names
matching classes used in code.
Also fix IpConnectivityLogTest to use the module utility instead of the
hidden BitUtils, as the test would fail after internal utils are
jarjared.
Bug: 187935317
Test: atest ConnectivityCoverageTests TetheringCoverageTests
Change-Id: Ib95b58dab93f7adebc445b662a6d15db1ce0e7c2
The test suite is not signed with any particular key so
can be in general-tests. This is also required for TEST_MAPPING.
Bug: 187935317
Change-Id: I9dbf98eaa28172a172e707091ea75ffdddd4971b
Test: TH for test mapping
When an AndroidTest.xml is used, configuration needs to be in the
AndroidTest.xml file, not in the Android.bp.
This currently causes tests not to be run in TEST_MAPPING as they should
be.
Test: TH needs to test
Bug: 187935317
Change-Id: Ie0aca0c64646825175769cd375bcecf65de4b4c8
Add the tests to both postsubmit and mainline-postsubmit.
This should allow moving the tests to presubmit in the near future,
after they have been verified to pass in postsubmit.
Bug: 187935317
Test: treehugger needs to test
Change-Id: I9a05d6a300c5f777497e867d0456bc59b06eee80
The coverage tests will allow measuring code coverage for all
Connectivity+Tethering code.
This is a combination of the current TetheringCoverageTests, and
FrameworksNetTests.
Adding min_sdk_version to the test prevents it from using deprecated
IoUtils utilities. Replace it with the non-deprecated alternative.
Test: atest ConnectivityCoverageTests
Change-Id: I5366e1cc9cd6ddb41f24718246381cc2b1cc1383
The build file currently holds a single build rule in test/. Move it to
the existing build file in tests/common/Android.bp.
(clean cherry-pick of history in downstream branch)
Test: m
Bug: 186628461
Merged-In: I3c2563d4ae4e3715d0c6270344ba8f7ef067872f
Change-Id: Ifa32681c0cdd2f6a70cb83a81cd7fec0f91824d1
The defaults follow the same pattern as framework-wifi-test-defaults to
allow unit tests to build against hidden API in Connectivity.
(clean cherry-pick of history in downstream branch)
Bug: 171540887
Test: m
Merged-In: I3c2563d4ae4e3715d0c6270344ba8f7ef067872f
Change-Id: Ia8531f672820fcc8968f98494903e486c4e42652
Move the tests together with packages/Connectivity code, so both can be
moved to packages/modules/Connectivity together.
Also reorganize unit tests in a unit/ directory, as other tests
(integration/, common/ etc.) have been added in tests/net since they
were created. This makes the directory structure consistent.
Test: atest FrameworksNetTests
Bug: 187814163
Merged-In: I254ffd1c08ec058d594b4ea55cbae5505f8497cc
Change-Id: I254ffd1c08ec058d594b4ea55cbae5505f8497cc
