Different "build.settings" for different build targets (re: DRM on Amazon vs Google Play)

Solar2D Android
#1

I went looking for an answer to this, but didn’t find any that were satisfying.  I would really love to see a technique (that would be easy to maintain) that would allow me to specify different permissions for android builds because they are different on Google Play and Amazon due to licensing / DRM integration.

In particular, I don’t like requiring the INTERNET permission on children’s apps.  It sets off an alarm for many people who are concerned that other content may be dynamically downloaded.  In fact, Amazon warns users of that when viewing my app in the app store.  However, the only reason it’s there at all is because it’s required for the Google Play licensing check integration.  Amazon has their own DRM solution that does not require me to declare any permissions at all… they do it all on their side by wrapping the APK from what I understand.

So I went hunting for an easy way to do this in my Corona projects… I like to automate as much as possible so I don’t have to remember all these little details when I go into “production mode” on a project and start building and testing for release on the various platforms.  I couldn’t find an easy way to do this.

Given that Corona supports special builds (and special tags like “android” in the build.settings)… it seems reasonable for me to be able to put special settings in there per build target type as well.  Actually, in this case, it would also be convenient for the Google Play builds with licensing enabled to infer the permissions since it’s really only for that purpose.

Anyways… any ideas are welcome.  Just please don’t suggest that I keep a bunch of copies and rename them before each build.  That’s the obvious workaround… and the solution I hate the most.   :slight_smile:

#2

The way I do it is to have a specific directory structure. One for my source code and another for my targets.

For each unique target (Apple, Google, Amazon, Paid, IAP etc) I have a separate directory. In each of these directories I create symbolic links to the actual source files. This way you can have multiple versions of any file and just link them in the appropriate target directory.

It may sound complicated however it’s possible to develop scripts that automate the process.

#3

Just FYI for anyone else stumbling across this posting… I’m on windows and wanted a strategy to easily manage this workaround and be able to keep files in source control… so I ended up settling on a “file based” workaround whereby I just name different “build.settings” files according to their intended target and prefix them with a “dot” so they are ignored (e.g., “.build.settings.google”, “.build.settings.amazon”, “.build.settings.ios”).  Then I just copy from those to the main “build.settings” before building for each target.

This is an area that I hope the devs at Corona start to pay more attention to… streamlining the build process for productivity is an area that really needs some attention.  In particular, I would love to be able to do a scripted command line build that builds for all of my intended targets whenever I am ready to release an update.  This GUI based build process with manual steps required to build differently for iOS versus Google Play versus Amazon/Nook is a productivity killer.  I know there are some tricky parts to deal with (e.g., M4A versus OGG, app store features, device features, etc) but it can be cleaned up with a few more conventions to make it easy to keep organized and/or command line options so builds can be kicked off in combination with some scripting that automates as much of these annoyances as possible.

Don’t get me wrong here… I still love Corona!  Even with these annoyances… it’s been an awesome way for me to implement projects that target multiple platforms in a very productive way.  I just think the build process needs some attention before it gets out of hand with all of these differences to deal with (audio formats, device capabilities, app store capabilities, etc).   :slight_smile:

#4

The way I do it is to have a specific directory structure. One for my source code and another for my targets.

For each unique target (Apple, Google, Amazon, Paid, IAP etc) I have a separate directory. In each of these directories I create symbolic links to the actual source files. This way you can have multiple versions of any file and just link them in the appropriate target directory.

It may sound complicated however it’s possible to develop scripts that automate the process.

#5

Just FYI for anyone else stumbling across this posting… I’m on windows and wanted a strategy to easily manage this workaround and be able to keep files in source control… so I ended up settling on a “file based” workaround whereby I just name different “build.settings” files according to their intended target and prefix them with a “dot” so they are ignored (e.g., “.build.settings.google”, “.build.settings.amazon”, “.build.settings.ios”).  Then I just copy from those to the main “build.settings” before building for each target.

This is an area that I hope the devs at Corona start to pay more attention to… streamlining the build process for productivity is an area that really needs some attention.  In particular, I would love to be able to do a scripted command line build that builds for all of my intended targets whenever I am ready to release an update.  This GUI based build process with manual steps required to build differently for iOS versus Google Play versus Amazon/Nook is a productivity killer.  I know there are some tricky parts to deal with (e.g., M4A versus OGG, app store features, device features, etc) but it can be cleaned up with a few more conventions to make it easy to keep organized and/or command line options so builds can be kicked off in combination with some scripting that automates as much of these annoyances as possible.

Don’t get me wrong here… I still love Corona!  Even with these annoyances… it’s been an awesome way for me to implement projects that target multiple platforms in a very productive way.  I just think the build process needs some attention before it gets out of hand with all of these differences to deal with (audio formats, device capabilities, app store capabilities, etc).   :slight_smile: