* 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 a1410e6789ce72bc423793315a51aea8b6bad6c7
Change-Id: I109f1b1f54c1e609941243cabab9241871b6b12b
- When notifications vibrate as a fallback (that is,
because they want to play a sound but the device is in
vibrate mode), this no longer requires the VIBRATE
permission.
- As a bonus, if your notifications use DEFAULT_VIBRATE,
you don't need the VIBRATE permission either.
- If you specify a custom vibration pattern, you'll still
need the VIBRATE permission for that.
- Notifications vibrating in fallback mode use same
vibration pattern but can be changed easily in future.
- The DEFAULT_VIBRATE and fallback vibrate patterns are now
specified in config.xml.
Bug: 7531442
Change-Id: I7a2d8413d1becc53b9d31f0d1abbc2acc3f650c6
Display events in each batch received from IPC were being processed in
reverse order, and stopped after the first vsync event (latest
chronologically) was handled. This makes perfect sense for vsync
events, but is broken for hotplug events.
Now we process them all in order, handling all except vsync as we see
them. For vsync events, only the last is reported.
Bug: 7491120
Change-Id: I04528fea8f38c1013734d4aa92fb1955ac24d7cc
The new test is more general, allowing mobile RSSI to be
shown on devices without voice telephony.
Bug: 7490266
Change-Id: Ib5b243c0d92e74fe4385989c3a6c16edd00a9ec9
