Did you publish the file? I ask because that's what solved my problem and uh . . . cause everybody has the right to be uniformed, I didn't realize that publishing in the Air sense is very different than publishing a flash file. It involves creating an installer. If you knew that already don't laugh. If not then maybe that's the first step.
The other thing that I've read with respect to newer operating systems is that writing to certain directories is blocked and the recommendation is that you use the application storage directory.
This bit will tell you where that is but I still couldn't get past it because uh . . . well you know
var f:File = File.applicationStorageDirectory.resolvePath("presentations.xml");
path_ti.text = f.nativePath;
Never mind . . . I will read up on this . . . Someday.
For my fellow coders, my issue seemed to stem from the fact that I was providing an absolute path to a child SWF which was playing the video.
I switched to relative path to the SWF and the original configs for the FLV and skin which were absolute and problem appears to be solved.
I guess this next bit of info also makes sandbox sense but JPGs accessed via an absolute path gave no error so I wasn't looking to hard a the code were the paths loading the children were defined.
I'm the first to admit that I'm not fully versed in AIR sandbox security, but here's a couple of things to consider.
If you embed the swf it will be loaded with the proper privledges. You might also be able to load with an app:/ URI, or via loadBytes() + allowLoadBytesCodeExecution.
Here are a couple of docs that might interest you when you have some free time