Some fixes to the WebView Tracing API related documentation.
In particular this patch makes sure that:
- the defaults are correct,
- the examples are correct,
- the formatting is ok,
- the text for parameters etc.. is formatted consistently,
- the documentation is spellchecked and typos corrected.
BUG: 63750258
Test: manual inspection of the generated html documentation
Change-Id: I53ac1a1d003e519739464b8d8554f3d8262c46e4
The old native implementation of findAddress only accepted addresses
without zip codes if they appeared at the end of the string. This was
probably a bug as the documentation implies this should work in all
cases, but fixing this bug has caused a lot of false positives while not
fixing very many false negatives and this functionality is being
deprecated anyway, so change it back.
Fixes: 75409267
Test: tested upstream in chromium; direct copy of that code
Change-Id: I3f3c300035cf02a23284737431bc6f94f542cbe7
We want to rename the method WebView.getLooper() to
WebView.getWebViewLooper().
We have already added the method WebView.getWebViewLooper() so with this
CL we remove the method WebView.getLooper().
Bug: 74831609
Test: make
Change-Id: I2d3c8ddeae032aa27ae3eed30d952a06b0abe854
No change to logic, this only changes documentation.
This clarifies how shouldInterceptRequest behaves for various URL
schemes as well as other edge cases (e.g., redirects).
Bug: 74841041
Test: make docs (manually verify)
Change-Id: Id59033590ea6025a00ae39c7b05486be082973e7
This patch:
- remove the RECORD_UNTIL_FULL_LARGE_BUFFER tracing option, because
this does not appear really useful in the production setting as
the buffer size limit exceeds the device memory and can grow
uncontrollably large.
- make RECORD_CONTINUOUSLY the default mode for tracing, to make
sure the least memory is used by default (typically 4x less than the
previous default RECORD_UNTIL_FULL).
- add some missing IntDef values (to make them match with the constants)
BUG: 63750258
Test: CTS
Change-Id: Ib3698273dee776ebc7a8388fc1bd8c80255e3b63
We want to rename WebView.getLooper() to contrast it better with the
unrelated method WebView.getHandler(). For now we just create a method
to replace WebView.getLooper(), so that we can remove references to
WebView.getLooper() before removing it.
Bug: 74831609
Test: make
Change-Id: I8e493a67aa078f9c8ceea6706dc940abacfdd6e6
This reverts "Delay starting the webview_zygote until first use." but
instead wraps the start in a background task, to avoid blocking the
system server startup waiting for the zygote to be ready.
Bug: 73743583
Bug: 63749735
Bug: 74079433
Test: Verify webview_zygote already running after boot
Change-Id: Iacf968cc2d2857a92c6bacf4012dc88f098c6013
WebView was never returning correct return value in
onCheckIsTextEditor(). However, startinput optimization work at
ag/3455281, requires a correct return value when switching between
windows. Chrome-side change (crrev.com/c/952217) has dropped into
66.0.3359.14.
BUG: 74199870
Test: manually verified
Change-Id: I954365a70f1ff2680ed9a6d76e695c1193a4cfa3
No change to logic, only an annotation change.
startSafeBrowsing() should never receive a null Context. This adds
@NonNull to hint to developers not to pass null Contexts.
Test: N/A
Change-Id: I46d863047bf7563ea2a1adf592f3f381be95ca49
This relaxes URLUtil#isFileUrl() to accept a prefix of "file:" instead
of requiring "file://". Chromium treats "file:path" as if the user had
typed "file:///path". An app may incorrectly believe it's safe to load
anything that URLUtil#isFileUrl() rejects, intending to refuse all URLs
which point to the file system.
Bug: 72848579
Test: cts-tradefed run cts -m CtsWebkitTestCases -t android.webkit.cts.URLUtilTest#testIsFileUrl
Change-Id: I7b3bba961523d4bdda6169a0f50fe7f1d1579e38
During boot, WebViewZygote.setMultiprocessEnabled() is called by the
WebView initialization logic. Starting the WebViewZygote here causes a
slowdown in the system_server boot process, so delay launching the
zygote until it is needed.
Previously the webview_zygote was launched by init, and merely
connecting to it in the boot process didn't have significant overhead.
Bug: 73743583
Bug: 63749735
Test: Boot a device, verify that webview_zygote process is not running.
Test: Launch "Third-party licenses" activity from Settings, and it
renders correctly via the WebView.
Change-Id: I1352a5df95e4a793ac64862c439ba2573ddd2d18
Now that the WebView zygote is a child of the system zygote it has the
smae address space layout and can use the existing WebView native
library RELRO file.
Preload the native library using the RELRO file in the zygote, to share
this data with applications which are using WebView. This can save up to
1-2MB of dirty memory, replacing it with clean pages that are shared
with more processes and thus have a smaller impact on PSS.
Bug: 63749735
Test: CtsWebkitTests
Change-Id: I7ce670f5fcddae9e98631e21329840ef3ad52f9a
No change to logic, documentation change only.
This changes "URL" to "host" everywhere in this API documentation.
This API never accepted a list of URLs, it only ever accepted a list of
hosts (e.g. "www.google.com" is ok, "http://www.google.com/" is not).
The original documentation was misleading.
Test: make docs (manually verify)
Change-Id: I3b57a2a160ff00ba8f92b30f6e3b4399e55f2ea0
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
This uses the new ZygoteProcess.startChildZygote() method to launch the
webview_zygote, rather than having init start it. This will share more
memory between the app_process and the webview_zygote, reducing the
overall system footprint.
Bug: 63749735
Test: m
Test: Launch "Third-party licenses" activity from Settings, and it
renders correctly via the WebView.
Change-Id: I3e39cd8adb9c099c92ee34640428916d90cb2b8f
The change to handling of the deprecated Apache HTTP library means that
the WebView implementation package might have a non-empty shared library
list. Make sure to fetch shared libraries when querying WebView
implementations, and take them into account when constructing both the
actual classpath to be used to precreate the classloader, and when
deciding what the cache key for the precreated classloader should be.
Change-Id: I5e1409358d935e1c9f325db434bc6d4ef8ead759
Merged-In: I5e1409358d935e1c9f325db434bc6d4ef8ead759
Fixes: 65574359
Test: launch anything that uses WebView
(cherry picked from commit 4fd8aa51e4)
Address comments from the API council regarding the WebView Tracing API.
android.webkit.TracingController:
* start() throws IllegalStateException if the system is already tracing
(this is instead of returning false)
* stop uses Executor instead of Handler
* removed stop() (the method w/o arguments)
* renamed stopAndFlush to stop
* use OutputStream instead of a custom callback interface TracingOutputStream
* dropped requirement for UI threading
* updated documentation
android.webkit.TracingFileOutputStream:
* removed the TracingFileOutputStream file completely (functionality
replaced by the existing FileOutputStream)
android.webkit.TracingConfig:
* removed example with CATEGORIES_NONE and “-input,-gpu”.
* customCategories are List<String> instead of String
* updated documentation
* added two more predefined categories: CATEGORIES_ALL,
CATEGORIES_ANDROID_WEBVIEW
* some refactoring, added a Builder class
* ensure that only include category patterns can be specified
* uniform addCategories interface for construction
* predefined category sets are a bitmask now
BUG: 71584598,71584599,63750258
Test: CTS
Change-Id: I615ef5f43d26968329182b09e7c26178f1f85ecc
Update the javadoc for the WebView data directory methods to make it
more clear in what cases these APIs should be used, and what limitations
apply to applications with multiple data directories.
Bug: 63748219
Test: n/a
Change-Id: I98f49c7a75df00aedf2472731b915c3e30e6ba13
Some WebView APIs contain checks ensuring apps only use WebView APIs
from one single thread. The WebView Support Library should perform
similar thread checks. To do so we publish an API to get the WebView
thread, so that the support library knows which thread to check against.
Test: Ran the corresponding CTS tests.
Bug: 38220806
Change-Id: Ibab878e211d9594df6d39f99ce130e28fac7f019
