This commit follows the guideline in go/ae-v-thread-admin-control that
Thread radio should be disabled when the user restriction is set and
nobody can enable Thread again (it fails with
ERROR_FAILED_PRECONDIFITION).

This commit adds only unit tests, E2E CTS tests are tracked in b/319079428

Bug: 319077876
Change-Id: I8981aa9e71948c64ee79701427ac794880826327

If sdk_version is empty, by default the library will be built against
the implementation of the framework jars. There are on going project to
automatically repackaging flag libraries in the libray which is built
direactly against the implementation of the framework jars.

This change set the right sdk_version for the testing library.

Bug: 310504781
Test: atest jarjar-rules-generator-test and CI
Change-Id: I24d8dc47f7ed83f0b84c632d24396e2bdf932424

This CL also specifies aconfig_declaration module in java_sdk_library
register_nsd_offload_engine will be moved to the platform flags.aconfig
in the followup CL.

Test: TH
Change-Id: I430a5f0b1e1ef2e3394cf6aa8efebbd46da41765

When adding a service, the MdnsRecordRepository finds the
existing service solely by service name, which is wrong. it should check
both the service name and the service type.

Bug: 325862182

Change-Id: I72c6837d0dfb41fc9b2d7763e18b3f5415f8c0d9

This test case lets the BR send a UDP message to Thread device using
socket API and verify the message is received on the Thread device via
ot-ctl udp command.

For now this only verifies the direction BR -> ED because the other
direction ED -> BR is depending on platform UDP feature which is not
enabled yet.

Bug: 321168973
Test:  atest ThreadNetworkIntegrationTests:BorderRoutingTest#unicastRouting_borderRouterSendsUdpToThreadDevice_datagramReceived

Change-Id: I590583dd818f3d72dec41184e5427a8b08f842bb

For reasoning see:
  https://android-review.googlesource.com/c/platform/system/netd/+/2966803



Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: If479b0443a64e0bf98ca89016d42ca37e231c576

follow up to http://aosp/2965923

 to hopefully eliminate
that class of bug in the future...

Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ie09db001ff15a6b2b15bb1bb0c1ce8228e162337

Test: atest CtsHostsideNetworkTests

Bug: 304347838
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:4cef70d592e91c2ccd3419f52bf779e29fcb4a79)
Merged-In: I88ffa390a890a09d95109518329ba6abcb162bc1
Change-Id: I88ffa390a890a09d95109518329ba6abcb162bc1

The enum is already using 12 bits, so using fewer bits loses information.
This is in sync with the UidOwnerValue struct used to contain this data.

Test: atest resolv_integration_test
Test: atest resolv_unit_test

Bug: 325150155
Change-Id: Ide0ccea9614cda803b3700a0cc22977e9608209e

Rename API methods and update API docs as per API
council feedbacks

Bug: 316603231
Test: make update-api && make
Change-Id: Ibb1f58792d2e40ef1084c2b532e999a516a87b37

Bug: 324326824
Test: TH
Change-Id: I6d5f9c27b2fc2f2290e27f63b933b9ccacfffa85

Make TetheringRequest parcelable so we can pass it via Wifi APIs and map
Soft AP state changes to the correct request.

Bug: 216524590
Test: build
Change-Id: I63a45b14e9abc288b353159dfdcbe96fde485cb7

CtsNetTestCasesLatestSdk was originally used for MTS to prevent
installation issues with CUR_DEVELOPMENT target SDK modules (as is the
case for CtsNetTestCases) not installing on released devices.

However setting the min_sdk to a given value should be enough for that
purpose. While there may have been other blockers requiring separation
of CtsNetTestCases and CtsNetTestCasesLatestSdk at the time (in the Q/R
timeframe), more recent modules like CtsAdServicesDeviceTestCases seem
to be using CUR_DEVELOPMENT target SDK in MTS just fine.

Not specifying a target SDK means that the branch default will be used,
depending on the release configuration. So for example trunk_staging
would typically be CUR_DEVELOPMENT=10000, and "next" may use the SDK
version of that release.
This makes sense as a test suite targeting CUR_DEVELOPMENT is necessary
to verify a development build, while a production "next" configuration
should generally use the latest released SDK. But in any case, for
CtsNetTestCases purposes, this would cause the exercised connectivity
APIs to use their latest non-compatibility behavior, which is what
tests expect.

Considering this, add CtsNetTestCases to MTS, so that
CtsNetTestCasesLatestSdk can be removed. This will allow having one test
suite for both CTS and MTS, which in turns allows marking
CtsNetTestCases as MCTS, so that the version of the test to run is
autodetected based on installed modules.

Note this change also removes the unnecessary "platform_api" statement
and comment as this is already handled in
framework-connectivity-test-defaults.

Bug: 317913702
Test: m, aapt dump badging, verify (min)sdkVersion=30, targetSdk=10000
Change-Id: I2267e5c9219f059872928cc681547c3bd5fbc394

Apps will now lose network access once they are in top-sleeping or
higher process state. Adding some cts tests to ensure correct behavior.

The tests are using temporarily using junit Assume to skip if the
feature flag is enabled to enable a following code migration.

Test: atest CtsHostsideNetworkTests

BYPASS_INCLUSIVE_LANGUAGE_REASON=Existing method

Bug: 304347838
Change-Id: Iba7c7bd01309fa7a301fdc1524033f0fad5ae512

* changes:
  Introduce Powered Off Finding API
  Add Powered Off Finding operations to NearbyService

Bug: 307898240
Test: atest CtsNearbyFastPairTestCases
Test: atest NearbyIntegrationPrivilegedTests
Test: atest NearbyIntegrationUntrustedTests
Change-Id: I57b37ea796c0791d72fec931f731a0143e816dac

On V, this feature is enabled on all devices.
On U, this feature is enabled if the flag is enabled.

Test: TH
Change-Id: I025b9a8098a0896be51cf06c5b8262243ba439b7

Raise the max listener per client limit from 10 to 200.

A frequent use-case for NsdManager is to file a DiscoveryListener,
and try to resolve/listen for every service using a ServiceInfoCallback.

The current limit of 10 callbacks is easy to hit in that case, since it
would happen if there are at least 10 devices on the network.

Raise the limit to 200 to avoid such problems. In practice it is very
unlikely that there would be more than 200 services on a network; if
advertised by different devices, they would barely fit in a /24 IPv4
prefix, so a limit of 200 should generally be high enough.

Note that for discovery 200 listeners does not mean that batches of 200
queries will be sent: listeners on the same service type are grouped
together so only one query is sent for the type, and results are
distributed to matching listeners.

Note also that the limit is currently only checked when registering
discovery or advertising requests. This should be also checked when
registering other kinds of listeners in a future change.

Bug: 324377460
Test: atest
Change-Id: I86fc00777e9dea3e5192b575581ba562e7401e42

(this will land in M-2024-05 ie. May mainline tethering module)

Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I250b691eb03751da05ce10d41d6721f4964dd1d5

The flag com.android.net.flags.ipsec_transform_state gates APIs
exposed by the Tethering module, and thus should also be included
in Connectivity/common/flags.aconfig

Bug: 324278950
Test: make
Change-Id: Ia1fe733a4971ac56cae65870a5339362594322e6