Application de débogage du lanceur AIR (ADL)

L’application de débogage du lanceur AIR (ADL) permet d’exécuter à la fois des applications SWF et HTML lors de la phase de développement. Grâce à ADL, vous pouvez exécuter une application sans la mettre en package et l’installer au préalable. Par défaut, ADL utilise un moteur d’exécution fourni avec le kit SDK. Autrement dit, il est inutile d’installer le moteur d’exécution séparément pour se servir d’ADL.

ADL imprime les instructions trace et les erreurs d’exécution au format de sortie standard, mais ne prend pas en charge les points d’arrêt ou d’autres fonctions de débogage. Vous pouvez utiliser l’outil Flash Debugger (ou un environnement de développement intégré tel que Flash Builder) pour résoudre les problèmes plus complexes.

Remarque : si vos instructions trace() ne s’affichent pas sur la console, assurez-vous de ne pas avoir spécifié ErrorReportingEnable ou TraceOutputFileEnable dans le fichier mm.cfg. Pour plus d’informations sur l’emplacement propre à la plate-forme de ce fichier, voir Modification du fichier mm.cfg .

AIR prend directement en charge le débogage. Vous n’avez donc pas besoin d’une version de débogage du moteur d’exécution (contrairement à Adobe® Flash® Player). Pour effectuer le débogage sur la ligne de commande, vous utilisez le débogueur de Flash et l’application de débogage du lanceur AIR (ADL).

Le débogueur de Flash est distribué dans le répertoire du kit SDK Flex. Les versions natives, telles que fdb.exe sous Windows, résident dans le sous-répertoire bin. La version Java se trouve dans le sous-répertoire lib. L’application de débogage du lanceur AIR (ADL), adl.exe, figure dans le répertoire bin de l’installation du kit SDK Flex (il n’existe pas de version propre à Java).

Remarque : il est impossible de démarrer une application AIR directement à l’aide du débogueur de Flash (fdb), car celui-ci tente de la lancer à l’aide de Flash Player. Laissez plutôt l’application AIR se connecter à une session fdb en cours.

Utilisation de l’application ADL

Pour exécuter une application à l’aide d’ADL, utilisez la syntaxe suivante :

adl application.xml

application.xml est le fichier descripteur de l’application.

La syntaxe complète d’ADL est la suivante :

adl     [-runtime runtime-directory] 
    [-pubid publisher-id] 
    [-nodebug] 
    [-atlogin] 
    [-profile profileName] 
    [-screensize value] 
    [-extdir extension-directory] 
    application.xml 
    [root-directory] 
    [-- arguments]

(Les éléments entre crochets, [], sont facultatifs.)

-runtime RépertoireMoteurExécution Indique le répertoire contenant le moteur d’exécution à utiliser. Si vous ne le précisez pas, le répertoire du moteur d’exécution situé dans le même kit SDK que le programme ADL est utilisé. Si vous déplacez ADL hors de son dossier SDK, spécifiez le répertoire du moteur d’exécution. Sous Windows et Linux, indiquez le répertoire contenant le dossier Adobe AIR . Sous Mac OS X, spécifiez le répertoire contenant Adobe AIR.framework .

-pubid IdentifiantEditeur Affecte la valeur indiquée comme identifiant d’éditeur de l’application AIR pour cette exécution. L’utilisation d’un ID d’éditeur temporaire vous permet de tester les fonctions d’une application AIR (telles que la communication via une connexion locale) nécessitant ce type d’identifiant afin d’identifier une application de manière unique. Depuis la version 1.5.3 d’AIR, vous pouvez également stipuler l’identifiant d’éditeur dans le fichier descripteur de l’application (n’utilisez donc pas ce paramètre).

Remarque : depuis la version 1.5.3 d’AIR, un identifiant d’éditeur n’est plus automatiquement calculé et affecté à une application AIR. Vous pouvez stipuler un identifiant d’éditeur lorsque vous créez une mise à jour d’application AIR existante, mais les nouvelles applications ne nécessitent pas - et ne devraient pas comporter - d’identifiant d’éditeur.

