What's the best way to mix AIR 14 and the Flex 3.5 SDK and use new AIR features?

Question

I am returning to development of a popular desktop AIR app, after about 4 years of no code changes. Both AIR and Flex have actively moved forward during my coding absence, and it is time to play catch up.
When last built, the app was using Flex 3.5 and AIR 2.6.
End Goal - I want my app to look good on high density displays
I'd like to keep Flex version at 3.5, but use the newer version of AIR, to render more clearly on high density displays (Retina on OSX and hiDPI on Win8).
The pixel doubling performed by the "compatibility" modes of OSX.Retina or Win8.hiDPI make my app look pretty gross, and the customer base is starting to complain.
While I may eventually switch over to the Apache Flex SDK to bring the application design into the current state, my customer base just doesn't care right now. They like the current app, but want it to work, out-of-the-box, on high density displays.
So I need to limit my scope to changing only the AIR SDK, not the Flex SDK at this time.
Step 1 - Overlaying AIR14 SDK on Flex 3.5
I followed the official generic overlay instructions here, and that worked well enough. I named my hybrid SDK folder "3.5.0.AIR14". I have been able to recompile, run, and verify my app using the hybrid SDK. (my app is compiled and packaged from an ant script, using the Antennae framework. I had already switch SDKs a number of times over the initial course of development, so pointing my project to a new SDK was pretty simple enough.
Step 2 - Updating the app.xml descriptor
This part was also easy. I used the templates\air\descriptor-template.xml as a starting point, customizing the name, app id, and folders. Now my app descriptor is correctly based on the <application xmlns="http://ns.adobe.com/air/application/14.0"> namespace.
Step 3 - Enabling Retina/hiDPI support - Help??
I added <requestedDisplayResolution>high</requestedDisplayResolution> to the <initialWindow> tag of the app descriptor, but that made no difference. The app compiles, installs, and runs, but pixel doubling is still occurring and the app looks gross.
I also tried setting the SWF version to 25, according to the official overlay guide. This proved to be more difficult. The official overlay guide suggests setting the -swf-version=25 compiler option, but that option is not supported by the Flex 3.5 compiler. So all I had to try was using the legacy -target-player=25 compiler option. That setting was accepted by the compiler, and it produced a SWF with byte offset 0x3 == 0x19 (25 dec), so that appears to be right.
But -target-player=25 didn't have any effect either.
Is setting the SWF version even required? Isn't the whole point of using the AIR 14 namespace in the app descriptor the way of telling the compiler "I want to use all features of the AIR 14 release". Why do I need to tell the compiler multiple times to use all the features of the SDK I'm compiling with? It just seems weird to me.
Have I missed a secret setting somewhere?
How can I tell the AIR runtime to simply run as pixel-dense as possible? When the workarounds listed below are performed, my app looks fantastic on high-density displays. But its the pixel scaling that is making everything look bad, and I desperately want to get this fixed.
Workarounds?
On Windows 8+, we are asking our users to enable the "Disable display scaling on high DPI settings" checkbox on the AIR application shortcut. This works, but is a confusing setting for average users to discover. Most just give up in frustration.
On OSX, we can't even disable Retina mode on a per-application basis, its all or nothing, so that's even worse. SwitchResX will automatically switch resolutions based on the selected app, but that's a pretty clunky (and non-free) workaround too.
Any other workaround ideas are appreciated too.
Cheers,
Doug

Answer 1

It took me a while to figure out (without much help from Adobe, grrr!), since some internet writeups were terse and implied somehow that AIR's Retina support (setting your app descriptor's <initialWindow/requestedDisplayResolution> to high) would also work on Windows. They don't.
On OSX, the steps to disable pixel-doubling are:
update your app descriptor to AIR 14
set initialWindow/requestedDisplayResolution = high
compile with SWF version 25 or greater
vector assets, including text, will scale automatically
you'll need to replace your bitmap assets with Retina-quality bitmaps as appropriate
when running on a Retina display, you will see stage.contentsScaleFactor=2. It will be 1 for non-Retina displays.
On Windows, the pixel-doubling kicks in when you have a HiDPI scaling set to about 150% or greater (hiDPI scaling was introduced in Win7). There is no way to detect from within an AIR app when Windows is doing its HiDPI scaling. stage.contentsScaleFactor is always 1, under all configurations.
The only thing you can do for AIR apps on Windows is explicitly disable display scaling (like you have done) and update your app to manually scale all UI elements at runtime (that's really gross and hard, and it what I working on right now).
For my app, I updated our Windows installer to set the registry to disable hiDPI scaling, for all users, just for our app. Here's how you do that:
Key = HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
Name = <fullPathToYourExe>
Type = REG_SZ
Value = "~ HIDPIAWARE" (without the quotes, tilde space HIDPIAWARE)
That should be set in the full 64-bit registry, not the Wow32Node registry, even if your app is a 32-bit app (which all AIR apps are). If your installer is a 32-bit app (mine was), you may need to jump through some hoops to have it affect the 64-bit registry hive from a 32-bit process.
If you only want to change the setting for the current user (not all users), the KEY root is HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE.
If you don't have an explicit installer for your AIR app (ie. if you are deploying from the web via a badge installer), then you're even more messed up, and you will need to tell your users to disable the scaling manually.
I know, it's a total pain. I hope this helps.
Cheers,
Doug
PS: Adobe devs, if you are listening ...