This commit replaces a regex pattern match for Linkify.PHONE_NUMBER
with a call to libphonenumber's PhoneNumberUtil.findNumbers().
Bug: 5533245
Change-Id: I0e0563b241fb62e77d7f49e4a8484c6b0685dd8f
This patch makes ZWSP (U+200B, zero width space) a potential line break
in text layouts. This is a fix for bug 8501809.
Change-Id: I18c1f8464e6c821ff75f819141bacc714a878700
Also rewrite @deprecated comments to use an initial capital so they
look right in the generated documentation.
Also improve formatIpAddress documentation.
Change-Id: I317ebe411ef76e16a4535318ce73e00b63af38da
- remove the ICU related methods and update the methods using the "reserved" argument
- update to CTS in another CL too
Change-Id: I5509736568c342d9d17bfeafc17951117ab5d3cc
Interesting nits about this:
- getMetaState(long) and getMetaState(long, int) do not
seem to be used anywhere in the framework. Maybe we
want to skip adding getMetaState(long, KeyEvent) and
getMetaState(long, int, KeyEvent).
- getMetaState(CharSequence, int) is used extensively
throughout the code. In some places, a KeyEvent is
available and should be considered - this change does
implement this. In many other cases, there is no
relevant KeyEvent for this action (for example,
Editor#extractTextInternal). In these cases, the
behavior is affected by the current latch state, so
it's fine to leave them as is.
Bug: 8303489
Change-Id: I4a948c497c49e48f83ba1048520e7fe5bfe84727
The DatePickerDialog is using DateUtils to format the dialog's title
and the DateUtils class does not work with dates outside to the
specified range.
For example, if user selects 2038-03-07, DatePickerDialog shows
1902-01-30 on Title.
The reason for the DateUtils class not being able to format dates
outside the range of 1902 and 2036 is because internally it is using
the Time class which does not support such dates.
To fix it, use Calendar class in DataUilts format method.
Steps to reproduce:
1. Settings -> Date & time
2. uncheck Automatic date & time
3. Set Date
4. choose any date before 1902 or after 2037
5. update wrong date on Title
Bug: https://code.google.com/p/android/issues/detail?id=13050
Change-Id: I003266765751b5c340426af84daef271f39f771e
Add support for the 'c' format character, required in many non-English locales.
Reimplement 'c' and 'E', and 'L' and 'M', so they correctly interpret 5-count
pattern characters.
Replace the old incorrect class documentation with a pointer to the
well-maintained libcore equivalent and the Unicode UTS to which these two
implementations are supposed to conform.
Deprecate the useless constants for pattern characters. No one sane is going
to write MONTH + MONTH + MONTH + MONTH instead of "MMMM".
Correct the documentation for getLongDateFormat and getMediumDateFormat.
Also fix DateUtils.getStandaloneMonthString for LENGTH_SHORTEST.
Tests are in https://android-review.googlesource.com/53291.
Change-Id: I4dda8b18070f05ccdc11c1f0a9381a9d233db4e8
The bug we're fixing here is that languages that don't
distinguish the "one" case grammatically (such as Japanese)
would say the equivalent of "In 1 day" rather than "Tomorrow"
because of the misuse of getQuantityString.
This has the side-effect of switching us over to the CLDR
strings for relative day names, which have consistent capitalization;
the Android donottranslate-cldr.xml strings varied even within
a language, so although this is a change, it seems like a step
in the right direction.
In a future change, we should actually push all relative
day formatting down into icu4c.
Bug: 7098707
Change-Id: Ia2f9af3d18c441d6093dd5da7956a3d0130e5b06
This cleans up a comment mentioning a private API and
declares constants for the return value of some public
functions.
Bug: 8303489
Change-Id: If06cc64952a572c506961e8125d0874428b5580c
This also fixes "dead key -> same dead key" combination.
Both these key sequences should only give the non-combining
version of the combining character.
Bug: 8158374
Change-Id: I51f01685dd2997c2c5316ce6aa4f10ac9354c877