-nodebug Désactive la prise en charge du débogage. Si cette option est utilisée, le processus de l’application ne peut pas se connecter au programme Flash Debugger et les boîtes de dialogue relatives aux exceptions non gérées sont masquées. (Toutefois, les instructions trace sont toujours imprimées dans la fenêtre de la console.) La désactivation de la fonction de débogage permet d’accélérer l’exécution de votre application et d’émuler plus étroitement le mode d’exécution d’une application installée.

- atlogin Simule le lancement de l’application lors de la connexion. Cet indicateur permet de tester la logique applicative qui s’exécute uniquement lorsqu’une application est configurée de sorte à démarrer lorsque l’utilisateur se connecte. Lors de l’utilisation de -atlogin , la propriété reason de l’objet InvokeEvent envoyée à l’application correspond à login , et non à standard (à moins que l’application soit déjà en cours d’exécution).

-profile NomProfil L’application ADL débogue l’application avec le profil indiqué. La valeur NomProfil gère l’une des valeurs suivantes :

  • desktop

  • extendedDesktop

  • mobileDevice

Si le descripteur de l’application comprend un élément supportedProfiles , le profil spécifié avec l’indicateur -profile doit figurer dans la liste prise en charge. Si vous n’utilisez pas l’indicateur -profile , le premier profil du descripteur de l’application fait office de profil actif. Si le descripteur de l’application ne comprend pas d’élément supportedProfiles et que vous n’utilisez pas l’indicateur -profile , le profil desktop est utilisé.

Pour plus d’informations, voir supportedProfiles et Profils de périphérique .

-screensize valeur Taille de l’écran simulée à utiliser lors de l’exécution d’une application associée au profil mobileDevice sur le bureau. Indiquez la taille de l’écran en sélectionnant le type d’écran prédéfini ou saisissez les dimensions (en pixels) de la largeur et de la hauteur standard correspondant au mode Portrait, plus la largeur et la hauteur en plein écran. Pour spécifier la valeur par type, utilisez l’un des types d’écran prédéfinis suivants :

Type d’écran

Largeur x hauteur standard

Largeur x hauteur standard en plein écran

480

720 x 480

720 x 480

720

1 280 x 720

1 280 x 720

1 080

1 920 x 1 080

1 920 x 1 080

Droid

480 x 816

480 x 854

FWQVGA

240 x 432

240 x 432

FWVGA

480 x 854

480 x 854

HVGA

320 x 480

320 x 480

iPad

768 x 1 004

768 x 1 024

iPadRetina

1 536 x 2 008

1 536 x 2 048

iPhone

320 x 460

320 x 480

iPhoneRetina

640 x 920

640 x 960

iPhone5Retina

640 x 1 096

640 x 1 136

iPhone6

750 x 1 294

750 x 1 334

iPhone6Plus

1 242 x 2 148

1 242 x 2 208

iPod

320 x 460

320 x 480

iPodRetina

640 x 920

640 x 960

iPod5Retina

640 x 1 096

640 x 1 136

NexusOne

480 x 762

480 x 800

QVGA

240 x 320

240 x 320

SamsungGalaxyS

480 x 762

480 x 800

SamsungGalaxyTab

600 x 986

600 x 1 024

WQVGA

240 x 400

240 x 400

WVGA

480 x 800

480 x 800

Pour spécifier directement les dimensions de l’écran en pixels, utilisez le format suivant :

widthXheight:fullscreenWidthXfullscreenHeight

Veillez à toujours spécifier les dimensions (en pixels) correspondant au format Portrait, c’est-à-dire de spécifier une valeur de largeur inférieure à la valeur de hauteur. Spécifiez par exemple comme suit l’écran NexusOne :

-screensize 480x762:480x800

-extdir extension-directory Répertoire dans lequel le moteur d’exécution doit rechercher les extensions natives. Ce répertoire contient un sous-répertoire pour chaque extension native qu’utilise l’application. Chacun de ces sous-répertoires contient le fichier ANE extrait du package d’une extension. Exemple :

C:\extensionDirs\ 
    extension1.ane\ 
        META-INF\ 
            ANE\ 
                Android-ARM\ 
                    library.swf 
                    extension1.jar 
                extension.xml 
            signatures.xml 
        catalog.xml 
        library.swf 
        mimetype 
    extension2.ane\ 
        META-INF\ 
            ANE\ 
                Android-ARM\ 
                    library.swf 
                    extension2.jar 
                extension.xml 
            signatures.xml 
        catalog.xml 
        library.swf 
        mimetype 
    

