I've accomplished this in three ways all of which avoid or replace the trace method available, only one of which I really still use and like.
1: Trace to log file: Pretty basic, instead of air.trace I sent the traces to a log file. This was a total pain sometimes because getting the user (or me) to their applicationStorageDirectory was not always fun and had to code a rotating log as well. Worked pretty well occassionally though.
2: Trace to window: Because I primarily write JS/HTML air apps I've found it extremely handy to script to a window that the user can choose to show or hide. I've used this method because it was extremely simple to implement and for the user to use.
3: Trace to socket: Much more involved but I'm moving to this currently. My apps currently set a log level (0: none, 1: errors, 2: actions, 3: verbose) specific to the application that the user can toggle. Combined with a key that's set on the application level, this allows me to send errors to a web server and collect them automatically. The biggest issue with this method is complexity. While it's relatively easy to create the socket and send stuff, this can get cumbersome if not as "perfect" as possible. The last thing you want to be doing is debugging your debug methods. That said I'm moving to this because it seems to be the ideal way for me to debug multiple applications on multiple operating systems without relying too much on user input.
For me implementing each style exposed issues that caused me to contemplate and eventually move to the next. I'm not convinced there exists a good / universal way to remote debug AIR applications and my stabs at this have been only sufficient for me. I'd recommend you try to come up with something on your own as well because you might stumble on a method that is far superior.
If anyone's interested I'll write a blog post about my method 3 (socket reporting) and update here when complete.
Cool, it would be really interesting to see your method with sockets, though I'm still wondering is it possible to do real debug so you can set break points, step into etc, (not just trace) and debug your app that is running on Linux from Flex Builder that is runnung on Windows.
Absolutely, I should've clarified that I've never found a method that allows for proper "real" debugging for our HTML/JS/Flash applications. I'm going this route because it'll help me at least see a little better what's going on on an end users app without having to install any development tools or require much user interaction.
This is a big deal to me as the multi operating system / multiple product aspect of my AIR development so far has made for super complicated customer support that more often than not can end in confusion for the CSR as well as the end user when the CSR isn't sure what's happening in the app. Within the QA phase our tester loads our apps on all flavors of OS we have available (3 linux, 2 mac, 5 ms) and runs though them as best she can. If we had a real ability to debug those machines during the QA phases without installing development environments on each that would be great. My approach is attempting to help find those issues that make it past testing and development (no matter how rigorous there's always something) and deploy this same approach to our more common Java apps. We're barely scratching the surface on Flex apps (we have one test that we're toying with but I doubt it'll become anything real) and our 3 main apps are JS/HTML with a bit of Flash which the Flex debugger isn't all that useful with.
Good luck! I'll update this when I post some code on socket traces to a remote server however if you happen across anything that could be of use, please share