History log of /frameworks/base/services/voiceinteraction/java/com/android/server/voiceinteraction/SoundTriggerHelper.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
45c00b5877e908f44853783b42deb437cfd30d94 17-Oct-2014 Sandeep Siddhartha <sansid@google.com> Don't unload the sound model on stopRecognition

This helps us in majority of the scenarios where the sound model doesn't
change across start/stop calls.

Bug: 17954633
Change-Id: Ibff817bb69bc69d2bb3a2603460fed596688b892
/frameworks/base/services/voiceinteraction/java/com/android/server/voiceinteraction/SoundTriggerHelper.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/services/voiceinteraction/java/com/android/server/voiceinteraction/SoundTriggerHelper.java
2475e38c10a02973665752e0b829153a5c493b28 10-Sep-2014 Eric Laurent <elaurent@google.com> SoundTriggerHelper: handle media server death

Retry to attach sound trigger module when startRecognition() is called.

Bug: 17373746.
Change-Id: I5b2f806b6cab47741d345be1cde73a84f5a62590
/frameworks/base/services/voiceinteraction/java/com/android/server/voiceinteraction/SoundTriggerHelper.java
efe0f9c7f2bdc10cfd28c186e68676e27b6944a1 23-Aug-2014 Sandeep Siddhartha <sansid@google.com> Turn off hotword when in power save mode

Bug: 15705459
Change-Id: Ifa8b80223affffdc00da467c2066bc6370c85af1
/frameworks/base/services/voiceinteraction/java/com/android/server/voiceinteraction/SoundTriggerHelper.java
6df952ec2208714d3206c54987eb388aee799be6 09-Aug-2014 Sandeep Siddhartha <sansid@google.com> Add debugging info to VIS via dump()

Change-Id: I9e8f4536de309256db835b30d94765bfc27d4e80
/frameworks/base/services/voiceinteraction/java/com/android/server/voiceinteraction/SoundTriggerHelper.java
6b8556d2e320b631d3741bf064796efddb6e51df 07-Aug-2014 Sandeep Siddhartha <sansid@google.com> Dump the state of SoundTriggerHelper for bugreports

Change-Id: I01a17d969fbd22c6bcbb161e3542ca14a3f8c7c8
/frameworks/base/services/voiceinteraction/java/com/android/server/voiceinteraction/SoundTriggerHelper.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/services/voiceinteraction/java/com/android/server/voiceinteraction/SoundTriggerHelper.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/services/voiceinteraction/java/com/android/server/voiceinteraction/SoundTriggerHelper.java
5e33fb057c20b84418d96574abe861e9d05956eb 02-Aug-2014 Sandeep Siddhartha <sansid@google.com> Stop recognition when shutting down VIS

Bug: 16629417
Change-Id: I9c98d7e6d487d3eaff604df401c320f8554589f9
/frameworks/base/services/voiceinteraction/java/com/android/server/voiceinteraction/SoundTriggerHelper.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/services/voiceinteraction/java/com/android/server/voiceinteraction/SoundTriggerHelper.java
299efbe1fbdca7bf2c852b67df3da361930f3ef2 30-Jul-2014 Sandeep Siddhartha <sansid@google.com> Don't unload sound model in start recognition unless the model changes

This helps in start -> detected -> start again scenarios

Change-Id: I6d8d55e469e0623b9eb07595df8897ad4942aa11
/frameworks/base/services/voiceinteraction/java/com/android/server/voiceinteraction/SoundTriggerHelper.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/services/voiceinteraction/java/com/android/server/voiceinteraction/SoundTriggerHelper.java
2e14dd46e16432fe264025087b57ce6ec71622a3 29-Jul-2014 Sandeep Siddhartha <sansid@google.com> Use keyphrase id from the recognition event

Bug: 16516658
Change-Id: I8be773eec39e1c4c57d106e03a443cbfc5c6dc5d
/frameworks/base/services/voiceinteraction/java/com/android/server/voiceinteraction/SoundTriggerHelper.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/services/voiceinteraction/java/com/android/server/voiceinteraction/SoundTriggerHelper.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/services/voiceinteraction/java/com/android/server/voiceinteraction/SoundTriggerHelper.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/services/voiceinteraction/java/com/android/server/voiceinteraction/SoundTriggerHelper.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/services/voiceinteraction/java/com/android/server/voiceinteraction/SoundTriggerHelper.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/services/voiceinteraction/java/com/android/server/voiceinteraction/SoundTriggerHelper.java