SoundTriggerService is used by Now Playing to read DSP audio. Now that audio permissions are gated on process capability, we need this flag for system server to pass on its capability during the bind. With the new capability, permissions will no longer be denied.
Bug: 150508177
Fixes: 150508177
Test: todo
Change-Id: I79a18a9c98e5f36000f329bf15ca5a5f73826ffe
A forced recognition does not stop recognition.
SoundTriggerHelper had a bug where it assumed that it does, and so
future interactions would assume the wrong state and would eventually
erroneously use the underlying layers.
Bug: 147568295
Change-Id: I5ae69a8b292fda6aadc6011c4bf5cbc4d263a1ca
Per-model control to AlwaysOnHotwordDetector interface.
Models are selected by keyphrase and locale associated with the
AlwaysOnHotwordDetector instance.
Bug: 141929369
Test: tested manually with test app
Change-Id: Iffeb0954059fa030d8a4fefb934a3e665323be37
add support for model parameter control APIs with THRESHOLD_FACTOR
as the first supported parameter
Bug: 141929369
Test: Tested manually with test app and confirmed with GTS test
gts-tradefed run gts-dev -m GtsAssistIntentTestCases
Change-Id: I06874fcf2ae2ef8796e7c52c4475252e8a026e2c
Make sure mRecognitionRequested is reset when a failure
condition disables all recognitions: A stale value would
prevent from registering call and power state listeners
and properly update the states.
Also:
- In isRecognitionAllowed(), read current call and power
states directly from services if listeners are not registered.
- Also add missing null checks on mModule at various places.
Bug: 139268184
Test: repro steps in the bug
Change-Id: I763130b4d491a1a6a9e0756c7a18943e406ce73e
exposes sound trigger module properties to privileged
system apps with MANAGE_SOUND_TRIGGER permission
Bug: 139071862
Test: GTS test confirmed API accessible and providing valid data
Change-Id: Iec7ba6fc59912f44341fbe8d7f99193b9ead52f0
When stopping a recognition, do not unregister power save mode
listener if no recognition is active any more but only if no recognition
is requested. Otherwise recognitions suspended due to power save mode will
never resume.
Bug: 136978230
Test: Activate power save mode, plug USB and verify OK G works.
Change-Id: I426e11447fcde5c578ae2f64aa1fe18ef00fba0f
This limitation is being added to increase privacy protection.
Bug: 70619678
Bug: 117213117
Test: built android
Change-Id: Ic6ceed60a9687204fc7bf440becaa344a42d8e74
Updated logic to allow HotWord detection while phone is ringing (still
not off-hook).
Test: Manual Testing
Bug: 124762676
Change-Id: Idce6d39a5589aee6d5baa4e5bcd8d98b3e13b239
events.
This change should have been part of ag/5933708
Test: manual test with NowPlaying app on p19 device
Change-Id: I42ed7c17ebdd2cb75055122b8d45302e28c510b6
as regular recogntion events
The application will differentiate between DSP and app triggered
regcognition events.
Test: manual test with STTA and NowPlaying app on p19
Bug: 119386757
Change-Id: I4a3eb4da6ee6be35084fec8aaa3c495423d74033
Add @GuardedBy for simple functions that require locks and have a name in
one of the frameworks naming styles for locks ("^.*(Locked|LPw|LPr|L[a-zA-Z]|UL|AL|NL)$").
Derived by errorprone.
Bug: 73000847
Test: m
Change-Id: If70bb03313388af34d547efca20fb5115de95bf1
Currently we don't have a way of throttling sound trigger events without
upsettings the DSP.
Bug: 78212455, 78310504
Test: Played music while having song detection enabled. Saw songs being
detected
Change-Id: I3494d608f097532f02e6a588e22d9fe2d06048b1
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
If we skip an operation we used to just return. This lead to the service
staying connected, holding the wakelock and consuming power.
Hence after we skip an operation we need to check if we can disconnect
the service, basically treating skipping an operation similar failing
to execute the operation.
Fixes: 77766977
Test: Detected music via sound trigger service and triggered dropping of
operations
Change-Id: Ia837d628193b3a5c2763f4aae666193d624b6d7f
How that we have the SoundTriggerDetectionService we don't need the
pending intent based mechanism anymore.
Test: Checked that ambient music still detects music
Change-Id: If16c59028b31ff7d2e7f4d7f764460ac948ba946
Fixes: 73829108
It is not clear when the day should start. Further a day might have
25 hours in the case of daylight savings time.
Hence a day in this case is the last 24 hours, not a calendar day.
Keeping track of the time of each operation might waste memory as we
don't need that much precision.
Hence keep track how many operations were performed in the last 24
hours in buckets of hours. If the total count reaches a maximum suppress
any further operations.
The maximum is configurable via global settings. It can be updated
by apps that have the appropriate permissions. Hence if the default
value turns out to be incorrect, it can be adjusted after release.
This does not throttle based on battery state as it is better to
completely unload the sound model to not even have a detection event.
Test: atest SoundTriggerDetectionServiceTests (separate CL)
atest android.provider.SettingsBackupTest
Bug: 73829108
Change-Id: Ied8570b60b61b6a055bd2576d1502c1b36424efa
The service is meant to replace the PendingIntent based API. Once all
users of the PendingIntent based API switched the PendingIntent based API
will be removed.
To have as little as possible impact on the whole SoundTrigger framework
the RemoteSoundTriggerDetectionService class implements the same
interface as the PendingIntent based class. Hence the exising code has
very little change. Further once the old code can be removed the amount
of changed (and added) code is limited.
The RemoteSoundTriggerDetectionService -> SoundTriggerDetectionService
is a vanilla as possible service implementation. The special behaviors
are:
- The system holds a wakelock while service operations are in progress
and the service is bound as foreground. Hence the service can e.g.
listen to the microphone.
- Service operations have a certain amount of time they are allowed to
run. Once every operation is either finished or the the operation
exceeded the allotted time, the system calls onStopOperation for each
still pending operation. This is a similar model as for the commonly
used JobService.
Please note that if the time allowed for an operation is 15s and
op1 was run as 0si, and op1 was run at 5s, the service is allowed to run
until 20s. Hence _both_ onStopOperations will happen at 20s. This is
done for ease of implementation but should not give the service more
power than calling onStopOperation exactly 15s after each operation is
triggered.
- If an operation is done before the allotted time is reached, the
service can declare the operation as finished manually by calling
onOperationFinished. This is a call back into the system, hence a
'client' binder is sent to the service. If the operation is finished
by calling this method onStopOperation will not be called.
- As the service instance might be killed and restored between
operations we add a opaque bundle 'params' to each operations. The users
of the API can use this to send data from the start command to the
operations. It can also just be set to null. The params are not meant to
store changing state in between operations. Such state needs to be
persisted using the regular methods (e.g. write it to disk)
- A service can be used for multiple recognition sessions. Each
recognition is uniquelity defined by its sound model UUID. Hence each
operation gets at least tree arguments: Operation ID, sound mode UUID, params
- As a small optimization the params are cached inside of the service
instance.
The time allowed for each operation is in a @SystemAPI global setting,
so the service can make sure it finishes the operations before they are
stopped. It might take some time to deliver the operations via the
binder, hence it is not recommended to try to use every last ms of
allotted time.
Test: atest SoundTriggerDetectionServiceTest (added in separate CL)
atest android.provider.SettingsBackupTest
Change-Id: I47f813b7a5138a6f24732197813a605d29f85a93
Fixes: 73829108
When sending outbound callbacks on CELL_INFO and CELL_LOCATION, check to
make sure that the user has authorized us and the receiving app to get
information on their location.
Bug: 69637693
Test: manual: telephony testapp
Change-Id: Iacfc894428b11a7ec973567d7a797eedb281355f
The callback of the SoundTriggerService using the intent API used to try
and grab the same lock that other calls to the STS were using when they
accessed the SoundTriggerHelper.
This happens because most functions in the STH grab the STH's lock,
including the one that handles the recognition events. The recognition
event callback in the STS would then try to grab the STS lock, while
implicitly holding the STH one.
However, a concurrent call to the STS from outside could first grab the
STS lock, then call into the STH which may need the STH lock, resulting
in a deadlock.
By removing the requirement that the STS callback grab the main STS
lock, this condition is avoided.
Bug: 70346433
Test: On device
Change-Id: I44571fba786a82a17423d45f503be9537b476a01
so other components (system UI, settings, etc) can use them.
Bug: 68769804
Test: Build & presubmit
Change-Id: I30fe78e49d2187bee7c7aeba735cd9c26fc332a5
When invoking updateAllRecognitions, if a callback binder was determined
to have died, an internal function would go and remove it from
mModelDataMap. However, updateAllRecognitions was iterating over this
map, so it would then explode. By first making a copy of the model datas
before iterating over all of them, this problem is avoided.
(As part of trying to figure out what was happening, also updated all
the method names that implicitly assumed they had a lock, and double
checked that everything with a Locked suffix is actually locked)
Bug: 62487479
Test: Use the sound trigger test app to load and start two models, force
kill the app (so the dangling binders hang around), then enable power
save (which triggers the call to updateAllRecognitions)
Change-Id: I87b9dfc1b2af5e294050b146737916ccaad882c1
If some process tries to start a recognition, the STH will now check to
see if there are any other models that have been loaded and either:
- Have a callback that's died (determined by pinging the binder)
- Don't have a callback at all (meaning they didn't clean up after the
last detection and didn't start it again).
If it finds such a model, it will be stopped and unloaded, freeing up
resources in the HAL.
Test: Manually load model/kill the process and make sure that it is
unloaded the next time some other model is loaded. Also made sure
running models aren't evicted.
Change-Id: Ia1139b47afe5f88102a3773d90f4f056ea3cdc92
If an app has died while being connected to the sound trigger helper/the
binder goes away, we should stop and unload the model since there's no
way to get a handle on it again (without reloading the same UUID at some
point).
Test: Force stop the SoundTriggerTestApp while it has a model started,
trigger the sound model, then watch it get unloaded when the helper
notices that the binder is dead.
Change-Id: Iddfaaa03482d56e71f23e5982d4bd579f386b51d
The BatterySaverPolicy is designed to consolidate all battery saver
knobs into a central location. Usually it is consistent to
mLowPowerModeEnabled unless it gets different data for specific
service. By adding these knobs, we can effectively tune the battery
saver.
This cl sets up the framework for BatterySaverPolicy and updates
following service to get battery saver data from BatterySaverPolicy
1. GnssLocationProvider
2. VibratorService
3. WindowManagerService
4. BackupManagerService
5. SoundTriggerService
6. NetworkPolicyManagerService
Screen brightness will come in a following cl.
Bug: 34693888
Test: FrameworksServicesTests
Change-Id: I6b040e93391614b44d136a485faa4a332c396e51
If the recognition was aborted due to the service state being set to
false, clients were not made aware that the model had been stopped (but
would get a resume event).
Bug: 30233664
Change-Id: I9f663362ff142eadfd5ef727c5f0c941f8e9e89d
When the VIMS changes the implementation or has its implementation force
stopped, it used to stop all the recognitions that were in the
SoundTriggerService (without letting those clients know that they've
been stopped). Instead, the VIMS should just unload the keyphrases that
it loaded, so the other clients are not perturbed.
Bug:28518547
Change-Id: Ia70e8576f43cb8a8521c947ff7fc56f63cfbad54
