commit | 17fc27f19b672a56f01c5f20773fb1047876646d | [log] [tgz] |
---|---|---|
author | Nate Fischer <ntfschr@google.com> | Fri Apr 06 16:04:59 2018 -0700 |
committer | Nate Fischer <ntfschr@google.com> | Thu Apr 12 11:13:16 2018 -0700 |
tree | a2c0364d56f57613d943070aac49f4c36acc45e3 | |
parent | 1fb10aef6f0c55ee0ddc15d15538d03c94aaec86 [diff] |
[WebView Support Library] Implement onSafeBrowsingHit This is the third CL in a series to implement WebViewClientCompat. This implements WebViewClientCompat#onSafeBrowsingHit() and adds the abstract class SafeBrowsingResponseCompat. As in the previous CL, we define 3 signatures for onSafeBrowsingHit(): 1. Inheriting the WebViewClient method with SafeBrowsingResponse (called by legacy WebView APKs on 27+) 2. Implementing the boundary interface method with an InvocationHandler (called by up-to-date WebView APKs) 3. A new signature which uses SafeBrowsingResponseCompat (which apps may override) Signatures 1 and 2 convert their parameter into a SafeBrowsingResponseCompat and invoke signature 3. Signature 3 also implements default behavior resembling the corresponding WebViewClient method. SafeBrowsingResponseCompat intentionally differs from SafeBrowsingResponse in that it may not be instantiated by applications. Applications have no reason to instantiate SafeBrowsingResponse(Compat), and it was a mistake for SafeBrowsingResponse to have a public constructor. Also, this adds explicit NonNull annotations for the static #from*() conversion methods (including those on WebResourceErrorCompat), since these methods already assume NonNull parameters. Design doc: http://go/wv-support-library-callbacks Bug: 73151460 Test: Manual - build a test app with WebViewClientCompat Change-Id: I52ae652077a180b20c8ae7ad3a307224d5e744e8
We are not currently accepting new modules, features, or behavior changes.
NOTE: You will need to use Linux or Mac OS. Building under Windows is not currently supported.
Follow the “Downloading the Source” guide to install and set up repo
tool, but instead of running the listed repo
commands to initialize the repository, run the folowing:
repo init -u https://android.googlesource.com/platform/manifest -b ub-supportlib-master
Now your repository is set to pull only what you need for building and running support library. Download the code (and grab a coffee while we pull down 7GB):
repo sync -j8 -c
You will use this command to sync your checkout in the future - it’s similar to git fetch
Open path/to/checkout/frameworks/support/
in Android Studio. Now you're ready edit, run, and test!
If you get “Unregistered VCS root detected” click “Add root” to enable git integration for Android Studio.
If you see any warnings (red underlines) run Build > Clean Project
.
You can do most of your work from Android Studio, however you can also build the full support library from command line:
cd path/to/checkout/frameworks/support/ ./gradlew createArchive
If you intend to repeatedly make changes to Support Library and to wish to see the results in your app, and you don't want to have to repeatedly build them as separate Gradle projects, you can configure your app build to build Support Library too
Run FooBarTest
Run android.support.foobar
Support library has a set of Android applications that exercise support library code. These applications can be useful when you want to debug a real running application, or reproduce a problem interactively, before writing test code.
These applications are named support-*-demos (e.g. support-4v-demos or support-leanback-demos. You can run them by clicking Run > Run ...
and choosing the desired application.
cd path/to/checkout/frameworks/support/ repo start my_branch_name . (make needed modifications) git commit -a repo upload --current-branch .
If you see the following prompt, choose always
:
Run hook scripts from https://android.googlesource.com/platform/manifest (yes/always/NO)?