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
The STH just needs to log the fact that a model has been stopped when it
is aborted. We also need to allow models to be stopped even if the
service is unavailable.
Bug:28474708
Change-Id: I2d618ae9c7c87311223f7d75b8ded7678252d11c
During stopAllRecognitions(), the internal state of a sound model was
being cleared (which made it look like the model was being unloaded).
However, the model was still loaded, so subsequent calls to load a 'new'
model would break.
Bug:28432002
Change-Id: I7090bf52704c6e46e3bb6d495d8fe4b8a1d9e2ad
This CL adds the ability in STH to manage multiple voice models indexed by
keyphrase ID, which is an integer.
Bug: 28104190
Change-Id: I8e10cca05ed8b4b8414cae7fffc26c132d4b7cbd
This CL redesigns and cleans up a lot of the core logic in STH.
Major changes include:
- Adds Tron logging based counters.
- Common startRecognition(), stopRecognition() and updateRecognition()
routines that work on both Keyphrase and Generic sound models.
- Common streamlined logic for when recognition is aborted, requested and
paused due to phone call/power save etc, for both keyphrase and generic
models.
- Special handling of the singleton nature of keyphrase models in
startRecognition().
- Moves all Keyphrase model state to the common ModelData structure.
- Adds Recognition pause/resume() for generic sound models so that they react
to power save, call state, recognition aborted due to service unavailable
etc.
Bug: 27972641
Change-Id: I96a7f567d2a4973facec556892a163ca74176bbf
Parcelables don't work well with inheritance. So changed the
IRecognitionStatusCallback to have onKeyphraseDetected() and
onGenericSoundTriggerDetected() for those respective events.
Made corresponding changes to AlwaysOnHotwordDetector and SoundTriggerDetector.
Bug: 27250528
Change-Id: Ic08a431e7cc4248c688b05c865348170246de576
When delete is called, now the STH unloads the corresponding models.
Fix bug with keyphrase where a delete call didn't unload (or stop)
the keyphrase model.
Bug: 27279380
Change-Id: Ia34f713d2aecef4102c0f0ccc57b8d2e5febe4bb
- Fix issue when multiple starts cause multiple spurious loads to be sent to
the native layer.
- Fix scrolling issue in the native app.
Bug: 27222043
Change-Id: Iddf36a8b68637f478dc23b001ecbde352db3a5f0
- Refactoring SoundTriggerHelper to handle generic sound models.
- Ability to store multiple models, callback and state information.
- Separate out initialization to be done per voice model, per any model
and per generic model.
- Minor change to the API exposed -- removing the Handler from the
createSoundTriggerDetector call.
- Added callback processing for onRecognitionEvent().
- Added logic for stopAll().
- Changes to the SoundTriggerTestApp to start/stop recognition.
- Multiple models (3).
- Ability to start/stop/load/unload individual models.
Bug: 22860713
Bug: 27222043
Change-Id: Ie5d811babb956bead653fb560a43f1e549ed11bd
This CL implements the SoundTrigger API improvements as given in b/22860713. Only the java-level
parts are implemented in this CL.
Key changes include:
* Addition of a SoundTriggerManager/SoundTriggerDetector system API to manage
the sound-trigger based sound models.
* Addition of a SoundTriggerService service that manages all sound models
including voice (keyphrase) and sound-trigger based models.
* Includes logic to write sound-trigger based models to the database.
* VoiceInteractionManager service now uses SoundTriggerService instead of
SoundTriggerHelper.
Bug: 22860713
Change-Id: I7b5c0ed80702527c4460372efeb5e542d3693a69
