Create a portable Android/Eclipse on Mac/OSX

Question

I'm trying to create a portable environment (USB Flash/Disk) that can be copied from one device to another - and work "out of the box" on a Mac/OSX (10.10.x environment) specifically. My purpose for this, is I'm teaching a "Portable Programming" class next semester, and I want to be able to just copy (or give the student a .zip file), have them expand it on a specifically named volume, and the environment works. This includes the SDK version(s), AVDs, etc. I've got everything apparently working (so far), but have a problem with the AVDs.

This is a new install, using latest Eclipse, etc.

I'd hoped to find these directories, etc. within an XML/INI file, and use an editor or sed to change the strings, but can't seem to find the directory names of anything I've needed to change so far within an XML/INI file within the unzipped Android directory - but don't see them.

I do see a reference within Preferences->Android->Build "Default debug keystore" that references ~./android - but it is not editable. There IS a "custom" debug keystore setting on the same dialog page, but changing it does not seem to have an effect on the AVDs and their location. So far, that's the ONLY reference I've found for my home directory. I've looked at the Eclipse CLI at eclipse.org , but don't seem to see anything relating to this issue (at least not anything that's ringing a bell with me).

So - how can I change my default "home" directory (without boogering up the environment, etc.) for Eclipse/Android, so my AVDs (and whatever else I HAVEN'T run into yet), can be installed and used/run from the USB drive/stick?

Please - I DO NOT WANT links to other "portable" packages, as I'm not sure what's actually been altered in them (and probably not current, and an update is likely to hose everything anyway), and don't want to pass along anything to students. I'm downloading official packages from official locations, and want to keep it that way. So I'm only looking for things that can be fixed/edited within an officially installed environment to get the effect I'm looking for. Thanks!

Answer 1

Found this at Launch mac eclipse with environment variables set

There is an alternate solution which involves replacing the executable that is run by MacOS X when the user launches the Eclipse application with a shell wrapper that sets up the environment.

Create an empty text file called "eclipse.sh" in the Eclipse application bundle directory /Applications/eclipse/Eclipse.app/Contents/MacOS.

Open the eclipse.sh in a text editor an enter the following contents:

#!/bin/sh

export ENV_VAR1=value
export ENV_VAR2=value

logger "`dirname \"$0\"`/eclipse"

exec "`dirname \"$0\"`/eclipse" $@

In the example ENV_VAR1 and ENV_VAR2 are the environment variables being set up. These variables will be visible to processes launched from within Eclipse. The logger command will just log the path of the eclipse executable to the system.log as a debugging aid.

In the Terminal set the executable flag of the shell script eclipse.sh, ie:

chmod +x /Applications/eclipse/Eclipse.app/Contents/MacOS/eclipse.sh

Open the Eclipse.app Info.plist and change the value for the key CFBundleExecutable from eclipse to eclipse.sh.

MacOS X does not automatically detect that the Eclipse.app's Info.plist has changed. Therefore you need to force update the LaunchService database in the Terminal by using the lsregister command:

/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -v -f /Applications/eclipse/Eclipse.app

The next time you launch Eclipse.app from the Dock or from the Finder the environment variables should be set.

It took me a while to research, as that info was from Sep. '09, which was back in Snow Leopard (OSX 10.6) days. I'm now running 10.10, and while some things don't change - a LOT has changed, so it took a while to research the above approach and make sure it wasn't going to do some potential damage to the installation. A LOT of under-the-cover stuff has changed in those 4 versions, and I wasn't willing to just take off with it. I've also not found a good explanation of exactly what ANDROID_SDK_HOME actually controls - although this above approach seems to work - so far.