This commit unregisters all country code callbacks (WiFi, Telephony and
Location) when the CountryCode module detects that the co-processor
doesn't support setting the country code.
Bug: b/402276117
Test: atest ThreadNetworkUnitTests:ThreadNetworkCountryCodeTest#setCountryCodeNotSupported_returnUnsupportedFeatureError_unregisterAllCallbacks
Change-Id: I65d57e0e826202ad696335200645bf6d78c8b87c
Some the co-processors do not support setting the country code. This
commit enables the CountryCode module doesn't set the country again
after it knows that the co-processor doesn't support setting the
country code.
Bug: b/402276117
Test: atest ThreadNetworkUnitTests:ThreadNetworkCountryCodeTest#setCountryCodeNotSupported_returnUnsupportedFeatureError_countryCodeNotSetAgain
Change-Id: I8ca1f7aed3774a086e114e91d8100fb7fe9e3664
This is to avoid applications uses Aloc address for source address which
would cause issues when there are multiple devices sharing the same
Aloc.
Bug: 396019291
Change-Id: I287007ddecd9d0fa2ac8da92f4de691e7844b259
When checking for trel services published by a BR, we need to filter the
services by their service name, since there might be other devices
publishing trel service at the same time.
Bug: 399518677
Change-Id: I56518dbe6c79b48aa048073d8556a53e1261e8bd
1. We don't need to assert that ThreadNetworkManager is always null
when the Thread hardware features are not present. There can be more
useful Thread features which don't require the hardware
2. The getAllThreadNetworkControllers() API has no documentation says
the returned list is guaranteed not empty.
Change-Id: Ie77110067ff670053a2125b30b2791b9f54b2582
The current settings APIs have a few issues:
1. It doesn't support default value which is derived from resource
overlays
2. It exposes the default values of settings entries as public APIs
while they shouldn't be
Bug: 401654864
Change-Id: I1bbe3f14507a497320401f02fa6da512558fe385
This commit adds a resource overlay config for OEMs to disable the
Border Router feature by default. Also updates the tests to cover both
BR and non-BR use cases
Bug: 401654864
Change-Id: I7dd4363836269a08853b58304f62fe52f9021a9e
Wait for route to be added/removed from link properties in the tests
instead of checking immediately, as it takes time for the change to
propagate from ot.
Bug: 401815392
Change-Id: Ie95f4beaa370514d31875b9f2e926762a38bc99e
Setting country code is not a must support feature on all platforms.
This commit skips the country code related tests when the platform
doesn't support setting the country code.
Bug: b/401793629
Test: atest ThreadNetworkIntegrationTests
Change-Id: I6bb8444f70afb2635d7791af2128741bc02e8ff3
The leave() API can now correctly clear the in-memory state for the
Thread stack, it's better to use the leaveAndWait() API in the tests to
ensure timing sequences
Bug: 338061061
Change-Id: Ic91f8043cd5a35f19b9161c5778f83b83a713946
Now that python 2 is fully removed, there's no need for
version-specific properties. Remove them.
Also remove usages of embedded_launcher: true, as that
is the new default value.
Bug: 399954452
Test: Presubmits
Change-Id: I368416638bbf1f5e76f7756792d537f72f3c9714
These were added to allow tests to build against flagged off APIs, in
legacy downstream branches that did not support the flagging
infrastructure and stripped out flagged off APIs from the stubs.
Flagged off APIs are part of the regular stubs in branches used today,
so this is not needed anymore.
Bug: 399365344
Test: atest
Change-Id: Ica7df0c5c9be39d9dca49e0114711a7c43125c3d
Remi NGUYEN VANauthored and Paul Duffincommited 2025-02-28 10:47:40 +00:00
The bring up delay of SRP server is higher than before. In the integration test case we need to explicitly wait for the SRP server to show up in Network Data. Otherwise the test may be flaky.
Bug: 399263029
Change-Id: Id6346bcbfd55a34103ba8de0dcee75d3cacde446
All the 3 meshcop_xxx CTS tests in ThreadNetworkControllerTest are
flaky:
1. meshcopService_threadEnabledButNotJoined_discoveredButNoNetwork fails
if thread is disabled and then enabled
2. meshcopService_threadDisabled_notDiscovered fails if the discovery is
not specifically on the test network
3. meshcopService_joinedNetwork_discoveredHasNetwork is already flaky
Bug: 332195449
Bug: 333649897
Bug: 396311014
Change-Id: Ibd3f7b05bddb6b28408f9411350e364dd720b335
The flag is read-only, and is tested with flag filtering. The target
preparer was prepared for manual testing before the flag was rolled out
in M25-02.
Bug: 398553026
Change-Id: Id678a147e38b8b5454b37bf72cb66bdac24786f8
This test had an assumption that Thread is enabled which is not true. This CL enables Thread in the setUp().
Bug: 397583601
Change-Id: I9c4d5028a663c6fe1c581267ff7d172d0cba577c
Test: verified that when the config is set to `false`, thread won't start up after reboots:
```
➜ main-aosp-2 adb shell ot-ctl state
leader
Done
➜ main-aosp-2 adb reboot
➜ main-aosp-2 adb shell ot-ctl state
/system/bin/sh: ot-ctl: inaccessible or not found
➜ main-aosp-2 adb root
➜ main-aosp-2 adb shell ot-ctl state
disabled
Done
```
Bug: 378587036
Change-Id: I4d1c90ab3121f39219cbaf795879a7ba91db02a3
It's default enabled that it waits for border routing establishment
before starting the SRP server. But there are also use cases where
the user may want to know what are the devices in the Thread network
before actually reach to the devices, or it doesn't depend on border
routing to reach to a Thread device.
Given that, this commit adds the support of starting SRP server
without waiting for border routing by adding a new
Runtime Resource Overlay configuration parameter:
config_thread_srp_server_wait_for_border_routing_enabled
Test: it's difficult to assert on the SRP server starts up timing. But manually verified that the SRP server starts without waiting for the routing manager when the RRO config is flipped:
```
01-09 20:18:35.835 7555 7555 I ot-daemon: [I] RoutingManager: RsSender: Sent RS 1/3
01-09 20:18:35.835 7555 7555 I ot-daemon: [I] RoutingManager: Received RS from fe80:0:0:0:98af:44ff:fe2e:fa80 on infra netif 17
01-09 20:18:35.835 7555 7555 I ot-daemon: [I] RoutingManager: Will evaluate routing policy in 00:00.150 (150 msec)
01-09 20:18:35.926 7555 7555 I ot-daemon: [I] NetDataPublshr: DNS/SRP service - State: Adding -> Added
01-09 20:18:35.926 7555 7555 I ot-daemon: [I] SrpServer-----: Start listening on port 53536
01-09 20:18:35.926 7555 7555 I ot-daemon: [I] NetworkData---: Sent ServerData
01-09 20:18:35.926 7555 7555 I ot-daemon: [I] NetworkData---: Received ServerData
01-09 20:18:35.926 7555 7555 I ot-daemon: [I] NetworkData---: Allocated Service ID = 1
01-09 20:18:35.926 7555 7555 I ot-daemon: [I] NetworkData---: Sent ServerData ack
01-09 20:18:35.926 7555 7555 I ot-daemon: [I] Notifier------: StateChanged (0x00000200) [NetData]
01-09 20:18:35.926 7555 7555 I ot-daemon: [I] Mle-----------: Send Data Response (ff02:0:0:0:0:0:0:1)
01-09 20:18:35.926 7555 7555 I ot-daemon: [I] BbrLeader-----: PBBR state: Unchanged
01-09 20:18:35.926 7555 7555 I ot-daemon: [I] BbrLeader-----: Rloc16:0x8800, seqno:69, delay:5, timeout:3600
01-09 20:18:35.926 7555 7555 I ot-daemon: [I] RoutingManager: Will evaluate routing policy in 00:03.558 (3558 msec)
01-09 20:18:35.926 7555 7555 I ot-daemon: [I] NetDataPublshr: DNS/SRP service (state:Added) in netdata - total:1, preferred:0, desired:2
```
Bug: 378587036
Change-Id: Ib768014f3c44dca89390cec823a1c2acac38ab0d
TestTunNetworkUtils is a centralized place to control the test TUN networks used by integration test. With this we can safely tear down all test networks in `teardown()` instead of tearing down the newly created network in `finally` clause.
Bug: 377640059
Change-Id: I57b34bb2644bd6a5bb73ed1573932f35de657c8f
In the situation where infra state changes very frequently, it may cause the border routing to frequently restart.
Bug: 377821980
Test: atest ThreadNetworkIntegrationTests
Change-Id: Id2862b0db7e01f89da20c56c4ad2f0086d4b6a98
This CL adds a test case for UDP traffic in InternetAccessTest. The test case verifies that a Thread device can send a UDP message to a UDP echo server and receive a reply.
Bug: 374232259
Change-Id: Id138248f1ed26c1cc5728cc06b42e3223c449125
This class is useful for creating a class that responds to specific type of UDP messages. E.g. DNS server and UDP echo server.
Bug: 356770473
Test: atest ThreadNetworkIntegrationTests:android.net.thread.InternetAccessTest
Change-Id: I6880bb825ac5077d4a73f9d986116c571863e1d8