Thanks Xavier. I think I'll just have a debug specific proguard config. It's the least intrusive way I can think of.
One more thing which comes to my mind would be to run the tests with a different build type. Is there any way to control which apk is taken by connectedAndroidTest task? Thanks, Tomek On Thursday, May 1, 2014 9:02:51 PM UTC+2, Xavier Ducrohet wrote: > > First I want to mention that the setup of the proguard task was broken > with regard to how it detect inputs and this broken incremental support. > This should be fixed in 0.10 which was released yesterday). > > The reason you want to run proguard on the test is not to obfuscate or > shrink the test but to update the test code to reflect obfuscation in the > tested code. Otherwise the tested app code won't match the code expected by > the test and it'll fail. > > For libraries it's a bit different since the tested code is packaged with > the test app. > > In case of a tested app/test app, the test app compiles with the output of > the tested app javaCompilation put on its classpath. > For libraries, it's the packaged libraries that's put on the classpath of > the test app, so you don't get access to non-obfuscated versions of > classes. Clearly this is not great when testing a library, and you probably > would want to test the non-obfuscated version. Right now this would require > you to test against a version that's not proguarded. > > > On Thu, May 1, 2014 at 11:38 AM, Tomek Kwiecień > <[email protected]<javascript:> > > wrote: > >> Hi, >> >> Scenario: >> From time to time the app gets broken when using proguard. This is either >> during the building process which is an easier case or during the app start >> on a device usually with some missing classes. To address this I want to >> enable proguard for the debug build and run simple 'sanity' integration >> tests. (I understand it will make actual debugging harder but I would like >> to have at least one build variant with proguard enabled i can test >> automatically). >> >> Problem: >> If i enable proguard like this: >> >> runProguard true >> proguardFile 'proguard.cfg' >> >> The build will be fine but it will also try to run proguard on the test >> apk. It forces me to introduce a test app specific proguard configuration. >> I want to use the same configuration i use for the release apk. >> I can disable proguard task: >> >> gradle.projectsEvaluated { >> proguardDebugTest.enabled = false >> } >> >> This will make the build fail because it wont run :preDexDebugTest and >> the :dexDebugTest task will have no input: >> >> Execution failed for task ':dexDebugTest'. >> > com.android.ide.common.internal.LoggedErrorException: Failed to run >> command: >> D:\Dev\Android SDK\build-tools\19.0.1\dx.bat --dex --output >> D:\Workspace\keepsafe\KeepSafe\mobile\android\build\dex\test\debug >> Error Code: >> 1 >> Output: >> no input files specified >> >> >> >> I've searched SO and this group but can't find any answer to my problem. >> Does anybody have a configuration like this running successfully? >> If it can't be done like this: >> >> - Can I make integration tests take a release apk? >> - The android plugin registers tasks depending on the configuration. >> If i turn proguard on :preDexDebugTest wont even get registered. Wouldn't >> it make more sense to register them anyway and build the dependsOn chain >> depending on configuration? >> >> There is one thing I've noticed while going through the sources. >> BasePlugin.groovy:1414 >> has a flag like this: >> >> boolean runProguard = variantConfig.buildType.runProguard && >> (variantConfig.type != TEST || >> (variantConfig.type == TEST && >> variantConfig.testedConfig.type != >> VariantConfiguration.Type.LIBRARY)) >> >> Why it makes sense to run proguard if the test apk is not a library but >> it doesn't make sense for a library. Is there any reason to run proguard >> for the test apk at all? >> >> Sorry if this something crazy I'm trying to do, I'm new to Android. I'd >> be grateful for any tips how I can solve this. >> >> Thanks, >> Tomek >> >> -- >> 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.
