| b82b99e0420253bb59f8e32f9448b93712626c4e |
|
14-Jul-2010 |
Martin Hibdon <mah@android.com> |
am 216ba00e: Fix Bug 2835657
Merge commit '216ba00e6225ed9461fa1cbf5171ef3dd32a6e23' into gingerbread
* commit '216ba00e6225ed9461fa1cbf5171ef3dd32a6e23':
Fix Bug 2835657
|
| 216ba00e6225ed9461fa1cbf5171ef3dd32a6e23 |
|
14-Jul-2010 |
Martin Hibdon <mah@android.com> |
Fix Bug 2835657
If the bluetooth voicedialer was used while the
lock screen was up, it would sometimes get stuck
trying to keep the confirmation utterance. This
is fixed by holding a wakelock as long as the
BluetoothVoiceDialerActivity is present.
Change-Id: I8f07c5a7a6720d2bd36dfdc105ce95979699de6b
/packages/apps/VoiceDialer/src/com/android/voicedialer/BluetoothVoiceDialerActivity.java
|
| cfc085a842355f6f498a1b43079f2dc47cfe4500 |
|
02-Jun-2010 |
Jaikumar Ganesh <jaikumar@google.com> |
Update getState() Bluetooth Headset call.
Change-Id: I8b80b85cfadfe946a800c6c87a06bf472db3b077
/packages/apps/VoiceDialer/src/com/android/voicedialer/BluetoothVoiceDialerActivity.java
|
| ef5d3e8cd31873c7af4902986ae61b408d0343bb |
|
20-Apr-2010 |
Martin Hibdon <mah@android.com> |
Fix Bug: 2606879
The problem is that if the user leaves the VoiceDialerActivity
using the home button, when it is started again it never starts
listening. This is because all of the initialization is done
in onCreate, but the teardown is done in onStop. When the
activity is left using the home button, the activity is stopped,
but not destroyed, so onCreate is never called when the activity
is started up again.
This change moves the initialization to onStart, and leaves teardown
in onStop. It really doesn't make any sense for this particular activity
to be stopped or paused, if it's stopped at all it should be finished.
So now the onStop function also calls finish().
Change-Id: I4ddc7e329dfbf88d7b732191581877d9e5a3f0a3
/packages/apps/VoiceDialer/src/com/android/voicedialer/BluetoothVoiceDialerActivity.java
|
| 09c678b7092506b54f6c6ed8e21c176e0dc62d3f |
|
15-Apr-2010 |
Martin Hibdon <mah@android.com> |
Undo part of change I23cc8c1e
In this change, in addition to the changes I intended to
make, I accidentally reverted to a previous version
of BluetoothVoiceDialerActivity. Revert to the previous
version, except for the changes that I intended to make
to this file.
Change-Id: I2d680dcfc81300dac645990c11675c7b1a048118
/packages/apps/VoiceDialer/src/com/android/voicedialer/BluetoothVoiceDialerActivity.java
|
| 1b715dc663bd7155d996576774e487d31bf331f7 |
|
13-Apr-2010 |
Martin Hibdon <mah@android.com> |
Put the beep back into the voiceDialer
Bug: 2326485
Now the VoiceDialerActivity plays a beep just as it starts listening.
The hard part here is that we need the end of the beep to line up
pretty accurately with the start of the microphone listening.
If the beep happens before the microphone is listening, then the
user will start speaking too soon. If the beep happens after the
microphone is listening, then the sound corrupts the incoming sample.
The other difficulty is that the time to start the microphone varies
considerably from platform to platform, so there is no practical way
to time the beep so matches. So instead, the VoiceDialerActivity
will play the beep after the mic starts, and then pull the first part
of the audio sample off of the incoming stream.
The beep is 40 milliseconds long, but there is some lag in between
requesting the tone to play and getting it back on the mic.
Experimentally, pulling out the first 350 milliseconds of sample
removes the beep without losing too much else on both Passion
and Sholes.
Change-Id: I23cc8c1e3969fd94a27a44e9e0e8c4f0a5cd5c00
/packages/apps/VoiceDialer/src/com/android/voicedialer/BluetoothVoiceDialerActivity.java
|
| 2abf40fd5f901da1b6168aa778cbf7e6713a1e9b |
|
02-Apr-2010 |
Martin Hibdon <mah@android.com> |
Cherry pick e5258ff473c778362d612389db79b740e9c35911 into Froyo
/packages/apps/VoiceDialer/src/com/android/voicedialer/BluetoothVoiceDialerActivity.java
|
| 6444f225a32d6115035876f50f2090c16d0292fd |
|
31-Mar-2010 |
Martin Hibdon <mah@android.com> |
Cherry pick a3f9202fb99e2019baf437df68d00c705d7a93a1 into Froyo
/packages/apps/VoiceDialer/src/com/android/voicedialer/BluetoothVoiceDialerActivity.java
|
| 26775474a548d5aed4c3292c2600877dbac32d1a |
|
26-Mar-2010 |
Martin Hibdon <mah@android.com> |
Cherry-pick 78c3b0c9d52776b9487367360d3342d1ce29ef60 into Froyo
Change-Id: I4c080561e3727ce0c53040690cd0d298ab393ff6
/packages/apps/VoiceDialer/src/com/android/voicedialer/BluetoothVoiceDialerActivity.java
|
| 547ef32e060d291edb3cbdeca143799ad3e0ce5f |
|
31-Mar-2010 |
Eric Laurent <elaurent@google.com> |
Fix issue 2546651: Speech indistinct/ jarred when using voice dialer over BT.
Use stream STREAM_BLUETOOTH_SCO instead of STREAM_VOICE_CALL for TTS playback.
It is more appropriate as it corresponds to current user setting for the bluetooth
headset now that STREAM_BLUETOOTH_SCO and STREAM_VOICE_CALL are not synchronized
any more.
Also limit volume to an absolute max of -18dB instead of dividing it by 2 in order
to avoid saturation without impacting lower volumes.
Change-Id: I4576de363254b666bc3d4782693592b438f1d9ed
/packages/apps/VoiceDialer/src/com/android/voicedialer/BluetoothVoiceDialerActivity.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/BluetoothVoiceDialerActivity.java
|
| 8611523ea9031389812c54b2f65d2edc3bf0cb5e |
|
17-Mar-2010 |
Eric Laurent <elaurent@google.com> |
Use new method of BluetoothHeadset API to check if voice dialer over bluetooth is supported.
Needed for issue 2416481: Support Voice Dialer over BT SCO.
Change-Id: I720f7f08d1bad0d61e0d7a9afeb696fefed18761
/packages/apps/VoiceDialer/src/com/android/voicedialer/BluetoothVoiceDialerActivity.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/BluetoothVoiceDialerActivity.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/BluetoothVoiceDialerActivity.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/BluetoothVoiceDialerActivity.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/BluetoothVoiceDialerActivity.java
|