| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current 130MiB is not sufficient for the latest Chrome x86 dev build
of stripped native library. Official ARM library is around 59 MiB (on
disk). This flavor is slower to build and is less convenient to test
with.
Keep the 32bit arm reservation size unchanged, it is sufficient and
allows growth.
Bug: 184808875
Test: Manual: start a "release" build of Chrome/x86 (but not
"official"), observe that with the change Chrome can
mmap(MAP_FIXED) all the segments of the native library into the
region successfully
Change-Id: I00507169eafbdcfc4d413bb9c76188e179ca0c0e
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Most pre-Q devices actually reserved around 130MiB in the 32-bit zygote
for the WebView native library; 100MiB was only the lower limit and the
file size based calculation that older OS versions use would come up
with a larger number. Increase the hardcoded value for Q to 130MiB so
that the behaviour is roughly the same across OS versions.
Fixes: 132081320
Test: manually verified via inspection of process maps
Change-Id: I0f03ac2f118bb0627ea6be229e5064d4590d8afb
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Pass the library file name to WebViewLibraryLoader.loadNativeLibrary
instead of passing the ApplicationInfo, which was only used to look the
native library file name up. This will allow loadNativeLibrary to be
called from the webview zygote, which doesn't have the ApplicationInfo
available.
Bug: 63749735
Test: CtsWebkitTests
Change-Id: I0bd2de38cd1a0112bbeee6225563d4d0add048e7
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, process start is initiated in ActivityManagerService
holding the main lock and this takes ~40ms to complete. As seen
in some of the issues in previous releases, this is one of the
contributors of the lock contention in system_server. This change
tries to address this issue by moving the process start outside
the locked section.
When a process start is required, instead of doing it synchronously,
this request will be posted on a handler thread. On the handler thread,
this process start request will be completed without holding a lock.
If for some reason, we decide the process is not needed anymore before
it is actually started or being started, then AMS does everything as
usual removing the references to the process from internal state except
actually killing the process which will be handled on the handler
thread.
Bug: 68775202
Test: Ran app startup perf tests using forrest, will update the bug with results.
Test: https://docs.google.com/spreadsheets/d/1cW81guRALZXKsN-WZsKyQiCSY-RgkJ2m_M9IfqIquz8
Test: cts-tradefed run singleCommand cts-dev -m CtsActivityManagerDeviceTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsWindowManagerDeviceTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsAppTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsMultiUserHostTestCases
Test: adb shell am instrument -e package com.android.server.am -w \
com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Test: adb shell am instrument -e class com.android.server.pm.UserManagerTest -w \
com.android.frameworks.servicestests/android.support.test.runner.AndroidJUnitRunner
Test: adb shell am instrument -e package android.content -w \
com.android.frameworks.coretests/android.support.test.runner.AndroidJUnitRunner
Test: cts-tradefed run singleCommand cts-dev -m CtsProviderTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsContentTestCases -t \
android.content.cts.ContentResolverTest
Test: cts-tradefed run singleCommand cts-dev -m CtsContentTestCases -t \
android.content.cts.ContentProviderTest
Test: cts-tradefed run singleCommand cts-dev -m CtsWebkitTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsHostsideWebViewTests
Test: cts-tradefed run singleCommand cts-dev -m CtsAssistTestCases
Test: make WebViewLoadingTests && make tradefed-all && tradefed.sh \
run template/local_min --template:map test=WebViewLoadingTests
Test: adb shell setprop wrap.com.google.android.apps.maps \
'"LIBC_DEBUG_MALLOC_OPTIONS=backtrace logwrapper"'
&& adb shell dumpsys meminfo --unreachable <PID_OF_APP>
&& check ppid of <APP> is logwrapper's pid.
Test: cts-tradefed run singleCommand cts-dev -m CtsWrapWrapNoDebugTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsWrapWrapDebugTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsWrapNoWrapTestCases
Test: cts-tradefed run singleCommand cts-dev -m CtsWrapWrapDebugMallocDebugTestCases
Test: manual
Change-Id: I1fe7ce48cd5a4aadccaf6b3d6fdb5cad3304f1d3
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This CL rewrites notes to use the 'note' CSS class, to help them stand
out. This isn't every instance of 'note', but it catches the handful
where I think there's a readability benefit to the new format.
This changes a few other non-public notes for the sake of consistency.
Change-Id: Icf62e34a719c79f74e74abdb55f1be42939c2f9e
Fixes: 68324591
Test: make -j40 docs (and manually verify it looks good)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Now that we no longer pass the paths of the native WebView libraries to
the native loading code we can simplify the code for fetching the path
and the size of the native WebView library.
Also add automated tests (WebViewLoadingTests) for loading native
libraries from test APKs where the libraries are stored either on disk
or as uncompressed libraries in the APKs.
Bug: 28736099
Test: start WebView-app, and ensure that the relro file is loaded into
the app process. Do this for both 32-, and 64-bit apps. And both for a
WebView APK where the libraries are loaded onto disk, and an APK where
the libraries are loaded uncompressed from the APK.
Test: make WebViewLoadingTests && make tradefed-all && \
tradefed.sh run template/local_min --template:map test=WebViewLoadingTests
Change-Id: I219dd03aa93de8cf6e64e01f1d8abe38474f5790
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This is in preparation for a patch which with bigger changes for
WebViewLibraryLoader (including tests).
Bug: 28736099
Test: ensure relro loaded into app process on 32-bit device.
Change-Id: Ic1aef697c1010380d8bce466ee14627d9cdff9e7
|
| |\ \ |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |/
|
|
|
|
|
|
|
|
|
| |
There's no context available in the relro creator process, resulting in
a NPE and crash when it tries to see if WebView is supported. Skip the
check in this case, because we know it's supported if we ran the relro
creation process at all.
Change-Id: I95e9aad7407b8f73dddf8a8b685d41d2f500736a
Fixes: 67398770
Test: boot, make sure no crash dialog from "android"
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
WebViewFactory contains a mix of functionality related to preparing and
loading WebView.
This CL breaks out the functionality related to relro-creation and
native library loading into its own class/file to make WebViewFactory
easier to interpret.
Some variables/methods must stay in WebViewFactory since they are
SystemApis.
Bug: 28736099
Test: start WebView-using app, ensure libwebviewchromium64.relro is
loaded into the app process.
Change-Id: I956e1536f23d47f1de1b6c23fc6abeb2768b58ae
|
