This updates to use Skia's new api which takes the vulkan apiVersion
instead of the instance version. This is technically more correct since
the application apiVersion is really the only client modifiable version
value in vulkan.
This change also updates the webview structs to use the apiVersion as
well.
Test: manual build and testing.
Change-Id: I6ce7c20949eb7242f7bbe69955b54c0785696891
Bug: 115613038
Test: Turning on vulkan with appropriate webview apk does not crash and
sort of works.
Change-Id: If1504da7a35e4bd74a994ab2c2a351e6bc415a18
The color space parameters are currently separate members. This was
making passing color space parameters to functions a bit messy.
This CL puts the color space parameters into their own struct which can
be cleanly passed to functions.
Test: Builds locally
Change-Id: I3709b88dbdedb9616d4905ee973c3099f95b3ca7
Several of the first-iteration file/class/member variable names did not
match the style of their surrounding neighbors. This CL fixes that.
Test: Compiles
Change-Id: I9374e6cab79c57413e728d253067306d15011f2c
plat_support to pass through the GL functor even if hwui is using vulkan
pipeline, since interop calls the GL functor.
Also remove sGLDrawThread and call functor on render thread, since
onDestroy and onContextDestroy are currently hard coded to run on render
thread as well, and functor expects all calls to be called on a single
thread.
Bug: 115613038
Test: draw_fn functor works with vulkan enabled
Change-Id: Ie3fa643695e95a6cc383f7ffe3eb3ad741792707
Add plumbing to native/webview for the new functor.
Add a void* data parameter to avoid having to use a thread safe
map for in both the plumbing and in webview.
Test: Compiles and webview runs
Bug: 120997728
Change-Id: I0f9f3acb05688a5afcf95974bc0b3b117f33a8e3
An interop Vulkan functor already exists. It will call the OpenGL
functor and use AHardwareBuffer to translate the OpenGL textures into
something which can be used in Vulkan.
This CL adds the frameworks for a non-interop Vulkan functor. This
functor is not yet complete (and as a result cannot yet be tested). This
is just setting the stage for future work.
Test: This is dead code and cannot yet be tested.
BUG=115613038
Change-Id: I2b87c86cb511abb961c31c17c2fbbc085b07ca4a
In a separate code review we agreed that at ABI boundaries it feels nice
to explicitly call out enum values rather than rely on the rules of
C/C++ which others may not be comfortable with.
This CL adds explicit values to enums inside draw_gl.h.
Test: I built and tested on a Pixel 2.
Change-Id: I64c03e2684c1ab096a9c0665e4ed3d8b7bb22ac7
"override" provides a compile-time gaurantee that the function is indeed
overriding a virtual function. This prevents the potential mistake of
creating a new virtual function rather than overriding the original.
I happened to notice we could use "override" here instead of "virtual".
Might as well tidy up a bit.
Test: Built locally
BUG=115613038
Change-Id: I7f43f4a466d8ceaa1b863d6a2af054e69618d0c8
So it shows up in showmaps output as "[anon:libwebview reservation]"
instead of grouped in with the rest of "[anon]", to facilitate memory
debugging.
Test: Manually confirm libwebview reservation shows up in system server showmap.
Change-Id: I4897aff4406265a7be9fc37aecbe5967bcf29426
Instead of having the system server search for the absolute path to the
WebView's native .so file, simply pass the package name and library
filename to the RELRO creation process. The RELRO creation process can
then request a classloader that corresponds to that package, and use
that classloader to let the system search for the library itself using
the standard platform library search path logic.
This significantly simplifies the WebView code, but more importantly
enables the library to be found even if it's not actually present in the
main WebView APK and is instead stored in a shared library APK: our
previous code was never updated to handle this new case when the
platform introduced it.
As a side effect of no longer searching for the library, we also no
longer discover the size of the library, and thus cannot use the size to
calculate the amount of address space to reserve. This has been replaced
with a fixed size: 100MB for 32-bit processes (the previous default size
for when the size had not yet been calculated), and 1GB for 64-bit
processes. We do not anticipate WebView ever needing more than 100MB of
virtual address space for its native library on 32-bit platforms; it
currently uses about 44MB.
The unit tests covering the complex library searching logic have been
removed, as the functionality they are testing no longer exists.
Bug: 110790153
Test: WebView-related CTS and GTS tests
Change-Id: Icc7bcd0a2b33f4dbf26d0d663e098c9e207281a5
See build/soong/README.md for more information.
Test: m libframeworks_coretests_jni
Test: m FrameworkCoreTests_install
Test: m libshim_jni
Test: m CtsShimPrivUpgrade
Test: m libfilterfw
Test: m PMTest_Java_dual
Test: m libdefcontainer_jni
Test: m libperftestscore_jni
Test: m libpmtest32 libpmtest64
Test: m libprintspooler_jni
Test: m libsmartcamera_jni
Test: m idmap
Test: m libdrmframework_jni
Test: m libdvr_loader com.google.vr.platform com.google.vr.platform.xml
Test: m libfilterpack_imageproc libfilterpack_base
Test: m libwebviewchromium_loader
Test: m shared_mem_test
Test: m test-touchlag
Change-Id: I868561dd237fa28647896d59049ab9260373ada1
Move this code to be in the same repository as the other parts of
WebView's current implementation.
Bug: 62445369
Test: m
Change-Id: I567eac7f3484fa78a948fb84545e578fe18c236d
There's no need to send both 32-bit and 64-bit paths to the native side
of the relro-creation/loading logic, we can check which one to send on
the java side instead.
Bug: 28736099
Test: Load WebView app, ensure relro file is loaded into the app
process.
Change-Id: Ia3fb4b3ed686c3e70c26a384aae966bda179d225
When loading WebView's native libraries we now have a classloader
pointing to the namespace of thise libraries - so we no longer need to
explicitly reference those libraries by their path names.
Bug: 62860565
Test: Start a WebView-using app. Ensure that libwebviewchromium.so is
loaded into the app process.
Change-Id: I205131f4b5fac7c33374560515b85ddef19a7ce9
The Java-side of the WebView loading lives in frameworks/base/ while the
native side lives in frameworks/webview/. It would be great to be able
to change the JNI interface between these two without having to update
two separate projects.
This CL moves the native side into frameworks/base/.
Bug: 62445369
Test: Run app using WebView (and ensure it loads WebView).
Change-Id: I6915e996b3a035e9d87000ccd11e5fb89deecde7
