summaryrefslogtreecommitdiff
path: root/tools/aapt2/java/JavaClassGenerator_test.cpp
diff options
context:
space:
mode:
authorPhilip P. Moltmann <moltmann@google.com>2018-05-04 13:59:45 -0700
committerPhilip P. Moltmann <moltmann@google.com>2018-05-04 13:59:45 -0700
commita5b4403a1feea1148c9714986cbfdab116f17b35 (patch)
tree0d5903ad02db7706e08714c1b8c7c219bace30c7 /tools/aapt2/java/JavaClassGenerator_test.cpp
parent8aec7be10eb87507a5dc1d8e264c8b6225b1e185 (diff)
Simulate handling of event when throttling
When trottling we need to simulate handling of the event as otherwise the DSP gets upset and SoundTriggerService and SoundTriggerHelper get out of sync. (1) Currently the DSP requires to open and release the AudioRecord if a event was detected. Hence If we drop and event we need to do the minimal version of that (2) If a recognitions is set up with !allowMultipleTriggers the other parts assume that as soon as one even is handled no further will be needed. The other parts of the system are not aware of throttling. Hence even when throttled we have to destroy the service when !allowMultipleTriggers. We do this by splitting the ops into three parts. Setup (always executed): Takes care of problem (2) by checking the flag and setting the destroy-once-ops-and-handled flag Execute (not thottled): Send the op to the remote service Drop (Trottled): Do what is needed if the remote service is not involved. This handled issue (1) Test: Caused throttling and saw - AudioRecord started and released - service connection destroyed Bug: 78212455 Change-Id: I0ff81a7b38d07db1365be7ecc44e93cf329b32d5
Diffstat (limited to 'tools/aapt2/java/JavaClassGenerator_test.cpp')
0 files changed, 0 insertions, 0 deletions