I work for PreEmptive Solutions, and we make DashO, an obfuscation and
application protection tool for Java and Android apps. Starting with the
1.0 version of the Android Gradle plugin, we’ve provided a deep integration
between DashO and Gradle, for Android builds, by carefully modifying the
Android Gradle plugin. Our approach was essentially to replace the
“proguard” task with one of our own, because that was the only effective
way to be able to do everything we need to do, within the Android Gradle
build framework.
Now with Android Gradle 1.5, the changes to the plugin are so significant
that we’re going to have to re-do much of our work. It looks like it might
be possible for us to again replace the “proguard” task (which seems risky,
given how fluid that code has been), but we are also looking at using the
new Transform API to better integrate DashO. However there are a few things
in the current implementation that prevent us from being able to do that.
First there are a few simple/general issues that probably affect everybody:
1. The outputs require unique names but the inputs do not have unique
names. All the aar inputs all have the same name: classes.jar. This
prevents a transform from simply using the input name as the output name.
A proposed solution is to use the unique dependency information in the
name (E.G. "com.android.support.appcompat-v7_23.1.1.aar” (or .jar))
2. Jars can get lost between transforms. I was using the unique paths of
the inputs to attempt to create unique output names. None of the outputs
which contained path separators as part of the unique names were passed on
to the following transform.
I have a sample transform and application which I can provide to show the
above issues.
There are also a number of issues that currently make it very difficult for
us to use the Transform API:
1. We need more information passed in the Context.
1. BuildFlavor name.
2. Signing Configuration
3. Sdk directory
Possibly just include
com.android.builder.core.VariantConfiguration
2. We would like to be able to transform the AndroidManifest.xml along
with the classes and resources. If a class gets renamed, its reference in
AndroidManifest.xml also needs to be renamed.
3. The names of the inputs have no context to determine what they
represent (E.G. Classes.jar). In our transform we may want to merge a
particular aar into another or into a single output. Without any context,
this is not possible.
4. We provide our own obfuscation and would like to be able to configure
resource shrinking without configuring ProGuard to run.
We know that you want to make the Transform API as useful as possible, and
we also want to be able to use the Transform API, on the assumption that it
will give us a more-stable way to integrate with Android Gradle. Can we
work together to make that possible?
--
You received this message because you are subscribed to the Google Groups
"adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
