tree 165fa6211de9daced40e9ea75817b62538802eae
parent 444fcf2ecc5335f2bc14661e7d9c3463e30e43ff
author Jinseong Jeon <jsjeon@google.com> 1528870518 -0700
committer Jinseong Jeon <jsjeon@google.com> 1528871267 +0000

Add tests for Proguard's behavior regarding -allowaccessmodification.

That is, this CL does not change the way R8 handles that flag.

According to the black-box testing, access flags are modified only if:
  1) minification is enabled;
  2) -repackageclasses is provided; and
  3) -allowaccessmodification is set.

Besides, Proguard tries to keep even access modifiers as-is if items
are mentioned in keep rules.

------

Access relaxation could be related to:

* minification:
For example, relaxing private Base#neverConflict() may conflict with
public Sub#neverConflict(), without changing either name. Assigning
a new name to previously private method is one good way to avoid that.
That is, without minification being enabled, what we can apply access
relaxation would be quite limited.

* repackaging:
Similar to minification, without repackaging, package-private methods
and their enclosing classes should be treated carefully. For instance,
say Cls#foo() is package-private, and its method references are used
somewhere as a lambda. Synthetic lambda desugared class should be in
the same package scope---with the same package prefix, otherwise an
illegal access error rises.  With repackaging---if package hierarchy can
be ignored, we can easily promote package-private methods to public and
put lambda classes anywhere.

Bug: 92236970, 72109068
Change-Id: I8dbe7688b9ea7b310693948743a7e2fdabc645d5