Commande ADT package

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 :

    • EXE : Windows

    • DMG : Mac

    • DEB : Ubuntu Linux (AIR 2.6 ou versions antérieures)

    • RPM — Fedora ou OpenSuse Linux (AIR 2.6 ou versions antérieures)

    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 - ADT met en package APK pour la plate-forme Android armv7.

  • x86 - ADT met en package APK pour la plate-forme Android x86.

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.