Official support for Adobe AIR

#1

I wanted to mention quickly that we are adding official support for Adobe AIR in OpenFL 6.1 (which has just been released on haxelib)

Adobe AIR support is not new to OpenFL, as I know many developers who already run adt themselves to package OpenFL Flash projects for use with Adobe AIR, but the new Lime 5.4 tools support a new “air” target which should help simplify the tooling. It’s all new, so I’d love to hear your feedback and any edge cases you run into. Pull requests are also welcome :wink:

Download the Adobe AIR SDK, and extract it on your system. Edit ~/.lime/config.xml and add the following:

<set name="AIR_SDK" value="path/to/your/air/sdk" />

Then, in order to support Adobe AIR testing on the desktop, use openfl test air.

If you would prefer to generate an *.air package instead of testing the SWF, run openfl deploy air

The “air” target defines air and flash in project.xml and Haxe code, and should use desktop or mobile depending on the AIR target.

We should include a set of “extern” classes for Adobe AIR, meaning the full Adobe AIR APIs (beyond the standard Flash API) should be available. You will want to guard these calls in your code with #if air, though, to keep your code compiling on other targets:

#if air
var nativeWindow = stage.nativeWindow;
#end

We have not implemented Adobe AIR versions of all the existing Lime system APIs (such as control over windowing, gamepad events and other APIs) but all the standard AIR APIs should work fine.

To target Android, use openfl test air -android or openfl test android -air. Similarly, iOS should use openfl test air -ios or openfl test ios -air

The mobile targets have not been fully tested, but the foundation should be laid so that we can continue to polish up the tooling support, and help support your projects.

Please give it a try, and help make this even more solid :slight_smile:

13 Likes
Missing the AIR target for OpenFL apps
#2

Wow that’s awesome, specially now Flash on the web is dead :}

#3

Great news!

I’m new to the whole openFL / Haxe world but I enjoy it so far :slight_smile:
I see the air mobile export like a great opportunity to the export process.
I succefully exported my game to HTML5 and Android, but I’m having some trouble to export for iOS (I’m working on Windows).

When I try the command "openfl test air -ios"
I got this message : Provisioning profile not specified.

I guess, I need to specify this file somewhere, or maybe add a AIR Descriptor file somewhere, but I can’t find any doc on it :confused:

For the Android export I added this line:
<certificate path="cert/android/pre.keystore" alias="test" password="test" if="android" unless="debug"/>

Is the a specific line I need to add for the provisioning profile?

Thanks !

#4

Hello, and welcome :grinning:

I’m not super familiar with how provisioning profiles and certificates are handled in Adobe AIR on Windows.

For openfl test ios, normally, no provisioning profile is required (because Xcode resolves that automatically), but there is a configuration option, <config:ios provisioning-profile="path/to/file" />, for setting it up.

We’ll need to figure out what the Adobe AIR tools are expecting, is it only a provisioning profile, or is it also a P12 certificate?

Do we specify the paths to these files when calling the AIR packaging tools, or are they intended to be listed in the application manifest?

#5

Thanks :slight_smile:
Yes I can compile for ios using open fl ios using a virtual machine, but I face other problems…
It’s a kind of complexe app using json or yml config/language files, mp3/ogg, animations.
I use Robotlegs / Starling (cause the app was originaly coded in AIR and targeting iOS and Android).
I started with the HTML5 version, and had to start another branch when starting working on a mobile port. The Android version seems to be ok now, but I’ll have to create another branch specificaly for iOS, because I got some compatibility pb (rendering / compatibility) when targeting this platform.
That’s why I think using AIR could allow me to have pretty much the same source base for these two platforms (Android / iOS) and keep working without using such an heavy VM.

I’m pretty familiar with AIR, working with it since it began.
When building the App I’m using this command line:

adt -package -target ipa-ad-hoc -hideAneLibSymbols yes -storetype pkcs12 -keystore "cert\ios_distribution.p12" -provisioning-profile cert\DIST.mobileprovision "dist\FicheTest-ad-hoc.ipa" "application_prod.xml" -C bin . -C "icons/ios" . -extdir ext/

p12 & mobile provision aren’t specified in the manifest, but in the ADT command line used to build the app.

Hope it helps :slight_smile:

#6

Oh, it looks like we should have it wired up:

So try doing these tags in your project.xml:

<certificate path="to/your.p12" if="ios" />
<config:ios provisioning-profile="path/to/profile" />
#7

:confused:
I added these tag to the project.xml but I still have this message:
Provisioning profile not specified.
I’ve tried both commands: openfl test air -ios and openfl test ios -air

Maybe it’s because there is a confusion between target platform AIR & iOS?

#8

Fixed:

Sorry again about the rough edges, the Adobe AIR code was written a long time ago, and we’ve just been patching it up to make it work with our current tools, and to help push it forward to a solid state.

We needed to pass a project instance internally here in the tools. Now it properly picks up the <config:ios provisioning-profile="" /> value, which is good because we can’t find one automatically on Windows :sweat_smile:

This will go out in our next release, or if you build Lime from source you can lime rebuild tools to get this change immediately and try it out

1 Like
#9

EDIT: You might actually be able to lime rebuild tools yourself without a development version, you can try making the change to the file manually in your Lime install, run haxelib install format then lime rebuild tools

