secondary_user_on_secondary_display is for background users that have
access to UI on assigned displays (a.k.a. visible background users) on devices that have config_multiuserVisibleBackgroundUsers enabled. The main use case is Automotive's multi-display Whole Cabin experience where
passengers (modeled as visible background users) can interact with the display in front of them concurrently with the driver (modeled as the the current user) interacting with driver's display.
Tested on gcar_md emu
Flag: TEST_ONLY
Bug: 356700021
Bug: 354233217
Bug: 358707308
Test: atest --user-type secondary_user_on_secondary_display CtsThreadNetworkTestCases
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:b642178a9426f854f4496c07c8440d5ed417167c)
Merged-In: Iad7deb2c2715f6ef684ecc16b95a2fbbc7bb5260
Change-Id: Iad7deb2c2715f6ef684ecc16b95a2fbbc7bb5260
(cherry picked from commit 47b87650d1)
This is basically a revert of aosp/3079292 to disable the handling of
the airplane mode. The cause is that there are a few reported ANR issues
on real devices and they points to the handlers here in Thread module.
Before we figure out the root cause, let's disable the airplane mode
handler in Thread to recover the presubmit tests.
Bug: 353115531
Bug: 352484437
Bug: 350586929
Bug: 352316041
Change-Id: I569ced2855658f965ddf51242600ee3c325781a7
per offline discussion, it's better to provide support of customizing
any vendor-specific TXTs to make the solution more generic. The preivous
defined "vgh" TXT entry is deprected.
Bug: 343671003
Change-Id: I6e2804e346d04078b7d28bfdc18ed6c23c5c10e6
This commit fills in the ticks of active timestamp of randomly generated
dataset as defined in Thread spec.
Bug: 347838683
Change-Id: I5d8ba3ca7728e1890996fdd64198f7bc90bfb1fa
* changes:
[Thread] support ThreadConfiguration API at ThreadNetworkControllerService
[Thread] add support for configuration at ThreadNetworkController
Treehugger Robotauthored and Gerrit Code Reviewcommited 2024-06-24 10:03:18 +00:00
This CL adds methods for setting the ThreadConfiguration and
subscribing/unsubscribing to Configuration changes. The ThreadConfiguration
is used for controlling Thread features for the device.
Bug: 342519412
Change-Id: I9e20391eb3b2f20312a2cb0b587cc5bdf200d24d
It turns out context.registerReceiver(receiver, intentFilter,
permission, flags, handler) is not posting the receiver on the handler
and will result in ANR in activity manager if the receiver is blocked
This commit makes it safer by posting the receiver body to mHandler
explicitly.
Bug: 340368050
Change-Id: Ib6b8c0a8952ce43c935f39b0978f47268b108a79
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
Mayank Garg
commited 
Kangping Dong
commited 
Treehugger Robot
authored and
Gerrit Code Review
commited 
Yakun Xu
authored and
Handa Wang
commited 
Automerger Merge Worker
commited 
Yang Sun
authored and
Xin Li
commited