| 85a421c6d6bf1fdbbee134d99c1a7450b00ce8fc |
|
28-Nov-2011 |
Daisuke Miyakawa <dmiyakawa@google.com> |
Recognize phone numbers without supported types
Currently VoiceDialer cannot show a candidate when it has a type
the recognition engine cannot recognize. For example if a
contact has one phone number with the type CUSTOM, VoiceDialer
never shows the person as a candidate even when a user ask so
("Call XXX").
This change prepares "fallback" phone number id and use it when
there's no other available ids with recognizable types, to support
the case above.
TESTED:
- Have a contact (say "Ada" here) with several phone numbers one
of which must have a custom type which isn't supported by
VoiceDialer ("CUSTOM"). Say "Call Ada" and see if that custom
phone number appears as another entry ("Call Ada")
- Try "Call Ada at home" or other voice command and see they work
as before.
Bug: 5585945
Change-Id: Idd0e539209cd14e786007e8ce0b121c165994c5a
/packages/apps/VoiceDialer/src/com/android/voicedialer/CommandRecognizerEngine.java
|
| 13a75ecbb8d8f6b4658dff832133d0fba574d62f |
|
04-Nov-2011 |
Daisuke Miyakawa <dmiyakawa@google.com> |
Re-introduce workaround for issue 3090362
This is originally I790da2e1ad1a37130ceaa2bd6cdb7cd779a5925c,
which happened to be ignored during auto-merge.
Bug: 5508989
Change-Id: Ida37ad9d0edf05538fdd9506571c0661463394d6
/packages/apps/VoiceDialer/src/com/android/voicedialer/CommandRecognizerEngine.java
|
| d3694c0511a27f1fb44fa2760ee0d4562ffe1066 |
|
08-Apr-2011 |
Joe Onorato <joeo@google.com> |
Remove the deprecated things from Config.java. These havent been working since before 1.0.
Change-Id: I097f48d9eec969553b34765a48ed652ea16c1a98
/packages/apps/VoiceDialer/src/com/android/voicedialer/CommandRecognizerEngine.java
|
| e5258ff473c778362d612389db79b740e9c35911 |
|
02-Apr-2010 |
Martin Hibdon <mah@android.com> |
Fix a problem with voicedialing on brand new phones
The code in VoiceContact runs a query to get all phones
from the contacts provider. It expects these phones
to be grouped by the person the phone is associated with,
but it actually sorts by LastContactedTime.
The comment indicates that this is done so that in case
there are too many contacts to fit into the grammar, at
least the most recently contacted will be the first ones
entered. These are probably the most likely ones to be
contacted again.
Normally, this works correctly. LastContactedTime is
actually a column on the Person table, so all phones
for a single person would have the same LastContactedTime,
and ties in this value are unlikely. However, when one gets
a new phone, or wipes data from an existing one, and
then imports contacts, all of them will have a LastContactedTime
of zero. Since they all tie, the order they come back from in
the query is totally undefined, and can't be expected to
group multiple phones for the same person together.
This breaks an assumption, and results in multiple grammar
entries for the same person, each of which contains a single
phone number, rather than the intention, which is one row
per person, with all valid phone numbers for that person.
So on a new phone, sometimes saying something like
"call john smith" will result in only a single method
of calling that person, even if john smith has multiple
phones.
Now, the sorting is done on both LastContactedTime and
DisplayName, so in case of ties in LastContactedTime,
same names should still be grouped together.
Also, make VoiceDialerActivity and BluetoothVoiceDialerActivity
use a new API to acquire and abandon Audio Focus. This
is an improved way of turning other media playback while
voice dialing, and allowing it to turn back on when finished.
Also correct some minor spelling errors.
Change-Id: Icc71bcf104bf2c02fdd8c03aa2749640561248e7
/packages/apps/VoiceDialer/src/com/android/voicedialer/CommandRecognizerEngine.java
|
| 4a330957ce5190ed86c57e0c65910359b866cba7 |
|
24-Mar-2010 |
Martin Hibdon <mah@android.com> |
Make the voiceDialer work again
Bug: 2537307
The recognizer has a limit on the size of each semantic value
in the grammar. Now that we are storing both the package name
and class name there, it's pretty easy to overflow that limit,
causing the grammar initialization to fail. With this change,
only the spoken word is stored in the grammar (i.e. "calendar").
The mapping of words to package name/class name is stored
explicitly in a hashTable inside the commandRecognizerClient,
which circumvents the recognizer's fixed limit.
Bug: 2497802
If the orientation changes while an alert dialog is up,
the dialog would leak and causes an assertion failure.
With this change the VoiceDialerActivity uses the more
modern system of using dialogs, which automatically
brings down and recreates the dialog upon orientation
changes. The BluetoothVoiceDialerActivity can't handle
this right now, it's state machine is much more
complicated. For now, it just forces itself to be in
protrait mode all of the time.
Change-Id: I127c860b6db51426a93daf1df2d71c1c32673de5
/packages/apps/VoiceDialer/src/com/android/voicedialer/CommandRecognizerEngine.java
|
| 27d520022f552e3e4b17b00d6ec4db9306fe7dea |
|
23-Mar-2010 |
Martin Hibdon <mah@android.com> |
Make the VoiceDialer handle "open" commands again
Bug: 2515380
The problem here was that the VoiceDialer app was assuming
that the packageName of a component can be derived by
dropping the last token of the className. Apparently this
is not true, the packageName as far as the packageManager
is not the name of the package in the java sense.
Now when adding all of the "open" entries to the grammar,
the CommandRecognizerEngine adds both the package name
and the class name, separated by "/".
Change-Id: I79fe7d12f8f3b1b6873fcf1161b3d06f3e5e17c8
/packages/apps/VoiceDialer/src/com/android/voicedialer/CommandRecognizerEngine.java
|
| 8c7aac011e578450a6837ed4ba55b1167c17bf46 |
|
13-Mar-2010 |
Martin Hibdon <mah@android.com> |
Now the BTVoiceDialer waits for TTS utterances to complete before moving on
When the BluetoothVoiceDialer is about to place a call, it uses Text To Speech
to indicate which contact is about to call. Prior to this change, it would
just place the call after waiting a few seconds, which did not always line up
with the end of the TTS utterance. Now it waits for the utterance to complete.
Similarly, when it is about to exit it says "goodbye" to let the user know
it's exiting, and it now waits for that utterance to complete before exiting.
Fix a bug in VoiceContacts that caused it to skip the first row
returned by that phone query. This meant that the first person/phone
would not be entered into the RecognizerEngine, and therefore was
impossible to call from the VoiceDialer.
Change-Id: I4150f652d8df9bdc4ce54d573426bba64d13ad27
/packages/apps/VoiceDialer/src/com/android/voicedialer/CommandRecognizerEngine.java
|
| 5f25619fecb3fda9b34f90eb1e333a89ec431583 |
|
05-Mar-2010 |
Martin Hibdon <mah@android.com> |
Simplify the state machine of the VoiceDialer
* Eliminate the Retry state from the Bluetooth Voicedialer. Now
if the recognizer returns zero results, it will simply return to the
Listening for Command state, and expect the user to state a new
"call", or "dial" command.
* The voicedialer is no longer allowed to open any applications when
running from bluetooth. There may be security problems with
applications coming up over the lock screen.
* Make the Bluetooth VoiceDialer handle error conditions better,
now it will display an error message and exit if the Bluetooth
connection drops, if the TTS system cannot be initialized, or if
the recognizer returns a fatal error.
* Make the VoiceDialerTester work again, so it should be easier
to test recognition accuracy from many different speakers.
Change-Id: Ic123648c22cf83598a641dd4cc664476261f5063
/packages/apps/VoiceDialer/src/com/android/voicedialer/CommandRecognizerEngine.java
|
| 7a55150b308ed03d41091e4c3ac693d6eb0ab145 |
|
24-Feb-2010 |
mah <mah@android.com> |
Improve bluetooth voicedialing support
Bug: 2432200
When using voicedialing without being able to see or interact with the
screen, it is more important to keep the number of matches small. There
is now a setting on the CommandRecognizerEngine called "minimizeResults".
If this is set, then the CommandRecognizerEngine will in most cases return
only the highest confidence result.
It will return multiple results only in the case where it is unsure which phone
to call a particular person on. When this occurs, the BluetoothVoiceDialer
will announce the person it is about to call, and which phone types are available
(i.e. home, work, mobile, other), then begin listening for the the user to
indicate which phone.
/packages/apps/VoiceDialer/src/com/android/voicedialer/CommandRecognizerEngine.java
|
| 78d0235501ca19dd38e2ab12ed60c3fa86199fce |
|
24-Feb-2010 |
Martin Hibdon <mah@android.com> |
Make Voicedialer support "open" commands again
Bug: 2460661
I had inadvertently removed the call to adddOpenEntriesTooGrammar,
so the open commands were not being recognized.
/packages/apps/VoiceDialer/src/com/android/voicedialer/CommandRecognizerEngine.java
|
| 64c64e7c25e6efe31fa53369ec49db442b68ff9a |
|
09-Feb-2010 |
mah <mah@android.com> |
Add initial support for Bluetooth voice dialing.
Bug: 2432200
This adds a new BluetoothVoiceDialerActivity,
because the flow for bluetooth is so different from the regular VoiceDialerActivity.
This involved breaking RecognizerEngine's direct dependence on VoiceDialerActivity to
make callbacks on. RecognizerEngine now makes callbacks on an interface called RecognizerClient,
which is implemented by several different helper classes for different reasons.
I've made RecognizerEngine an abstract base class, it handles some general setup, logging, etc.
but it is up to the subclasses to set up the grammar and handle the results when recognition
succeeds. There are currently two subclasses, the CommandRecognizerEngine recognizes
phrases to call people, dial numbers, and open applications. The YesNoRecognizerEngine recognizes
"yes" and "no".
Known issues as of this checkin:
* 8khz audio has not been validated, it's not certain that the Recognizer is getting a good audio stream.
* There is still a problem with audio routing, the TTS output switches randomly between the speaker and
the headset.
* only the simplest case is supported, there's not a clean solution when there are multiple
possible matches.
* there are cases where the activity really should wait for the TTS utterance to finish before
moving on.
* we don't have a solution for when the phone is locked and the user activates bluetooth voicedial.
* the flow may or may not be ideal, the "no matches, try again" option may not be useful. We will
let some people try this and then revisit the approach.
/packages/apps/VoiceDialer/src/com/android/voicedialer/CommandRecognizerEngine.java
|