The -package command should be run from the main application directory. The command uses the following syntaxes:
About Adobe AIR: The Adobe AIR runtime enables developers to package the same code into native applications and games for Windows and Mac OS desktops as well as iOS and Android devices, reaching over a billion desktop systems and mobile app stores for over 500 million devices. Subject to Adobe Sign contractual use limits.Offer expires on Dec 31, 2020. Offer available worldwide only to first-time subscribers. Get Adobe Sign Small Business annual subscription for US$251.88/yr (plus applicable taxes/VAT/GST), a 40% discount based on the regular annual subscription price of US$419.88/yr (plus applicable taxes/VAT/GST) for the first year. 12-mo commitment required. The all-new Adobe Creative Suite 2 and Mac OS X v.10.4 (Tiger) make this a great time to be an Adobe customer on the Mac platform. Adobe and Apple have worked closely together through the development of Mac OS X 10.4 (Tiger) and Adobe Creative Suite 2 to. WebKit uses a few non-public APIs that are not allowed on the Mac App Store, so you cannot use HTMLLoader or any class in the flash.html package in your app. Manually remove WebKit.dylib and Flash Player.plugin from the Adobe AIR.framework/Resources subtree inside your app bundle.
Create an AIR package from the component application files:
Create a native package from the component application files:
Create a native package that includes a native extension from the component application files:
Create a native package from an AIR or AIRI file:
Create a native extension package from the component native extension files:
Note: You do not have to sign an ANE file, so the AIR_SIGNING_OPTIONS parameters are optional in this example.
AIR_SIGNING_OPTIONS The AIR signing options identify the certificate used to sign an AIR installation file. The signing options are fully described in ADT code signing options.
-migrate This flag specifies that the application is signed with a migration certificate in addition to the certificate specified in the AIR_SIGNING_OPTIONS parameters. This flag is only valid if you are packaging a desktop application as a native installer and the application uses a native extension. In other cases an error occurs. The signing options for the migration certificate are specified as the MIGRATION_SIGNING_OPTIONS parameters. Those signing options are fully described in ADT code signing options. Using the -migrate flag allows you to create an update for a desktop native installer application that uses a native extension and change the code signing certificate for the application, such as when the original certificate expires. For more information, see Signing an updated version of an AIR application.
The -migrate flag of the -package command is available in AIR 3.6 and later.
-target The type of package to create. The supported package types are:
air — an AIR package. “air” is the default value and the -target flag does not need to be specified when creating AIR or AIRI files.
airn — a native application package for devices in the extended television profile.
ane —an AIR native extension package
Android package targets:
apk — an Android package. A package produced with this target can only be installed on an Android device, not an emulator.
apk‑captive‑runtime — an Android package that includes both the application and a captive version of the AIR runtime. A package produced with this target can only be installed on an Android device, not an emulator.
apk-debug — an Android package with extra debugging information. (The SWF files in the application must also be compiled with debugging support.)
apk-emulator — an Android package for use on an emulator without debugging support. (Use the apk-debug target to permit debugging on both emulators and devices.)
apk-profile — an Android package that supports application performance and memory profiling.
iOS package targets:
ipa-ad-hoc — an iOS package for ad hoc distribution.
ipa-app-store — an iOS package for Apple App store distribution.
ipa-debug — an iOS package with extra debugging information. (The SWF files in the application must also be compiled with debugging support.)
ipa-test — an iOS package compiled without optimization or debugging information.
ipa-debug-interpreter — functionally equivalent to a debug package, but compiles more quickly. However, the ActionScript bytecode is interpreted and not translated to machine code. As a result, code execution is slower in an interpreter package.
ipa-debug-interpreter-simulator — functionally equivalent to ipa-debug-interpreter, but packaged for the iOS simulator. Macintosh-only. If you use this option, you must also include the -platformsdk option, specifying the path to the iOS Simulator SDK.
ipa-test-interpreter — functionally equivalent to a test package, but compiles more quickly. However, the ActionScript bytecode is interpreted and not translated to machine code. As a result, code execution is slower in an interpreter package.
ipa-test-interpreter-simulator — functionally equivalent to ipa-test-interpreter, but packaged for the iOS simulator. Macintosh-only. If you use this option, you must also include the -platformsdk option, specifying the path to the iOS Simulator SDK.
native — a native desktop installer. The type of file produced is the native installation format of the operating system on which the command is run:
EXE — Windows
DMG — Mac
DEB — Ubuntu Linux (AIR 2.6 or earlier)
RPM — Fedora or OpenSuse Linux (AIR 2.6 or earlier)
For more information see Packaging a desktop native installer.
-sampler (iOS only, AIR 3.4 and higher) Enables the telemetry-based ActionScript sampler in iOS applications. Using this flag lets you profile the application with Adobe Scout. Although Scout can profile any Flash platform content, enabling detailed telemetry gives you deep insight into ActionScript function timing, DisplayList, Stage3D rendering and more. Note that using this flag will have a slight performance impact, so do not use it for production applications.
Adobe Air For Mac High Sierra
-hideAneLibSymbols (iOS only, AIR 3.4 and higher) Application developers can use multiple native extensions from multiple sources and if the ANEs share a common symbol name, ADT generates a “duplicate symbol in object file” error. In some cases, this error can even manifest itself as a crash at runtime. You can use the hideAneLibSymbols option to specify whether or not to make the ANE library’s symbols visible only to that library’s sources (yes) or visible globally (no):
yes — Hides ANE symbols, which resolves any unintended symbol conflict issues.
no — (Default) Does not hide ANE symbols. This is the pre-AIR 3.4 behavior.
-embedBitcode (iOS/tvOS only, AIR 25 and higher) Application developers can use the embedBitcode option to specify whether or not to embed bitcode in their iOS/tvOS application by specifying yes or no. The default value of this switch if not specified is no. For tvOS default value is yes in ipa-app-store target.
DEBUGGER_CONNECTION_OPTIONS The debugger connection options specify whether a debug package should attempt to connect to a remote debugger running on another computer or listen for a connection from a remote debugger. This set of options is only supported for mobile debug packages (targets apk-debug and ipa-debug). Hd audio ac97 motherboard. These options are described in Debugger connection options.
-airDownloadURL Specifies an alternate URL for downloading and installing the AIR runtime on Android devices. If not specified, an AIR application will redirect the user to the AIR runtime on the Android Market if the runtime is not already installed.
Adobe Air Package For Macbook Air
If your application is distributed through an alternate marketplace (other than the Android Market administered by Google), then you might need to specify the URL for downloading the AIR runtime from that market. Some alternate markets do not allow applications to require a download from outside the market. This option is only supported for Android packages.
NATIVE_SIGNING_OPTIONS The native signing options identify the certificate used to sign a native package file. These signing options are used to apply a signature used by the native operating system, not the AIR runtime. The options are otherwise identical to the AIR_SIGNING_OPTIONS and are fully described in ADT code signing options.
Native signatures are supported on Windows and Android. On Windows, both an AIR signing options and the native signing options should be specified. On Android, only the native signing options can be specified.
In many cases, you can use the same code signing certificate to apply both an AIR and a native signature. However, this is not true in all cases. For example, Google’s policy for apps submitted to the Android Market dictates that all apps must be signed with a certificate valid until at least the year 2033. This means that a certificate issued by a well known certificate authority, which are recommended when applying an AIR signature, should not be used to sign an Android app. (No certificate authorities issue a code signing certificate with that long a validity period.)
output The name of the package file to create. Specifying the file extension is optional. If not specified, an extension appropriate to the -target value and current operating system is added.
app_descriptor The path to the application descriptor file. The path can be specified relative to the current directory or as an absolute path. (The application descriptor file is renamed as application.xml in the AIR file.)
-platformsdk The path to the platform SDK for the target device:
Android - The AIR 2.6+ SDK includes the tools from the Android SDK needed to implement the relevant ADT commands. Only set this value to use a different version of the Android SDK. Also, the platform SDK path does not need to be supplied on the command line if the AIR_ANDROID_SDK_HOME environment variable is already set. (If both are set, then the path provided on the command line is used.)
iOS - The AIR SDK ships with a captive iOS SDK. The -platformsdk option lets you package applications with an external SDK so that you are not restricted to using the captive iOS SDK. For example, if you have built an extension with the latest iOS SDK, you can specify that SDK when packaging your application. Additionally, when using ADT with the iOS Simulator, you must always include the -platformsdk option, specifying the path to the iOS Simulator SDK.
-archApplication developers can use this argument to create APK for x86 platforms, it takes following values:
armv7 - ADT packages APK for the Android armv7 platform.
x86 - ADT packages APK for the Android x86 platform.
armv7 is the default value when no value is specified
FILE_OPTIONS Identifies the application files to include in the package. The file options are fully described in File and path options. Do not specify file options when creating a native package from an AIR or AIRI file.
input_airi Specify when creating a native package from an AIRI file. The AIR_SIGNING_OPTIONS are required if the target is air (or no target is specified).
input_air Specify when creating a native package from an AIR file. Do not specify AIR_SIGNING_OPTIONS.
ANE_OPTIONS Identifies the options and files for creating a native extension package. The extension package options are fully described in Native extension options.
ADT -package command examples
Package specific application files in the current directory for a SWF-based AIR application:
Package specific application files in the current directory for an HTML-based AIR application:
Package all files and subdirectories in the current working directory:
Note: The keystore file contains the private key used to sign your application. Never include the signing certificate inside the AIR package! If you use wildcards in the ADT command, place the keystore file in a different location so that it is not included in the package. In this example the keystore file, cert.p12, resides in the parent directory.
Package only the main files and an images subdirectory:
Package an HTML-based application and all files in the HTML, scripts, and images subdirectories:
Package the application.xml file and main SWF located in a working directory (release/bin):
Package assets from more than one place in your build file system. In this example, the application assets are located in the following folders before packaging:
Running the following ADT command from the /devRoot/myApp directory:
Results in the following package structure:
Run ADT as a Java program for a simple SWF-based application (without setting the classpath):
Run ADT as a Java program for a simple HTML-based application (without setting the classpath):
Run ADT as a Java program (with the Java classpath set to include the ADT.jar package): Streamlabs app.
Adobe Air Package For Mac Catalina
Run ADT as a Java task in Apache Ant (although it’s usually best to use the ADT command directly in Ant scripts). The paths shown in the example are for Windows:
Note: On some computer systems, double-byte characters in the file system paths can be misinterpreted. If this occurs, try setting the JRE used to run ADT to use the UTF-8 character set. This is done by default in the script used to launch ADT on Mac and Linux. In the Windows adt.bat file, or when you run ADT directly from Java, specify the ‑Dfile.encoding=UTF-8 option on the Java command line.