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-targets-from.html 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 <[email protected]> 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 <[email protected]> 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! > > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
