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
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.
Use a resource instead of a hardcoded string for the 24-hour format
since it is not exactly the same in every locale.
Make sure the 12-hour format is actually for a 12-hour clock, even in
locales where this is not a normal thing to do. In the cap_ampm version,
do not have it try to capitalize "am" and "pm" if these are non-ASCII
strings, since strftime() doesn't know about Unicode and will mess it up.
Add a comment so that people don't think the YEAR_IN_MILLIS constant is
actually the length of any real year.
Use java.text.DateFormat where possible, since that is already using
the CLDR data for the things it supports. Remove an unused date format
object from DatePickerDialog.
Add a new method for getting the standalone month names from applications,
although @hidden for now because it is an API change.
Pass the standalone month names down to native code in Time so that
tztime's strftime() can use them.
And then the bulk of the change: replace all the names for the months
and the days of the week, and AM and PM, and yesterday, today, and tomorrow,
with strings from CLDR. And replace several of the date format strings
with ones derived from CLDR, but reformatted to use strftime() style
instead of SimpleDateFormat style.
All these resource changes go into new donottranslate-cldr.xml files
and are removed from strings.xml so that they aren't part of the
normal translation process and the translators don't have to bother
with them (and risk messing them up).
TextView was previously following the "relaxed" line breaking
convention and would allow a line break between any two
ideographic characters. Tighten that up and do not allow
line breaks before non-starter characters (sound and iteration
marks and small Hiragana and Katakana).
Original author: enf
Merged from: //branches/cupcake/...
Automated import of CL 143678
The hardware keyboard doesn't have all the accents needed for
Czech and Polish, so round out the selection.
Original author: enf
Merged from: //branches/cupcake/...
Automated import of CL 143669
