History log of /frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
f47f173b06e2972bb376da8ff11db3a83c21d10b 19-Feb-2016 Arunesh Mishra <arunesh@google.com> Fix AlwaysOnHotwordDetector recognition event bug.

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
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
a772e5fc062c8de48cb9c1d61755110f6b2e189b 25-Jan-2016 Arunesh Mishra <arunesh@google.com> SoundTrigger API improvements.

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
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
8cf8f71644643601fe8c3e9538fd00412b1ae8b1 15-Sep-2014 Sandeep Siddhartha <sansid@google.com> Fix issues with multiple languages and multi-users

For multi-user the issue was looking into the user ID of the current
process instead of the active user. The current process was the system
process and the call to UserManager was returning a user handle that
wasn't of any use while trying to map sound models to a user.

For language, the issue was that we were incorrectly just looking up the
model based on the keyphrase id, however we should have also taken the
enrolled model's locale into account.

Explicitly document that for model management the string representation of locales
is a BCP47 language tag.

Remove debug logging.

Bug: 16798166
Bug: 17462570
Bug: 17463511
Change-Id: Ieffb3e218de63f6e7f40af9705dced481a35b0ad
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
50c290406af81850a5d876754fd2bb4bd29df5d4 08-Sep-2014 Dharmesh Mokani <mokani@google.com> Remove old methods : AlwaysOnHotwordDetector

Bug: 17389896
Change-Id: I47d0ae3ecad0ce8a74ed65a73309faa541b74a06
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
ae686a51288031271685861436f7c67201791d09 04-Sep-2014 Dharmesh Mokani <mokani@google.com> Address API review comment:AlwaysOnHotwordDetector

- Methods creating an Intent should be named createFooIntent

Bug: 17389896
Change-Id: Icb9c9f9ca3a41fca09f79ff22b99988a1ded331f
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
ee16bdc33d32e923032073919ded1f2efe9677e1 25-Aug-2014 Sandeep Siddhartha <sansid@google.com> Address API review comments

- Make Callback an abstract class
- Split manage intents into 3 different methods
- Remove RECOGNITION_FLAGS_NONE

Bug: 17255602
Change-Id: I1329f889bb2ab35938f42d2ecfe755d2b17ec542
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
dcf3068fcb55f101680e70a8a6f84f3b2c9cb1e3 23-Aug-2014 Sandeep Siddhartha <sansid@google.com> Fix the Locale story in the hotword API

Tighten the API by taking in a locale rather than a string tag.
Tighten the checks when reading the enrollment metadata, bail out if any
attribute is missing or invalid.
Add missing recycle call for a TypedArray

Stop recognition when sound model(s) change. This is needed during
un-enrollment/re-enrollment.

Bug: 17187528
Bug: 17205230
Change-Id: Idb00b51ef8c4ea0a8f8993decea582223181fa3d
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
97887cf2555b395524ac4f9105c30a1a49c93684 11-Aug-2014 Sandeep Siddhartha <sansid@google.com> Merge "Remove direct field access from event payload" into lmp-dev
d5730bc88c24531d63ca4e818d7063498470b69e 09-Aug-2014 Sandeep Siddhartha <sansid@google.com> Remove direct field access from event payload

Change-Id: I0b4462e56a977bfbaaebd2dd31d9246051af1b99
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
6df952ec2208714d3206c54987eb388aee799be6 09-Aug-2014 Sandeep Siddhartha <sansid@google.com> Add debugging info to VIS via dump()

Change-Id: I9e8f4536de309256db835b30d94765bfc27d4e80
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
fd7070fdff6864abf750beaef697cc2fdb8c5eb9 08-Aug-2014 Sandeep Siddhartha <sansid@google.com> Add the capture session (and its availability) in the EventPayload

Keep it hidden till the API to start capture using a session isn't public

Bug: 16731718
Change-Id: I112dec307257739ef1e6c5c1e0358b6ecabe9a9e
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
cb4e81c7fe1ec843d80f7604a688c71086c23685 06-Aug-2014 Sandeep Siddhartha <sansid@google.com> Handle microphone contention/Phone calls while recognition is active

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
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
2178e2e085056186141ac44563103c6f455de89c 06-Aug-2014 Sandeep Siddhartha <sansid@google.com> Read audio format from the recognition event

Bug: 16549061
Change-Id: I9e418f7be67eb330b7bfaa97bbb90d0b5640469d
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
0db30899f0d44e4fbaddffb79cc3415db6efb657 04-Aug-2014 Sandeep Siddhartha <sansid@google.com> Use @IntDef for manage actions

