| a192a8ced65ceea8bfe44f0eac6a394cbf80d936 |
|
11-Jan-2017 |
Roozbeh Pournader <roozbeh@google.com> |
Treat Latin American locales specially
Due to legacy reasons, Android translations of European Spanish were
kept under 'es', while Latin American Spanish translations were kept
under 'es-US'. The combination of this, and the new locale
preference rules in Nougat, resulted in 'es' winning over 'es-US' for
all Latin American locales, since 'es' was a direct ancestor, while
'es-US' was just a fallback.
The changes in Nougat had assumed that app developers would put Latin
American Spanish translations under 'es-419', but that could create a
backward-compatibility problem under older Android versions that did
not support three-digit region codes properly.
This CL keeps the Nougat logic and its locale parent tree, but
special-cases es-US and es-MX to be treated as equivalents of es-419
in cases where they are present and es-419 is not.
Bug: 31545805
Bug: 34126460
Test: unit tests are included
Change-Id: Iab26f41294587ee044685a5a6560520c7cbb06f7
/frameworks/base/libs/androidfw/tests/ConfigLocale_test.cpp
|
| 7e5f96f1a37e51164a594930ecc862a94cc8c231 |
|
14-Jun-2016 |
Roozbeh Pournader <roozbeh@google.com> |
Move matching Tagalog and Filipino to ResourceTypes.cpp
Previously, if a mix of "fil" and "tl" resources existed in Resources
(from mixing resources from libraries for example), only resources
from one or the other would be chosen, resulting in default resources
getting surprisingly used. Now, we resolve the equivalent languages
at a per-resource levels (breaking ties for the identical code).
Also, previously if both "tl" and "fil" resources were present in
assets, getLocales() could return a list with duplicate locales.
This change removes Filipino duplicates in the return value of
AssetManager::getLocales().
Finally, there was a bug in the replacement of "tl" with "fil" that
considered any locale starting with the letter "tl" to be Tagalog.
This failed in case of various languages, including Klingon ("tlh")
and Tlingit ("tli"). It's now fixed.
Bug: 29073000
Change-Id: I0e8b9ae337ced2e640a2575897948c4c5ca307d3
/frameworks/base/libs/androidfw/tests/ConfigLocale_test.cpp
|
| 7960898f6f886aadda1dd3d7a89106dde9f44217 |
|
04-Mar-2016 |
Roozbeh Pournader <roozbeh@google.com> |
Fix script-related parts of locale resource matching
Previously, a bit was kept to find if the script of a locale was
explicitly "provided" in a resource. This was not backward
compatible, and failed in some edge cases when the package was
created with older versions of AAPT that did not set the bit.
The cases would happen when the old resource had an explicit script
specified in its locale, but since the "provided" bit was not set in
the package, we would assume that the script was computed by us.
This CL replaces the "provided" bit with a "computed" bit, so the
default value of the bit (set to "false" for old packages) would be
correct.
Bug: 27156990
Change-Id: I99e7f1ad8f70c90e25ab3640ed34cc1a6f8d1d64
/frameworks/base/libs/androidfw/tests/ConfigLocale_test.cpp
|
| 4de4596ac1175908657f29cdc2a56529f2ca4b25 |
|
12-Feb-2016 |
Roozbeh Pournader <roozbeh@google.com> |
Fix locale matching algorithm for resources
We get ResTables two different ways: one is from AAPT, another from
settings-based requests from the Java side. In the settings-based
requests, localeScript will be autocomputed, but for AAPT-filled
tables (especially if they come from older versions of AAPT), we need
to compute the script.
Previously, locales that came from packages were incorrectly assumed
to have "undeterminable" scripts, rather than "undetermined" scripts.
This led to us mistakenly falling back to the old logic of requiring
the locales' countries to match, rather than just looking at computed
scripts.
Bug: 27157452
Change-Id: Id7e346d3ecfb17273ffb63de5bcb4849a6eafbbd
/frameworks/base/libs/androidfw/tests/ConfigLocale_test.cpp
|
| 27953c349fa1c46698f57ae5f26339560c21adac |
|
01-Feb-2016 |
Roozbeh Pournader <roozbeh@google.com> |
Make default resources a better match for en-US requests
When locale fallback landed, resources which specified an 'English'
locale started to be considered a better match for en-US, even though
traditionally, apps tend to ship US English resources under their
default locale.
This fixes that, and makes en-US requests match default locales.
Bug: 26756573
Bug: 26789680
Bug: 26803868
Change-Id: I460c276bfc6ddba0439dcdf87497a0aece0fa05d
/frameworks/base/libs/androidfw/tests/ConfigLocale_test.cpp
|
| b927c559e1ef8530b08712507f320502627db298 |
|
15-Jan-2016 |
Roozbeh Pournader <roozbeh@google.com> |
Implement smarter locale resource selection
* Add support for determining script from language and region.
* Add support for determining special parents of locales.
* Add support for smart comparison of locales with only a difference
in region, using the locale parentage tree.
* Fix LocaleData.matchScore() to not fallback to old locale matching
behavior if we can't determine a script.
* Allow four-character variant codes. (Previously, only five- to
eight-character variant codes were allowed.)
Bug: 7296673
Bug: 26589793
Change-Id: Ibde0a48c0564ff383b41068095a5cbacfe7b94bc
/frameworks/base/libs/androidfw/tests/ConfigLocale_test.cpp
|
| 31245b4f06003f1c8cd44c31b387c96ab4e282f9 |
|
23-Aug-2014 |
Adam Lesinski <adamlesinski@google.com> |
Introduce anydpi density resource qualifier
This is meant to be used with scaleable vector
drawables, and are chosen as the best match unless
there is a configuration that matches the density
requested exactly.
Bug:17007265
Change-Id: Ic3288d0236fe0bff20bb1599aba2582c25b0db32
/frameworks/base/libs/androidfw/tests/ConfigLocale_test.cpp
|