Setting up an Android environment for Flash mobile applications development

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.

  • Zeh,

    first of all thanks a lot for this tutorial and pointing out your findings!

    Regarding point number 8: Please note that the latest Android Template that is shipped with FDT creates 3 diffentent build files. One of them “android_wireless_debug_build.xml” includes exacly those changes you pointed out in 8.1 and 8.2.
    Also it’s may be better practice to use FDTs predefined ANT properties. e.g. ${FDTHostIP} instead of hardcoding your machines ip ito the buildfile. Same goes for the projectname. ${FDTProject} will be resolved to your actual project name when launching the ANT file.
    More information about these properties are available here: http://fdt.powerflasher.com/docs/FDT_Ant_Tasks#fdt.loadProjectProperties_.28FDT_4.1.29

    regards,
    Philipp

  • Zeh

    Hi Philipp,

    Thanks for the comments. I’ve added the note about the FDTHostIP and the -listen parameter to the list of steps as soon as I saw your comment on the other page.

    I’ll update the notes with the {$FDTProject} var. I was assuming such a thing existed but didn’t investigate too much.

    As for the fdt.startDebugger and -connect parameters, I really had to add those because I was using the “debug” method, not a wireless debug. It just confused me that it wasn’t running the same as the project shown in the video tutorial – logging was never starting. It’s only after I added those manually (they were not there) that it started working. I realize this is still just the initial support for mobile development from FDT so I’m not too worried, but I thought it was important mentioning in case anyone ran into the same problem and they expect the “debug” build to trace their statements. Otherwise just let me know if the “wireless” method is the one that we’re supposed to use even with wired debugging.

    Thanks again!

  • Zeh

    Ah Philipp, I get what you mean now — the “wireless” one is the right one to use *because it uses the wifi connection for debugging* so it’s the one that should be used, even when using a USB cable. I guess I misunderstood the original naming and that’s why I was trying to do everything by using the ‘debug’ version only. I’ve updated the instructions to remove the need to manually change the debug xml.