Selecting different source code options for the build is easy, but outputting different package names is not.
It is if you start using Gradle for Android for your builds.
Each installation might be an internal beta alongside the production release
This maps to the Gradle for Android concept of "build types".
or it might be different versions of the same app with different options
This maps to the Gradle for Android concept of "product flavors".
or it might be for A-B testing purposes
I think that the conventional approach here isn't to have separate APKs, but rather a single APK that determines whether it is A or B based upon other criteria and behaves accordingly.
The package name is specified in the AndroidManifest.xml and then turns up in the R.java and as a namespace in the XML. According to some searching, it also could be a factor in dynamic loading of resources, intent naming, etc. It's not easy to find all the places where it needs to be renamed.
Gradle for Android helps split the role of the package name into:
the application ID, used to determine whether this app and another app can be installed at the same time on the same device
the package name used for R.java generation
Build types allow you to add a suffix to the package name for the purposes of the application ID role. Product flavors allow you to replace the package name for the purposes of the application ID role. Neither affects the package name as is used for your resources.
(a) is this a viable solution
If I had to guess, that switch is what Gradle for Android uses for the aforementioned application ID change, and so it should be viable for use elsewhere.
(b) can it be done with an Eclipse build
I am not aware that you can alter switches for those sorts of things in Eclipse. Gradle for Android would also not run from inside Eclipse either, at least not at the moment. But what you are seeking does not make much sense for an IDE, anyway, IMHO. Use Ant directly, Gradle for Android directly, or a continuous integration server that uses Ant or Gradle for Android.
(c) what will it miss, requiring awareness in the running app?
If by "it" you mean the renamed application ID, it should have no effect on most of your code. getPackageName() should return the application ID, though, so things that depend upon it (e.g., Maps V2 API keys) will need to take the various possible values into account.
