Xavier, Thanks for your quick feedback. The sample can be found on github at https://github.com/minsko/AndroidGradleTransformTest. It is just a quick Hello World app created in Android Studio. The transform is in buildSrc.
Regards, Matt Insko On Friday, November 20, 2015 at 8:09:56 PM UTC-5, Xavier Ducrohet wrote: > > On Fri, Nov 20, 2015 at 8:59 AM, Matthew Insko <[email protected] > <javascript:>> 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] <javascript:>. >> 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.
