This commit fills in the ticks of active timestamp of randomly generated
dataset as defined in Thread spec.
Bug: 347838683
Change-Id: I5d8ba3ca7728e1890996fdd64198f7bc90bfb1fa
This is to avoid running tests on devices that do not support Thread. Otherwise, the tests will fail with ClassNotFoundException when the test classes are loaded
Change-Id: I286394ae925ad7258aa82cd308ac963ee334992c
When developing and debugging a test case, sometimes the FTD may stuck and will not give any output. In such a case the test may time out after 1 minute (or longer). We should enforce a timeout (e.g. 5 seconds) when reading from its stdout so we don't have to wait for it that long.
Bug: 343885515
Test: CI
Change-Id: I766c172364106f19500032459de12ed6de38fb05
On U- devices, the ThreadNetworkManager class is not available, so we need to use the service name instead. And we should make sure Thread test cases runs on only devices that does has Thread feature supported.
Change-Id: Idd356062277a5180933789c7d471c70e2689350d
This CL lets NsdPublisher support resolving an mDNS host via one-shot
mDNS query. Because NsdManager not yet responds to such a query
properly, we cannot add an integration test for this. I've verified the
Discovery Proxy use case work properly on real devices.
Bug: 322434640
Test: atest NsdPublisherTest
Change-Id: Ie67f2fb9dd012408c123c354fc29f1a943280780
Only call onThreadEnableStateChanged() when the callback is registered
or the state has changed.
Bug: 342999416
Test: atest CtsThreadNetworkTestCases:android.net.thread.cts.ThreadNetworkControllerTest#subscribeThreadEnableState_getActiveDataset_onThreadEnableStateChangedNotCalled
Change-Id: I822d2b98b221c3312ff472b82ebb3e7e88e313fe
On some devices, Thread and Bluetooth HAL share a single UART device
and Thread HAL (hence ot-daemon) can't be started when the Bluetooth
HAL is disabled. When airplane mode is turned on, Bluetooth service may
receive the broadcast event first and disable the Bluetooth HAL. This
effectively stops Thread HAL and ot-daemon. When the
ThreadNetworkControllerService receives the death signal, it doesn't get
the airplane mode changed event from the system yet and so it tries to
restart ot-daemon. Then get blocked because ot-daemon can't be started
now (because the Thread HAL can't be started).
The proper fix is to allow enabling/disabling Thread HAL independent of
the Bluetooth HAL, so that Thread can function no matter Bluetooth is
disabled or not. But that may takes longer fix cycles, so here takes a
wrokaround by always querying the latest airplane mode value from
Settings.Global when deciding whether to restart ot-daemon in the death
handler.
Test: test on the real device that ot-daemon will not be requested to
restart when airplane mode is turned on
Bug: 340744397
Bug: 340236524
Bug: 340368050
Change-Id: I603d085d66a95b612c613ba07dc432ff0df135db
This commit tries to use network time as authoritative time source for
generating Thread operational dataset. If the time is get successfully,
the authoritative bit will be set in the dataset.
Bug: 340130726
Test: presubmit
Change-Id: Ibaca1f866be0be121763fdb63e02621809484b17
A summary of changes in this commit:
1. add new commands mirroring the java APIs: "join", "migrate" and
"leave"
2. Use THREAD_NETWORK_TESTING for guarding access to shell commands
which are for testing
3. Refactor ThreadNetworkShellCommand for readability
Bug: 329368792
Change-Id: Ibdb256674533704dc1d000a15c162f41cec5047f
The function is updated to throw IllegalStateException when called off
the handler thread.
Added the check for setEnabledInternal().
Bug: 342286647
Test: presubmit
Change-Id: I378b588af958bf4b913b32b096af1361f179c16e
@Test annotated methods are running in threads like
"Thread[Time-limited test,5,main]" which is created by FailOnTimeout.java,
while @Before annotated setUp() is running in thread
"Thread[Instr: androidx.test.runner.AndroidJUnitRunner,5,main]" which is
created by AndroidJUnitRunner.
The issue is that there are code in ThreadNetworkControllerService
checking all its methods runs on the thread associated to the provided
handler. This constraint doesn't hold in this unit test because
TestLooper runs all the posted tasks on the current thread rather than
the thread associated to its backed looper. So the tests will fail with
Log.wtf() which terminates the process on eng build.
This commit fixes this issue by annotating the test class with
@UiThreadTest to force methods annotated with @Before, @After and @Test
to run on the main / UI thread.
Test: run this test class on aosp_cf_x86_64_phone-trunk_staging-eng
Bug: 342092067
Change-Id: I7d75de5ac31234f3051e9ed332da33c1da6a8c98
OpenThread generates the link-local address randomly, so the kernel
shound't generate another lla again.
Bug: 305605130
Change-Id: I0ec79adf0de4edc6921703c3cc50cfcfe63b853b
This commit changes OpenThread to simulate on eth1 instead of loopback interface.
Bug: 329188649
Test: presubmit
Change-Id: I80a2842be02c03c5987ac8be8368fa86d7c6bace
This commit adds a basic multi-device test for Thread network.
Two nodes are used. One creates a network and the test verifies
the other one can discover it by Thread scan.
Test: presubmit
Bug: 329188649
Change-Id: Ice03015838bbf6fe836fac48c659a97850a89132
When there are thread devices with DUA in the thread network, BR itself
may not have a DUA address, so it doesn't have route to DUA in the
thread-wpan routing table. When thread device sends a packet from the
DUA to AIL via BR, BR rpfilter would drop the packet. Adding the route
to DUA prefix in thread-wpan solves this problem.
Bug: 335762753
Test: atest ThreadNetworkIntegrationTests:android.net.thread.ThreadIntegrationTest#addPrefixToNetData_routeIsAddedToTunInterface
atest ThreadNetworkIntegrationTests:android.net.thread.ThreadIntegrationTest#removePrefixFromNetData_routeIsRemovedFromTunInterface
Change-Id: I5ca8f7e723116a63718734f72f1b463d9c380329
Listens to airplane mode in Thread system service and enables/disables
Thread accordingly:
1. When airplane is on, disable Thread but don't persist the state
2. If Thread is explicitly enabled when airplane mode is on, Thread will
be enabled and the choice is remembered so that Thread will not be
disabled the next time airplane mode is turned on
3. If Thread is explicitly disabled when airplane mode is on, it will be
considered that the user wants to disable when airplane mode is
turned on, so Thread will be auto disabled the next time airplane
mode is turned on
The behavior described above is consistent with Wi-Fi and bluetooth.
Bug: 322742298
Change-Id: I1750922d9c304095e4114cddfbfe24d70d0e223a