Many Thread radio chips need to reduce their transmit power on edge
channels to pass regulatory RF certification. This CL restrcits the
dataset to select a channel from channel 11 to 24.
Bug: b/331708479
Test: atest ThreadNetworkUnitTests
Change-Id: I758c9f33629a0cafcc39bb9fde0ad45ab2699db8
The country code is lost after the ot-daemon is restarted. This
CL stores the country code to persistent settings and reads
out the previously stored country code to set the country code
when the ot-daemon is initialized.
Bug: b/326021472
Test: atest ThreadNetworkUnitTests
Change-Id: I6982a57ba4845f5a45f3366400c531398e82339e
1. the OtDaemonState in OtDaemonCallbackProxy class is not cleared when
ot-daemon dies
2. register ot-daemon state callback within the IOtDaemon#initialize API
to avoid missing state changes between initialize() and
registerStateCallback()
Bug: 330441708
Change-Id: Ice58566582b40a6d25627cf01dec93da61ad3596
The `setChannelMaxPowers` allows privilege app to set the max
power of each channel. It is going to be used for controlling the
output power of the Thread radio chip.
Bug: b/320594263
Test: atest ThreadNetworkUnitTests && atest CtsThreadNetworkTestCases
Change-Id: Ic47eccd6de2da0e6cdb8f21d5b4df156b1f11747
The Thread HAL supports only one client for a single Thread chip, so
ot-daemon needs to be force stopped in VTS tests because the testapp
needs to connect to the HAL service to perform tests.
Bug: 328538612
Change-Id: I5288e5747ab3957050d0e85c1ea684c6ead6c87d
Current implementation will auto-restart ot-daemon even when Thread
has been disabled by ThreadNetworkController#setEnabled(false). This
commit fixes this issue and also adds the "enable" / "disable" shell
command to ease testing.
Bug: 328538612
Change-Id: Icc9360ccf5d7daa6345def75d1860f046600b85b
Currently support customizing the vendor name, vendor oui and model
name.
Bug: 311324956
Test: atest ThreadNetworkIntegrationTests:android.net.thread.ServiceDiscoveryTest#meshcopOverlay_vendorAndModelNameAreSetToOverlayValue
Change-Id: I3ad916112c73c3f8a7eef4e3fa8d421ab9bf8276
This is needed by `ot-daemon` to clear all registrations when
re-initializing the `ot-daemon`'s `Application` class.
Bug: 323301831
Change-Id: I5ed3d2d29b08f4187ac1f406052d362cf2249c19
Multicast routing is only supported on 14_5.15.0 and onwards. When sdk
version is 34+, thread is supported, if kernel version is e.g.
5.15.144-android13 then multicast routing is not supported so we need to
skip multicast routing tests.
Bug: 328133320
Test: atest ThreadNetworkIntegrationTests:android.net.thread.BorderRoutingTest
Change-Id: I5d67f4558b40ee3ec0569298c7c02726d5d19e98
This CL also adds an integration test case for the Advertising Proxy feature.
Currently the test case is disabled because it's unstable on some branches.
Will re-enable the test case when it's stable enough.
Bug: 318323473
Test: atest ThreadNetworkIntegrationTests:android.net.thread.ServiceDiscoveryTest
Change-Id: Ic88efb3b80640f95b53e4ec2428369e87be71649
This CL also adds an integration test case for the Advertising Proxy feature.
Bug: 318323473
Test: atest ThreadNetworkIntegrationTests:android.net.thread.ServiceDiscoveryTest
Change-Id: I626aa6250bc2cb94aee09067b4f8e6b14bd90fcf
Previously we were using TUN test network which is not eligible for mDNS
operations. The tests are flaky because we need to depend on other test
cases to connect to WiFi, which is not guaranteed. We'll use the TAP
test network to fix it.
Bug: 327306555
Bug: 327306158
Bug: 327306608
Test: https://android-build.corp.google.com/builds/abtd/run/L70000030002206431
Change-Id: Ie8ed0ee8b8208150efcd4424ed26e9ca7d85fd82
Previously we were using TUN test network which is not eligible for mDNS
operations. The tests are flaky because we need to depend on other test
cases to connect to WiFi, which is not guaranteed. We'll use the TAP
test network to fix it.
Bug: 327306555
Bug: 327306158
Bug: 327306608
Change-Id: Ia6de8a507578dbdeea4a7ceaf52f417acf35baa2
Make the default Thread and Border Router enabled state customizable for
vendor via resource overlay.
Bug: 322734489
Change-Id: I278d6afa82aac8d1bb06ee79f22bae6fb0199386
Existing ThreadNetworkControllerService tests are using RunAsShell to
grant the permissions for indivitual APIs. Given the permission checks
are tested in the CTS tests, this is not very useful with the overhead
of complicating the testing code. Instead, this CL grants all the
permissions in setUp() with spy-ed Context.
This commit also fixes the issue in b/326793058 that the tests doesn't
run on a U device where the THREAD_NETWORK_PRIVILEGED permission doesn't
exist.
Bug: 326793058
Test: m ThreadNetworkUnitTests
Change-Id: I477cf30d737969ccf12180eae48d3b8fd6ed4a51
The API `createRandomizedDataset()` randomly selects a channel
between channel 11 and 26. But not all countries support channels
between 11 and 26.
This CL selects random channel from the preferred channel mask if
the preferred channel mask is not 0, otherwise choose one from the
supported channel mask.
Bug:b/308310823
Test: atest ThreadNetworkUnitTests && atest CtsThreadNetworkTestCases
Change-Id: I6add3edc7e4fa888c46b57c4463ab18e0aa84e80
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
Per CTS review comment in aosp/2949385:
```
You might want to make this a bit larger, otherwise if some new error codes are added in the future in a mainline update, already released CTS test packages will start to fail.
That should be fixed by mCTS, but since mCTS is not in place yet, it's best to be safe
```
This commit moves the too-large error code check into unit test to avoid
potential CTS compatibility issues.
Bug: 323791003
Change-Id: If99191630e1044cb8f5ed189bf79567cd51c3905
For ot-daemon to perform mDNS operations, we need to implement an AIDL
service NsdPublisher. MdnsPublisher forwards the calls to NsdManager.
For now, only register & unregster a service without a custom host is supported.
Bug: 320211657
Bug: 318323473
Test: atest CtsThreadNetworkTestCases
Change-Id: Ia392a0f57046f53973ac6bd6043dec915d170666
This CL is created as a best effort to migrate test targets
to the new android ownership model. If you find incorrect or unnecessary
attribution in this CL, please create a separate CL to fix that.
For more details please refer to the link below,
<add g3 doc link>
Bug: 304529413
Test: N/A
Change-Id: I243f17b3f0ad7af9ffa15ca242456e36688733f5
Merged-In: I243f17b3f0ad7af9ffa15ca242456e36688733f5
ThreadNetworkControllerService handles setEnabled requests and
asks ot-daemon to enable/disable Thread. The desired Thread enabled state
is saved in thread persistent setttings, the setting is loaded at bootup.
Bug: 299243765
Test: atest CtsThreadNetworkTestCases:android.net.thread.cts.ThreadNetworkControllerTest
Change-Id: Ifd0135433df25d9c6cfd3f365dd06ec7908268e7
The Thread country code should be a 2-Character alphabetical country
code. The `00` is an invalid country code for Thread country code,
but it is the default country code for WiFi country code. If setiting
the `00` as the Thread country code, the ThreadCountryCode throws
an exception.
This CL checks whether the country code is a valid Thread country
code before setting the WiFi country code as the Thread country code.
Bug: b/322404467
Test: atest ThreadNetworkUnitTests
Change-Id: Ic5fd69fc254ee25ad1e75e17096a5f5310a9140f
The ThreadPersistentSetting class can be used to read/store key value
pairs in ThreadPersistentSetting.xml file.
Bug: 299243765
Test: atest ThreadNetworkUnitTests:com.android.server.thread.ThreadPersistentSettingTest
Change-Id: I564ce8373e6af8f5cdf066a579bec46bfffecb72
Adds the Thread service unit test skeleton and make the services
testable.
Initially, a few trivial unit tests for existing APIs are added in
ThreadNetworkControllerServiceTest.java, and more tests will be added in
separate CLs later.
Bug: 317555104
Change-Id: I7b9e5f3663493d8da2448568de792e4272ee1df6
This CL adds resource overlay support to allow developers to
change the default configuration of using the location country code.
Bug: b/311324956
Test: Set the resource overlay in cuttlefish, check the default
configuration via the command `dumpsys thread_network`.
Change-Id: Ide853975e8244f06a382b2eda4844e030539b95d
This CL selects the Thread country code from location country code.
If the location country code is not avaliable, the country code `WW`
will be selected as the default Thread country code.
This CL also adds Shell commands for developers to override the Thread
country code for testing.
Bug: b/309357909
Test: Run `atest ThreadNetworkUnitTests`.
Change-Id: Id87c293005f0e75922a72854b40c41837b74397f
`setTestNetworkAsUpstream` allows to specify a test network as the upstream of Thread network. This is going to be used in Thread integration tests. E.g. android.net.thread.BorderRoutingTest.
Bug: 295843010
Test: atest android.net.thread.BorderRoutingTest
Change-Id: I66474e2aa5b3434c4c66078a1d6bd6e522e32ae5
Per API council feedback and API guideline at
go/android-api-guidelines#provide-executor, it should call
Binder.clearCallingIdentity() before invoking the app-supplied callbacks
so that the app doesn't use the system-server's identity for permission
check in the callback.
Bug: 309952666
Test: atest ThreadNetworkUnitTests
Change-Id: I3cfbce29c0a516506bb76a44b151a583c8477806
This commit renames `createRandomDataset` to `createRandomizedDataset`
and moves this method to ThreadNetworkController class.
The reason for moving this method is that we rely on the service side to
know which channels are currently supported by this device and there is
no safe way for ActiveOperationalDataset to created a randomized full
dataset by its own. Moving this method to ThreadNetworkController also
allows us to support future platform-dependend configurations.
Bug: 308117328
Bug: 307939803
Change-Id: I0b0b7b727c3b326ab59bb1299ace15df1ff1ad5e
OperationalDatasetTimestamp is saving the timestamp as an Instant
object, and this has the problem that when the dataset timestamp is
written to a TLV, it's going to loss precision as the nanoseconds
of the Instant is converted to "Ticks". This results in bug that
the dataset timestamp doesn't equal to the same value when it's
converted back from a TLV:
```
var timestamp1 = OperationalDatasetTimestamp.fromInstant(Instant.ofEpochSecond(100, 999938900));
byte[] tlv = timestamp1.toTlvValue();
timestamp2 = OperationalDatasetTimestamp.fromTlvValue(tlv);
assertThat(timestamp2).isEqualTo(timestamp1); // This fails!!!
```
Bug: 308408536
Test: atest ThreadNetworkUnitTests CtsThreadNetworkTestCases
Change-Id: I81b482a05337b6d1150edaa28b860034592a4347
Zhanglong Xia
commited 
Handa Wang
commited 
Treehugger Robot
authored and
Gerrit Code Review
commited 
Kangping Dong
commited 
Yang Sun
commited 
Vaibhav Devmurari
authored and
Ram Peri
authored and
Fangqiu Su
commited 
Joseph Murphy
authored and
Aditya Choudhary
commited 
Krzysztof Kosiński
commited