Do not use framework-connectivity stubs for
framework-connectivity-t-pre-jarjar, as that library can build against
the full framework-connectivity implementation including hidden symbols:
it already builds against framework-connectivity-pre-jarjar.

The stubs are only necessary to build framework-connectivity-t stubs, to
avoid circular dependencies between these and the framework-connectivity
implementation.

This change allows using hidden symbols of framework-connectivity in
framework-connectivity-t-pre-jarjar, but does not fully fix the problem
as framework-connectivity-t will use the framework-connectivity stubs
both to build its own stubs and to build its implementation library, due
to "libs" being used in both cases (and prioritized over
impl_only_libs). As a result, it is still not possible to build
framework-connectivity-t when it references hidden symbols of classes
that are also part of the stubs. Still, this is a first step and
organizes the build rules closer to what they should be.

Bug: 139774492
Test: m
Change-Id: I5e696fa6a7871d048e0ba16442de33b5f139faae

Changing multiple instances where the assert order for an assert.equals
was (actual, expected) to the more widely (and suggested) ordering of
(expected, actual).

Bug: 235605892
Test: atest FrameworksNetTests
:com.android.server.ethernet.EthernetNetworkFactoryTest

Change-Id: I6e9459d34d6cc7f43a2bfe346d2c2ca9551d46da

R8 emits "missing class" warnings when optimizing service-connectivity
because service-connectivity combines several already built static_libs
(service-connectivity, service-connectivity-t, service-nearby), but does
not specify any classpath library, which are actually needed for R8.

This causes wrong optimizations, where R8 would sometimes strip out code
that it thinks is unused (because it considers it unreachable due to the
missing class, or it does not know the superclass of a callback and
thinks the overridden methods cannot be called).

Add the necessary classpath libraries to remove the warnings.

Bug: 226127213
Bug: 239990030
Test: m service-connectivity, see no "Missing class" warnings
Change-Id: I1eaa39b70da4b540e3a3e8e798bec1359b5bf533

Use new Builder API which was introduced in Android T.

Bug: 238843364
Test: FrameworksNetTests
      dumpsys netstats --checkin and check the output
Change-Id: Ieb0a2ee04056a1cedb71274ea710ff5153e2d68c

DscpPolicyTest now tests the ether program, which is also the one used
in production. The raw program can be removed now.

Test: atest DscpPolicyTest
Bug: 235559605
Change-Id: Idefa22918c5ccb71c9cd141ab3460507aca1f753

* changes:
  DscpPolicyTest: fix linter errors
  DscpPolicyTest: use tap instead of tun
  TestNetworkService: fix test network interface bringup

* changes:
  Sendcallback when setting eth interface up
  ethernet: add test for enable/disable interface

Tests were introduced in aosp/2114533. But we disabled them because they
affect the actual state of networking on the device after the tests and
this might cause unexpected behavior of the device.

This commit updates tests to restore the status after the tests and
enables tests.

Bug: 208371987
Test: atest
CtsNetTestCases: android.net.cts.ConnectivityManagerTest#testFirewallBlocking
Change-Id: I7e3ebdff7d2d8a227291ac12c4fe72529986e74d

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

CTS tests for EthernetManager APIs:
    #updateConfiguration

Bug: 236420528
Bug: 210487893
Test: atest CtsNetTestCases
:android.net.cts.EthernetManagerTest --iterations

Change-Id: I394cd306c0f78973564f9196834e690e4a51a3fd

Fix so callbacks are sent when changing the interface link state for an
ethernet interface from down -> up.

Bug: 235605892
Test: atest FrameworksNetTests
:com.android.server.ethernet.EthernetNetworkFactoryTest

Change-Id: If13254d4882aa2f0021f6443f31ef173b3867727

More tests to come, specifically around toggling carrier up / down, once
that behavior has been fixed.

Test: atest EthernetManagerTest
Change-Id: I2424bd4f39013302d416e8e1ae5c8a7dd357c250

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

SdkLevel utilities should be used instead.

Test: atest
Change-Id: I81bf2807be30e3e4d2d7102cf03f267b28c65a08

Bug: 206482423
Test: atest HostsideVpnTests#testBlockIncomingPackets --iterations 30
Change-Id: I5a9c515c163f0f19e261fe3468e246ae299fa261

Test: TH
Change-Id: I6501cd09b72734382fe05fd2227ad735cfc4fb15

This switches the DscpPolicyTest to use a tap interface rather than a
tun interface. This should now test the same bpf code path that is used
in production and the raw ip version should be able to be removed.

Test: atest DscpPolicyTest
Change-Id: I1633b85810838afde6191f0a5094269e45c15ae4

Bring up tun/tap interfaces after disabling dad / setting rs delay to 0,
so it is applied properly.

Test: TH
Bug: 235559605
Change-Id: I6bc209a12f9cbdba7bdde99c2a8817f8e52d34ce

DscpPolicyTest does not have an IpClient, so it relies on assigning the
LinkAddresses at interface creation. If DAD is enabled, the global
address cannot be used immediately, so the test packet selects the wrong
source address. There is no obvious way to fix this without disabling
DAD as the TestableNetworkCallback receives the LinkProperties update
before the address can be used.

This functionality will also be useful in ethernet tests, which
currently have to block for a long time.

Test: atest DscpPolicyTest
Bug: 235559605
Change-Id: Id7788df5e92ebd8eaf4619a23f44135ea4a2144e

* changes:
  Rename time_in_state.o to timeInState.o
  Rename gpu_mem.o to gpuMem.o