That being said, here's how to take apart an AIR for Android app you've downloaded from the Android Market.
- Get the free Astro file manager from the Android Market.
- Run Astro.
- From the app menu, choose "tools" and then "Application Manager/Backup".
- Choose any app you've installed on your Android device. You can choose any app you want, but AIR apps are particularly egregious in their lack of security.
- The application will be copied from internal storage and will be copied to your backup folder (most likely on your SD card) as an APK file.
- While still in Astro, navigate over to that backed up APK file and click on it. Choose "send to", and send it to your desktop machine via email or Dropbox.
- Now that the APK is on your desktop computer, rename the APK extension to ZIP and open it with your favorite ZIP-reading program.
- In the "assets" folder within the ZIP, you should find a file with the extension SWF. Yes, this is the same SWF that was created with Flash/Flex. The AIR Android packager doesn't do anything to the file at all. It just copies it into the right spot in the APK ZIP-file so the AIR runtime can run it.
- Copy that SWF out of the ZIP file, and you're done.
Note that there are tools like secureSWF (which I reviewed here) that are very effective at munging ActionScript bytecode into something that can't be meaningfully decompiled, but that would only prevent people from decompiling and/or reading and/or recompiling your source code into a new SWF. There's still nothing preventing me from making a new APK out of your game's SWF.
also note that exactly ZERO of the AIR for Android apps I tried actually had obfuscated their bytecode with a third-party tool . A couple of you guys have atrocious naming conventions 
Fact is, if you are going with Adobe and Android's recommended sequence to make an AIR for Android APK file with the aim of putting your app on the market, you are essentially open-sourcing your app. Unless you go with some further security (and I don't even know what further security you could implement beyond obfuscating bytecode), you are leaving your app wide open for IP theft.And I'm not doing this with the aim of convincing every 13 year-old creep with a decompiler to start stealing apps and republishing 'em under his own name. It's more like discovering that every door-keypad at the Pentagon opened with the combination 1-2-3-4-5. Would publishing such information be inviting terrorism or would it be informing the Pentagon that their security is worthless and needs updating ASAP?
Also I'm posting this because I'm angry. And I'm angry because I brought this up during a Q&A at an Adobe conference when AIR was announced as "Apollo" in 2007. The Q&A went something like this:
Me: If your compiling step is just zipping up all of the web-app's assets with an XML manifest file and some icons, what's to prevent me from unzipping that file, making changes, and re-deploying it.
AIR guy: We're planning some security stuff.
Turns out the "security stuff" was apparently their app signing process. And the ONLY thing that prevents me from doing is me making changes within the AIR file itself. I can't open an AIR (or APK) file and make changes to the file itself, as the certificate file would no longer match file checksums for the AIR/APK file. I'm still free to open, decompile, read, write, update, steal, and rebuild the app under my own name.AIR guy: We're planning some security stuff.
They've had four years to fix this.
Finally, a note about the iPhone. While an iPhone IPA file is also a renamed ZIP and IPA files are also easy to retrieve, the contents of AIR for iOS files beyond icon PNG files and a manifest XML weren't in a readily decompile-able format. Looks like the Adobe AOT compiler really works.
Source
