Fix for failing android.speech.tts.cts.TextToSpeechServiceTest#testSynthesizeToFile.
In test env, ParcelFileDescriptor instance may be EXACTLY the same one that client uses.
And if it's closed by a client, then service is prevented from writing anything to the output.
Bug: 8377754
Change-Id: I7f95aae1b877e543ab02d3c548b29537aa852a89
Recent TTS change altered how the TextToSpeech.synthesizeToFile method
operates. Previously, synthesis service was responsible for creating
output file. Now, client API creates a file and then sends opened file
descriptor using ParcelFileDescriptor.
On service side, I forgot to keep a reference to a ParcelFileDescriptor object.
When GC was removing it, it was closing underlying file descriptor, resulting
in a EBADF error for all following writes to the output file.
This change makes use of a ParcelFileDescriptor.AutoCloseOutputStream to keep a
reference to the ParcelFileDescriptor. It will be referenced until we are done
with writing.
Change-Id: I8327af0eaeabaebfbbd8816d959783e89086a7c5
In previous setup, synthesizeToFile method relied on synthesizer
service to create world readable output file. This is potential
source of vulnerabilities.
This change moves output file creation to the client side, and
synthesizer service receives already opened file descriptor.
This change may break applications that are creating files in
now unaccessible locations, like /sdcard/.
Bug: 8027957
Change-Id: I97351be5d2f2f8ef9aa43d0ab08c4b825ca4c22b
Second changeset, first one was committed too hastily.
TTS Voice-data related API was originally written with
one engine in mind (pico sVox TTS). It exposes implementation
details that should be private to the engine implementation.
- Deprecating fields of ACTION_CHECK_TTS_DATA results that were
used by sVox language packs to find out location of voice data.
Those fields are TTS engine implementation details and should be
private:
EXTRA_VOICE_DATA_ROOT_DIRECTORY
EXTRA_VOICE_DATA_FILES
EXTRA_VOICE_DATA_FILES_INFO
- Deprecating fields of ACTION_CHECK_TTS_DATA request that are
providing unnescesary functionality (it can be easily done on client
side):
EXTRA_CHECK_VOICE_DATA_FOR
- Deprecating some of the return codes of ACTION_CHECK_TTS_DATA - they
are specific to sVox pico voice data and in all cases can be replaced
by CHECK_VOICE_DATA_FAIL result code.
CHECK_VOICE_DATA_BAD_DATA
CHECK_VOICE_DATA_MISSING_DATA
CHECK_VOICE_DATA_MISSING_VOLUME
- Changing semantics of ACTION_TTS_DATA_INSTALLED intent. It's now
more generic and covers any change of available voice data set (so, not only
adding languages, but also removing them should trigger broadcast. Adding and
removing features to existing locale (like embedded synthesis) should be marked
by broadcast as well).
- Deprecating its EXTRA_TTS_DATA_INSTALLED result field - client should discover
the change by running ACTION_CHECK_TTS_DATA intent.
- Making GetSampleText intent public again - it's used by most TTS engines to
provide unique demonstation data.
- Deprecating TextToSpeech.OnUtteranceCompletedListener - it was replaced
by UtteranceProgressListener in API level 15, but no one put deprecation tag
on it.
Change-Id: Ia58af7f218dc1568570712f435782d2003260e82
TextToSpeech.shutdown() never worked properly if was called before receiving
onServiceConnected in connection object. Also, due to recent changes,
TextToSpeech.shutdown() did not work until async task created in
onServiceConnected returned its result to the main thread.
This change makes .shutdown() work in all those cases. To allow that
runAction can now execute code with connection that's not fully setuped
- so we can shutt it down. Also, newly created connection is now hold in
new member variable mConnectingServiceConnection, so it can be closed
before receiving onServiceConnected callback.
Also, I changed name of OnServiceConnectedAsyncTask to
SetupConnectionAsyncTask, I find it more descriptive.
Bug: 8003757
Change-Id: I41d84cfdb8fa28fe44235fb4a9764fa8f3d0643c
TTS Voice-data related API was originally written with
one engine in mind (pico sVox TTS). It exposes some implementation
details that should be private to the engine implementation.
- Deprecating fields of ACTION_CHECK_TTS_DATA results that were
used by sVox language packs to find out location of voice data.
Those fields are TTS engine implementation details and should be
private:
EXTRA_VOICE_DATA_ROOT_DIRECTORY
EXTRA_VOICE_DATA_FILES
EXTRA_VOICE_DATA_FILES_INFO
- Deprecating fields of ACTION_CHECK_TTS_DATA request that are
providing unnescesary functionality (it can be easily done on client
side):
EXTRA_CHECK_VOICE_DATA_FOR
- Deprecating some of the return codes of ACTION_CHECK_TTS_DATA - they
are specific to sVox pico voice data and in all cases can be replaced
by CHECK_VOICE_DATA_FAIL result code.
CHECK_VOICE_DATA_BAD_DATA
CHECK_VOICE_DATA_MISSING_DATA
CHECK_VOICE_DATA_MISSING_VOLUME
- Changing semantics of ACTION_TTS_DATA_INSTALLED intent. It's now
more generic and covers any change of available voice data set (so, not only
adding languages, but also removing them should trigger broadcast. Adding and
removing features to existing locale (like embedded synthesis) should be marked
by broadcast as well).
- Deprecating its EXTRA_TTS_DATA_INSTALLED result field - client should discover
the change by running ACTION_CHECK_TTS_DATA intent.
- Making GetSampleText intent public again - it's used by most TTS engines to
provide unique demonstation data.
- Deprecating TextToSpeech.OnUtteranceCompletedListener - it was replaced
by UtteranceProgressListener in API level 15, but no one put deprecation tag
on it.
Change-Id: I6609cde5c50236457f14955e2e7c0481b2b217ec
A recent change altered semantics of getLanguage call to return client
language instead of service language. This solved problems
with interferences between two clients using different lanaguages.
This change created a bug - new TTS client instance have no language set.
Since reading user preferences requires additional permissions I've
added new tts service method - getClientDefaultLanguage that will return
user preferences.
I've also added new client method, getDefaultLanguage, that allow easy
access to this data.
Bug: 7666482
Change-Id: Ieb7d2ba3a99d20c513add97f054874720a1cd82e
TTS input limit is now publicly available from getMaxSpeechInputLength()
static method.
Bug: 7456118
Change-Id: Ib2afbb7202ad9dc15895f322fbd1480a5f1f7278
Previously, onLoadLanguage was executed without minding synthesis queue.
Now onLoadLanguage is queued item, so it won't be executed before the items
on the queue (previously TTS could receivecall to onLoadLanguage
while synthesizing in completly different language).
I've divided SpeechItem into ControlSpeechItem and UtteranceSpeechItem.
Utterance one dispatches callbacks about synthesis progress.
Bug: 7510063
Bug: 5351864
Change-Id: Ibd156b3cecb190e5c07c4451e61121127b54d51e
Previously, getLanguage returned language set on the TTS service side.
In most cases client wants to receive value that was set on the Client side
(value that was set by last call to the setLanguage). That's true, for
example, for android settings app.
This is not an issue if there's only one client, or when all clients use the same
language. In that cases, service and client languages are in sync.
But if there are multiple clients using different languages, getLanguage might
return values that were not set by the client - and that's not what most of clients expect
to happen.
Change-Id: I5fd8313725e677c20fb2a84a087fc7555897bd30
ITextToSpeechService.setCallback (service rpc call) is no longer
executed on UI thread.
I kept OnInitListener.onInit being called on the UI thread. It's
not specified explicitly, but I don't want to introduce subtle
bugs.
+bonus import fix.
Bug: 6540404
Change-Id: I0136e7efeb374b605ed29ee8b3f550ec2bd2c356
Many media files and source code files were marked as executable in Git.
Remove those.
Also a shell script and python script were not marked as executable.
Change-Id: Ieb51bafb46c895a21d2e83696f5a901ba752b2c5
Clarification about when android.speech.tts.SynthesisCallback.done()
should be called.
Bug: 2481825
Change-Id: Ic781a6facc2d9acb3f06afb952fbac0b494c56cf
This fixes the issue where one thread calls .stop() on
mAudioTrack that was released (or being released) by other thread.
Bug: 7029291
Change-Id: Ia6db803e8ee40379b63327acf578466127cfabcb
- Sets the service connection to null when unbindService is called,
instead of in onServiceDisconnected. This avoids a double disconnect
if a call to onServiceConnected is received before a call to
onServiceDisconnected.
- Extended synchronize on runAction error handling and reconnection.
This prevents from reconnecting N times if N>1 threads enter this method
while there's issue with TTS service.
Bug:6993880
Change-Id: I5a387622c6032a18d17fc072029ae6be1a9b8e6c
- Fixes a strict mode violation, defers file validity checks
to when the engine starts synthesizing audio.
- Fixes some log spam when done() is called twice.
bug:6215680
bug:5415258
Change-Id: I4001be848b5208422d4091b7398e94ed311c649f
Will be seen when createStreamingAudioTrack() returns null,
which will happen if the audioflinger / audiomanager are unhealthy.
Also removes some confusing synchronization from this class.
bug:6636401
Change-Id: Iaf68a305665b7bc973898145e9cd1563e2569a2b
New action and extra for android.speech.RecognizerIntent:
ACTION_VOICE_SEARCH_HANDS_FREE
EXTRA_SECURE
Change-Id: I1f390ede4f4087bae1781347bb211dc0a093e857
Now uses a queue of runnables, one per synthesis. Also
introduce an abstraction that wraps AudioTrack that implements
the blocking semantics that we desire.
bug:5680699
Change-Id: I34a1248ff05766a7d9b3002055fb5b24aa9f230b
When stop() is called twice or after done().This relates
to bug 5662598 because users using the old deprecated API
will see two calls to onUtteranceCompleted.
bug:5662598
Change-Id: I5d59cf66b4f4c8650d3f8f9e503ac3f33132c0d0
We now use an IBinder object as an identity token of the
caller instead of Context#getPackageName.
bug:5680696
Change-Id: I1ca29e7161f709d2a85218206f3f117dfa620282
The TTS instantiated from here shouldn't clobber any
existing TTS objects opened within the same package context.
Ideally, the TTS API should work fine with multiple TTS object
instances within the same package context but making that happen
correctly is a larger change.
bug:5659758
Change-Id: Ia1f63c61b9f12ac92ff42a427a004d414e42a759
(a) onUtteranceCompleted should be called on errors too. Also,
fix up the error handling so that onUtteranceCompleted is
always called.
(b) Don't treat empty utterances as errors, and let the engine
synthesize them, as before.
bug:5662598
Change-Id: I9223592bc6fe5f47d71103f4f02f046b54a655a8
When synthesized files are written to app private data dirs,
they are written with owner/grp set to the TTS engine and
are inaccessible by the app itself. This is a reported regression
from gingerbread behaviour. Note that the dir in which the
engine writes files is itself already world writable.
bug:5523587
Change-Id: I2cb26c6f3c3d9cb3cedd60fab32c99a85a27f4b1
Also explicitly disallow locales with empty countries. This
is required to match them against the set of engine supported
locales.
bug:5309930
Change-Id: Ie9714fdc09d3081081a2393d97c31e3a42bca294
(a) Fix a null pointer exception, caused by a race condition
between stop / start calls.
(b) Fix a deadlock observed when multiple apps call stop() when
an item from one of those apps is currently being processed.
bug:5253061
Change-Id: I78533aecfda028588ce6aedb041009bc0a6f4620
This is made necessary by a bug when the utterance is smaller
than the audio buffer size. In that case, we call stop() to
flush the audio to the mixer, but that causes the playstate to
be set to stopped though some audio is still being mixed. This
breaks our waiting loop.
We now wait a fixed amount of time for such short utterances
and do not observe the playback head position.
bug:5220048
Change-Id: Ic81dec751c1faca0b14164caeda6305c8f9815fe
For each synthesis request, we inspect the number of
bytes of audio that have not been written to the mixer yet
and if that is above a certain threshold (currently 500ms),
we block the synthesis thread.
bug:5214603
Change-Id: I24c64c48466bdb96ce47b34cee7da2523ee5f0eb
It's at a very high priority currently - and will trump
foreground processes (and UI threads) which it shouldnt.
bug:5076001
Change-Id: I0d71c2941950782491ae31526a47ea6f97c38ffb
(a) Call stop() when we've written less than the
AudioTrack buffer. This forces pending buffers to
get mixed.
(b) Introduce a minimum sleep time to avoid spinlocks
if they system is busy
Change-Id: If70937e8b4e8c5d02d7dadc0d3086f97a10eb7ef
Also fixes a bug where PlaybackSynthesisCallback would
continue to pump audio to the audio playback thread after
being stopped.
Change-Id: I3233eb4858245b6e7c7df72e241a0708c668f1b4
