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
No change to behavior, only docs change.
The docs for setAllow(File|Universal)AccessFromFileUrls were previously
wrong. They implied that:
* Default value is 'false' when SDK_INT > Jellybean
* APIs were added in Jellybean (so they can't be called pre-Jellybean)
* Therefore, setAllow*AccessFromFileUrls(false) is always a NOOP
Actually, WebView examines targetSdk, not SDK_INT. So apps should call
setAllow*AccessFromFileUrls(false) when targeting ICE_CREAM_SANDWICH_MR1
and below.
The docs previously had mixed use of ICE_CREAM_SANDWICH and
ICE_CREAM_SANDWICH_MR1. This corrects the docs to use the right one
(ICE_CREAM_SANDWICH_MR1).
Lastly, this fixes a minor grammar mistake (misplaced comma).
Test: make docs (manually verify)
Change-Id: I206dff54a8c342ae7b47bd40d69d0b01dbad3cc6
The WebView Support Library needs a way to hook into the WebView APK,
this new method returns a classloader that can be used to load internal
WebView classes.
The idea is to have this classloader be provided by the WebView APK
itself, so that the classes accessed from the classloader can be
filtered to avoid apps accidentally adding dependencies on internal
details of the WebView APK.
Test: N/A - cannot add CTS tests until we drop a WebView APK containing
the implementation for this API.
Bug: 38220806
Change-Id: If744a740ff0b1728d2d4674e73697bc6a5e27dde
WebView Safe Browsing will be on by default. While previously it was
opt-in (applications needed to enable via manifest or API), now it is an
opt-out feature.
This CL updates documentation to mention that the feature is on by
default and provides steps for applications to opt-out if necessary.
This also makes the case of "Safe Browsing" consistent across
documentation.
Bug: 69579509
Test: make docs (manually verify)
Change-Id: I77683a684cd79d2e3cd313ddbff8c52fe510b72b
In an earlier release we had to allow disk reads during a part of
WebView initialization, now that this fault is fixed we can remove that
allowance.
Bug: 63324842
Test: Manual: ensure calling new WebView() doesn't cause StrictMode disk
read violation.
Test: run WebViewHostSideStartupTest.testStrictMode()
Change-Id: If7b4ad790c67469806c255427d86e5fd28d19f35
This stops calling findAddress (possibly indirectly via Linkify) from
loading webview native code, resulting in a performance and memory
improvement for those apps that call WebView#findAddress but do not
otherwise use WebView.
Bug: 22362008
Test: Existing WebView CTS test.
Change-Id: I5fcab725ceaf0d6a00e931d3b6cd2f3799d68391
Docs change only, no change to logic.
This CL provides a better loadData() example, using base64 encoding.
This uses the Base64 class already provided by Android to automatically
handle the encoding.
This also changes the percent-encoding docs to:
* Link to the official RFC
* No longer provide examples of characters to encode (one example was
incorrect, '\' is not %27)
Bug: 70555565
Test: make docs (manually verify things look good)
Test: I built a sample app and tested Base64#encodetoString to make sure the flags are correct
Change-Id: If9f810e6b568efdc5d1ad84ac64f2abf3788f40b
We are currently storing WebView package signatures as Strings in
WebViewProviderInfo, represent these as Signatures instead.
Bug: 62429931
Test: start WebView app + run WebViewTest GTS tests + WVUS tests
Change-Id: I910db133cd147b44b4b1c63921308d82db44e5b3
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
Add classes/interfaces necessary for the support of tracing API
in WebView.
In particular:
- TracingController: singleton class for starting and stopping
tracing and inspecting tracing status.
- TracingConfig: holds tracing configuration, such as categories
to filter and the tracing mode.
- TracingOutputStream: interface for capturing tracing data.
- TracingFileOutputStream: supporting class for capturing tracing
data to a file.
BUG: 63750258
Test: in progress
Change-Id: I7decd486788766fc8dfa766ae027c02f9d4c6f80
Add WebView.setDataDirectory(String suffix) and WebView.disableWebView()
interfaces. These will enable applications to better control the use of
WebView when running multiple processes, since it's not safe for more
than one process in an app to use the same data directory.
disableWebView is completely implemented in this change;
setDataDirectory will require WebView-side implementation changes to be
functional.
Bug: 63748219
Test: cts android.webkit.cts.WebViewDataDirTest
Change-Id: Ieff225dc99b6b3ca5f223c35f7a854f0c53692df
This change edits the WebView documentation to specify that the mimeType
parameter to loadData and loadDataWithBaseUrl should be a valid mimeType
and the data will be downloaded if it is not.
Test: manual - this only changes documentation
Bug: 70528830
Change-Id: I58ca4655673c6ccfe7547572579ef86a14a259ed
It turns the version code into almost a 64-bit integer, with the
new major part being the upper 32 bits.
The only tricky part about this is the backup manager, since it
stored 32-bit version codes in its backup data sets. This is dealt
with by, when the major version code is not 0, writing MIN_INT as
the version code and following that by the full long version code,
which we can detect when reading. Note that this makes backup sets
containing apps with major version codes incompatible with older
versions of the platform.
Bug: 64459786
Test: Added in Change-Id: Iab8a682b62103babd6c16a56b8dc1e97d7078658
Change-Id: Ibfffe235bbfcf358b3741abd3f7197fdb063d3f3
No change to behavior, only docs changes. No change to wording.
This linkifies ClientCertRequest method names in the docs for
WebViewClient#onReceivedClientCertRequest.
Test: make docs (looks good, no errors)
Change-Id: I1de855e8cdf91b3aace3a188aafaa9ac9f90ed2a
Update testTargetSdkVersionValidity to use the same minimum sdk as the
actual code it's testing.
Bug: 69554263
Test: run com.android.server.webkit.WebViewUpdateServiceTest tests.
Change-Id: Ide04ede774072a10b84a9726bdff536bfef12712
No change to logic, only docs changes.
This is mostly just formatting changes to documentation. Changes fall
into a few categories:
* Linkify ({@link}) or codify ({@code})
* Spelling errors
Test: make docs (looks better)
Change-Id: Ibcd762ab06e51451a53bbce5860cc137bee22ccf
Redirect developers to use the Support Library
versions of Fragments and Loaders to ensure that
they get consistent behavior across versions of
Android and all devices as well as access to
Lifecycle improvements.
Test: Confirmed APIs deprecated in current.txt
BUG: 68381801
Change-Id: I58ec599e557fc93c8547c45ba7c9ced96b0c8616
No change to logic, just docs updates.
It looks like our documentation for the Safe Browsing manifest tag was
poor. This clarifies that the manifest opt-in should go inside the
application tag.
This also updates the documentation for MetricsOptOut, since this has
the same requirement.
Bug: 69007974
Test: make docs (verify it looks better)
Change-Id: Ieb29932f1460e3aa25c486b47692b63c0b87f509
No change to logic.
This CL has miscellaneous docs changes for WebViewClient.java:
* Spelling
* Codify some terms ({@code } annotations)
* Linkify references to other methods
Test: make docs (all links work, things look better)
Change-Id: Ia748a258a29b467b9655c018b5783b5b22fad0eb
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 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)
No change to logic, documentation change only.
WebView requires an Activity Context in order to work properly (several
features depend on this).
This CL documents this in each WebView constructor by specifying
"Activity Context" for the Context param. This CL also adds a note in
WebView(Context) to explain the importance of an Activity Context.
Fixes: 67945912
Test: make -j40 docs (manually verify it looks good)
Change-Id: I6f84093f7ce39f6bd924fd6e27737f047348d8a4
Docs change only, no change to logic.
This replaces "iff" (if and only if) with "if". The former term is
unclear, and there's no real benefit to expanding to "if and only if."
Change-Id: I1ac26e24b816f784b6868c8860849d4118b33294
Fixes: 68133964
Test: make -j40 docs (manually verify the change 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: I00d9b7f0650fe440ebee971eed8482759c7cbc79
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
