Update (May 2012): The information below applies to an old version of FDT and is deprecated. If you’re using FDT 5.5 or newer (which I recommend), you can skip most of it and just follow the IDE’s own mobile project setup steps, which are must easier and straightforward.

There’s something wonderful about using the same code base for an application and running it on several different devices. I knew that was possible with the Flash platform – given the newly found ubiquity of Adobe AIR support on mobile devices – but that’s still the kind of thing that always warrants setting up your development workflow first.

I finally spent part of this weekend setting up such an environment for Flash development that allows me to run my application locally (on the desktop) and on a device (Android) without any porting hassle and I can state that things are nearly as good as they get when it comes to ease of development; it just takes a while to get it running.

(I haven’t tried iOS yet because I don’t have an iOS device at home, but that’s the next step).

I’m using FDT and the Flex SDK with Adobe AIR for development. And while FDT’s blog has a ton of information on how to set up an environment for mobile devices, it’s not complete as it skips the mobile device SDK parts (I guess it assumes the developer already has everything in place). So because of this, I thought I’d share my notes on how to set up a  Flash development environment with Android as a target, with links to the necessary information on each step.

(I’m using FDT because it’s my IDE of choice. Everything I’m doing is possible with other ActionScript development tools – even Notepad – and luckily no commercial tools are required for compilation or deployment, but of course setting up your environment and project templates will be very different depending on your preferred IDE).

So those are the steps:

1. Download and install FDT in case you don’t have it.
2. Install the Flex SDK 4.5.1 and Adobe AIR 2.7.1. Extract them to the same folder (Flex already comes with AIR, but it’s an older version). For a tutorial on this, see this blog post (first video).
3. Install the Android SDK. This can be done by following the instructions on this page. You don’t need to download Eclipse, Eclipse plugins, samples, or the different APIs, however; that’s for native Android development. You’ll only be using the Android tools and, sometimes, the driver for your specific device.
4. Setup your phone for debugging by following these notes (skip step 1, this is done automatically). This includes installing the drivers for your device, if needed.
• Note for Nexus S users on a Windows machine: the documentation mentions that the USB Drivers for your devices are at “…/android-sdk-windows/usb_driver“. This is incorrect; that’s version 3 of the drivers. You need version 4, which is actually at “…/android-sdk-windows/extras/google/usb_driver“.
5. Connect your device to your computer using the USB cable.
6. Test your device. If you did everything correctly, running the command like adb devices (from “…/android-sdk-windows/platform-tools/“)  should list a connected device ID.
7. You can now run FDT and create a new project using the built-in mobile development templates. See this blog post again for more information (second video). Make sure to create your project on the default FDT workspace – if you use a separate folder, the ANT tool won’t work so your application will be compiled but never deployed (I’m still investigating this, as I always use separate folders).
8. Now you can finally write your application’s code. When testing, run the wireless-based debug profile (found on “Run” > “Debug Configurations”) as explained in that blog post again. Your application will be automatically compiled, installed and ran on the device. Notice that you’ll need a wireless network already setup so the device can connect back to your computer to get the result of the trace() statements; for more information on how debugging is done, see the reference to the fdt.startDebugger command, and to AIR’s -connect parameter.

The cool thing about compiling and debugging like that is, if you use the first launch profile, you compile a normal application running on your computer, like you would do with a normal AIR or Flash application; but if you use the other launch profiles, it runs on your device. It’s a super easy testing and deploying method and it certainly beats, say, using the Android emulator for native Android development (although, of course, you’ll have to keep performance in mind since your application will run much faster as a desktop AIR application).

With a few conditionals (or even different “Main” classes), it should be easy to have the same code based being used for deployment on several different platforms. Right now, FDT’s mobile templates offer two separate templates for Android and iOS development, but merging them together for a single project that supports everything should be possible. I plan to create a template that does that as soon as I have some free time and can get my hands on an iOS device.