diff options
| author | Daulet Zhanguzin <dauletz@google.com> | 2020-07-09 17:02:27 +0100 |
|---|---|---|
| committer | Pete Bentley <prb@google.com> | 2020-07-10 09:02:15 +0000 |
| commit | 93b558169cfc0351a6195ac99cb74a8733aaf6fe (patch) | |
| tree | a69b7c59ad1f3b47ca11b850dfa4dd1ec29fc698 /ojluni/annotations/hiddenapi/java/util/TimerTask.java | |
| parent | 73b7233e26fd4c23916923d906f9340cd84f4202 (diff) | |
DateFormatSymbols.getInstance(Locale.ROOT) behaves more closely to
English locale for targetSdkVersion <= 29
In Android Q or before, when LocaleData class tries to load {@link
Locale#ROOT} data, en_US_POSIX
locale data is incorrectly loaded.
The class used to pass "und" string as BCP47 language tag to our jni
code, which then
passes the string as as ICU Locale ID to ICU4C. ICU4C 63 or older
version doesn't recognize
"und" as a valid locale id, and fallback the default locale. The default
locale is
normally selected in the Locale picker in the Settings app by the user
and set via
frameworks. But this class statically cached the ROOT locale data before
the
default locale being set by framework. Thus, in Q or before, en_US_POSIX
data is loaded.
As https://unicode-org.atlassian.net/browse/ICU-20273, an upstream bug,
is fixed,
ICU version 64.1 resolved inconsistent behavior of
"root", "und" and "" (empty) Locale ID which libcore previously relied
on, and they are
recognized correctly as {@link Locale#ROOT} since R. This ChangeId gated
the change,
and fallback to the old behavior by checking targetSdkVersion version.
Bug: 159514442
Bug: 159047832
Test: atest CtsLibcoreTestCases
Change-Id: I62207fcb104bbc5d1d970b57b13d8f8ecb1e1ba0
Merged-In: I62207fcb104bbc5d1d970b57b13d8f8ecb1e1ba0
(cherry picked from commit 7d61b511bd75e3b950fc3357e774eee5ac455776)
Diffstat (limited to 'ojluni/annotations/hiddenapi/java/util/TimerTask.java')
0 files changed, 0 insertions, 0 deletions