| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |\
| | |
| | |
| | |
| | | |
* changes:
Clarify use of InputType flags
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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)
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| |
| |
| |
| |
| |
| | |
BUG=1751496
Automated import of CL 144001
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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).
BUG=1735619
Automated import of CL 143540
|
| |
| |
| |
| |
| |
| |
| |
| | |
The hardware keyboard doesn't have all the accents needed for
Czech and Polish, so round out the selection.
BUG=1742856
Automated import of CL 143495
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | |
| | |
| | |
| | | |
Change-Id: I2205eebae419eaf4a0992c9f5b7cd807eb843fe1
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | |
| | |
| | |
| | | |
Bug 2024806
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 'c6eb5ac988518f41938c4f021003d6c202d84819'
* commit 'c6eb5ac988518f41938c4f021003d6c202d84819':
Fix issue #2018454: NullPointerException in ImageSpan constructor
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
* changes:
When you double-tap a word in an EditText, select the word.
|
| | | |
| | | |
| | | |
| | | | |
Bug 1978109
|
|\ \ \ \
| | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | | |
Merge commit '11ea33471e1a14a8594f0b2cd012d86340dd3bd8'
* commit '11ea33471e1a14a8594f0b2cd012d86340dd3bd8':
Allow for screen density drawables in compatibility mode.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
|\ \ \ \
| |/ / /
| | / /
| |/ /
|/| |
| | |
| | | |
Merge commit '7c187de14f6b5ec6d90bc8e26265a2ca2824e39a'
* commit '7c187de14f6b5ec6d90bc8e26265a2ca2824e39a':
Make the DatePicker respect the date format setting if the date is numeric.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
|\ \ \
| |/ /
| | |
| | |
| | |
| | |
| | | |
Merge commit 'c93af6dc5bc78f02d4ee549890da12dc669fc2fe'
* commit 'c93af6dc5bc78f02d4ee549890da12dc669fc2fe':
Allow system colors in <font> tags
|
| | |
| | |
| | |
| | | |
Fixes http://b/issue?id=1970693
|
|\ \ \
| |/ /
| | |
| | |
| | |
| | |
| | | |
Merge commit 'b0b815da8c487bbfac6b2eadc91c619682720a71'
* commit 'b0b815da8c487bbfac6b2eadc91c619682720a71':
Always clear the TextView drag state whenever a touch begins.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |
| |
| |
| |
| | |
Make the date formats that want abbreviated month names use either
the full name or a numeric format.
|
| |
| |
| |
| |
| | |
In particular allow the French and Polish translators to put a space between
the number and the unit.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\ \
| | |
| | |
| | |
| | | |
* changes:
Manual merge from cupcake_dcm. Need to be reviewed by enf.
|
| | | |
|
|/ /
| |
| |
| |
| | |
There are corresponding changes to hardware/ril and packages/apps/Phone
that are required to go with these changes.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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).
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
The semantics of Config.DEBUG will be changing soon, and all other
Config.* fields will become deprecated/hidden.
BUG=1780938
|
| |
| |
| |
| |
| |
| |
| | |
Original author: takaoka
Merged from: //branches/cupcake/...
Automated import of CL 144002
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
characters.
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
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
text.
Original author: enf
Merged from: //branches/cupcake/...
Automated import of CL 143165
|
| | |
|
| | |
|
| | |
|