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
