Merge commit '592f1a65815598f705260df9dbe5488e3990b45d'
* commit '592f1a65815598f705260df9dbe5488e3990b45d':
Prevent the setLanguage() method in TextToSpeech to change the language
* changes:
Prevent the setLanguage() method in TextToSpeech to change the language for all current TextToSpeech instances by only caching the language value so it is used with each subsequent utterance for this instance. Synchronize calls to the engine around a global mutex since the engine isn't thread-safe, except for the stop() call which is meant to interrupt the synthesis loop.
for all current TextToSpeech instances by only caching the language
value so it is used with each subsequent utterance for this instance.
Synchronize calls to the engine around a global mutex since the engine
isn't thread-safe, except for the stop() call which is meant to interrupt
the synthesis loop.
Merge commit '2acbec4918db4ab6eca32cf427ffd771c9efe35f'
* commit '2acbec4918db4ab6eca32cf427ffd771c9efe35f':
add comment to illuminate why we only dismiss the dialog when launching an intent for in app search
Merge commit '9ff71d38a060476ba19deacf12ddaeef3cbac00d'
* commit '9ff71d38a060476ba19deacf12ddaeef3cbac00d':
whoops, still need to dismiss when launching an intent for in-app search
When a restore agent throws an exception back into the framework, assume that it
may have left the app's data in an inconsistent state and clear the data for
that app (again -- it was cleared just prior to the attempted restore, too).
Now that the search manager service handles hiding (not dismissing) and reshowing it
when the user hits back after launching a result, search manager can't cache
"mShowing". Also noticed a few other minor problems that was hosing the handling
of pause / resume to reshow the dialog, like moving some logic to onHide instead
of onDismiss.
When we parse the metadata we check that there is enough data in the parcel by checking
the byte availables and the size in the header.
Since the size is in the header has been read, we should make sure than dataAvailable() >= size - 4
This bug was hidden by some test code which has been removed.
Instead of calling remove(), which would hide the soft
keyboard, remove the WebTextView manually, so the soft
keyboard remains up (if it was up to begin with). WebView
will properly handle the keys now that the focus has
changed.
* changes:
Fix 1986313. WebKit assumes things happened in a certain order. In this case, we can't call LoadListener's nativeError until BrowserFrame's startLoadingResource returns. Otherwise, the failed request will not be removed from the DocLoader's request list. So the page will never finish loading.
Before, if dropDownAlwaysVisible was false,
the soft keyboard height was always taken into
account when calculating the available vertical space for
the AutoCompleteTextView drop-down height.
This meant that the drop-down would never pop over the soft
keyboard when navigating in the drop-down list.
This change makes the drop-down pop over the soft keyboard
when the keyboard is not needed, regardless of the value of
dropDownAlwaysVisible.
Fixes http://b/issue?id=1978935
That way we don't have to wait for clearsilver to write the thousands
of html files during every build.
(this is the frameworks/base change, there is also a build change)
A subclass of SurfaceView is created in order to appear like a normal
SurfaceView to jni but can be managed in Java easily. This class implements the
SurfaceHolder.Callback interface in order to notify the native PluginSurface
when the surface changes.
This does not change the actual thread priority but if the default priority
changes, this will have the desired result of being slightly less favorable.
I tried messing with the priorities to see if a higher or lower priority helped
but it seemed to do more harm than good. It might be worth more investigation to
find out where all the thread time is being spent so we can determine the
correct priority.
