Fixing WebView ProGuard config for annotations

Fixing WebView ProGuard config for annotations

WebView used to not -keep its annotations. Thus, when trying to do
anything useful with ProGuard, it appeared that the annotations were not
being obeyed, since ProGuard had already stripped them out.

Note - since we still have the -keepnames class *** { *; }, this effectively
prevents any real optimizations from being run.

This change brings the .dex size down 7356 B, and removes 12 types, 5 fields,
and 57 strings. However, these all seem inconsequential, as this is the
method/class diff of this change:

org.chromium.base.Log
-  void d(java.lang.String,java.lang.String,java.lang.Object)
-  void v(java.lang.String,java.lang.String)
-  void d(java.lang.String,java.lang.String,java.lang.Object,java.lang.Object,java.lang.Object)
-  java.lang.String formatLogWithStack(java.lang.String,java.lang.Object[])
-  void d(java.lang.String,java.lang.String)
-  void v(java.lang.String,java.lang.String,java.lang.Object,java.lang.Object,java.lang.Object)
-  void <init>()
-  void d(java.lang.String,java.lang.String,java.lang.Object,java.lang.Object)
-  java.lang.String getCallOrigin()
-  void debug(java.lang.String,java.lang.String,java.lang.Object[])
-  void verbose(java.lang.String,java.lang.String,java.lang.Object[])

BUG=541543, 583143, 624827, 627139
Committed: https://crrev.com/6eff9fcd9bce74c436c3ce33355f1b7acbcc3b34
Cr-Commit-Position: refs/heads/master@{#405491}

[smaier, 2016-07-12 21:39:22]

smaier@chromium.org changed reviewers:
+ agrieve@chromium.org, torne@chromium.org

[smaier, 2016-07-12 21:42:56]

Description was changed from

==========
Fixing WebView ProGuard config for annotations

WebView used to not -keep its annotations. Thus, when trying to do
anything useful with ProGuard, it appeared that the annotations were not
being obeyed, since ProGuard had already stripped them out.

BUG=541543
==========

to

==========
Fixing WebView ProGuard config for annotations

WebView used to not -keep its annotations. Thus, when trying to do
anything useful with ProGuard, it appeared that the annotations were not
being obeyed, since ProGuard had already stripped them out.

Note - since we still have the -keepnames class *** { *; }, this effectively
prevents any real optimizations from being run.

This change brings the .dex size down 1668 B, 11 types, 5 fields, and 17
strings. However, these all seem inconsequential, as there are no methods or
classes stripped from this change.

BUG=541543
==========

[smaier, 2016-07-12 21:43:01]

The CQ bit was checked by smaier@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-12 21:45:11]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-13 00:38:59]

The CQ bit was unchecked by commit-bot@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-13 00:39:00]

Dry run: This issue passed the CQ dry run.

[smaier, 2016-07-13 12:46:22]

Description was changed from

==========
Fixing WebView ProGuard config for annotations

WebView used to not -keep its annotations. Thus, when trying to do
anything useful with ProGuard, it appeared that the annotations were not
being obeyed, since ProGuard had already stripped them out.

Note - since we still have the -keepnames class *** { *; }, this effectively
prevents any real optimizations from being run.

This change brings the .dex size down 1668 B, 11 types, 5 fields, and 17
strings. However, these all seem inconsequential, as there are no methods or
classes stripped from this change.

BUG=541543
==========

to

==========
Fixing WebView ProGuard config for annotations

WebView used to not -keep its annotations. Thus, when trying to do
anything useful with ProGuard, it appeared that the annotations were not
being obeyed, since ProGuard had already stripped them out.

Note - since we still have the -keepnames class *** { *; }, this effectively
prevents any real optimizations from being run.

This change brings the .dex size down 1668 B, and removes 11 types, 5 fields,
and 17
strings. However, these all seem inconsequential, as there are no methods or
classes stripped from this change.

BUG=541543
==========

[smaier, 2016-07-13 12:46:50]

Description was changed from

==========
Fixing WebView ProGuard config for annotations

WebView used to not -keep its annotations. Thus, when trying to do
anything useful with ProGuard, it appeared that the annotations were not
being obeyed, since ProGuard had already stripped them out.

