| Age | Commit message (Collapse) | Author |
|---|
|
The WebView native library has so far only depended on native libraries
that were already loaded by the zygote, and has only shipped a single
.so file in its APK. Splitting the code into multiple libraries worked,
but only the top-level library would have its RELRO section shared,
causing a memory regression.
To avoid this regression if we do decide to split up the native code in
future, load the native library using the new RESERVED_ADDRESS_RECURSIVE
flag in the linker, which means that any depended-upon libraries will
also be loaded into the reserved address region and will have their
RELRO sections saved and reused.
Fixes: 128623590
Test: tested manually with modified WebView
Change-Id: I19ee3ff971e8dcd1c683f94af304abf918860a10
|
|
|
|
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
|
|
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
|
