We'll also want to make sure deobfuscation happens in the relevant crash/etc pipelines for webview as well; I'm not sure where to check for this.

It might be good to double-check this doesn't affect support library. That would involve:

 1. http://go/repo-init/ub-supportlib-master (~18 GB on disk, after building webkit support lib)
 2. installing a proguarded webview on the device (preferably L device)
 3. running the test suite (frameworks/support/gradlew :webkit:connectedAndroidTest)

Full instructions are at http://go/wvsl-contribute. Feel free to try the support lib if you feel ambitious, otherwise I don't mind testing locally once we have an obfuscated canary.

Here's what it'd take to enable obfuscation:
https://chromium-review.googlesource.com/c/chromium/src/+/1114348

Sounds like it might make sense for someone that works on webview to take this over so that it can be properly tested.

I cherry picked https://chromium-review.googlesource.com/c/chromium/src/+/1114348 and ran the CTS webkit module as well as the support library webkit tests.

In CTS 1 test failed:
android.webkit.cts.WebViewDataDirTest#testSameDirTwoProcesses
Issue: b/75614531

In support library tests 1 test failed:
testApkSupportsExpectedFeatures
Invalid WebView version string: 'Developer Build' - so this is expected


There is still work to be done to make sure that java code is being proguarded (comparing against a monochrome build) and ensure that deobfuscating stack traces work properly.

Thanks for checking these tests! Sounds like both failure are unrelated?

What sort of monochrome comparison are you thinking of?
For deobfuscation, we'd use the same pipeline as monochrome. Is there pending work here that you know of?

I can confirm the support lib failure is expected (it's been on my radar for a bit, but I filed http://b/111314566 to track).

The testing in #4 seems sufficient to me, thanks laisminchillo!

To make sure obfuscation was working I checked the mapping for both Monochrome and Webview: all classes that were not obfuscated in Webview were also not obfuscated in Monochrome, with the exception of com.android.webview.chromium.WebViewApplication (which is Webview specific).

Awesome! Branch cut is next week, so would it make sense to wait until afterwards to land the change? or should we just go for it?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d2bc29d132cc7469cb09befb7cba8e1208c177d1

commit d2bc29d132cc7469cb09befb7cba8e1208c177d1
Author: Andrew Grieve <agrieve@chromium.org>
Date: Tue Jul 24 16:30:21 2018

android_webview: Enable ProGuard obfusction

Bug:  855726 
Change-Id: I451b9cc0d68982a9cf3deba0af3d7146e8beb14b
Reviewed-on: https://chromium-review.googlesource.com/1114348
Reviewed-by: Richard Coles <torne@chromium.org>
Reviewed-by: Nate Fischer <ntfschr@chromium.org>
Commit-Queue: agrieve <agrieve@chromium.org>
Cr-Commit-Position: refs/heads/master@{#577573}
[modify] https://crrev.com/d2bc29d132cc7469cb09befb7cba8e1208c177d1/android_webview/system_webview_apk_tmpl.gni
[add] https://crrev.com/d2bc29d132cc7469cb09befb7cba8e1208c177d1/base/android/proguard/proguard.gni
[modify] https://crrev.com/d2bc29d132cc7469cb09befb7cba8e1208c177d1/chrome/android/chrome_public_apk_tmpl.gni

I've verified this on 70.0.3502.0.

Installed this APK (AndroidWebview.apk), and dumped the list of classes. I see 1550 obfuscated class names. If I try 70.0.3501.0, I see zero obfuscated class names.