Apps targeting Q+ will not get the backward compatibility quirk for
loadData content using a # character applied and will instead get the
documented/spec-compliant behaviour; document this.
Bug: 124371734
Test: m offline-sdk-docs
Change-Id: I05a3b4e951f4b3b051e94a22ba3eeae486228fbb
No change to logic, only OWNERS file.
I'm proposing myself as a code owner for frameworks/base/.../webkit. I'm
already an owner for our AndroidX APIs, so I think it's reasonable and
convenient to also be an owner for our framework APIs too.
Bug: None
Test: None
Change-Id: I602ad9fb88017c68e7e58cb29093fa29d80c1fc4
The webview zygote is shared for all users on the system, and so unlike
the app zygote, it can't use a single whitelisted UID range. For now,
clamp to the upper bound of the UID range, until we have a better idea.
This is still an improvement from the previous status quo, because it
will prevent setuid/setgid into system users.
Bug: 123597434
Test: builds, webview_zygote running
Change-Id: Ia975826ed5b1f20cabb46f60f5951723b1ba80c9
This commit made the following changes to make the code conform to the
Frameworks style guide:
* Re-named variables
* Re-flowed code
* Organized includes
Topic: zygote-prefork
Test: make & flash & launch apps
Bug: 68253328
Change-Id: I9274b32f1f606f29f6eb3a1e5068ca18f607afe7
Merged-In: I9274b32f1f606f29f6eb3a1e5068ca18f607afe7
In the "common" case where the WebView stub is not being used, have the
WebView zygote use the new APK preload path added for the app zygote,
which avoids duplicating logic from the framework to construct the
classpath. This allows the WebView implementation to use a static shared
library, which was not previously possible.
The old codepath is retained for now to keep the WebView stub working
when it's in use, as it requires the special mechanism to override the
classloader cache key, but this can be removed when we no longer require
the stub.
Bug: 110790153
Test: Manual verification of classloader cache state
Change-Id: Ie49e5810d570bae7bec0341753e6c50d081189b5
This commit made the following changes to make the code conform to the
Frameworks style guide:
* Re-named variables
* Re-flowed code
* Organized includes
Topic: zygote-prefork
Test: make & flash & launch apps
Bug: 68253328
Change-Id: I9274b32f1f606f29f6eb3a1e5068ca18f607afe7
No change to logic, only docs.
This adds {@link}'s for references to SslErrorHandler methods, improving
readability. This also clarifies this API is only called for recoverable
errors.
Fixes: 123042566
Test: m offline-sdk-docs
Change-Id: I0e94c9903e638e2fce59f35ec76eb5566e7ad875
The application zygote can run untrusted user code; since it also
has the capability to change the uid/gid of the process, we need
to ensure that any changes to the uid and/or gid stay within the
range that we have allocated for this application zygote.
For application zygotes, we install the app_zygote seccomp
filter instead of the regular app filter; the only difference
between this filter and the app one is that it allows
setuid/setgid calls.
To further limit this, pass down the allocated UID range to the
Zygote itself, which in turn installs an additional seccomp
filter that restricts setuid/setgid calls to this range.
The actual calls into seccomp are commented out until the seccomp
changes are merged; to avoid catastrophe, this will leave the
regular app filter for the app_zygote, which is more restrictive
and doesn't allow setuid at all.
Bug: 111434506
Test: atest CtsSeccompHostTestCases passes
Change-Id: I112419629f5ee4774ccbf77e2b1cfa5ddcf77e73
WebViewRendererClient is a callback class responsible for informing
applications about renderer state changes.
Specifically, these callbacks added as part of this feature are:
onRendererUnresponsive(renderer) - called when the renderer associated
with a webview does not ack an input event, or a navigation does
not commit within 5 seconds. The callback will continue to be
called at 5 second intervals until the renderer is killed or the
unresponsiveness resolves. |renderer| may be null if webview is
operating in single process mode.
onRendererResponsive(renderer) - called once when an unresponsive
renderer becomes responsive again.
This CL also adds the ability to get a webview renderer handle from a
WebView instance, and then terminate that renderer. This allows recovery
from unresponsive renderer situations when webview is in multiprocess
mode and termination is correctly handled via
WebViewClient.onRendererUnresponsive().
Bug: 111332462
Test: CTS test TBD
Change-Id: I0ec026f539a70f412c5567dd87a86a0d851b39ae
Explicitly state in the documentation that the WebView will call
InputStream.close() after it's finished reading the response from a
WebResourceResponse.
Fixes: 122665050
Test: m offline-sdk-docs
Change-Id: I933c58e335ff1af31db6b4f959316ee389359e01
When an application has requested isolated services to be spawned
from an app zygote, we need to spawn the app zygote itself, and then
ask it to fork an isolated service.
The application zygote currently only creates the class loader, and
doesn't do much else. We keep track of the isolated services that
use the app zygote, and when the last isolated service goes away,
we stop the app zygote itself (after a timeout).
The app zygote itself runs with the app's UID and under the app
seccomp filter. That last one is too restricted, so this currently
only works with SELinux disabled.
Future CLs will add an application callback for preloading.
Test: start multiple isolated services with useAppZygote="true",
verify app_zygote starts, services start as a child of
app_zygote. Stopping all services stops app_zygote as well.
Bug: 111434506
Change-Id: I10ee1d4bd148c9298974d434fbc5e5eccbec16cb
Add plumbing to native/webview for the new functor.
Add a void* data parameter to avoid having to use a thread safe
map for in both the plumbing and in webview.
Test: Compiles and webview runs
Bug: 120997728
Change-Id: I0f9f3acb05688a5afcf95974bc0b3b117f33a8e3
Members modified herein are suspected to be false positives: i.e. things
that were added to the greylist in P, but subsequent data analysis
suggests that they are not, in fact, used after all.
Add a maxTargetSdk=P to these APIs. This is lower-risk that simply
removing these things from the greylist, as none of out data sources are
perfect nor complete.
For APIs that are not supported yet by annotations, move them to
hiddenapi-greylist-max-p.txt instead which has the same effect.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Change-Id: Ia937d8c41512e7f1b6e7f67b9104c1878b5cc3a0
Merged-In: I020a9c09672ebcae64c5357abc4993e07e744687
Members modified herein are suspected to be false positives: i.e. things
that were added to the greylist in P, but subsequent data analysis
suggests that they are not, in fact, used after all.
Add a maxTargetSdk=P to these APIs. This is lower-risk that simply
removing these things from the greylist, as none of out data sources are
perfect nor complete.
For APIs that are not supported yet by annotations, move them to
hiddenapi-greylist-max-p.txt instead which has the same effect.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Change-Id: I020a9c09672ebcae64c5357abc4993e07e744687
No change to logic, only docs change.
The bar/pipe symbols have no meaning in javadoc. We should mark this
with {@code} instead.
Bug: 122046530
Test: None
Change-Id: I594480ea3bf4fec9c87a48275364c7c616a0e3ea
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 121237128
Bug: 120783643
Test: m appcompat
Change-Id: Ib7a8bdf3151290aa8a5ca85dc8650612432f0d59
Developers commonly misuse the mimeType and encoding parameters in the
WebResourceResponse constructor as the meaning is different to the
similarly named HTTP headers. Explain more carefully what valid/invalid
inputs look like and mention that this is different to HTTP.
Change-Id: I14d159bc50c89c2215f7de5f4732569e5e246930
Fixes: 64765685
Test: m offline-sdk-docs
Force dark mode is a tristate:
- never invert colours for webview content
- always invert colours
- follow the parent view behaviour
Test: CTS test, after WebView implementation.
Bug: 120599879
Change-Id: Ib11358bc3a3cbc5e55c0ec184084c7d205acf60c
These APIs never really launched, and the Token Binding protocol is no
longer supported by the chromium team (which means these APIs have been
broken for some time).
This removes most of the TokenBinding API surface, keeping (and
deprecating) just enough to allow us to still compile and run WebView
APKs.
Bug: 119576150
Test: make update-api
Change-Id: Ia5a4258aac5ed21691ea36a428b4aa7195ff21ca
That method was returning a boolean to indicate whether the IntelligenceManager
should be notify, so views with virtual hierarchy could return false.
But now it returns void and always notify, which makes the API easier to
understand and use.
Bug: 117944706
Test: m -j update-api doc-comment-check-docs
Test: atest CtsAutoFillServiceTestCases
Change-Id: I216cacb6edb144239b6eabe56ab177fc2582e1aa
In http://ag/5298658, I said this constant is only used when apps have a
targetSdkVersion (strictly) greater than Q. I actually meant "greater
than or equal to."
This CL changes the wording to "is at least," which is both correct and
concise.
Bug: 117470538
Test: N/A
Change-Id: I8c2e016a7b26ce2ff406c433cc6071eb9d887753
No change to logic, this adds a new integer constant for Safe Browsing
billing threats.
This also adds ending periods in the docs for existing threat types.
Bug: 117470538
Test: N/A
Change-Id: I5368601efc7d587af1f530b7bf2825f277424082
