I'm just going through a similar exercise in order to build lite and
pro versions of the app from a single codebase.
I'm using an Ant script derived from this one:
http://ulrichscheller.blogspot.com/2009/10/android-deploying-multiple...
which converts the project from one target to the other.
The Ant script only does three things:
(1) Copies the resources which are different for the two targets into
the /res directory
(2) Changes import com.company.product.lite.R; into import
com.company.product.pro.R; (or vice-versa) in all the Java files
(3) Changes the package name in the manifest from
com.company.product.lite into com.company.product.pro
I'm suprised to find that I can leave the package name
(com.company.product) unchanged in the java files, and my pro and lite
builds can coexist on a device. I had expected a clash of classnames
there.
I only have a couple of wrinkles remaining. I need to use a different
name (or maybe a different authority?) for my provider for the two
variants:
<provider android:name="com.company.product.MyProvider"
android:authorities="com.company.product.MyProvider"
/>
since having that identical in both apps stops the second one loading.
And, because I am using the same mime type and so on in my intents,
having both apps installed means that most activity transitions go
through a chooser asking the user which version of the app to use.
That may be acceptable, because I don't expect both apps to be
installed for long over the lite->pro upgrade.
Richard
On Jan 9, 12:41 am, Lance Nanek <lna...@gmail.com> wrote:
> I managed to do it without updating the imports, but it is pretty
> nasty besides that.
> I have two projects, lets call them A and B. All the directories in
> project B are actually just SVN externals that reference the
> directories of project A:http://svnbook.red-bean.com/en/1.0/ch07s03.html
> Therefore the only thing different about project B, when it is fully
> up to date with the repository, is the AndroidManifest.xml. That's a
> duplicate except that I change the package name.
> The code can tell the package being used via Context#getPackageName.
> Project B has project A in its Java build path in Eclipse, so all the
> R class imports written for project A work even in project B.
> Occasionally there is a random build error and I have to remove
> project A from the build path and put it back, or open and close the
> project.
> I saw someone mention that aapt can be used manually to generate the R
> class in a different package than normal. So maybe a cleaner way to do
> this, without giving up and doing the change all the imports thing
> each build, is to use that to generate an R class for B that is in A's
> package. That would remove the scary hack of having project B access
> its own resources via project A's R class, which just happens to be
> generated with the same values because all the files are the same.
> On Jan 8, 6:01 pm, BrianS <bnsaw...@aol.com> wrote:
> > Hi--
> > I need to be able to easily create different "flavors" on an app, each
> > with a unique package name so that they can coexist on the same
> > device. Is there a simple way this can be done, which doesn't require
> > manually updating all the imports and other references to the package
> > name each time I change it?
> > Thanks much!