Note - since we still have the -keepnames class *** { *; }, this effectively
prevents any real optimizations from being run.

This change brings the .dex size down 1668 B, and removes 11 types, 5 fields,
and 17
strings. However, these all seem inconsequential, as there are no methods or
classes stripped from this change.

BUG=541543
==========

to

==========
Fixing WebView ProGuard config for annotations

WebView used to not -keep its annotations. Thus, when trying to do
anything useful with ProGuard, it appeared that the annotations were not
being obeyed, since ProGuard had already stripped them out.

Note - since we still have the -keepnames class *** { *; }, this effectively
prevents any real optimizations from being run.

This change brings the .dex size down 1668 B, and removes 11 types, 5 fields,
and 17 strings. However, these all seem inconsequential, as there are no
methods or classes stripped from this change.

BUG=541543
==========

[agrieve, 2016-07-13 13:42:29]

lgtm

https://codereview.chromium.org/2147743002/diff/1/android_webview/apk/java/pr...
File android_webview/apk/java/proguard.flags (right):

https://codereview.chromium.org/2147743002/diff/1/android_webview/apk/java/pr...
android_webview/apk/java/proguard.flags:11: -keep @interface **.AccessedBy*
nit: Can you add a comment warning that removing them causes the below -keeps to
not work.

[smaier, 2016-07-13 16:03:04]

Description was changed from

==========
Fixing WebView ProGuard config for annotations

WebView used to not -keep its annotations. Thus, when trying to do
anything useful with ProGuard, it appeared that the annotations were not
being obeyed, since ProGuard had already stripped them out.

Note - since we still have the -keepnames class *** { *; }, this effectively
prevents any real optimizations from being run.

This change brings the .dex size down 1668 B, and removes 11 types, 5 fields,
and 17 strings. However, these all seem inconsequential, as there are no
methods or classes stripped from this change.

BUG=541543
==========

to

==========
Fixing WebView ProGuard config for annotations

WebView used to not -keep its annotations. Thus, when trying to do
anything useful with ProGuard, it appeared that the annotations were not
being obeyed, since ProGuard had already stripped them out.

Note - since we still have the -keepnames class *** { *; }, this effectively
prevents any real optimizations from being run.

This change brings the .dex size down 7356 B, and removes 12 types, 5 fields,
and 57 strings. However, these all seem inconsequential, as this is the
method/class diff of this change:

org.chromium.base.Log
-  void d(java.lang.String,java.lang.String,java.lang.Object)
-  void v(java.lang.String,java.lang.String)
-  void
d(java.lang.String,java.lang.String,java.lang.Object,java.lang.Object,java.lang.Object)
-  java.lang.String formatLogWithStack(java.lang.String,java.lang.Object[])
-  void d(java.lang.String,java.lang.String)
-  void
v(java.lang.String,java.lang.String,java.lang.Object,java.lang.Object,java.lang.Object)
-  void <init>()
-  void d(java.lang.String,java.lang.String,java.lang.Object,java.lang.Object)
-  java.lang.String getCallOrigin()
-  void debug(java.lang.String,java.lang.String,java.lang.Object[])
-  void verbose(java.lang.String,java.lang.String,java.lang.Object[])

BUG=541543,583143,624827
==========

[Torne, 2016-07-13 16:54:25]

Why does keeping all names prevent any real optimisations from being run? What
exactly are we missing out on?