Lors de l’utilisation du paramètre -extdir, tenez compte des points suivants :

  • La commande ADL requiert que chacun des répertoires spécifiés possède l’extension de nom de fichier .ane. La partie du nom de fichier qui précède le suffixe « .ane » peut néanmoins correspondre à n’importe quel nom de fichier valide. Il n’est toutefois pas impératif qu’elle corresponde à la valeur de l’élément extensionID du fichier descripteur de l’application.

  • Vous pouvez spécifier plusieurs fois le paramètre -extdir .

  • L’outil ADT et l’outil ADL traitent différemment l’utilisation du paramètre -extdir . Dans ADT, ce paramètre spécifie un répertoire contenant les fichiers ANE.

  • Vous pouvez également utiliser la variable d’environnement AIR_EXTENSION_PATH pour spécifier les répertoires de l’extension. Voir Variables d’environnement ADT .

application.xml Fichier descripteur d’application. Voir Fichiers descripteurs d’applications AIR . Le descripteur d’application est l’unique paramètre requis par ADL et, dans la plupart des cas, l’unique paramètre nécessaire.

RépertoireRacine Indique le répertoire racine de l’application à exécuter. S’il n’est pas spécifié, c’est le répertoire contenant le fichier descripteur d’application qui est utilisé.

-- arguments Toutes les chaînes de caractères figurant après « -- » sont transmises à l’application sous forme d’arguments de ligne de commande.

Remarque : lorsque vous lancez une application AIR déjà en cours d’exécution, aucune nouvelle occurrence de l’application n’est ouverte. Au lieu de cela, un événement invoke est distribué à l’occurrence en cours d’exécution.

Exemples ADL

Exécutez une application dans le répertoire actif :

adl myApp-app.xml

Exécutez une application dans un sous-répertoire du répertoire actif :

adl source/myApp-app.xml release

Exécutez une application et transmettez deux arguments de ligne de commande, « tick » et « tock » :

adl myApp-app.xml -- tick tock

Exécutez une application à l’aide d’un moteur d’exécution spécifique :

adl -runtime /AIRSDK/runtime myApp-app.xml

Exécutez une application sans prise en charge du débogage :

adl -nodebug myApp-app.xml

Exécutez une application du profil de périphérique mobile et simulez la taille de l’écran Nexus One :

adl -profile mobileDevice -screensize NexusOne myMobileApp-app.xml

Exécutez une application par le biais d’Apache Ant (les chemins illustrés dans l’exemple se réfèrent à Windows) :

<property name="SDK_HOME" value="C:/AIRSDK"/> 
<property name="ADL" value="${SDK_HOME}/bin/adl.exe"/> 
<property name="APP_ROOT" value="c:/dev/MyApp/bin-debug"/> 
<property name="APP_DESCRIPTOR" value="${APP_ROOT}/myApp-app.xml"/> 
 
<target name="test"> 
    <exec executable="${ADL}"> 
        <arg value="${APP_DESCRIPTOR}"/> 
        <arg value="${APP_ROOT}"/> 
    </exec>  
</target>

Codes d’erreur et de sortie d’ADL

Le tableau suivant décrit les codes de sortie imprimés par ADL :

Code de sortie

Description

0

Lancement réussi. ADL se ferme après la fermeture de l’application AIR.

1

Appel réussi d’une application AIR déjà exécutée. Fermeture immédiate d’ADL.

2

Erreur d’utilisation. Les arguments transmis à ADL sont incorrects.

3

Moteur d’exécution introuvable.

4

Impossible de démarrer le moteur d’exécution. En général, cela se produit car la version spécifiée dans l’application ne correspond pas à celle du moteur d’exécution.

5

Une erreur d’origine inconnue s’est produite.

6

Fichier descripteur d’application introuvable.

7

Le contenu du descripteur de l’application est incorrect. Cette erreur indique généralement que le fichier XML n’est pas bien constitué.

8

Le fichier de contenu principal de l’application (spécifié dans l’élément <content> du fichier descripteur d’application) est introuvable.

9

Le fichier du contenu principal de l’application n’est pas un fichier SWF ou HTML valide.

10

L’application ne prend pas en charge le profil spécifié par le biais de l’option -profile.

11

L’argument -screensize n’est pas pris en charge dans le profil actuel.