Merge commit '88f2acb066f2b66a01807ad4f3d26ef575a1bf37' into eclair-plus-aosp
* commit '88f2acb066f2b66a01807ad4f3d26ef575a1bf37':
Add Turkish accented letters for G and S on the hard keyboard.
Merge commit 'eaa18dec91b6dd0ce3191a9ab65cdc95ef68b935' into eclair-plus-aosp
* commit 'eaa18dec91b6dd0ce3191a9ab65cdc95ef68b935':
scroll text field with touch
Add a hidden public method to text/method/Touch.java that
computes the maximum scroll amount for a text field.
Remove 'faketouch' code; it causes a crash and is
no longer required.
Pass the percentage of the current scroll from the UI
thread to webkit. One additional fix is to allow very
small movements which are currently disallowed because
they are smaller than 'smallerSlop' in WebTextView.java.
Companion fix is in external/webkit.
Fixes http://b/issue?id=2133049
Merge commit '193a6261894619985866220c320017f0831d6055' into eclair-plus-aosp
* commit '193a6261894619985866220c320017f0831d6055':
add hashCode() and equals() to Rfc822Token, as well as a convenience tokenizer method to Rfc822Tokenizer, as part of a calendar guest bugfix.
Merge commit '7f3fb7dec2afdffa37e3067ca8a5b9d01809a9ce' into eclair-plus-aosp
* commit '7f3fb7dec2afdffa37e3067ca8a5b9d01809a9ce':
Turn animations on by default.
Add API to skip the animation for a particular start activity, so that
a latter better one can be used.
Fix Theme.NoDisplay to actually work.
Fiddle with various animations: don't do a different animation for task
switching, try a scale animation for switching in/out of the wallpaper.
Adjust the animation duration so that at normal speed we have something
more like the slower animation option (so slow is now the default).
Change-Id: Ieba9f3db0bd9a762a19b327a3ecccbc7b547893d
Merge commit '12cc9d82a6f3bd2aebad8ed97a29e2cbad3ec77a' into eclair-plus-aosp
* commit '12cc9d82a6f3bd2aebad8ed97a29e2cbad3ec77a':
Add a new flag for IMEs to disable suggestions for certain fields.
Merge commit '0828beee503b99a8f38f456416592d4ed6c799ae' into eclair-plus-aosp
* commit '0828beee503b99a8f38f456416592d4ed6c799ae':
Add one more hardware keyboard character popup: \ if you hold /
Merge commit 'b6a7ea540ef9537bcedc707a87514e63438a533a' into eclair-plus-aosp
* commit 'b6a7ea540ef9537bcedc707a87514e63438a533a':
Reconcile the character popups for the hard and soft keyboards.
Merge commit '13bc4ad18bc401c2a80e7dde8cba18841d709a78' into eclair-plus-aosp
* commit '13bc4ad18bc401c2a80e7dde8cba18841d709a78':
Add "rtsp" to the list of URL schemes that get linkified.
Merge commit 'e989496e2bb7a64abe7336db1e728095ebc83a0c' into eclair-plus-aosp
* commit 'e989496e2bb7a64abe7336db1e728095ebc83a0c':
Make the hardkeyboard long press dialog look the same as that of soft keyboard.
Merge commit '56205fea879543a50bb797016832416a8b48cabb' into eclair
* commit '56205fea879543a50bb797016832416a8b48cabb':
Fix an emoji-measuring bug that caused an exception when editing a contact.
It was measuring the text to try to determine the size that it needed to
scale the emoji character to. Unfortunately it was accidentally trying
to measure the character under the cursor instead of the emoji character
itself, which is wrong, but more seriously doesn't work at all when the
cursor is at the end of the line.
This was already fixed before in change 144474, but that change never got
merged over to donut. So this merges it now.
Bug 2087915
Change-Id: Ib4804d330a029a966207b3b07271f84e6b2652c0
BoringLayout assumes it doesn't have to do any work to calculate the
line height. In this case, though, there may actually be work to be
done, so have it fall back to StaticLayout to do the more thorough job.
Bug 2051050
This unfortunately requires API changes because the existing text markup
classes had no access to the screen density.
TextPaint gains a "density" field so that TextView can pass the density
along. AbsoluteSizeSpan gains a new flag to indicate that its argument
is in dip instead of in physical pixels. LineHeightSpan gains an inner
interface whose chooseHeight() method includes a TextPaint argument so
it can get at the density. And when StringBlock creates the markup
objects, it now uses the density-aware versions.
Bug 1976971, Bug 2031746
Merge commit '11ea33471e1a14a8594f0b2cd012d86340dd3bd8'
* commit '11ea33471e1a14a8594f0b2cd012d86340dd3bd8':
Allow for screen density drawables in compatibility mode.
Merge commit '7c187de14f6b5ec6d90bc8e26265a2ca2824e39a'
* commit '7c187de14f6b5ec6d90bc8e26265a2ca2824e39a':
Make the DatePicker respect the date format setting if the date is numeric.
This change allows us to use drawables that match the current screen
density even when being loaded in compatibility mode. In this case,
the bitmap is loaded in the screen density, and the bitmap and
nine-patch drawables take care of accounting for the density difference.
This should be safe for existing applications, for the most part, since
they shouldn't really be pulling the bitmap out of the drawable. For
the small rare chance of them breaking, it worth getting the correct
graphics. Also this will only happen when there is actually a resource
of the matching density, and no existing apps should have resources for
anything besides the default density (though of course all of the
framework resources will be available in the native density).
As part of this, the bitmap density API has been changed to a single
integer provider the DPI unit density.
In some locales, there are no abbreviated month names; the abbreviated
date formats are essentially numeric. If the user is in such a locale,
have the DatePicker respect the date format setting so that the order
of the fields will match other numeric-only dates.
In locales that have abbreviated month names, continue to use the order
that is normal in spelled-out dates.
And update the order in updateDate() so that the new order is reflected
if you change the order setting and immediately go to change the date
without leaving and returning to the Date & Time settings in between.
At the same time, change DateFormat.getDateFormatOrder() back to working
the way it did in cupcake (prioritizing the date order preference over
the locale), even though the DatePicker no longer calls the method.
Bug 1805085
Some developers were confused about how to use the inputType field
and were omitting the class type when setting variations.
There are places in the framework where it specifically checks for
a class and variation before it invokes the desired behavior.
For instance, in EditText when setting the input type to a visible
password, it specifically checks for this condition:
inputType == (TYPE_CLASS_TEXT | TYPE_TEXT_VARIATION_VISIBLE_PASSWORD)
Apparently it can sometimes miss a touch release, which would prevent
the longpress menu from appearing if the location of the new touch was
too far from the location of the previous touch.
Bug 1673223
DateUtils.formatDateRange is using String.format which isn't efficient for
formatting large number of strings. I have added the Formatter parameter which
allows the caller to reuse the formatter of subsequent calls for faster
performance.
It is only used for numeric dates -- spelled-out dates have such a complex
variety of formats that they can only be meaningfully formatted from
locale strings.
In addition, the preference is left null when initializing, on the assumption
that the locale will still specify a more useful numeric format than we can
guess as part of a build-wide configuration.
But if the user has specified a format, the date will be formatted in the
order they asked for, with locale-appropriate punctuation substituted in.
The format strings are newly generated from CLDR. The code is once again
the same as in cupcake: do the natural thing for the locale if the user
has never specified, but follow the checkbox if the user has ever set it.
