What happened
In a November 10, 2026 announcement, Google’s AI Edge and Android ML teams introduced on-device automatic speech recognition (ASR) and text-to-speech (TTS) capabilities in Google AI Edge Gallery. Google presents these as components for pairing with small language models such as Gemini Nano and Gemma 4, enabling applications to transcribe speech as it arrives and generate spoken replies without a network connection.
For Android, Google describes ML Kit GenAI Speech Recognition and Text-to-Speech APIs, with the underlying models managed through AICore and its on-device speech services. The recognition API streams partial and final transcripts and accepts audio from a device microphone or external streams, including smart glasses. Google reports multilingual recognition across more than 100 languages, an 8.0% to 9.0% Word Error Rate on FLEURS, and transcription at ten times real-time speed—about 300 ms for three seconds of speech. The company also says the system cuts end-to-end speech-translation wait times by 35% to 44%. Android’s speech models are integrated into the operating system, so Google says they add no APK size; hardware acceleration and background model updates are handled by the platform when available.
Google’s Android TTS API uses a compact, few-step diffusion model. The announcement says it begins speaking in about 100 ms, generates 24 kHz audio at up to 50 times real-time speed, and supports eight expressive voices across 21 locales. Google reports that a 27-second paragraph is synthesized in about 500 ms, with active device power more than 50% lower than for traditional autoregressive TTS models. The API also includes earcon support.
For cross-platform applications, Google describes MediaPipe Tasks APIs for iOS, macOS, Windows, Linux and web, with LiteRT powering the inference infrastructure. MediaPipe’s ASR task handles audio framing, configurable voice activity detection and decoding; it supports streaming, batch and hybrid transcription. The TTS task offers voice selection and low-latency streaming output. Google lists open-weight examples including Parakeet-TDT 0.6B, PocketTTS 100M, Kokoro-82M and Phonon 31M. Required model components and assets can be packaged in a single .litertlm file. The announcement says the updated AI Edge Gallery is available on Android and iOS, and points developers to Google’s code repository, APIs and model bundles.
What the archive adds
New Runtime’s earlier coverage noted Phonon TTS’s compact on-device speech generation and benchmark results in an earlier Field Note. This is a new Google product update, not a new Phonon release: the additional fact is that Phonon is one option in a broader local speech pipeline that Google now demonstrates alongside recognition, chat and app APIs.
Trend signal
This update fits the idea that generative media becomes more useful when applications can compose it as infrastructure rather than request a one-off output. Google’s announcement describes separate recognition and synthesis components, model bundles and APIs that developers can combine with on-device language models. That supports the pattern tracked in generative media becoming application infrastructure, though the announcement does not establish how broadly developers will adopt the approach.
Why now
Google frames the release around voice interactions on phones and wearables, including situations where Wi-Fi or roaming data may be unavailable. It says improvements in compact speech architectures make multilingual recognition and expressive synthesis possible locally, with low latency and a small memory footprint. The announcement does not tie the release to a specific device launch or deadline.
Why it matters
Teams building voice interfaces can now evaluate a local pipeline without assembling every low-level audio component themselves. On Android, the system-managed ML Kit route may reduce model-download and packaging work; cross-platform teams can instead use MediaPipe Tasks and LiteRT with the listed open-weight models. The example implementation also addresses practical details beyond model inference: streaming partial transcripts, switching languages and voices within a response, synchronizing spoken output with highlighted sentences, and avoiding competition for memory and compute while a language model generates tokens.
Those choices change the product trade-offs. Offline speech can preserve functionality where connectivity is poor and keep audio processing on the device, but it shifts attention to supported languages, device performance, memory use and the target platform. Google’s figures offer starting points for testing, not a substitute for measurements on a team’s own hardware, languages and real-world audio. Builders should compare the integrated Android path with the more configurable cross-platform path against the devices and interaction patterns they intend to support.
Limits and uncertainty
The performance, power and accuracy figures in the announcement are Google’s own claims; they are not independently verified here. The stated FLEURS Word Error Rate and speed do not establish results for every language, accent, microphone or noisy environment. The announcement does not provide a complete device compatibility matrix, memory measurements for each listed model, or comparative results across the cross-platform model bundles. Android’s hardware acceleration depends on availability, and the company does not quantify how performance varies when speech and a language model run together on different devices.
Skill to build now
Build a small test harness for one real voice interaction your application needs. Feed it representative audio and compare streamed partial transcripts with the final transcript, then measure time to first audio and memory use for one candidate TTS model on your target device. For Android, test ML Kit; for a cross-platform prototype, try a MediaPipe Tasks example. Keep the language, device and network conditions fixed so the results are useful for choosing an implementation.
Reader takeaway
Google has made a local voice pipeline easier to try, with an integrated Android option and cross-platform APIs that expose open-weight models. Treat its reported numbers as hypotheses to validate: the useful choice depends on your devices, languages and tolerance for the trade-offs of running speech and language models locally.