Also the ability to start voice activities is turned off,
though for testing purposes it can be turned back on with a system
property.
Change-Id: I867704d32c53beeb851ceea9b45c28bf5c01ef61
We weren't taking care of the case of an upgrade to L. The main
change here is that the voice interaction service setting now has
an empty string when the user has explicitly said they don't want
one, so when it is null we will initialize it to its default.
Change-Id: Icdd30b4f09498f8928cea759a64628bd43bc5d0e
Issue #16739817 VIS doesn't start for non-primary user(s)
Issue #16709247 GSA is not the default voice interaction agent
These are both fixed by getting rid of the existing code for applying
the default voice recognizer, moving it in to the voice interaction
manager service, and extending it to also set up the default voice
interaction service.
Change-Id: If8d5936c28aebfa7eff77c8d99241c3a2ffdb0a4
Internally we pause the recognition when:
- a phone call is active/off-hook/ringing
- or some other application grabs the microphone
we auto-resume when the condition that caused us to pause reverses.
Both these events are notified to the client via callbacks so that they can choose to display on their UI,
that the recognition is paused for some reason.
Bug: 16515468
Bug: 16740806
Bug: 16514535
Change-Id: Ib274d68522c8cf37d42402c875b16159957657f0
Add sound model update callback.
Add native service state change callback.
Add vendor UUID in sound model description.
Add coarse confidence level in recognition event.
Add capture format in recognition event.
Bug: 12378680.
Change-Id: Id63437819ec7b9a4a69e1ff6185b747e20cad95e
Also annotate the flags with @IntDef to make things clearer and safer
Add more debug logging
Revert to start/stop being synchronous since telephony and microphone will
need to be handled internally.
Bug: 16731586
Bug: 16514535
Bug: 16549061
Change-Id: I83695d52e9547269c95d443e4d921c9238b7401e
- This is needed for telephony and audio integration which should happen via async callbacks
that'll end up starting/stopping recognition.
e.g. if a startRecognition happens when in a phone call - the onDetectionStarted will get called once the phone
call ends.
For now the transient stoppages due to internal reasons will not be propagated back to the client.
Bug: 16514535
Bug: 16515468
Change-Id: I1b2b8edd28f5c5e67c453f66c23e1a67a626114e
- Tie the sound model and keyphrase for simplicity
We won't support multiple keyphrases in a single model out of the box.
The db schema will need to be changed by the OEM wishing to add multiple hotwords.
This is because we currently have no way to test the flow and make sure that things work well with multiple keyphrases
and also the framework only reads the metadata for one keyphrase.
- Make the delete/update operations atomic
- Make the flow of data from Enrollment -> VIMS; the large sound model doesn't cross the process boundary any other time.
This is achieved by passing they key around, instead of the model themselves.
- Add a specific delete operation in DatabaseHelper rather than relying on emptying the keyphrases to delete.
Bug: 16555803
Bug: 16516353
Change-Id: I1e0cce137517502a669e431ca7e9f9f755598328
This helps us make the list sound models operation an async one, it also helps us
with the case where a detector is invalidated, so the client doesn't have to keep checking the
state.
Synchronize DatabaseHelper methods on its instance so that other VoiceInteractionManagerService
calls aren't blocked on db writes/reads.
It's still possible for the list operation to be blocked on update and vice-versa
Change-Id: Ib8ec4ac5056b62d443038560ce31d0641b4627b0
Add a callback for when any sound model change happens. This helps the VIS
to re-check the availability and either enroll the user, or start/stop recognition.
Also shut down any active recognition when VIS dies, or a different hotword detector instance is obtained from VIS.
Change-Id: I03f94e78c6ee307afe822a84aebc7e74c64de7b4
- Remove unnecessary recognition status from AlwaysOnHotwordDetector
- Remove unnecessary recognition started callback from IRecognitionStatusCallback
- Fix a bug around the fact that we weren't picking up enrollment at runtime because
we were storing the availability at instantiation time.
- Handle 0-length arrays in SoundTrigger classes while parceling/unparceling
- Fix issue in SoundTrigger helper where we were not comparing binders for start/stop calls
- Unload the previous model when starting a new recognition
- Add more debug logging
Change-Id: Icc56d7f3dd1ffa49a8cfeea49080e3ab4d342c32
the updateKeyphrase call is also used to clear out a sound model currently,
this happens when the sound model passed in has no keyphrases.
We can revisit if we need another deleteSoundModel method
- Also fix an issue with the way we were writing keyphrase to the DB
and when updating keyphrase, we actually addOrUpdate
Change-Id: Ib7250c2fdafef6bc40387912a79366c334d73292
...state changes.
Add a new API to tell the activity manager about a new dependency
one process has on another package. Start using it already for
when apps is Context.createPackageContext() to load code from another
app.
Also do some work on getting the monitoring of proc/uid states
in shape so it can be used by unundled code, along with an
AppImportanceMonitor class for doing so.
Some small fixes and additions to VoiceInteractionService.
Improve handling of unaccounted/overcounted battery use so that
they aren't shown to the user unless they are significant.
Change-Id: I22dd79a73f4e70103d3f8964494aebc8a31f971c
Add model management API skeleton to VoiceInteractionManagerService
Add an "interactor" for all always-on APIs
- The VoiceInteractionService will get an interactor for the given
keyphrase and locale.
- It can then check the availability and call methods to start and
stop recognition on this interactor.
- Add a common class to deal with SoundTrigger APIs
- Cleanup the keyphrase representation:
We now have separate representations for the keyphrase metadata and
a keyphrase being used for recognition.
This'll also help us to handle custom keyphrases in the
future easily.
This also ensures that for use within the framework,
we rely on the ID of the KeyphraseInfo rather than comparing the
text everytime.
Add a callback for the AlwaysOnHotwordDetector
This callback should be passed in by the VoiceInteractionService and is used to notify it
of recognition events.
Change-Id: I26252298773024f53a10cdd2af4404a4e6d74aae
class Keyphrase: replaced number of users by list of user IDs.
class RecognitionEvent: added capture preamble duration.
class KeyphraseRecognitionEvent: add keyphrase ID and explicit list of
user ID/confidence level pairs.
startRecognition(): takes a RecognitionConfig specifying the list of
keyphrases to listen to as well as for each keyphrase the recognition mode,
users and min confidence levels for each user.
Bug: 12378680.
Change-Id: I57036cc83b5d9e90512b8bb3f951af3a4a74c0ce
- We use a DB to store and persist the sound models.
- This'll be used by SoundTriggerModelManager, a service that lists,
deletes and registers new models. This'll be used by the enrollment
client to enroll and unenroll users.
- This needs the unique identifiers for sound model & keyphrases to be
present in the respective data structures
This is very early stage so please point out any concerns.
Change-Id: I82962895bf326167458f20e6ba995295551de025
New window layer that voice interaction service windows
go in to. Includes a new voice-specific content rectangle
that voice activities are placed in to.
Add specific animations for this layer, sliding down from
the top (though this can be customized by the voice interaction
service).
Also add the concept of activities running for voice interaction
services for purposes of adjusting the animation used for them,
again sliding from the top, but not (yet?) customizable by the
voice interaction service.
Change-Id: Ic9e0e8c843c2e2972d6abb4087dce0019326155d
This makes VoiceInteractionSession a more first-class
concept. Now the flow is that a VoiceInteractionService
calls startSession() when it wants to begin a session.
This will result in a new VoiceInteractionSession via the
VoiceInteractionSessionService containing it, and the
session at that point an decide what to do. It can now
show UI, and it is what has access to the startVoiceActivity
API.
Change-Id: Ie2b85b3020ef1206d3f44b335b128d064e8f9935
On the app side, requests are now composed by subclassing
from various types of Request objects.
On the service side, starting a voice interaction session
involves starting another service that will then manage the
session. This leads the service design much more to what
we want, where the long-running main service is very tiny
and all the heavy-weight transient session work is elsewhere
in another process.
Change-Id: I46c074c6fe27b6c1cf2583c6d216aed1de2f1143
This gives a basic working implementation of a persist
running service that can start a voice interaction when
it wants, with the target activity(s) able to go through
the protocol to interact with it. It may even work when
the screen is off by putting the activity manager in the
correct state to act like the screen is on.
Includes a sample app that is a voice interation service
and also has an activity it can launch.
Now that I have this initial implementation, I think I
want to rework some aspects of the API.
Change-Id: I7646d0af8fb4ac768c63a18fe3de43f8091f60e9
