.toList() was only introduced to android in api level 34, which is newer than
this module's min_sdk_version. Replace it with .collect().
This was found while updating android lint.
Flag: EXEMPT refactor
Bug: 394096385
Test: Presubmits
Change-Id: I472bff7749aebb21bd8681ecf4235ce7a6cfc7de
most of these are spammy and/or not useful.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Iab101ce7de076ef025a046d5e3e9007e091b271f
Maciej Żenczykowskicommited 2025-01-31 12:53:11 -08:00
This commit adds CtsTetheringTestLatestSdk to the postsubmit
configuration. This is a preparatory step towards moving the test to
presubmit, ensuring it runs regularly and catches issues earlier in the
development cycle.
Test: TH
Change-Id: I6932b0b660a675a20102d2683119f689557d8590
Add a basic implementation of stopTetheringRequest that simply stops
tethering for that specific type if it is active, or fail with
TETHER_ERROR_UNKNOWN_REQUEST if not. In the future, we will do fuzzy
matching to ensure the correct request is removed.
Bug: 216524590
Test: atest TetheringManagerTest#testStopTetheringRequest
Change-Id: Ib4a660aacdb83e645e39ceb61b7cda45bb24d89d
Quang Anh Luongcommited 2025-01-31 16:23:04 +09:00
Linux Kernel documentation states:
* u64 bpf_get_netns_cookie(void *ctx)
Description
Retrieve the cookie (generated by the kernel) of the network
namespace the input *ctx* is associated with. The network
namespace cookie remains stable for its lifetime and provides
a global identifier that can be assumed unique. If *ctx* is
NULL, then the helper returns the cookie for the initial
network namespace. The cookie itself is very similar to that
of **bpf_get_socket_cookie**\ () helper, but for network
namespaces instead of sockets.
Return
A 8-byte long opaque number.
This was introduced in Linux 5.7, see get_netns_cookie in
https://elixir.bootlin.com/linux/v5.7/source/net/core/filter.c
vs
https://elixir.bootlin.com/linux/v5.6/source/net/core/filter.c
But only for sock & sock_addr, while sock_ops & sk_msg were
added later (present in 6.12)
Test: N/A
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Idccb7191552be8048a02fff2358e7d7898123dd9
Maciej Żenczykowskiauthored and Patrick Rohrcommited 2025-01-30 18:48:51 -08:00
Adding this to make sure we have 'unprivileged_bpf_disabled = 0'
This is currently set by NetBpfLoad, but if we remove that things currently work.
However with this change the device then fails to boot:
$ adbz logcat -s -d *:* | egrep -i -C10 bpf
I NetdUpdatable: libnetd_updatable_init: Initializing
I NetdUpdatable: BPF programs are loaded
I NetdUpdatable: initMaps successfully
E NetdUpdatable: libnetd_updatable_init: Failed: (1) [Operation not permitted] : map create failed
This is because even though system/netd/server/netd.rc has:
service netd /system/bin/netd
class main
capabilities CHOWN DAC_OVERRIDE DAC_READ_SEARCH FOWNER IPC_LOCK KILL NET_ADMIN NET_BIND_SERVICE NET_RAW SETUID SETGID
user root
group root net_admin
and we thus run as root/root with CAP_NET_ADMIN, but we do *NOT* have CAP_BPF nor CAP_SYS_ADMIN.
This means netd is considered 'unprivileged' from the point of view of that sysctl.
Creating maps from outside the bpfloader (ie. netd/system server/network stack)
is required for map-in-map.
While the sepolicy for netd.te map_create is in V, there is no real
need for this test on V atm, doing this to prevent *future* regressions.
A rollout purely to the not yet existing 25Q2+ is safer.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Ia39c74cfb1707e88b0aa534ddf42139b1698d5d6
Maciej Żenczykowskicommited 2025-01-30 14:58:07 -08:00
These are convenience macros which do
(const|volatile) cast for atomic operations.
I've run into a case where two 32-bit writes get optimized
by the compiler into a single 64-bit write, which then fails
verification. WRITE_ONCE() avoids that by virtue of the volatile annotation.
Technically I think the same thing could happen on read,
so add READ_ONCE too.
Test: N/A
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Iade089aab3522916bd7b431d4064f89a21bc78b0
Maciej Żenczykowskicommited 2025-01-30 14:43:45 -08:00
* changes:
Remove redundant requestedState from IpServer#enable
Log tethering started with placeholder request
no-op: Make TetheringRequest @NonNull in enableIpServing
Quang Luongauthored and Gerrit Code Reviewcommited 2025-01-30 00:44:35 -08:00
IpServer#enable is called with both a non-null TetheringRequest and the
requestedState, but the requestedState is derived from the
TetheringRequest's connectivity scope. Remove this requestedState arg
and simply have IpServer read the connectivity scope itself.
Bug: 216524590
Test: covered by existing tests
Change-Id: I73227f5053da3a2ab35563268fc416b6dd9b1801
Quang Anh Luongcommited 2025-01-30 14:30:51 +09:00
Currently the enableIpServing->tetherInternal call stack may have a
tethering request alongside a redundant tethering type and requested
state. The redundant arguments were necessary since there may be cases
where the active request is null (e.g. back-to-back start/stop, which
removes the active request before the link layer event enables ip
serving).
This change gets rid of the redundant arguments and makes the call stack
take a non-null TetheringRequest. In case the active request is not
found, we will create a placeholder request with just the type and
connectivity scope (i.e. requested state). This should be equivalent to
the old code of sending a null request (since none of the other fields
in TetheringRequest are used), making this a no-op change.
Bug: 216524590
Test: covered by existing tests
Change-Id: I5ac83c74f5bc4aec2fe85daa9477740749d95c63
Quang Anh Luongcommited 2025-01-30 14:30:49 +09:00
Avoids:
android.net.cts.DnsTest#testDnsWorks: FAILED (4.993s)
STACKTRACE:
java.lang.AssertionError: Default network did not provide IPv6 connectivity after 5000ms. Please connect to an IPv6-capable network.
lp={InterfaceName: wlan0 LinkAddresses: [ fe80::6c1f:76ff:fe50:2c84/64,192.168.99.115/25 ] DnsAddresses: [ /192.168.99.1 ] Domains: l
an MTU: 0 ServerAddress: /192.168.99.1 TcpBufferSizes: 524288,1048576,2097152,262144,524288,1048576 Routes: [ fe80::/64 -> :: wlan0 m
tu 0,192.168.99.0/25 -> 0.0.0.0 wlan0 mtu 0,0.0.0.0/0 -> 192.168.99.1 wlan0 mtu 0 ]}
at org.junit.Assert.fail(Assert.java:89)
at org.junit.Assert.assertTrue(Assert.java:42)
at android.net.cts.DnsTest.ensureIpv6Connectivity(DnsTest.java:319)
at android.net.cts.DnsTest.testDnsWorks(DnsTest.java:90)
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I4b94edae6d196ca02858702dec40ee2bad1db494
Maciej Żenczykowskicommited 2025-01-29 19:56:31 -08:00
due to:
android.net.cts.ConnectivityManagerTest#testOpenConnection: FAILED (277ms)
STACKTRACE:
java.lang.AssertionError: Same address '104.135.180.196' on two different networks (153, 143)
at org.junit.Assert.fail(Assert.java:89)
at org.junit.Assert.assertTrue(Assert.java:42)
at org.junit.Assert.assertFalse(Assert.java:65)
at android.net.cts.ConnectivityManagerTest.testOpenConnection(ConnectivityManagerTest.java:934)
This would possibly be fixed by cuttlefish having IPv6 connectivity, but it doesn't atm.
@RequiresDevice doesn't work right with atest.
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I5bd4189ed6297a2491dc0ab7b251ffd19d1ecb5d
Maciej Żenczykowskicommited 2025-01-29 19:54:48 -08:00
* changes:
Rename mActiveTetheringRequests to mPendingTetheringRequests
Give the two variants of ensureIpServerStarted different names.
Move the TetheringRequest further up the stack.
Un-nest legacyTether by moving lambda contents to new method.
Quang Luongauthored and Gerrit Code Reviewcommited 2025-01-29 13:48:17 -08:00
When setIncludeTestInterfaces(false) is called, any RTM_DELLINK
callback for a testtap interface is ignored, since the interface is no
longer considered to be a valid ethernet interface.
Change setIncludeTestInterfaces to go through all interfaces, and stop
tracking the ones which are no longer valid. Otherwise, they will
stick around forever (and break subsequent tests).
Bug: 390722214
Test: TH
Change-Id: Ied73e86c0452831f4d6b00f67908c51201af8bbd
mActiveTetheringRequests is a misnomer because the requests aren't
actually active yet. Rename this to mPendingTetheringRequests since
they're pending a link layer event that the iface is ready to start IP
serving.
Bug: 216524590
Test: covered by existing tests
Change-Id: Ib0c4a52e0aa72fc27b67bce25187124b20082c05
Quang Anh Luongauthored and Lorenzo Colitticommited 2025-01-29 17:15:53 +09:00
The fact that the two overloads have the same name is confusing
because one of them fetches the type and one of them has it
passed in. This means it's not obvious whether they behave
identically or not.
This is a no-op refactor.
Bug: 216524590
Test: covered by existing tests
Change-Id: Iff7d2981cb5835831f00117166035d48b44a61a4
Lorenzo Colitticommited 2025-01-29 17:11:37 +09:00
Currently, the active TetheringRequest (if any) is fetched at the
very bottom of the stack, just before enabling the IpServer.
Have the callers pass it in instead.
This CL is a no-op refactor. In particular, it ignores the fact
that the TetheringRequest can be null, and that the connectivity
scope in the request might not match the requested state, etc. -
it just documents the current behaviour (bugs included) and
leaves it unchanged. It exists only to make future changes
easier.
Bug: 216524590
Test: covered by existing tests
Change-Id: Ie8af8b718a9de1f1d5adde0ac589060dce112a27
Lorenzo Colitticommited 2025-01-29 17:11:37 +09:00
This bug was introduced in aosp/3342195 and can occur when calling
setEthernetEnabled() while ethernet tethering is enabled and the
tethering interface has disappeared.
Bug: 392912047
Test: TH
Change-Id: I4c4c2144558ad9057195ddcf30c055227f3fc62a
With b/391766151 fixed by the previous patch, this can now
be reverted.
This reverts commit 4f59de2f85.
Test: atest NetworkAgentTest on an S device
Change-Id: Ie2cb2ca5653a134c0eaa1cac5b0c4b4221f1c0ac
b/391766151 is caused by the combination of three things :
• Newer compilers, such as the Kotlin K2 compiler, will use the
`invokedynamic` instruction introduced in Java 7.
→ Before then, lambdas had to be wrapped in synthetic classes,
which would be generated by the compiler. The compiler would
then generate code that instantiates the synthetic class and
pass it to the callee as the lambda.
→ After then, there is no need for synthetic classes. Instead, the
compiler synthesizes a static method that corresponds to the
lambda and emits an invokedynamic opcode at that call site.
The JVM will then lookup the class dynamically and create a
MethodHandle object from which it can substitute an immediate
method call at runtime.
→ The new way means a much smaller footprint (because
there are less classes in bytecode) and typically much better
call performance after the initial resolution, at the cost of linking
the method at the first execution of the lambda. For most
modern apps, the trade-off is very advantageous.
→ In this case, the methods that accept the lambda are of the
`runAsShell` family.
→ Because there are captured local variables of the *WaiterCallback
types, the generated static methods take instances of these types.
• JUnit uses reflection to enumerate the methods of test classes.
It does not take care to only enumerate public methods, and as
such will try to resolve all private methods including the types of
their arguments.
→ Note that the `Class` class has a way to retrieve all methods
of public visibility including inherited methods, a way to
retrieve all non-inherited methods including all visibilities, but
not a way to retrieve only public locally-declared methods, so
JUnit's implementation is understandable.
→ In this case, this means JUnit has code that will try to resolve
the *WaiterCallback classes.
• The test code is compiled against newer SDKs but run with the
JUnit test harness on older SDKs which don't have the base classes
for the *WaiterCallback classes.
The net result is that as JUnit enumerates methods, it finds the
private synthetic methods emitted by the newer compilers, which
causes the JVM to try and resolve the type of the arguments, which
in turn is not possible on older frameworks. The test run promptly
crashes with ClassNotFoundException before it can run any test
method.
Note that this would also happen with newer Java compilers.
This patch solves this method by annotating the relevant
lambdas with @JvmSerializableLambda, which causes the
Kotlin compiler to use the old behavior on just those lambdas.
The drawback of this patch is that the @JvmSerializableLambda
feature is pretty obscure and it needs to be managed per-lambda.
Bug: 391766151
Test: revert aosp/3464183 on top of this, then atest NetworkAgentTest
on an S device, then atest CtsNetTestCases to test whether there
are other instances of this issue
Change-Id: Iacaadddb597c4a5dfdd8c497e6ebc1243ae1e923
This rtnl message is used with sendOneShotKernelMessage() which expects
that kernel returns an ACK. We need to set NLM_F_ACK explicitly for
that.
Bug: 390722214
Bug: 392491075
Test: Manually run the affected test, no more exception with EAGAIN.
Change-Id: I7ef9497461a8e89e9f7f7fe399562b2d8ede14a9
The atom no longer just represents log list update failures, and will
instead be representing the entire log list update result regardless of
success or failure.
Flag: com.android.net.ct.flags.certificate_transparency_service
Bug: 378626065
Test: atest NetworkSecurityUnitTests
Change-Id: Ide254542aeb9c9657e79a154e53f651478bb1a54
Previously, we would only log to statsd if a default threshold of 10 had
been met to avoid noise in the logs. Because we will instead be logging
every time a log list update happens (success or failure), we are
removing this threshold logic.
Flag: com.android.net.ct.flags.certificate_transparency_service
Bug: 378626065
Test: atest NetworkSecurityUnitTests
Change-Id: Id3ad2c75fcceb3c15add70d4263f6c443f145348
The change to use Kotlin 2 by default causes NetworkAgentTest to
crash on S, possibly due to the compiler emitting synthetic methods that access API classes that don't exist on S. Force it to compile with Kotlin 1.9 until we can fix it.
Change-Id: Ief9b34c8d1eb1469ea33408736d9ca250019dbe9
Fix: 391766151
Test: Test-only change
Lorenzo Colitticommited 2025-01-24 00:38:41 -08:00