This was (mistakenly?) added in aosp/1267639 patchset 2; however, there
does not seem to be any apparent reason to post
trackAvailableInterfaces() to the back of the handler thread. All
operations that precede trackAvailableInterfaces() are synchronous.
Test: atest EthernetManagerTest
Change-Id: Ic8e888ce5d8909c4b7a00e26c54286c454ff3e75
Update isUidNetworkingBlocked to return false for system uids regardless
of firewall chain status since this is an actual behavior
Bug: 328732146
Test: TH
Change-Id: Ic4760b927f51a1229e9af09c79b5261f85fe89d1
This CL checks if the device supports Thread specific features before
running the test case ThreadNetworkControllerTest. If the device
doesn't support specific features, just skip the test case.
Bug: b/330879812
Test: atest ThreadNetworkIntegrationTests
Change-Id: I1452ab02cc62228102d4a140f39abf13b79542c7
r.android.com/3005052 changed the user id of the bpfloader service to
system, which cut off its access to /dev/kmsg, resulting in its logs
silently being dropped. Give back its access to /dev/kmsg.
See //system/core/init/README.md:
file <path> <type>
Open a file path and pass its fd to the launched process. type must be "r", "w" or "rw". For native executables see libcutils android_get_control_file().
and //system/libbase/logging.cpp's OpenKmsg()
Test: boot sdk_phone64_x86_64, check logs
Change-Id: I65f00545400140983737f3ff92e2c912eebce1fd
Theodore Duboisauthored and Maciej Żenczykowskicommited 2024-03-25 22:49:56 +00:00
When some of a custom host's addresses are removed, the services which
are using the custom host should be updated accordingly:
- For the services being probed, the probing should be restarted with
the updated address records.
- For the services which already finished probing, they should be
re-announced with the updated address records.
For example, here is a scenario where the fix is necessary:
1. Register a host (host1) with addresses (addresses1)
2. Register a service (service1) using the host1.
3. Unregister the host1.
4. Re-register the host1 with different addresses (addresses2).
Then the probing messages of the second registration of host1 may
conflict with the announcements of service1 (which containing addresses
records of the addresses1). This is an undesired conflict. Restarting
the announcement of service1 when updating the addresses of host1
can get rid of this conflict.
Bug: 327304356
Change-Id: Ie97b72f1482c69fb5f24eab3ce9ed8f7cea957ec
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
When calling a ot-daemon API, getOtDaemon() should always be used.
Access mOtDaemon directly can crash because it will be reset to null
when ot-daemon dies.
Change-Id: Id9941497fd43b1d57aba4bace31be0fbd9439c9c
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
(for now for better testing we don't make V special)
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: Id2835bd393c0ec9e1710644681bc5aab0d7d2aae
Maciej Żenczykowskicommited 2024-03-19 21:45:21 +00:00
Note:
2 == BPFLOADER_S_VERSION
19 == BPFLOADER_T_VERSION
25 == BPFLOADER_OBJ_AT_VER_VERSION
33 == BPFLOADER_IGNORED_ON_VERSION
37 == BPFLOADER_U_VERSION [*]
41 == BPFLOADER_V_VERSION [**]
and currently we have:
42 == BPFLOADER_MAINLINE_VERSION
43 == BPFLOADER_MAINLINE_T_VERSION
44 == BPFLOADER_MAINLINE_U_VERSION
45 == BPFLOADER_MAINLINE_V_VERSION
[*] udc-dev/udc-release are actually 38, as 37 was some earlier
udc beta2 (2.1 ifirc), and beta3+ switched to 38
[**] 24Q{1,2}-release (ie. U QPR2+) are technically actually 41,
but their platform bpfloader no longer even looks in /apex/com.android.tethering/etc/bpf/...
so it doesn't really matter (although 24Q1's platform
netbpfload still does, however that is obsoleted by
this change)
Thus we need to (as minimum for NetBpfLoad):
BPFLOADER_T_VERSION -> BPFLOADER_MAINLINE_T_VERSION
BPFLOADER_IGNORED_ON_VERSION -> BPFLOADER_MAINLINE_U_VERSION
to cause these to load appropriately from mainline.
One would perhaps also expect (as minimum for NetBpfLoad):
BPFLOADER_OBJ_AT_VERSION -> BPFLOADER_MAINLINE_U_VERSION
but (as maximum for platform bpfloader):
BPFLOADER_OBJ_AT_VERSION -> BPFLOADER_MAINLINE_U_VERSION
However, since the goal is actually for those to load via mainline on T+,
(with the 'old' version of the .o's loading on S via platform bpfloader)
thus one actually needs (as minimum for NetBpfLoad):
BPFLOADER_OBJ_AT_VERSION -> BPFLOADER_MAINLINE_T_VERSION
and (as maximum for platform bpfloader):
BPFLOADER_OBJ_AT_VERSION -> BPFLOADER_T_VERSION
Test: TreeHugger
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I4b688692ffca0db7ead20cefd9e7e892ca92c70a
Maciej Żenczykowskicommited 2024-03-19 21:33:55 +00:00
On Emulator system image, EthernetManager is not supported and it will
cause test crash when the "!!" operator is in place. Therefore, we
should skip the test before the lazy evaluation.
BUG: 323896504
Change-Id: I0f6f7bbb8ff7394730b193cf3f4ab5d89e65fa96
Signed-off-by: Weilun Du <wdu@google.com>
Vendor or product extra apps/files can't be added to the generic system
image. Like below error:
```
FAILED:
build/make/core/artifact_path_requirements.mk:31: warning: vendor/google/products/cf_x86_64_phone.mk produces files inside build/make/target/product/generic_system.mks artifact path requirement. Consider adding this file to the system_ext or product partition instead. Confused? Ch
eck out go/artifact-error.
Offending entries:
system/etc/permissions/privapp-permissions-com.android.threadnetwork.demoapp.xml
system/priv-app/ThreadNetworkDemoApp/ThreadNetworkDemoApp.apk
```
Bug: 330097284
(cherry picked from https://googleplex-android-review.googlesource.com/q/commit:4c39c8f63edfa55edbd84a8473887df17ffe52fd)
Merged-In: I1b3723c12da44d80555aa35a86b9bae722845cb3
Change-Id: I1b3723c12da44d80555aa35a86b9bae722845cb3
Kangping Dongauthored and Android Build Cherrypicker Workercommited 2024-03-19 12:44:43 +00:00
Treehugger Robot
authored and
Gerrit Code Review
commited 
Patrick Rohr
commited 
Ying Xu
authored and
Kangping Dong
authored and
Motomu Utsumi
commited 
Yuyang Huang
authored and
Yang Sun
commited 
Zhanglong Xia
commited 
Xiao Ma
authored and
Theodore Dubois
authored and
Maciej Żenczykowski
commited 
Handa Wang
authored and
Paul Hu
authored and
George Verhaegen
authored and
Lisa (LeeWei) Liu
commited 
Chidera Olibie
authored and
Weilun Du
authored and
Android Build Cherrypicker Worker
commited