Long term we want to allow fine tuning of what gets proguarded. It's a bit complicated though, so maybe we could add a single flag for all dependencies but I would think most people will want to to proguard at least some of their dependencies.
For the dependencies that require some classes to not be obfuscated, they should distribute an aar with its own proguard rules so that, as a consumer, you don't have to care. Easier said than done of course. So anyway, yes we want to provide more control over this but we're not sure when it'll happen. On Fri, Mar 28, 2014 at 7:29 AM, Croc <[email protected]> wrote: > We've been having problems with Proguard for quite a while now, but we've > always managed to solve them somehow. However, now we have a very strange > problem that we don't know how to solve with the build flow we've been > using so far, but we know how to solve it by changing the way apks are > being built/obfuscated. > > So, the problem with the current build flow, at least for us, is (when > building release versions of apks, or more precisely, when using Proguard) > that all the sources and classes/jars are sent to Proguard which makes a > single jar from all the input and then sends that single jar to dex. The > solution we are using with our "make" build tool is, that we only pass our > project sources to Proguard (we use -libraryjars for referencing jars) and > then pass *that jar along with other library jars* (that were never sent > through Proguard) to dex. So the difference is that we don't pass just one > (final) jar to dex, but we pass one obfuscated (our sources) and other > non-obfuscated (libraries) jars to dex and that solution works for us. We > need to do this at least in 2 different cases (one involves Unity and the > other Amazon jars). > > So my question is, how (if at all) can we do that with Gradle? Any kind of > feedback is much appreciated. > > P.S. > Adding -keepclass to Proguard settings doesn't work in these problematic > cases (in other cases it did, but those aren't the issue here), that's why > we need to bypass Proguard in some cases/jars completely. > Also, having a lot of ad proivders adding, updating and removing their > jars also means that proguard-project.txt has to be updated constantly, > which is error prone. It's much easier if those jars are just not passed to > Proguard at all. > > -- > 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.
