1

Copied:

  • bin
  • runtimes
  • airApp-app.xml
  • airApp.swf

Calling: G:\adl\bin\adl.exe -nodebug G:\adl\airApp-app.xml

Nothing on the screen, nothing in the console. I do, however, see adl.exe hanging in the processes and eating up memory - i assumed its the loaded, but invisible application.

Can't figure out the problem or where to look for the answer. Googling hasn't yielded much.

Update:Created a blank Flex 4.5 (Air 3.1) project that changes the background - and it worked out fine. Tried to use this config (tweaked the filename) - and it doesn't work. Seems the problem only applies to mobile projects.

Grigorash Vasilij
  • 673
  • 4
  • 13
  • `-nodebug` is there because i thought there was something _mystical_ about this option (a few posts claim that the window shows when this option is there). When i run debugging out of the IDE - i use it uses the very same tooling. And it launches the app - no exceptions, infinite loops or anything. I'll try building a blank screen and see how adl handles that - thanks for the idea O-) – Grigorash Vasilij Mar 24 '12 at 15:58

2 Answers2

2

This post gave me the good idea of where to get the guts Flash Builder (the IDE) pulls to debug the application. Took the config from there, got dirty with the args to find the bare minimum to run which was:

"G:\adl\bin\adl.exe" -profile mobileDevice "G:\adl\airApp-app.xml"

Pretty different from my initial attempt, eh? O-) Wasted like 5 hours yesterday...

So, basically, if you can debug your AIR project out of the IDE (i.e. it actually launches - no infinite loops or anything), then it means it can be run using adl.exe. Just be sure to indicate -profile mobileDevice if you're working with a mobile project (i guess the application descriptor also has some things related to this in it as well).

Community
  • 1
  • 1
Grigorash Vasilij
  • 673
  • 4
  • 13
0

I have hit this problem more times than I can count! The most likely culprit is an infinite loop somewhere in your code. It took me half a day to figure this out the first time.

The best way to locate the problem code is to look in any code you've written since the last successful compile. It is somewhere in there.

CodeMouse92
  • 6,840
  • 14
  • 73
  • 130
  • glad to know, i'm not the only guy that doesn't get things right O-) i put up a "developer proof" mobile project with 2 lines of code that can't ever go wrong - it didn't work either. The solution was to add a `-profile mobileDevice` arg – Grigorash Vasilij Mar 25 '12 at 14:46