'a' and 'j' specify the intent to use 12-hour format,
and the locale default 12-hour format, and they shouldn't be used
in the same skeleton, because they contradict to each other.
A skeleton, e.g. "jmma", is mapped into "ahmma" internally
by #mapSkeletonMetacharacters, and thus the internal skeleton
has duplicated fields "a".
This is a regression when we moved the implementation of
android.text.format.DateFormat#getBestPattern() from
udatpg_getBestPattern in ICU4C to ICU4j DateTimePatternGenerator
in the CL https://r.android.com/1355735.
The expected pattern generated from skeleton of "jmma" is
"h:mm a".
Bug: 170233598
Test: DateFormatTest
Change-Id: I13929f4b5bc66aaa90e0cef666cf52d7c32122ac
They can be replaced by the public API provided by ICU4J instead.
No extra layer of caching equivalent to the LocaleData cache is
added because ICU4J has caches instances, e.g. DateFormatSymbols,
etc.
Bug: 160606356
Test: atest FrameworksCoreTests:android.text.format
Change-Id: I07048e0e1a4835d2744b7fce6a5ed79a112e456b
The methods can be implemented with ICU4J directly.
Bug: 160606356
Test: atest android.text.format.DateFormatTest
Test: atest CtsTextTestCases:android.text.format.cts.DateFormatTest
Change-Id: I3d5f639a94026c599b487563c95bf9d165adfeec
Add checks during boot in case the persist.sys.timezone property is set
to a bad ID.
This can happen in the rare case of a mainline rollback: i.e. if a device has
been set to a new ID and then the update is rolled back. Using GMT as a
fallback probably works without this change (it does in java.util.TimeZone),
but relies on all code, including native code that uses
persist.sys.timezone directly, knowing to interpret a bad ID as "GMT".
This commit makes that choice more explicit and defensive.
This change also removes the possibility of IOException, which is never
thrown, from some ZoneInfoDb methods.
Bug: 155738410
Test: boot with a valid id, verify persist.sys.timezone is unchanged
Test: boot with an invalid id set, verify persist.sys.timezone is "GMT"
Merged-In: I6dc0f4f81848efbbaec6a11a62014471a0ef01fd
Change-Id: I6dc0f4f81848efbbaec6a11a62014471a0ef01fd
Exempt-From-Owner-Approval: Approved / landed internally
These were previously being suppressed by doclava but with this change,
all failures are fixed and the suppression logic has been removed.
To fix the issues, there were a few possible changes made:
- broken reference to a public API (such as incorrect parameters): fixed
- unnecessary @link inside an @see tag: fixed
- @see referring to an @hide or @SystemApi: reference removed
- broken references to inner class constructors
- worked around by fully qualifying the constructor
Bug: 6963924
Test: make doc-comment-check-docs
Exempt-From-Owner-Approval: cherry-picked from master
Change-Id: Ifbdce2de96cdffa560bd90f549fa7184d1f9af85
Merged-In: Ifbdce2de96cdffa560bd90f549fa7184d1f9af85
(cherry picked from commit e0624c7a40)
We were centralizing without considering that there could be some
additional translation passed to DynamicDrawableSpan#draw
Test: atest DynamicDrawableSpanTest
Fixes: 154489406
Change-Id: I9615f478d1962b2d6fd54123fc391554073f5bf1
An earlier CL with benchmarks has shown that sending strings as UTF-8
is 50% faster for US-ASCII strings, and still 68% faster for complex
strings referencing higher Unicode planes. (So an improvement in
both cases!)
Since code across the OS still makes heavy assumptions about Parcel
strings typically being UTF-16, we need to carefully migrate
Parcelables by hand, which is what this CLs begins doing.
This is a purely mechanical refactoring with no functional changes.
Bug: 154436100
Test: manual
Exempt-From-Owner-Approval: trivial refactoring
Change-Id: Ia9e581efd7c40269342b7528ca07363deb843c0f
As ICU is updated, delete special cases.
Test: atest core/tests/coretests/src/android/text/EmojiTest.java
Bug: 151964652
Change-Id: I89032c22e5464d257866d926062db34c65943572
(cherry picked from commit 31d7c155b7)
Change Linkify to
1) use fallback context from activity thread when a valid context
is not passed in the API.
2) use default locale if activity thread returns null context
Bug: 144576376
Bug: 148514283
Test: atest com.android.frameworks.coretests
Change-Id: I145821d12b49fcd4036dafce27857547f293124f
Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library.
Bug: 145132366
Test: m && diff unsupportedappusage_index.csv
Change-Id: I288969b0c22fa3a63bc2e71bb5009fe4a927e154
Merged-In: I288969b0c22fa3a63bc2e71bb5009fe4a927e154
Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library.
Bug: 145132366
Test: m && diff unsupportedappusage_index.csv
Change-Id: I288969b0c22fa3a63bc2e71bb5009fe4a927e154
Convert some frameworks/base/ users of android.text.format.Time.format()
to use calculations based on java.time instead. This avoids future
Y2038 issues associated with Time. A TimeMigrationUtils method is
added that has similar localization behavior to Time's format() method.
This commit only contains a replacement for basic formatting usecases.
Later commits can handle more complex usecases.
The only case that modifies the format is the changes to
CalendarContract.java: the pattern used there was unusual and only
used in logging/debug logic which was switched off by default.
Bug: 16550209
Test: build / boot / treehugger
Test: atest FrameworksCoreTests:android.text.format.TimeMigrationUtilsTest
Change-Id: Ib142979858012bb766b4c107d41a21b0324de506
Merged-In: Ib142979858012bb766b4c107d41a21b0324de506
As documented in Effective Java (http://go/ej3e#page=259), overloaded
methods with the same number of parameters can be confusing when the
parameters are in the same type hierarchy.
Aside from readability concerns, this may be related to some crashes
observed in Photos Android. For example in b/144849105 AutoCompleteViewBinder
calls the SpannedString constructor, which delegates to SpannedStringInternal.
The overload of copySpans that accepts a SpannedStringInternal has a call to
isOutOfCopyRange that should make the failure in checkRange impossible.
Bug: 144849105
Test: Simple refactor.
Change-Id: I47d01cffe6f66c4d631a9ef1341bf118fb6e51e4
