The test is currently based on old vts harness and not in vts suite.
Bug: 150383004
Test: atest VtsHalInputClassifierV1_0TargetTest
Change-Id: I5df4eff845fd49b8663d1589c5314d5acf4b5057
Merged-In: I5df4eff845fd49b8663d1589c5314d5acf4b5057
(cherry picked from commit 25a866eecc)
TODO for serial number support should be removed now that the feature is
implemented and merged.
Bug: 142654031
Test: Manual - comment only change
Change-Id: Ib733e71840e82e5cd9c47825a53f804f9c296a3d
Configuration files may now specify a list of serial numbers, or serial
number suffixes. These can be used to identify a USB peripheral,
regardless of what order the interface names are configured by the OS.
Bug: 142654031
Test: Manual
Change-Id: Idcdad1159b216119eb063df8bb229172a383b9ed
Merged-In: Idcdad1159b216119eb063df8bb229172a383b9ed
(cherry picked from commit 442b3badc8)
All aidl_interface modules should by default considered as stable, in
case it is used across system and vendor partitions, or across modules.
Like other API surfaces, we need to have a dump for the current
(yet-to-be-released) version and update it when there is an API change.
This is done via .
Then the owner of the interface can freeze the current version as a
numbered version via .
This change shal be rejected only when the owner is certain that the
interface is not used across the updatable boundaries.
Bug: 152655547
Test: m
Change-Id: Icc9c32aaf7f8555e6a3792bb5e5a2b48a446c545
All aidl_interface modules should by default considered as stable, in
case it is used across system and vendor partitions, or across modules.
Like other API surfaces, we need to have a dump for the current
(yet-to-be-released) version and update it when there is an API change.
This is done via .
Then the owner of the interface can freeze the current version as a
numbered version via .
This change shal be rejected only when the owner is certain that the
interface is not used across the updatable boundaries.
Bug: 152655547
Test: m
Change-Id: I93fba2721695a14e0eb4a2173066ce132228b895
All aidl_interface modules should by default considered as stable, in
case it is used across system and vendor partitions, or across modules.
Like other API surfaces, we need to have a dump for the current
(yet-to-be-released) version and update it when there is an API change.
This is done via .
Then the owner of the interface can freeze the current version as a
numbered version via .
This change shal be rejected only when the owner is certain that the
interface is not used across the updatable boundaries.
Bug: 152655547
Test: m
Change-Id: If899eb8ea77a20b0c097c61abe5bdab64cd6f487
All aidl_interface modules should by default considered as stable, in
case it is used across system and vendor partitions, or across modules.
Like other API surfaces, we need to have a dump for the current
(yet-to-be-released) version and update it when there is an API change.
This is done via .
Then the owner of the interface can freeze the current version as a
numbered version via .
This change shal be rejected only when the owner is certain that the
interface is not used across the updatable boundaries.
Bug: 152655547
Test: m
Change-Id: Idb1c34df81674321911e4a85f9e862b539a3f30c
All aidl_interface modules should by default considered as stable, in
case it is used across system and vendor partitions, or across modules.
Like other API surfaces, we need to have a dump for the current
(yet-to-be-released) version and update it when there is an API change.
This is done via .
Then the owner of the interface can freeze the current version as a
numbered version via .
This change shal be rejected only when the owner is certain that the
interface is not used across the updatable boundaries.
Bug: 152655547
Test: m
Change-Id: If47c5982894dc99a7f2d1767d64be60b491842c7
All aidl_interface modules should by default considered as stable, in
case it is used across system and vendor partitions, or across modules.
Like other API surfaces, we need to have a dump for the current
(yet-to-be-released) version and update it when there is an API change.
This is done via .
Then the owner of the interface can freeze the current version as a
numbered version via .
This change shal be rejected only when the owner is certain that the
interface is not used across the updatable boundaries.
Bug: 152655547
Test: m
Change-Id: Id167905590c0a596b0ed470ef668c47810966836
All aidl_interface modules should by default considered as stable, in
case it is used across system and vendor partitions, or across modules.
Like other API surfaces, we need to have a dump for the current
(yet-to-be-released) version and update it when there is an API change.
This is done via .
Then the owner of the interface can freeze the current version as a
numbered version via .
This change shal be rejected only when the owner is certain that the
interface is not used across the updatable boundaries.
Bug: 152655547
Test: m
Change-Id: Ia633e3a143b35626c59b2447c38c1710ee270f0c
All aidl_interface modules should by default considered as stable, in
case it is used across system and vendor partitions, or across modules.
Like other API surfaces, we need to have a dump for the current
(yet-to-be-released) version and update it when there is an API change.
This is done via .
Then the owner of the interface can freeze the current version as a
numbered version via .
This change shal be rejected only when the owner is certain that the
interface is not used across the updatable boundaries.
Bug: 152655547
Test: m
Change-Id: If547945d3bc8c8a73e2341ff9e90025ac10ce662
All aidl_interface modules should by default considered as stable, in
case it is used across system and vendor partitions, or across modules.
Like other API surfaces, we need to have a dump for the current
(yet-to-be-released) version and update it when there is an API change.
This is done via .
Then the owner of the interface can freeze the current version as a
numbered version via .
This change shal be rejected only when the owner is certain that the
interface is not used across the updatable boundaries.
Bug: 152655547
Test: m
Change-Id: I6fe1185e82d248deb021d8c75b4af7d9ca330db2
Adding support for extended format frames and remote transmission
request frames to canhalsend.
Bug: 149404884
Test: Manual
Merged-In: I330b9d24c34918b38612ddc1745f019e11bfd474
Change-Id: I330b9d24c34918b38612ddc1745f019e11bfd474
(cherry picked from commit 30bd3dce06)
I learned that we should be using PLOG to log errno strings, and we
should be avoiding stoi, stol, etc... conversions and instead use the
built in Android ParseInt/ParseUint functions.
Bug: 150250606
Bug: 150245058
Test: Manual for CLI tools, VTS for everything else
Merged-In: Icdd8a6af8564d5de3bedd1bc934f7928eb5e66e9
Change-Id: Icdd8a6af8564d5de3bedd1bc934f7928eb5e66e9
(cherry picked from commit 1173a7253b)
In current code, VTS tests checks on null pointer using EXPECT_NE
then proceed with using the variable. This causes a null pointer
exception when the test fails.
This commit replaces the EXPECT_NE with ASSERT_NE to exit the test
on failure.
Bug: 152576797
Test: atest VtsHalWifiV1_0TargetTest
Change-Id: I5e54634020216f91144a234caf2b990de5706d8c
The way I planned for this to work doesn't work. We'll revisit in
Keymaster5. For now, removing IOperation and beginOp.
Bug: 152536287
Test: Build & boot
Change-Id: I017d17079380cc3bacc6f05b2486e1b6e6c3f675
