Hmm, that makes sense and isn't something I had thought about. We currently don't have any resources in these projects, but that may become an interesting challenge in the future. I'll stick with stripping the code via proguard for now.
On Wednesday, October 29, 2014 3:05:48 PM UTC-7, Xavier Ducrohet wrote: > > known issue. > > https://code.google.com/p/android/issues/detail?id=77162 > > You shouldn't actually use an aar as a provided dependency. This makes no > sense if you have resources. > > (yes you could technically have an aar with resources in it, but we don't > yet handle this case). > > On Wed, Oct 29, 2014 at 3:00 PM, Chris Sarbora <[email protected] > <javascript:>> wrote: > >> If this isn't already a known bug, I'll create and attach a project that >> reproduces the issue. I've found that using the "provided" configuration >> with a JAR artifact will (correctly) include the jar on the classpath but >> exclude it from the APK, whereas specifying an AAR artifact ends up with >> that code being *included* in the APK. Currently the only workaround I >> have is to hack up the proguard<Variant> task and add the undesired classes >> to an exclude pattern. >> >> -- >> 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.