I really do want webview to keep all names, because I want people to be able to
make good guesses as to what they've done wrong from Java stack traces (plus
webview is entirely open source, so they can consult our sources if they want).
If there's a big benefit in size, though, we might have to reconsider and make
this more specific to keep only things that are likely to be helpful (not sure
how we'd really make that determination though).

https://codereview.chromium.org/2147743002/diff/60001/android_webview/apk/jav...
File android_webview/apk/java/proguard.flags (right):

https://codereview.chromium.org/2147743002/diff/60001/android_webview/apk/jav...
android_webview/apk/java/proguard.flags:14: -keep @interface **.AccessedBy*
It seems like the names here should actually match the ones used in the -keep
directives and not be globbed differently. Can you make them match one way or
the other?

https://codereview.chromium.org/2147743002/diff/60001/android_webview/apk/jav...
android_webview/apk/java/proguard.flags:46: -keep @**.UsedByReflection class *
This isn't consistent with the other class wildcards in here - either everything
should be *, or everything should be just the two package prefixes, not a
mixture?

[smaier, 2016-07-13 22:21:15]

On 2016/07/13 16:54:25, Torne wrote:
> Why does keeping all names prevent any real optimisations from being run? What
> exactly are we missing out on?

-keepnames is deceptive, as I have unfortunately learned. What -keepnames really
means is -keepnamesanddontoptimize. This prevents the names from being inlined,
which in a roundabout way is, indeed, keeping the name. However, as long as you
have your entry points explicitly -keep'ed, then it won't affect your API. 
Stack traces might be somewhat messed up (line numbers and such with inlining),
but I have a script checked into build/android/stacktrace/java_deobfuscate.py
that will fix it up.

> 
> I really do want webview to keep all names, because I want people to be able
to
> make good guesses as to what they've done wrong from Java stack traces (plus
> webview is entirely open source, so they can consult our sources if they
want).
> If there's a big benefit in size, though, we might have to reconsider and make
> this more specific to keep only things that are likely to be helpful (not sure
> how we'd really make that determination though).

I did a *very* preliminary run, and it looks like the absolute upper bound on
savings for system_webview_google_apk is 147kb .dex size, and 18.6kb dirty
memory. This included total obfuscation and optimization.

> 
>
https://codereview.chromium.org/2147743002/diff/60001/android_webview/apk/jav...
> File android_webview/apk/java/proguard.flags (right):
> 
>
https://codereview.chromium.org/2147743002/diff/60001/android_webview/apk/jav...
> android_webview/apk/java/proguard.flags:14: -keep @interface **.AccessedBy*
> It seems like the names here should actually match the ones used in the -keep
> directives and not be globbed differently. Can you make them match one way or
> the other?
> 
>
https://codereview.chromium.org/2147743002/diff/60001/android_webview/apk/jav...
> android_webview/apk/java/proguard.flags:46: -keep @**.UsedByReflection class *
> This isn't consistent with the other class wildcards in here - either
everything
> should be *, or everything should be just the two package prefixes, not a
> mixture?

[smaier, 2016-07-13 22:21:23]

https://codereview.chromium.org/2147743002/diff/60001/android_webview/apk/jav...
File android_webview/apk/java/proguard.flags (right):

https://codereview.chromium.org/2147743002/diff/60001/android_webview/apk/jav...
android_webview/apk/java/proguard.flags:14: -keep @interface **.AccessedBy*
On 2016/07/13 16:54:25, Torne wrote:
> It seems like the names here should actually match the ones used in the -keep
> directives and not be globbed differently. Can you make them match one way or
> the other?

Done.

https://codereview.chromium.org/2147743002/diff/60001/android_webview/apk/jav...
android_webview/apk/java/proguard.flags:46: -keep @**.UsedByReflection class *
On 2016/07/13 16:54:25, Torne wrote:
> This isn't consistent with the other class wildcards in here - either
everything
> should be *, or everything should be just the two package prefixes, not a
> mixture?

Done.

[Torne, 2016-07-14 10:20:47]

On 2016/07/13 22:21:15, smaier wrote:
> On 2016/07/13 16:54:25, Torne wrote:
> > Why does keeping all names prevent any real optimisations from being run?
What
> > exactly are we missing out on?
> 
> -keepnames is deceptive, as I have unfortunately learned. What -keepnames
really
> means is -keepnamesanddontoptimize. This prevents the names from being
inlined,
> which in a roundabout way is, indeed, keeping the name. However, as long as
you
> have your entry points explicitly -keep'ed, then it won't affect your API. 

Right, I'm not just concerned about the API though; remember that WebView is
used inside Android apps and when an app crashes, it will be harder for the
developer to understand the crash if the WebView-related parts of the stack are
obfuscated.

> Stack traces might be somewhat messed up (line numbers and such with
inlining),
> but I have a script checked into build/android/stacktrace/java_deobfuscate.py
> that will fix it up.

If it was just inlining messing up a few line numbers that might be okay, but
since obfuscation is enabled to allow the local variable table to be stripped,
it will actually remove all the intelligible names entirely if we don't
-keepnames here.

I guess we could, instead, disable the obfuscation pass again with
-dontobfuscate and then drop this -keepnames, allowing optimisation to do
whatever it likes. Since we're explicitly keeping the line number table it's
pretty much just the local variable table that's being dropped and it's possible
that the size gains from optimisation actually outweigh that?

In any case, this CL doesn't change anything in this regard, and you addressed
my other comments, so this CL LGTM, thanks a lot for doing this, I hadn't
guessed that keeping these would be required (that seems like a bug in proguard
tbh - it should really keep this information around internally between passes,
no? we don't actually need the types in the output).

> 
> > 
> > I really do want webview to keep all names, because I want people to be able
> to
> > make good guesses as to what they've done wrong from Java stack traces (plus
> > webview is entirely open source, so they can consult our sources if they
> want).
> > If there's a big benefit in size, though, we might have to reconsider and
make
> > this more specific to keep only things that are likely to be helpful (not
sure
> > how we'd really make that determination though).
> 
> I did a *very* preliminary run, and it looks like the absolute upper bound on
> savings for system_webview_google_apk is 147kb .dex size, and 18.6kb dirty
> memory. This included total obfuscation and optimization.

OK, so let's land this CL as-is, and also land the other debug/verbose log
stripping CL, and then we can experiment with different tradeoffs between
clarity of stack trace and size to see what our options are?

> > 
> >
>
https://codereview.chromium.org/2147743002/diff/60001/android_webview/apk/jav...
> > File android_webview/apk/java/proguard.flags (right):
> > 
> >
>
https://codereview.chromium.org/2147743002/diff/60001/android_webview/apk/jav...
> > android_webview/apk/java/proguard.flags:14: -keep @interface **.AccessedBy*
> > It seems like the names here should actually match the ones used in the
-keep
> > directives and not be globbed differently. Can you make them match one way
or
> > the other?
> > 
> >
>
https://codereview.chromium.org/2147743002/diff/60001/android_webview/apk/jav...
> > android_webview/apk/java/proguard.flags:46: -keep @**.UsedByReflection class
*
> > This isn't consistent with the other class wildcards in here - either
> everything
> > should be *, or everything should be just the two package prefixes, not a
> > mixture?

[smaier, 2016-07-14 13:35:41]

Description was changed from

==========
Fixing WebView ProGuard config for annotations

WebView used to not -keep its annotations. Thus, when trying to do
anything useful with ProGuard, it appeared that the annotations were not
being obeyed, since ProGuard had already stripped them out.

Note - since we still have the -keepnames class *** { *; }, this effectively
prevents any real optimizations from being run.

This change brings the .dex size down 7356 B, and removes 12 types, 5 fields,
and 57 strings. However, these all seem inconsequential, as this is the
method/class diff of this change:

org.chromium.base.Log
-  void d(java.lang.String,java.lang.String,java.lang.Object)
-  void v(java.lang.String,java.lang.String)
-  void
d(java.lang.String,java.lang.String,java.lang.Object,java.lang.Object,java.lang.Object)
-  java.lang.String formatLogWithStack(java.lang.String,java.lang.Object[])
-  void d(java.lang.String,java.lang.String)
-  void
v(java.lang.String,java.lang.String,java.lang.Object,java.lang.Object,java.lang.Object)
-  void <init>()
-  void d(java.lang.String,java.lang.String,java.lang.Object,java.lang.Object)
-  java.lang.String getCallOrigin()
-  void debug(java.lang.String,java.lang.String,java.lang.Object[])
-  void verbose(java.lang.String,java.lang.String,java.lang.Object[])

BUG=541543,583143,624827
==========

to

==========
Fixing WebView ProGuard config for annotations

WebView used to not -keep its annotations. Thus, when trying to do
anything useful with ProGuard, it appeared that the annotations were not
being obeyed, since ProGuard had already stripped them out.

Note - since we still have the -keepnames class *** { *; }, this effectively
prevents any real optimizations from being run.

This change brings the .dex size down 7356 B, and removes 12 types, 5 fields,
and 57 strings. However, these all seem inconsequential, as this is the
method/class diff of this change:

org.chromium.base.Log
-  void d(java.lang.String,java.lang.String,java.lang.Object)
-  void v(java.lang.String,java.lang.String)
-  void
d(java.lang.String,java.lang.String,java.lang.Object,java.lang.Object,java.lang.Object)
-  java.lang.String formatLogWithStack(java.lang.String,java.lang.Object[])
-  void d(java.lang.String,java.lang.String)
-  void
v(java.lang.String,java.lang.String,java.lang.Object,java.lang.Object,java.lang.Object)
-  void <init>()
-  void d(java.lang.String,java.lang.String,java.lang.Object,java.lang.Object)
-  java.lang.String getCallOrigin()
-  void debug(java.lang.String,java.lang.String,java.lang.Object[])
-  void verbose(java.lang.String,java.lang.String,java.lang.Object[])

BUG=541543,583143,624827,627139
==========

[smaier, 2016-07-14 13:48:47]

On 2016/07/14 10:20:47, Torne wrote:
> On 2016/07/13 22:21:15, smaier wrote:
> > On 2016/07/13 16:54:25, Torne wrote:
> > > Why does keeping all names prevent any real optimisations from being run?
> What
> > > exactly are we missing out on?
> > 
> > -keepnames is deceptive, as I have unfortunately learned. What -keepnames
> really
> > means is -keepnamesanddontoptimize. This prevents the names from being
> inlined,
> > which in a roundabout way is, indeed, keeping the name. However, as long as
> you
> > have your entry points explicitly -keep'ed, then it won't affect your API. 
> 
> Right, I'm not just concerned about the API though; remember that WebView is
> used inside Android apps and when an app crashes, it will be harder for the
> developer to understand the crash if the WebView-related parts of the stack
are
> obfuscated.
> 
> > Stack traces might be somewhat messed up (line numbers and such with
> inlining),
> > but I have a script checked into
build/android/stacktrace/java_deobfuscate.py
> > that will fix it up.
> 
> If it was just inlining messing up a few line numbers that might be okay, but
> since obfuscation is enabled to allow the local variable table to be stripped,
> it will actually remove all the intelligible names entirely if we don't
> -keepnames here.
> 
> I guess we could, instead, disable the obfuscation pass again with
> -dontobfuscate and then drop this -keepnames, allowing optimisation to do
> whatever it likes. Since we're explicitly keeping the line number table it's
> pretty much just the local variable table that's being dropped and it's
possible
> that the size gains from optimisation actually outweigh that?
> 
> In any case, this CL doesn't change anything in this regard, and you addressed
> my other comments, so this CL LGTM, thanks a lot for doing this, I hadn't
> guessed that keeping these would be required (that seems like a bug in
proguard
> tbh - it should really keep this information around internally between passes,
> no? we don't actually need the types in the output).
> 
> > 
> > > 
> > > I really do want webview to keep all names, because I want people to be
able
> > to
> > > make good guesses as to what they've done wrong from Java stack traces
(plus
> > > webview is entirely open source, so they can consult our sources if they
> > want).
> > > If there's a big benefit in size, though, we might have to reconsider and
> make
> > > this more specific to keep only things that are likely to be helpful (not
> sure
> > > how we'd really make that determination though).
> > 
> > I did a *very* preliminary run, and it looks like the absolute upper bound
on
> > savings for system_webview_google_apk is 147kb .dex size, and 18.6kb dirty
> > memory. This included total obfuscation and optimization.
> 
> OK, so let's land this CL as-is, and also land the other debug/verbose log
> stripping CL, and then we can experiment with different tradeoffs between
> clarity of stack trace and size to see what our options are?

Sounds good - lets use this bug (crbug.com/627139) for further discussion.

> 
> > > 
> > >
> >
>
https://codereview.chromium.org/2147743002/diff/60001/android_webview/apk/jav...
> > > File android_webview/apk/java/proguard.flags (right):
> > > 
> > >
> >
>
https://codereview.chromium.org/2147743002/diff/60001/android_webview/apk/jav...
> > > android_webview/apk/java/proguard.flags:14: -keep @interface
**.AccessedBy*
> > > It seems like the names here should actually match the ones used in the
> -keep
> > > directives and not be globbed differently. Can you make them match one way
> or
> > > the other?
> > > 
> > >
> >
>
https://codereview.chromium.org/2147743002/diff/60001/android_webview/apk/jav...
> > > android_webview/apk/java/proguard.flags:46: -keep @**.UsedByReflection
class
> *
> > > This isn't consistent with the other class wildcards in here - either
> > everything
> > > should be *, or everything should be just the two package prefixes, not a
> > > mixture?

[smaier, 2016-07-14 13:52:33]

The CQ bit was checked by smaier@chromium.org

[smaier, 2016-07-14 13:52:33]

The patchset sent to the CQ was uploaded after l-g-t-m from agrieve@chromium.org
Link to the patchset: https://codereview.chromium.org/2147743002/#ps80001
(title: "Addressing Torne's comments")

[commit-bot: I haz the power, 2016-07-14 13:52:53]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-14 14:36:36]

Description was changed from

==========
Fixing WebView ProGuard config for annotations

WebView used to not -keep its annotations. Thus, when trying to do
anything useful with ProGuard, it appeared that the annotations were not
being obeyed, since ProGuard had already stripped them out.

Note - since we still have the -keepnames class *** { *; }, this effectively
prevents any real optimizations from being run.

This change brings the .dex size down 7356 B, and removes 12 types, 5 fields,
and 57 strings. However, these all seem inconsequential, as this is the
method/class diff of this change:

org.chromium.base.Log
-  void d(java.lang.String,java.lang.String,java.lang.Object)
-  void v(java.lang.String,java.lang.String)
-  void
d(java.lang.String,java.lang.String,java.lang.Object,java.lang.Object,java.lang.Object)
-  java.lang.String formatLogWithStack(java.lang.String,java.lang.Object[])
-  void d(java.lang.String,java.lang.String)
-  void
v(java.lang.String,java.lang.String,java.lang.Object,java.lang.Object,java.lang.Object)
-  void <init>()
-  void d(java.lang.String,java.lang.String,java.lang.Object,java.lang.Object)
-  java.lang.String getCallOrigin()
-  void debug(java.lang.String,java.lang.String,java.lang.Object[])
-  void verbose(java.lang.String,java.lang.String,java.lang.Object[])

BUG=541543,583143,624827,627139
==========

to

==========
Fixing WebView ProGuard config for annotations

WebView used to not -keep its annotations. Thus, when trying to do
anything useful with ProGuard, it appeared that the annotations were not
being obeyed, since ProGuard had already stripped them out.

Note - since we still have the -keepnames class *** { *; }, this effectively
prevents any real optimizations from being run.

This change brings the .dex size down 7356 B, and removes 12 types, 5 fields,
and 57 strings. However, these all seem inconsequential, as this is the
method/class diff of this change:

org.chromium.base.Log
-  void d(java.lang.String,java.lang.String,java.lang.Object)
-  void v(java.lang.String,java.lang.String)
-  void
d(java.lang.String,java.lang.String,java.lang.Object,java.lang.Object,java.lang.Object)
-  java.lang.String formatLogWithStack(java.lang.String,java.lang.Object[])
-  void d(java.lang.String,java.lang.String)
-  void
v(java.lang.String,java.lang.String,java.lang.Object,java.lang.Object,java.lang.Object)
-  void <init>()
-  void d(java.lang.String,java.lang.String,java.lang.Object,java.lang.Object)
-  java.lang.String getCallOrigin()
-  void debug(java.lang.String,java.lang.String,java.lang.Object[])
-  void verbose(java.lang.String,java.lang.String,java.lang.Object[])

BUG=541543,583143,624827,627139
==========

[commit-bot: I haz the power, 2016-07-14 14:36:37]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-07-14 14:36:39]

CQ bit was unchecked.

[commit-bot: I haz the power, 2016-07-14 14:39:32]

Description was changed from

==========
Fixing WebView ProGuard config for annotations

WebView used to not -keep its annotations. Thus, when trying to do
anything useful with ProGuard, it appeared that the annotations were not
being obeyed, since ProGuard had already stripped them out.

Note - since we still have the -keepnames class *** { *; }, this effectively
prevents any real optimizations from being run.

This change brings the .dex size down 7356 B, and removes 12 types, 5 fields,
and 57 strings. However, these all seem inconsequential, as this is the
method/class diff of this change:

org.chromium.base.Log
-  void d(java.lang.String,java.lang.String,java.lang.Object)
-  void v(java.lang.String,java.lang.String)
-  void
d(java.lang.String,java.lang.String,java.lang.Object,java.lang.Object,java.lang.Object)
-  java.lang.String formatLogWithStack(java.lang.String,java.lang.Object[])
-  void d(java.lang.String,java.lang.String)
-  void
v(java.lang.String,java.lang.String,java.lang.Object,java.lang.Object,java.lang.Object)
-  void <init>()
-  void d(java.lang.String,java.lang.String,java.lang.Object,java.lang.Object)
-  java.lang.String getCallOrigin()
-  void debug(java.lang.String,java.lang.String,java.lang.Object[])
-  void verbose(java.lang.String,java.lang.String,java.lang.Object[])

BUG=541543,583143,624827,627139
==========

to

==========
Fixing WebView ProGuard config for annotations

WebView used to not -keep its annotations. Thus, when trying to do
anything useful with ProGuard, it appeared that the annotations were not
being obeyed, since ProGuard had already stripped them out.

Note - since we still have the -keepnames class *** { *; }, this effectively
prevents any real optimizations from being run.

This change brings the .dex size down 7356 B, and removes 12 types, 5 fields,
and 57 strings. However, these all seem inconsequential, as this is the
method/class diff of this change:

org.chromium.base.Log
-  void d(java.lang.String,java.lang.String,java.lang.Object)
-  void v(java.lang.String,java.lang.String)
-  void
d(java.lang.String,java.lang.String,java.lang.Object,java.lang.Object,java.lang.Object)
-  java.lang.String formatLogWithStack(java.lang.String,java.lang.Object[])
-  void d(java.lang.String,java.lang.String)
-  void
v(java.lang.String,java.lang.String,java.lang.Object,java.lang.Object,java.lang.Object)
-  void <init>()
-  void d(java.lang.String,java.lang.String,java.lang.Object,java.lang.Object)
-  java.lang.String getCallOrigin()
-  void debug(java.lang.String,java.lang.String,java.lang.Object[])
-  void verbose(java.lang.String,java.lang.String,java.lang.Object[])

BUG=541543,583143,624827,627139

Committed: https://crrev.com/6eff9fcd9bce74c436c3ce33355f1b7acbcc3b34
Cr-Commit-Position: refs/heads/master@{#405491}
==========

[commit-bot: I haz the power, 2016-07-14 14:39:33]

Patchset 5 (id:??) landed as
https://crrev.com/6eff9fcd9bce74c436c3ce33355f1b7acbcc3b34
Cr-Commit-Position: refs/heads/master@{#405491}

[sgurun-gerrit only, 2016-07-14 17:26:18]

On 2016/07/14 14:39:33, commit-bot: I haz the power wrote:
> Patchset 5 (id:??) landed as
> https://crrev.com/6eff9fcd9bce74c436c3ce33355f1b7acbcc3b34
> Cr-Commit-Position: refs/heads/master@{#405491}

I am late to the party, but fully agreed with Torne's comments here. We had
quite a bit of issues debugging GMSCore obfuscations. I don't want WebView
developers to have the same pain.

[sgurun-gerrit only, 2016-07-14 17:26:19]

On 2016/07/14 14:39:33, commit-bot: I haz the power wrote:
> Patchset 5 (id:??) landed as
> https://crrev.com/6eff9fcd9bce74c436c3ce33355f1b7acbcc3b34
> Cr-Commit-Position: refs/heads/master@{#405491}

I am late to the party, but fully agreed with Torne's comments here. We had
quite a bit of issues debugging GMSCore obfuscations. I don't want WebView
developers to have the same pain.