Bug 3090362
The voicedialer only supports phones of type "home", "work",
"mobile", and "other". Any phone type with a different label
is not entered into the grammar.
If a particular contact has no acceptably labelled phones,
then the voicedialer will know which person the user is
trying to call, but will not find any phone to do it on.
There was code in CommandRecognizerEngine intended as a
fallback in this case, it would create a CALL_PRIVILEGED intent,
whose uri was actually a contact.
Trouble is, there is no application that handles a CALL_PRIVILEGED
intent with a contact.
The best way to fix this would be to return results for all valid
phones of the matching contact, and let the user select. To do
this in a multilingual safe way would require adding new strings,
which is something we can't do at this stage. Instead, we just
ignore any oddly labelled phones, and return no results if we
can't find an acceptably labelled phone.
Bug 2848091
The BluetoothVoiceDialer accepts several voice commands that
actually control the voice dialer itself, rather than invoking
some external action. (for example, "exit", and "retry".)
When these commands are recognized, the CommandRecognizerEngine
returns a special intent of type ACTION_RECOGNIZER_RESULT.
The BluetoothVoiceDialer finds this special intent and performs
the appropriate action.
Unfortunately, the regular VoiceDialer was not handling these
intents correctly. It was simply displaying the string extra
that came with the intent in the choice dialog, and if that choice
was selected, it would try to start an activity with the
ACTION_RECOGNIZER_RESULT intent, which fails.
Now, the VoiceDialerActivity removes any intents of type
ACTION_RECOGNIZER_RESULT from the list of intents it receives,
so it will only display results that can actually be executed.
Change-Id: I790da2e1ad1a37130ceaa2bd6cdb7cd779a5925c

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

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

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

…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

…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