tag:blogger.com,1999:blog-7710955663058460658.post6375609885424987468..comments2015-05-06T04:59:55.858-07:00Comments on Brad's Android Blog: Android Gradle - Building Unique Build VariantsBrad McManushttp://www.blogger.com/profile/13197941975972434989noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-7710955663058460658.post-22910307062859509102015-05-06T04:59:55.858-07:002015-05-06T04:59:55.858-07:00Yes, dependsOn needs a task or a closure returning...Yes, dependsOn needs a task or a closure returning a task. doFirst should be the way to go, especially since you don't want to override those things if they won't be used at all (AS calling generateDebugSources for example).TWiStErRobhttps://www.blogger.com/profile/06796806062682950121noreply@blogger.comtag:blogger.com,1999:blog-7710955663058460658.post-31541957478078549532015-05-06T04:59:24.622-07:002015-05-06T04:59:24.622-07:00This comment has been removed by the author.TWiStErRobhttps://www.blogger.com/profile/06796806062682950121noreply@blogger.comtag:blogger.com,1999:blog-7710955663058460658.post-34301543163536921062014-02-07T12:57:15.149-08:002014-02-07T12:57:15.149-08:00Hey Brad, wow, thanks for this. The valuable "...Hey Brad, wow, thanks for this. The valuable "take home" for me is just how the override mechanism works for Android Gradle. I too noticed that my gradle code executed on a simple "gradle tasks" call. I believe the reason is that the code is executing on the 'configuration' rather than 'execute' phase. <br />I wonder is it possible to rewrite your override to:<br />variant.mergeResources.doFirst {<br /> overrideMapsKey(variant)<br /> overrideContentProviderAuthority(variant)<br />}<br />I intend to play with this, but haven't tried it yet.Anonymoushttps://www.blogger.com/profile/14618383610221351039noreply@blogger.comtag:blogger.com,1999:blog-7710955663058460658.post-45074352297271294522013-08-29T05:46:48.650-07:002013-08-29T05:46:48.650-07:00ok, I think now I understand the problem... I didn...ok, I think now I understand the problem... I didn't see the sourceSets of you buildTypes. I thought that your extra flavour "unique_overrides" would be merged with the other flavor ("free" and "paid").<br /><br />So this solution doesn't work for me. <br /><br />I think I have only two options: either I override string values of my flavors or complete lines in my manifest. I also read a lot about replacing tokens in gradle but I couldn't make it work.<br /><br />Thanks for your fast reply :)wolkehttps://www.blogger.com/profile/06025827731198617183noreply@blogger.comtag:blogger.com,1999:blog-7710955663058460658.post-70027809490539516982013-08-28T08:12:04.133-07:002013-08-28T08:12:04.133-07:00Hello,
If your code has generated the override va...Hello,<br /><br />If your code has generated the override value (and the contents of the file contain the correct value), but this override doesn't show up under build/res/all, then it is likely that variant hasn't been told to pick up the override resource folder. In my example, look at the sourceSets closure from build.gradle. Builds of the debug buildType will not take overrides (because it does not specify a resource folder for itself), but all other buildTypes specify a path for res.srcDirs.Brad McManushttps://www.blogger.com/profile/13197941975972434989noreply@blogger.comtag:blogger.com,1999:blog-7710955663058460658.post-66845212184766443082013-08-28T04:32:08.699-07:002013-08-28T04:32:08.699-07:00This comment has been removed by the author.wolkehttps://www.blogger.com/profile/06025827731198617183noreply@blogger.comtag:blogger.com,1999:blog-7710955663058460658.post-21575193263040765282013-08-27T14:45:52.177-07:002013-08-27T14:45:52.177-07:00The way that productFlavor and buildType resource ...The way that productFlavor and buildType resource folders get merged into the final set of resources does not work for the problem described in this post. The current system works by adding/merging the given productFlavor and buildType resource folders. The issue is when I need a unique resource for each buildVariant. Take the productFlavor { free, paid} and buildType { alpha, beta} example, for instance. There is no built-in facility for generating/selecting a unique resource for each of the buildVariants: freeAlpha, freeBeta, paidFree, and paidBeta.Brad McManushttps://www.blogger.com/profile/13197941975972434989noreply@blogger.comtag:blogger.com,1999:blog-7710955663058460658.post-77914965479368292752013-08-27T14:15:07.668-07:002013-08-27T14:15:07.668-07:00You can define multiple source folders (to go alon...You can define multiple source folders (to go along side main). When the build variant is generated, it will pick up the appropriate files. <br />I made a config file in 'paid' and 'free' source folders with keys and a boolean to keep the code exactly the same (programmatic check for paid/free).<br />You may be able to do the same with the manifest file (one in main, paid and free) which may help with the content provider (I haven't had chance to play with this yet)Anonymoushttps://www.blogger.com/profile/01666485042695215131noreply@blogger.com