GitLab

The general sequence of operations here is :

(1) Compile core-all with a specified input obfuscation map (see below).
Classes that aren't specified in the input obfuscation map are
obfuscated according to proguard's usual algorithm. Classes that match
keep rules (public API, usually) are left alone. In addition, proguard
will produce an output obfuscation mapping after it processes this target.
This will be a superset of the input obfuscation map.

(2) Compile core-all-obfuscated, which uses the same input fileset as
core-all but has proguard turned off.

(3) Compile core-oj and core-libart against core-all-obfuscated. Then
apply the obfuscation map from (1).

Why is an input obfuscation map necessary for step (1) ?
Native methods, mainly. Proguard will leave package names unchanged
for classes that have native methods. This will force *all* classes in
that package to have unobfuscated package names since proguard doesn't
go through the trouble of proving there's no package private accesses
across these packages. We want to force these classes to be obfuscated,
but in a manner that allows us to easily to fix up the native code to
reflect the new naming. This change includes a script that can munge an
obfuscation map from proguard to force obfuscation of known bad classes
and packages. In addition, we force proguard to perform an "inconsistent"
obfuscation for sun.misc. We want to leave the package name for Unsafe
unchanged but want the rest of the package to be obfuscated. This is
provably safe because Unsafe doesn't contain any non public methods.

Change-Id: Ibdfb8ca36d6e0bfedd7552268c5cb83e68cccf09