* commit '0b64976f19a3f03f80dfcd80b8894299d4dc71d7':
Revert "NumberPicker should adjust min and max when displayed values are set." (a.k.a. Santa is back)
* commit '0ee790408e19a2a820a080a8b4ad3af63d3a5eca':
Revert "NumberPicker should adjust min and max when displayed values are set." (a.k.a. Santa is back)
* commit '1586168302f79d10e85a5aeed7b486c4244cc98e':
Revert "NumberPicker should adjust min and max when displayed values are set." (a.k.a. Santa is back)
* commit 'e9812bae0e0ce08bd232dc2371fdb959e4f7a318':
Revert "NumberPicker should adjust min and max when displayed values are set." (a.k.a. Santa is back)
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
This reverted change was adjusting the min and max values for the NumberPicker
which is not desirable since it changes behavior and it will be possible for
an app that works on the current platform to crash on an older one. Also the
adjustment was not implemented correctly.
Updated the documentation to clarify the reltionship between the min value,
max value, and the displayed values array.
Bug:7518172
This reverts commit a1410e6789
Change-Id: I109f1b1f54c1e609941243cabab9241871b6b12b
ImageWallpaper runs on the main thread now and doesn't need to add
callbacks on different threads or lock against concurrent access.
Bug 7326921 fixed.
Change-Id: I6097e1dff8af743a4fb81b697efee0e02667125b
- keep the Error Drawable infos into the Drawables cache
- reset left/right Drawable state before resolving where to put the Error Drawable
- get the mirrored Drawable for the Error popup background
- set the Error popup position depending on the layout direction (so that the "triangle"
of the background is pointing to the middle of the Error icon)
One restriction: we load the Error popup background Drawable corresponding to the layout
direction of the System Locale. So if you set the Layout direction on a TextView (or
an EditText) to RTL and set an error to it when you are in a RTL System Locale, then you
see that the background "triangle" is not pointing to the Error icon. This is working as
intended as the AssetManager load the Drawable resource depending on the configuration
which is in that case the RTL one thus loading the RTL version of the background (and not
the LTR one).
Thus there can be a discrepancy between the "layout direction" of the TextView
and the one from the Error popup background. This would happen only thru using the SDK and
not in a normal case when running an App.
Change-Id: I91bbfbe46ac20efe0e585c5d4c766db23b5c709d
Backporting change made to AndroidHttpClient.java from
CL I0f3819e84542023fca65ec4a29534ef32e877570.
Bug: 7499444
Change-Id: Ie67d2917fa378afb00ec4bd7c3de238f48f7c6af