#10

Wow that was fast!

I’ll check it out and come back to you to let you know how it goes :slight_smile:

Thanks a lot!

#11

I’m getting closer :slight_smile:
First it prompted this error: pathoftheproject\bin\air\cert\ios\DEV.mobileprovision (can’t find the specified path)
I manually added the cert folder in the bin/air folder and I guess it worked, but I can’t find any .ipa in this bin folder.
However there is a .air, but I can’t open it, it says the file is corrupted.
:confused:

1 Like
#12

Try using the -v, -verbose, flag, when you build. That will let you see what commands the command-line tools use, and that might give us a better idea whether there are some wrong parameters being passed, or what output it should be generating

#13

Hi again, I had to switch to something else, but I’m back trying to package for AIR iOS :slight_smile:

I used the verbose, I fixed some compatibility problem I had in my code, and it seems to work (I got a 30Mo ipa) but there is still a tiny problem, the provisionning profile is “linked” but not the certificat.

Here is the command line:

adt -package -target ipa-test -storetype pkcs12 -keystore C:\HaxeToolkit\haxe\lib\lime/5,7,1/templates/air/debug.pfx -storepass samplePassword -provisioning-profile cert/ios/aDEV.mobileprovision bin/myproject.ipa application.xml -C bin myproject.swf _res/icon-16.png _res/icon-32.png _res/icon-48.png _res/icon-128.png

I added this field in the project.xml

<certificate path="cert/ios/ios_dev.p12" password="mypassword" if="ios" />

but it doesn’t seems to be considered and use default values…

Is there anything I missed? :confused:

#14

I found [this post] (http://www.openfl.org/archive/community/installing-openfl/building-air/) and added those lines:

 < setenv name="KEY_STORE_TYPE" value="pkcs12" if="air"></setenv>
    < setenv name="KEY_STORE" value="/path/to/mycertificate.p12" if="air"></setenv>
    < setenv name="KEY_STORE_PASSWORD" value="aaa" if="air"></setenv>

it seems to work, I can start the app on my iphone, perfect! except I got a white screen on my iphone … :frowning:

Sounds like I still have some stuff to figured out before have it full fonctional :smile:

#15

Thank you! I just opened an issue:

This was originally written for an old, old version of our tools, before we improved our code signing code. It looks like this needs to be updated properly. Thank you for the help! I will look at this.

Maybe a little debugging will help? AIR seems to work great on the desktop, but I’m not quite sure what form of translation they do when going to iOS (Android seems to work fine), if it’s a little more brittle than normal. Maybe some remote debugging will help give an idea of an error code or other bump its hitting?

1 Like
#16

Would be great to have a consistent way of adding provisioning / cert and a proper documentation :slight_smile:

That said, I’m trying to figured out what I need to change to add a debug option or override the application.xml file… sorry for the noob questions!

#17

It should be -debug in order to make it a debug SWF (like openfl test ios -air -debug), I don’t think anything else should be needed, but you can watch the -verbose output and our generated application.xml if there’s anything you would otherwise expect from an AIR debug build normally

1 Like
#18

Haha easy one :blush:
Regarding the application.xml I’d like to add few things and remove others in that generated application.xml file.
Is there a way to override it or should I change the template directly?

#19

Yes, you can override any of our templates by doing something similar to the following:

  1. Create a “templates” folder
  2. Add <template path="to/your/templates" /> to your project.xml (after <haxelib name="openfl" />). The <template /> tag works like a class path, but for template files
  3. In your “templates” folder, mirror the structure found in “lime/templates” or “openfl/templates” for the file you wish to override. The AIR application.xml is “templates/air/template/application.xml”

I would be interested in what you want to change. Since our AIR support is somewhat new, we might not be supporting something we really should. Any feedback on what you’d like to see helps us with knowing what we should A.) wire in behind some other existing feature (like the above certificate feature) or B.) maybe enable by default, or enable using a custom AIR config value

Thanks again

1 Like
#20

Thx,
I’ll give it a try :slight_smile:

On mobile there are actually few things not really useful:

	<systemChrome>standard</systemChrome>
	<transparent>false</transparent>
	<width>800</width>
	<height>600</height>

(I use Starling, and don’t need to force the size / ratio as I handle it in my app).

and at the contrary we need more icons:

  <image48x48>icons/icon_48.png</image48x48>
  <image57x57>icons/icon_57.png</image57x57>
  <image72x72>icons/icon_72.png</image72x72>
  <image76x76>icons/icon_76.png</image76x76>
  <image96x96>icons/icon_96.png</image96x96>
  <image114x114>icons/icon_114.png</image114x114>
  <image120x120>icons/icon_120.png</image120x120>
  <image144x144>icons/icon_144.png</image144x144>
  <image152x152>icons/icon_152.png</image152x152>
  <image512x512>icons/icon_512.png</image512x512>

EDIT: My bad, this one seems to be dynamic (but where if not in the project.xml?)

And sometimes a better control on permissions.

Also on iPhone I’m not sure why, it’s in my template since my first app, but I always add this

<iPhone>
  <requestedDisplayResolution>high</requestedDisplayResolution>
</iPhone>