Refactor HWUI unit tests to not invoke SkCanvas::getClipStack,
because this Skia API is going to be deprecated.
Test: Build and ran sailfish-eng. Ran HWUI unit tests.
Change-Id: Iac277aa26fbe9e2a0860cde2dd43732ed1c4c4e3
Fixes: 34598346
Prior to 2874daa4d38bddd3a5f0edb3774d5e5884dd9554 we
never freed the resources of root nodes. Now that this is being
done we need to ensure that the backdrop has content before
we try to draw that content. All other nodes passed in
deferRenderNodeScene check that nothingToDraw() returns false
before drawing them, but that check was missed on the backdrop
node.
Test: manual. open calculator then long-press on recents
Change-Id: I495749161b38b57278bdb60d5f872eeeb2b218d0
Refactor GLFunctorDrawable::onDraw to get SkCanvas clip region
with new Skia API (getClipStack is going to be deprecated).
Test: Built and ran angler-userdebug. Ran CTS WebView clip tests.
Change-Id: Ia11e3f3d64d5c33802b7a8f296f213ef39a69905
Added Macros for RENDERTHREAD_TESTS which run these tests using specific backends.
RENDERTHREAD_TESTS - Runs OpenGL, SkiaGL, and SkiaVulkan
RENDERTHREAD_SKIA_TESTS - Runs SkiaGL and SkiaVulkan
RENDERTHREAD_OPENGL_TESTS - Runs OpenGL
Test: manual running of hwui_unit_tests
Change-Id: Ia7420ee7a38803a15e2d58394d14b38cae8208d3
libandroidfw needs to make use of StringPiece, so
move it to libandroidfw and update all code referencing
StringPiece in aapt2.
Test: make libandroidfw_tests libaapt2_tests
Change-Id: I68d7f0fc7c651b048d9d1f5e7971f10ef5349fa1
Also add back script information for Yiddish old code (ji) that was
removed in ICU.
Bug: 26756576
Test: none
Change-Id: Ia785f86bf0407aeed6134ef9d44e504494256da2
SkDevice.h is being removed from Skia. This removes these already unused
includes which mention this file.
Test: refactoring CL. Existing unit tests still pass.
Change-Id: I8340a5822ad2b75c54fe0dca1303ceab9bbee805
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
(cherry picked from commit a192a8ced65ceea8bfe44f0eac6a394cbf80d936)
Skia is looking to make SkAutoMalloc private and will be moving it.
Using FatVector instead will make this code both less dependent on Skia
internals and more performant.
Test: refactoring CL. Existing unit tests still pass.
Change-Id: If9de10059775b75e1ab89078eacede2e20e91299
This CL enables developers to specify axis values to the underlying
font collection. The specification of the font variation settings is
the same as the CSS font-variation-settings attribute in CSS working
draft as of 2016-11-30.
Code example: Here is an example to set width 100 and weight 1.5.
TextView tv = (TextView) findViewById(R.id.textView);
tv.setFontVariationSettings("'wdth' 100, 'wght' 1.5");
Bug: 33062398
Test: Manually done. Ran FrameworksGraphicsTests, CtsGraphicsTestCases
and CtsWidgetTestCases
Change-Id: I249d464f8cdaa56017a987588b94ed685aadeb58
This adds support for shared resource libraries in the new
ResTable/AssetManager implementation.
The dynamic package map encoded in resources.arsc is parsed
and stored with LoadedArsc, and combined to form a resolved table
in AssetManager2.
Benchmarks show that this implementation is an order of magnitude
faster on angler-userdebug (make libandroidfw_benchmarks).
Test: libandroidfw_tests
Change-Id: I57c80248728b63b162bf8269ac9495b53c3e7fa0
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
The multiwindow model and Resources-per-activity
model that came in N puts greater demands on AssetManagers.
They are created whenever window dimensions change, which
can be frequently. There is a need to be able to cheaply
create a new AssetManager for each Activity, which shares
a lot of underlying state.
In order to make the creation of AssetManagers cheap,
we need a new implementation of the native AssetManager
and ResTable to support immutable representations of
APKs. This new data structure/class is ApkAssets.
ApkAssets have the same functionality of an AssetManager, except
that they operate on a single APK, and they do not do any caching.
Once loaded, they are immutable.
ApkAssets will be exposed as a Java object, with its implementation in
native code. The existing Java StringBlock will be owned by ApkAssets,
which means that Strings can be shared across AssetManagers.
ApkAssets can be cached by the ResourcesManager. Creating an AssetManager
requires only a list of ApkAssets and a configuration.
AssetManager2 (named with the suffix '2' for now while transitioning
to the new implementation) caches bags that are accessed.
Since ApkAssets are expected to be kept around longer, they do more validation
of the resource table, which cause slower load times. Measured on an angler-userdebug,
loading the framework assets takes 11ms with ApkAssets, and 2ms with the old
AssetManager implementation.
The tradeoff is that there does not need to be any security checks once an ApkAssets
is loaded, and regular resource retrieval is faster. Measured on an angler-userdebug,
accessing resource (android:string/ok) with many locales takes 18us with AssetManager2,
and 19us with AssetManager (this is per resource, so these add up).
Test: make libandroidfw_tests
Change-Id: Id0e57ee828f17008891fe3741935a9be8830b01d
