La commande
-package
doit être exécutée à partir du répertoire principal de l’application. Elle gère les syntaxes suivantes :
Création d’un package AIR à partir des fichiers d’application du composant :
adt -package
AIR_SIGNING_OPTIONS
-target packageType
-sampler
‑hideAneLibSymbols
NATIVE_SIGNING_OPTIONS
output
app_descriptor
FILE_OPTIONS
Création d’un package natif à partir des fichiers d’application du composant :
adt -package
AIR_SIGNING_OPTIONS
-target packageType
DEBUGGER_CONNECTION_OPTIONS
-airDownloadURL URL
NATIVE_SIGNING_OPTIONS
output
app_descriptor
-platformsdk path
FILE_OPTIONS
Création d’un package natif qui inclut une extension native à partir des fichiers d’application du composant :
adt -package
AIR_SIGNING_OPTIONS
-migrate MIGRATION_SIGNING_OPTIONS
-target packageType
DEBUGGER_CONNECTION_OPTIONS
-airDownloadURL URL
NATIVE_SIGNING_OPTIONS
output
app_descriptor
-platformsdk path
FILE_OPTIONS
Création d’un package natif à partir d’un fichier AIR ou AIRI :
adt -package
-target packageType
NATIVE_SIGNING_OPTIONS
output
input_package
Création d’un package d’extensions natives à partir des fichiers d’extension native du composant :
adt -package
AIR_SIGNING_OPTIONS
-target ane
output
ANE_OPTIONS
Remarque :
il n’est pas nécessaire de signer un fichier ANE ; les paramètres
AIR_SIGNING_OPTIONS
sont donc facultatifs dans cet exemple.
AIR_SIGNING_OPTIONS
Les options de signature AIR identifient le certificat utilisé pour signer un fichier d’installation AIR. Les options de signature font l’objet d’une description détaillée à la section
Options de signature du code de l’outil ADT
.
-migrate
Cet indicateur spécifie que l’application est signée avec un certificat de migration en plus du certificat spécifié par les paramètres
AIR_SIGNING_OPTIONS
. Cet indicateur n’est valide que si vous mettez en package une application de bureau sous la forme d’un programme d’installation natif et que l’application utilise une extension native. Dans les autres cas, une erreur survient. Les options de signature du certificat de migration sont spécifiées dans les paramètres
MIGRATION_SIGNING_OPTIONS
. Elles font l’objet d’une description détaillée à la section
Options de signature du code de l’outil ADT
. L’utilisation de l’indicateur
-migrate
permet de créer une mise à jour d’une application de bureau à programme d’installation natif qui utilise une extension native et de modifier le certificat de signature du code de l’application lors de l’expiration du certificat d’origine, par exemple. Pour plus d’informations, voir
Signature d’une version mise à jour d’une application AIR
.
L’indicateur
-migrate
de la commande
-package
est disponible dans AIR 3.6 et ultérieur.
-target
Type de package à créer. Les types de package pris en charge sont les suivants :
-
air : package AIR. « air » est la valeur par défaut et il est inutile de spécifier l’indicateur -target lors de la création de fichiers AIR ou AIRI.
-
airn : package d’application natif pour périphériques associés au profil de télévision étendu.
-
ane : package d’extensions natives AIR
-
Cibles des packages Android
-
apk : package Android. Un package créé à l’aide de cette cible ne peut être installé que sur un périphérique Android et non sur un émulateur.
-
apk‑captive‑runtime : package Android qui inclut l’application et une version captive du moteur d’exécution AIR. Un package créé à l’aide de cette cible ne peut être installé que sur un périphérique Android et non sur un émulateur.
-
apk-debug : package Android contenant des informations de débogage complémentaires. (Les fichiers SWF de l’application doivent également être compilés avec une prise en charge du débogage.)
-
apk-emulator : package Android réservé à un émulateur sans prise en charge du débogage. (La cible apk-debug permet d’autoriser le débogage sur les émulateurs et les périphériques.)
-
apk-profile : package Android qui prend en charge le profilage des performances et de la mémoire.
-
Cibles des packages iOS :
-
ipa-ad-hoc : package iOS destiné à une distribution ad hoc.
-
ipa-app-store : package iOS destiné à une distribution via l’App Store d’Apple.
-
ipa-debug : package iOS contenant des informations de débogage complémentaires. (Les fichiers SWF de l’application doivent également être compilés avec une prise en charge du débogage.)
-
ipa-test : package iOS compilé sans information de débogage ou d’optimisation.
-
ipa-debug-interpreter : fonctionnalité qui équivaut à un package de débogage, mais qui permet de compiler plus rapidement. Néanmoins, le pseudo-code ActionScript est interprété et non traduit en code machine. L’exécution du code est donc ralentie dans un package interpreter.
-
ipa-debug-interpreter-simulator : fonctionnalité équivalente à ipa-debug-interpreter, mais mise en package pour le simulateur iOS. Macintosh uniquement. Si vous utilisez cette option, vous devez inclure également l’option -platformsdk en spécifiant le chemin vers le kit SDK du simulateur iOS.
-
ipa-test-interpreter : fonctionnalité qui équivaut à un package de test, mais qui permet de compiler plus rapidement. Néanmoins, le pseudo-code ActionScript est interprété et non traduit en code machine. L’exécution du code est donc ralentie dans un package interpreter.
-
ipa-test-interpreter-simulator : fonctionnalité équivalente à ipa-test-interpreter, mais mise en package pour le simulateur iOS. Macintosh uniquement. Si vous utilisez cette option, vous devez inclure également l’option -platformsdk en spécifiant le chemin vers le kit SDK du simulateur iOS.
-
native : programme d’installation d’application de bureau natif. Le type de fichier produit correspond au format d’installation natif du système d’exploitation sur lequel est exécutée la commande :
Pour plus d’informations, voir
Mise en package d’un programme d’installation natif de bureau
.
-sampler
(iOS uniquement, AIR 3.4 et ultérieur) Active l’échantillonneur ActionScript basé sur la télémétrie dans les applications iOS. Cet indicateur permet de profiler l’application avec Adobe Scout. Bien que
Scout
puisse profiler le contenu de n’importe quelle plate-forme Flash, l’activation de la télémétrie détaillée vous permet de mieux connaître la durée des fonctions ActionScript, les rendus DisplayList et Stage3D, etc. Notez que l’utilisation de cet indicateur peut avoir une incidence sur les performances ; par conséquent, ne l’utilisez pas pour les applications de production.
-hideAneLibSymbols
(iOS uniquement, AIR 3.4 et les versions ultérieures) Les développeurs d’applications peuvent utiliser plusieurs extensions natives provenant de sources diverses, et si les fichiers ANE partagent un nom de symbole commun, l’outil ADT génère une erreur de type « symbole dupliqué dans le fichier d’objet ». Dans certains cas, cette erreur peut même se manifester sous forme de blocage au moment de l’exécution. Vous pouvez utiliser l’option
hideAneLibSymbols
pour indiquer si vous souhaitez rendre visibles les symboles de la bibliothèque ANE uniquement aux sources de cette bibliothèque (yes) ou à toutes les sources (no) :
-
yes
: les symboles ANE sont masqués, ce qui résout tous les conflits de symboles indésirables.
-
no
: (valeur par défaut) les symboles ANE ne sont pas masqués. Ce comportement est celui des versions antérieures à AIR 3.4.
-embedBitcode
(iOS uniquement, AIR 25 et versions ultérieures) Les développeurs d’application peuvent utiliser l’option
embedBitcode
pour indiquer s’il faut inclure le bitcode dans leur application iOS en spécifiant oui ou non. La valeur par défaut de cette option est non.
DEBUGGER_CONNECTION_OPTIONS
Les options de connexion au débogueur indiquent si un package à déboguer doit tenter de se connecter à un débogueur distant qui s’exécute sur un autre ordinateur ou écouter une connexion issue d’un débogueur distant. Cet ensemble d’options est réservé aux packages mobiles à déboguer (cibles apk-debug et ipa-debug). Il est décrit à la section
Options de connexion au débogueur
.
-airDownloadURL
Spécifie une autre URL de téléchargement et d’installation du moteur d’exécution d’AIR sur un périphérique Android. Si vous ne spécifiez pas d’autre URL, une application AIR redirige l’utilisateur vers le moteur d’exécution d’AIR dans Android Market, le cas échéant.
Si l’application est distribuée via un site autre qu’Android Market géré par Google, il peut s’avérer nécessaire de spécifier l’URL de téléchargement du moteur d’exécution d’AIR à partir de ce site. Certains autres sites n’autorisent pas les applications à demander un téléchargement externe. Cette option est réservée aux packages Android.
NATIVE_SIGNING_OPTIONS
Les options de signature natives identifient le certificat requis pour signer un fichier de package natif. Ces options de signature permettent d’appliquer une signature utilisée par le système d’exploitation natif, plutôt que le moteur d’exécution d’AIR. Les options sont sinon identiques à AIR_SIGNING_OPTIONS et font l’objet d’une description détaillée à la section
Options de signature du code de l’outil ADT
.
Les signatures natives sont prises en charge sous Windows et Android. Sous Windows, vous devez spécifier à la fois les options de signature AIR et les options de signature natives. Sous Android, vous ne pouvez spécifier que les options de signature natives.
Dans la plupart des cas, un même certificat de signature du code peut appliquer à la fois une signature AIR et une signature native. Certains cas de figure font toutefois exception à la règle. Google stipule, par exemple, que toutes les applications destinées à Android Market doivent impérativement être signées à l’aide d’un certificat valide jusqu’à l’année 2033 au moins. Cela signifie qu’un certificat délivré par une autorité de certification reconnue, recommandée lors de l’application d’une signature AIR, ne doit pas être utilisé pour signer une application Android. (Aucune autorité de certification ne délivre de certificat de signature du code dont la période de validité est aussi longue.)
output
Nom du fichier de package à créer. La définition de l’extension du fichier est facultative. Si vous ne l’indiquez pas, une extension adaptée à la valeur -target et au système d’exploitation en cours est ajoutée.
app_descriptor
Chemin d’accès au fichier descripteur de l’application. Il est possible de spécifier un chemin relatif (défini par rapport au répertoire actif) ou un chemin absolu. (Le fichier descripteur de l’application est renommé
application.xml
dans le fichier AIR.)
-platformsdk
Chemin d’accès au kit SDK de la plate-forme du périphérique cible :
-
Android : le kit SDK d’AIR 2.6+ inclut les outils du kit SDK d’Android SDK nécessaires à l’implémentation des commandes de l’outil ADT correspondantes. Ne définissez cette valeur que si vous souhaitez utiliser une autre valeur du kit SDK d’Android. Il est également inutile d’indiquer le chemin du kit SDK de plate-forme sur la ligne de commande si la variable d’environnement AIR_ANDROID_SDK_HOME est déjà définie. (Si les deux variables sont définies, le chemin indiqué sur la ligne de commande est utilisé.)
-
iOS : le kit SDK d’AIR est livré avec un kit SDK iOS captif. L’option -platformsdk permet la mise en package d’applications avec un kit SDK externe ; vous n’êtes donc pas obligé d’utiliser le SDK iOS captif. Par exemple, si vous avez créé une extension avec le dernier kit SDK iOS, vous pouvez spécifier ce kit SDK lors de la mise en package de votre application. En outre, lorsque vous utilisez l’outil ADT avec le simulateur iOS, vous devez toujours inclure l’option -platformsdk en spécifiant le chemin vers le kit SDK du simulateur iOS.
Les développeurs d’applications
-arch
peuvent utiliser cet argument pour créer un package APK pour les plates-formes x86, qui prend les valeurs suivantes :
armv7 est la valeur par défaut lorsqu’aucune valeur n’est spécifiée
FILE_OPTIONS
Identifie les fichiers d’application à inclure dans le package. Les options de fichier font l’objet d’une description détaillée à la section
Options associées aux fichiers et chemins
. Ne spécifiez pas d’options de fichier si vous créez un package natif à partir d’un fichier AIR ou AIRI.
input_airi
A spécifier lors de la création d’un package natif à partir d’un fichier AIRI. Les options AIR_SIGNING_OPTIONS sont obligatoires si la cible correspond à
air
(ou qu’aucune cible n’est spécifiée).
input_air
A spécifier lors de la création d’un package natif à partir d’un fichier AIR. Ne spécifiez pas d’option AIR_SIGNING_OPTIONS.
ANE_OPTIONS
Identifie les options et les fichiers permettant de créer un package d’extensions natives. Les options du package d’extensions sont décrites de façon exhaustive dans
Options d’extension native
.
Exemples de commandes ADT -package
Création d’un package de fichiers d’application spécifiques figurant dans le répertoire actif pour une application AIR de type SWF :
adt –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml myApp.swf components.swc
Création d’un package de fichiers d’application spécifiques figurant dans le répertoire actif pour une application AIR de type HTML :
adt –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml myApp.html AIRAliases.js image.gif
Création d’un package de tous les fichiers et sous-répertoires inclus dans le répertoire de travail actif :
adt –package -storetype pkcs12 -keystore ../cert.p12 myApp.air myApp.xml .
Remarque :
le fichier keystore contient la clé privée utilisée pour signer l’application. Veillez à ne jamais inclure le certificat de signature dans le package AIR. Si vous utilisez des caractères génériques dans la commande ADT, déplacez le fichier keystore afin qu’il ne soit pas inclus dans le package. Dans cet exemple, le fichier keystore (cert.p12) réside dans le répertoire parent.
Création d’un package contenant uniquement les fichiers principaux et un sous-répertoire d’images :
adt –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml myApp.swf images
Création d’un package contenant une application HTML et tous les fichiers contenus dans les sous-répertoires HTML, de scripts et d’images sous-jacents :
adt –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml index.html AIRALiases.js html scripts images
Création d’un package du fichier application.xml et du fichier SWF principal se trouvant dans un répertoire de travail (release/bin) :
adt –package -storetype pkcs12 -keystore cert.p12 myApp.air release/bin/myApp.xml –C release/bin myApp.swf
Création d’un package des ressources provenant de plusieurs emplacements du système de fichiers de développement. Dans cet exemple, les actifs de l’application résident dans les dossiers suivants avant la création du package :
/devRoot
/myApp
/release
/bin
myApp-app.xml
myApp.swf or myApp.html
/artwork
/myApp
/images
image-1.png
...
image-n.png
/libraries
/release
/libs
lib-1.swf
lib-2.swf
lib-a.js
AIRAliases.js
Exécution de la commande ADT suivante à partir du répertoire /devRoot/myApp :
adt –package -storetype pkcs12 -keystore cert.p12 myApp.air release/bin/myApp-app.xml
–C release/bin myApp.swf (or myApp.html)
–C ../artwork/myApp images
–C ../libraries/release libs
Résultats dans la structure de package suivante :
/myAppRoot
/META-INF
/AIR
application.xml
hash
myApp.swf or myApp.html
mimetype
/images
image-1.png
...
image-n.png
/libs
lib-1.swf
lib-2.swf
lib-a.js
AIRAliases.js
Exécution de l’outil ADT en tant que programme Java pour une application SWF simple (sans définir le chemin de classe) :
java –jar {AIRSDK}/lib/ADT.jar –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml myApp.swf
Exécution de l’outil ADT en tant que programme Java pour une application HTML simple (sans définir le chemin de classe) :
java –jar {AIRSDK}/lib/ADT.jar –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml myApp.html AIRAliases.js
Exécution de l’outil ADT en tant que programme Java (le chemin de classe Java étant défini de sorte à inclure le package ADT.jar) :
java -com.adobe.air.ADT –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml myApp.swf
Exécution de l’outil ADT en tant que tâche Java dans Apache Ant (bien qu’il soit plutôt conseillé d’utiliser la commande ADT directement dans les scripts Ant). Les chemins indiqués dans l’exemple correspondent à un système Windows :
<property name="SDK_HOME" value="C:/AIRSDK"/>
<property name="ADT.JAR" value="${SDK_HOME}/lib/adt.jar"/>
target name="package">
<java jar="${ADT.JAR}" fork="true" failonerror="true">
<arg value="-package"/>
<arg value="-storetype"/>
<arg value="pkcs12"/>
<arg value="-keystore"/>
<arg value="../../ExampleCert.p12"/>
<arg value="myApp.air"/>
<arg value="myApp-app.xml"/>
<arg value="myApp.swf"/>
<arg value="icons/*.png"/>
</java>
</target>
Remarque :
sur certains ordinateurs, les caractères à double octet figurant dans les chemins d’accès de système de fichiers risquent d’être incorrectement interprétés. Si tel est le cas, tentez de définir le JRE utilisé pour exécuter l’outil ADT de sorte à utiliser le jeu de caractères UTF-8. Tel est le cas par défaut dans le script de lancement de l’outil ADT sous Mac et Linux. Dans le fichier Windows adt.bat ou si vous exécutez l’outil ADT directement à partir de Java, spécifiez l’option
-Dfile.encoding=UTF-8
sur la ligne de commande Java.