I'm not familiar with Android, so I'm not sure about the capabilities of its client side speech recognition algorithms, but the short answer is that competent speech to text is currently a very, very intensive problem.
SR is roughly divided into acoustic and language modeling. The acoustic model proposes words that might have been said given some chunk of speech and the language model tells you what the most likely actual word is given what's been said.
The acoustic model can be solved in a large number of ways — though production technologies use very large hidden Markov models — but decoding a word sequence from speech might scale like O(knm^2) with n being the size of your vocabulary (often large), m the complexity of the acoustic model (# of phonemes modelled, perhaps) and k the number of acoustic frames. The n at the very least can be parallelized (embarrassingly), but the m and k cannot.
The language model involves a search through an exponential search space of orderings of words in the vocabulary (n^l choices, but l is also unknown). Anything sophisticated also will have an incredibly large (in memory) model as it has to have parameters across words, pairs of words, triples of words, grammatical categories, topics, etc. etc.
Solving both of these problems well simultaneously is not a task for a consumer computer. Speedy algorithms with small vocabularies and simple models exist and are implemented (Dragon Naturally Speaking, for instance) but Google didn't go and record a million hours of GOOG-411 to produce Dragon's technology over again.
---
Finally, there's a lot of work on front end signal processing in SR. Before you get into acoustic and language modeling, you often transform your input into another representation (often spectral components from sliding 10ms frames). A growing camp in SR research involves finding sparse front end representations of speech though. If the client-side software is capable of quickly computing a sparse representation of the speech, that could dramatically reduce the latency and bandwidth issues.
By the way, the reason Google is willing to spend this computational effort for your convenience is probably the same as GOOG-411. They are definitely recording every translation they do in order to use as a huge training corpus later.
SR is roughly divided into acoustic and language modeling. The acoustic model proposes words that might have been said given some chunk of speech and the language model tells you what the most likely actual word is given what's been said.
The acoustic model can be solved in a large number of ways — though production technologies use very large hidden Markov models — but decoding a word sequence from speech might scale like O(knm^2) with n being the size of your vocabulary (often large), m the complexity of the acoustic model (# of phonemes modelled, perhaps) and k the number of acoustic frames. The n at the very least can be parallelized (embarrassingly), but the m and k cannot.
The language model involves a search through an exponential search space of orderings of words in the vocabulary (n^l choices, but l is also unknown). Anything sophisticated also will have an incredibly large (in memory) model as it has to have parameters across words, pairs of words, triples of words, grammatical categories, topics, etc. etc.
Solving both of these problems well simultaneously is not a task for a consumer computer. Speedy algorithms with small vocabularies and simple models exist and are implemented (Dragon Naturally Speaking, for instance) but Google didn't go and record a million hours of GOOG-411 to produce Dragon's technology over again.
---
Finally, there's a lot of work on front end signal processing in SR. Before you get into acoustic and language modeling, you often transform your input into another representation (often spectral components from sliding 10ms frames). A growing camp in SR research involves finding sparse front end representations of speech though. If the client-side software is capable of quickly computing a sparse representation of the speech, that could dramatically reduce the latency and bandwidth issues.