Hope I got your right when assuming you're more looking for a general way how to do it then an actual list of files you've to change. Because this is something you'll probably won't come around to figure it out by yourself. (THough android projects are well structured it might be enough to just change the res/
, asserts/
folder and the android.manifest
file. I merely used anything more on my Phonegap projects.
So my weapon of choice would be git branches.
(Some words about git if you've not already heard about it.)
Given the last commit represents your finished application. From here you can fork the project for a (e.g. Valencia CF) release. Make sure that you only change the resources but nothing in the main program! It is important that your main development branch remains the most developed version!
So after releasing the second and third app you might want to do some bug fixes.
You'll switch back into your development branch and continue to make your code even better. Hitting the next release you'll again branch of for all the other teams you want to gives updates to.
So you have a couple of branches with the updated version but the same resources on the one hand and already styled apps all on your old version.
If you have a charming git client you could easily pick the files you want to changes. This takes varies from easy to "wtf-MOAH-pcCra$h throwing away the computer" if you have a lot of individual files to merge but not simply big folders + few files like res/
and android.manifest
.
Another possibility would be to use a git feature called cherry-pick. I've never used it but the description sounds pretty much like what you want:
Given one or more existing commits, apply the change each one
introduces, recording a new commit for each. This requires your
working tree to be clean (no modifications from the HEAD commit).
(Here's the rich SO thread where I've picked that it up.)
You have your clean working tree since you just branched of your new version to re-apply the Valencia CF design. Therefore the HEAD is clean and you can cherry-pick the commits from the old version where you've applied the design already.
Very probably something has changed from the old to the new version which requires to update the resources. (Some views went but other got introduced for example). However just go ahead and get it done but make sure to commit your final result because this commit will be the cherry-pick for the even better and greater version which you've already started to work on in your developing branch.
Though not directly related to your question I also would you recommend to read A successful Git branching model which gives you another idea how you can use branches to your favour.
Anyway I don't think it's the only possible solution but for it seems to be the most convenient method. Since all the magic you do is in the project folder you can just copy and paste them and edit the stuff manually or via clever programs. But I'm not sure where the Eclipse project files are stored and also copying them will probably let Eclipse freak out a little bit. (Same project name but wrong project path etc.).
Creating new Eclipse project all the times also sounds like a lot of work to me. While git cooperates independently from your IDE (it's nothing more than an extra folder in the project.) you can just close Eclipse switch the branches via git and reopen the program and you've got the changes you applied. (OK, you've might have to right click on the project and hit refresh ... right.)