Change-Id: I12473fb82bf865af36aaf681a1b12a19e9f218fc
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
d3b8223377b8046280e4c09e728edc600171f941 30-Jul-2014 Eric Laurent <elaurent@google.com> SoundTrigger API update.

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
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
2c0273e50a3162595e9a54030166f2369b039a5a 01-Aug-2014 Sandeep Siddhartha <sansid@google.com> Add a flag for multiple triggers with same recognition session

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
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
011dcbfa23b912bcfddbd8bd98c3202caf3de458 31-Jul-2014 Sandeep Siddhartha <sansid@google.com> Cleanup some documentation with @see references to constants

Change-Id: I1c9c4f25525732ecfecdf1faa91e0f24805ef295
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
668327d0286591324fa7592ee9b39255076e2165 29-Jul-2014 Sandeep Siddhartha <sansid@google.com> Tighten the checks around a detector being invalidated

Don't call back for a detector being marked invalid because
that happens when someone else obtains a detector or VIS shuts down,
in either case we don't want a loop where two entities keep creating new detectors
and being invalidated.

Don't call back on an invalid detector for availability change/detected/started and stopped
only propagate errors.

This helps us with cases where a callback for the previous VIS may get called and then crash because it
tries to make calls without being the current VIS.

In the new scheme of things, if the VIS changes, or the current VIS obtains a new AlwaysOnHotwordDetector,
the previous one is shutdown and internally marked as invalid and all calls to it fail with an IllegalStateException.

Bug: 16629417
Change-Id: I74417bf76ba80916ebc21b042c18b3467857733e
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
1ed12ddb8c46193cc4d790b9c7d6a5d61afb3311 29-Jul-2014 Sandeep Siddhartha <sansid@google.com> Make startRecognition async

- 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
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
6817337118655d5792e36e954b123e6daa4174a6 28-Jul-2014 Sandeep Siddhartha <sansid@google.com> Read the keyphrase ID from the recognition event

Bug: 16516658
Change-Id: Ibeee81c9543aa1091bb075066cfc2269107f13c0
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
39c12fab49075b715c253c68c84b5c10c3150197 26-Jul-2014 Sandeep Siddhartha <sansid@google.com> Use blob (shared memory) for large data in sound model/recognition event/config

Also add a missing null check in writeBlob

Bug: 16516353
Change-Id: Ie702f8daae541cab7c2cee6e13d49e7fc84c84e1
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
452a642430e3f8abfa053e48893dd0edfb12799b 25-Jul-2014 Sandeep Siddhartha <sansid@google.com> Fix various bugs with model management

- 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
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
f63bc523eadbe01ce0a5ad52868a5dccb3d5f6dd 22-Jul-2014 Sandeep Siddhartha <sansid@google.com> Make hotword availability a callback

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
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
6daae9622672e0b38fc2efed29f68061d749cacc 21-Jul-2014 Sandeep Siddhartha <sansid@google.com> AlwaysOnHotwordDetector needs to reflect enrollment changes

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
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
110f569b47bc21fb38ec25b6110ee302ce137e06 20-Jul-2014 Sandeep Siddhartha <sansid@google.com> Fix synchronization issues in AlwaysOnHotwordDetector

- 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
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
055897208d659e9734a82def88be4a806ff55448 18-Jul-2014 Sandeep Siddhartha <sansid@google.com> Move sound trigger calls to VoiceInteractionManagerService

- This ensures that any data being loaded on the DSP comes from the framework

Change-Id: Ie15f0994850ba8f298ca07c49fe0b89e066d9e2b
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
e6cd2476aa9d07df0de0a0081ab66d8401a7e228 11-Jul-2014 Sandeep Siddhartha <sansid@google.com> Add recognition modes to the enrollment metadata

This will be used by the Voice interaction service to determine what type of recognition may be run
on the DSP. e.g. If the DSP supports voice trigger only for the given keyphrase,
the voice interaction service may want to perform user identification at its end.

Also support keyphrase metadata for all keyphrases and locales.
In case the enrollment app supports open-ended keyphrases, it can leave the keyphrase text
to be empty
similarly, if the enrollment app supports all locales, it can leave the supported locales
attribute to be empty,

Change-Id: I782a17a877fc79ed569fa7c3a81697641182590b
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
8ecaf5f5cfd18e0436db1a27ccf46a063e9aacd7 11-Jul-2014 Sandeep Siddhartha <sansid@google.com> Hook in startRecogniton call

Add required info to the sound model database: users & recognition modes

Change-Id: I6e12cbc6342a2767c0e3d8328c0a3be899ac9952
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java
d7018200312e4e4dc3f67cf33dc90bf7ce585844 11-Jul-2014 Sandeep <sansid@google.com> Always on hotword changes

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
/frameworks/base/core/java/android/service/voice/AlwaysOnHotwordDetector.java