This change adds a VTS test case to validate a new
IEvsCamera::importExtenralBuffers() API. New test case allocates
graphic buffers and passes them via a new API call.
Bug: 152493110
Test: vts-tradefed VtsHalEvsV1_1_TargetTest
Change-Id: I157f3cf45092a9a4ca8bf5bf9ea54aa62d15225c
HMAC key was created with Digest(Digest::SHA_2_256) which is missing in
the UseHmacKey function
Bug: 152932473
Test: VtsHalKeymasterV4_1TargetTest
Change-Id: If63dd197fe12172e14be9890ab07a00c3eef4a4c
This change introduces a new API to import frame capture buffers
allocated by the clients.
Bug: 152493110
Test: m -j and run /system/bin/evs_app --test --extmem
Change-Id: I679c61719e4d0e3a7d0c41110afe66e0a4ccb305
The stopAllRecognitions API is not used at the layers above the HAL, and
it requires the HAL to own the state of all active recognitions. This
API causes discontinuity with the upper layers also maintaining state
information.
The VTS requirement is being removed.
Bug: 151281377
Test: atest VtsHalSoundtriggerV2_0TargetTest
&& atest VtsHalSoundtriggerV2_1TargetTest
Change-Id: If14ed8177e0ff2730d2ed78ba8fbbbd058c4d57a
SoundTrigger VTS tests were duplicated in minor version updates.
This is not required and thus removed.
Bug: 151281377
Test: atest VtsHalSoundtriggerV2_0TargetTest
&& atest VtsHalSoundtriggerV2_1TargetTest
Change-Id: I60cfbe664cf7c38b2894d3e5f0df824737854c82
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
