The following are the updates to the fuzzer:
1. Randomised order of API calls using fdp.
2. Added New APIs.
exec/s: 35
Test: ./automotiveCanV1.0_fuzzer
Bug: 301907840
Change-Id: I66b4622bcf93ac5fbead522f6991a62361b85dda
_LIBCPP_VERSION in external/libcxx is 8000. When _LIBCPP_VERSION is
newer, assume it's the new libc++ toolchain prebuilt, which has a
finalized std::filesystem, and use std::filesystem instead. To make
Soong happy, keep the android.hardware.automotive@libc++fs library for
now but stub out the C++ source files and make the
android::hardware::automotive::filesystem namespace an alias for
std::filesystem.
Bug: 152067309
Bug: 175635923
Test: treehugger
Test: m android.hardware.automotive.can@1.0-service
Test: m android.hardware.automotive@libc++fs
Change-Id: I7aede74cda0122434d972a075d7c7a9933845450
Let's move canhalconfigurator-aidl from the system partition to the
system_ext partition to share a common system image across internal
AAOS builds.
Bug: 263516803
Test: build and confirm the files are relocated
Change-Id: I54a65f49daff1ff4730056bc83b7dc57c836509d
Let's move canhalconfigurator from the system partition to the
system_ext partition to share a common system image across internal
AAOS builds.
Bug: 263516803
Test: build and confirm the files are relocated
Change-Id: Ibd68797aa9356e3e80662442434d939eca955576
Hardware address sanitizer is complaining about parseConfigFile. I
suspect the issue is that protobuf is taking a pointer to an ifstream
rather than a reference, unique_ptr, or shared_ptr. I _think_ this
results in some sort of attempt to access the stream after it's closed.
In order to get around this, I moved ownership of the stream up one
level so that the stream stays open for longer.
Bug: 263769296
Test: canhalconfigurator-aidl doesn't crash on seahawk_hwasan-userdebug
Change-Id: I937d501a4759f0781304c518b518beaf8c6fed68
Have the HIDL versions of libcanhaltools and canhalconfigurator provide
a warning message directing the viewer to use the AIDL version.
Bug: 170405615
Test: Build seahawk with AIDL CAN HAL and HIDL canhalconfigurator,
observe warning message.
Change-Id: I83a3dcedbdc5eafd3804e60950d0d8788cd6eddb
CAN HAL: now HIDL-free with 100% of your daily value of AIDL.
Bug: 170405615
Test: atest CanControllerAidlTest
Test: manually test slcan and socketcan hardware
Change-Id: I06bbb1379f4385e89757722c0276009b54cc7255
Some netlink attrib does not ending with null char.
Currently req.add string will always sending ending null character.
Add a new func called addBuffer that does not send ending null
character.
Bug: 238794143
Test: build, manual test
Change-Id: If51380cab95b2ae725673301b429b9e9889c5b0a
The memory alignemnt calculation is incorrect when adding request
with uint8_t data type.
Bug: 238756438
Test: Build, manual test
Change-Id: I4dae7ad337c6b8186e4ef0ae1fb5eb1e1463447d
evs and vehicle owners are already good, so did not touch.
Test: echo 'in TH we trust!'
Bug: yes, it bugs me
Change-Id: I6168956f7e21488f5fa6c4f0019c0885d074ba0e
VtsHalCanBusV1_0TargetTest needs buses brought up. On GSI images,
canhalctrl doesn't exist, so we have to attempt it on our own.
Bug: 213841914
Test: VtsHalCanBusV1_0TargetTest
Change-Id: I5553a95d047aef8e9d8e1eb6092cddea98f6d81e
VtsHalCanBusV1_0TargetTest needs buses brought up. On GSI images,
canhalctrl doesn't exist, so we have to attempt it on our own.
Bug: 213841914
Test: VtsHalCanBusV1_0TargetTest
Change-Id: I5553a95d047aef8e9d8e1eb6092cddea98f6d81e
Based on some back and forth on the internal IDL discuss group, it
sounds like we can't unregister interfaces anymore if they're defined in
the manifest. The CAN interface behind the HIDL interface will still be
taken down correctly, but this will get rid of the failing attempt to
bring down the HIDL interface.
Bug: 213841914
Bug: 213843613
Test: VtsHalCanBusV1_0TargetTest
Test: VtsHalCanControllerV1_0TargetTest
Test: VtsHalCanBusVirtualV1_0TargetTest
Change-Id: Iae4d6a650c30adacdc7c51140e0295915b516833
(cherry picked from commit d349f1d521)
Based on some back and forth on the internal IDL discuss group, it
sounds like we can't unregister interfaces anymore if they're defined in
the manifest. The CAN interface behind the HIDL interface will still be
taken down correctly, but this will get rid of the failing attempt to
bring down the HIDL interface.
Bug: 213841914
Bug: 213843613
Test: VtsHalCanBusV1_0TargetTest
Test: VtsHalCanControllerV1_0TargetTest
Test: VtsHalCanBusVirtualV1_0TargetTest
Change-Id: Iae4d6a650c30adacdc7c51140e0295915b516833
I should have checked for <=0, not == 0. Oops
Bug: 224850481
Test: TCU and HU don't burst into flames when pollerr happens.
Change-Id: I1b1d0855a588d065d29cad31b2ca40e4d981e086
nlproxy gets stuck if a POLLERR is encountered, and I found a CL that
suggests the only way to clear the error is to recv (which should return
zero bytes in theory) on that socket.
Bug: 224850481
Test: nlproxy works
Change-Id: Ib1420ce542deeb35977223baf787bdee1b125110
Added SPDX-license-identifier-Apache-2.0 to:
automotive/can/1.0/default/tests/fuzzer/Android.bp
Bug: 68860345
Bug: 151177513
Bug: 151953481
Test: m all
Change-Id: Id04cc3a1ae434664be40944cc86c8ffc2e19db24
Each VTS module is required to have OWNERS file. The ownership is based on
go/vts-owners. For more information about ownership policy, please visit
go/xts-owners-policy.
Test: Tree Hugger
Bug: 143903671
Change-Id: I0f9790146d64200ccbfa364ba2e12d016c6d0629
Add a new wrapper for nl::Socket::send() that doesn't require
sockaddr_nl to be passed in, just a uint32_t pid.
Bug: 173213787
Test: manual - switch hu/tcu to use new send() function and verify that
they still work.
Change-Id: Iba49f8b3db35d96772fc0cc0a5b0aca5fb4ae307
