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
When starting the voiceDialer, there is a tone played to indicate that the microphone is listening. It's important the tone not be picked up by the mic and sent to the recognizer engine, or it will corrupt the sample. Prior to this change, the VoiceDialerActivity would simply pull a fixed 380 milliseconds of audio from the microphone inputStream. This works, but may not be reliable on all hardware platforms because the size of audio buffers and performance of the audio system may vary. Now, the VoiceDialerActivity removes audio samples and attempts to detect the tone. When the tone ends, it stops pulling samples. If no tone is detected within 500 milliseconds, it times out and stops removing samples. Change-Id: Ic57ba1947fa0d315bec081bf03a32abb1a822fdf
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
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
…dialer over BT." into froyo
…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
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
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
…bluetooth is supported. Needed for issue 2416481: Support Voice Dialer over BT SCO. Change-Id: I720f7f08d1bad0d61e0d7a9afeb696fefed18761
…ing 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
* 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
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.
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.