On Fri, Nov 20, 2015 at 8:59 AM, Matthew Insko <[email protected]> wrote:
> 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)) > Right, this is something we want to do. > > 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. > I'd love to get this sample project. > > 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 > I think this is something that should be solved with per-variant configuration, which we want to do as well. Since you instantiate the transform, just create a different instance for each variant and pass it whatever you want in its constructor. > 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. > There is an order problem here. The current order is manifest merger -> aapt -> javac -> transforms -> dx The reason for this order is that aapt reads in the manifest and generates some code that needs to be compiled. This is the same steps that creates the compiled resources that gets packaged in the APK. In order to change the manifest after compilation, we have several options: 1) (naive) split aapt in two steps: 1) generate R.java, 2) create the binary. This is going to effectively double aapt's execution time. This is not good. 2) implement a transform pipeline for the manifest that runs aapt and has access to enough information to allow obfuscating the class names, in a way that the bytecode transform pipeline can reuse. I feel this would be complicated and error prone but we could investigate. 3) we have significant improvements in aapt coming which will make it incremental and split it in small tasks. This could allow us to do a better option (1) without doubling the aapt execution time. None of these are trivial though. It would take a bit of time to get right. > > 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. > This should be solve by making the "name" of the input relevant. This is definitively something we want to do. > > 4. We provide our own obfuscation and would like to be able to configure > resource shrinking without configuring ProGuard to run. > That's a fair requirement as well. Right now both proguard, and res shrinking are done through transforms, so it should be trivial to enable a custom obfuscation transform and res shrinking. > > 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? > Absolutely. The manifest part seems a bit more complex and I can't guarantee that we can fix this super quickly, but some of the other points are definitively something we want to fix quickly. > > > -- > 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. > -- Xavier Ducrohet Android SDK Tech Lead Google Inc. http://developer.android.com | http://tools.android.com Please do not send me questions directly. Thanks! -- 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.
