Mise en package d’un fichier d’installation AIR de bureau

Chaque application AIR doit disposer d’au moins un fichier descripteur d’application et d’un fichier SWF ou HTML principal. Il est également impératif de mettre en package dans le fichier AIR tout autre actif à installer avec l’application.

Cet article est consacré à la mise en package d’une application AIR à l’aide des outils de ligne de commande intégrés au kit SDK. Pour plus d’informations sur la mise en package d’une application par le biais de l’un des outils de création d’Adobe, voir :

Tous les fichiers du programme d’installation AIR doivent être signés à l’aide d’un certificat numérique. Le programme d’installation AIR fait appel à la signature pour vérifier que le fichier de l’application n’a pas été modifié depuis que vous y avez apposé votre signature. Vous pouvez utiliser un certificat de signature de code provenant d’une autorité de certification ou un certificat auto-signé.

Un certificat émis par une autorité de certification approuvée offre aux utilisateurs de l’application une certaine garantie de votre identité en tant qu’éditeur. La boîte de dialogue d’installation reflète le fait que votre identité est vérifiée par une autorité de certification :

Boîte de dialogue de confirmation de l’installation d’une application signée par un certificat approuvé

Lorsque vous utilisez un certificat auto-signé, les utilisateurs n’ont aucun moyen de vérifier que vous êtes véritablement le signataire. Par ailleurs, un tel certificat ne garantit en aucune façon que le package n’a pas été modifié (il se peut en effet qu’un faux soit substitué au fichier d’installation légitime avant que l’utilisateur ne l’ait en sa possession). La boîte de dialogue d’installation reflète le fait que l’identité de l’éditeur ne peut être avérée. Les risques sécuritaires liés à l’installation de l’application sont donc plus importants :

Boîte de dialogue de confirmation de l’installation d’une application signée par un certificat auto-signé

Vous pouvez créer et signer un package de fichier AIR au cours de la même opération grâce à la commande -package d’ADT. Vous avez également la possibilité de créer un package non signé intermédiaire à l’aide de la commande -prepare. Vous pouvez ensuite signer ce package intermédiaire au cours d’une étape distincte en utilisant la commande -sign.

Remarque : la version 1.5 et les versions ultérieures de Java ne prennent pas en charge les caractères ASCII étendus dans les mots de passe de protection des fichiers de certificats PKCS12. Lorsque vous créez ou exportez le fichier de certificat de signature du code, utilisez uniquement des caractères ASCII ordinaires dans le mot de passe.

Lors de la signature du package d’installation, l’outil ADT contacte automatiquement un serveur d’autorité d’horodatage chargé de vérifier l’heure. Les informations d’horodatage sont incluses dans le fichier AIR. Un fichier AIR comprenant un horodatage vérifié peut être installé à tout moment par la suite. Si l’outil ADT ne parvient pas à se connecter au serveur d’horodatage, la création du package est annulée. Vous pouvez ignorer l’option d’horodatage, mais sans horodatage, il devient impossible d’installer une application AIR une fois que le certificat utilisé pour signer le fichier d’installation est arrivé à expiration.

Vous devez utiliser le certificat d’origine pour signer un package créé pour mettre à jour une application AIR existante. Si vous avez renouvelé ce certificat, qu’il a expiré au cours des 180 derniers jours ou que vous souhaitez le remplacer, vous pouvez apposer une signature de migration. Dans ce cas, le fichier AIR est signé à l’aide des deux certificats, l’ancien et le nouveau. La commande -migrate permet d’appliquer la signature de migration, comme indiqué à la section Commande ADT migrate.

Important : vous disposez d’un délai de 180 jours au maximum pour apposer la signature de migration une fois le certificat d’origine périmé. Sans cette signature, les utilisateurs existants doivent désinstaller leur application existante pour pouvoir installer la nouvelle version. Le délai ne s’applique qu’aux applications pour lesquelles l’espace de noms stipule AIR 1.5.3 ou une version ultérieure dans le fichier descripteur. Lorsque vous ciblez des versions antérieures du moteur d’exécution d’AIR, vous ne disposez d’aucun délai.

Les signatures de migration n’étaient pas prises en charge préalablement à AIR 1.1. Pour apposer une signature de migration, vous devez mettre en package une application à l’aide d’un kit de développement SDK version 1.1 ou ultérieure.

Les applications déployées à l’aide de fichiers AIR font partie du profil de bureau. Il est impossible d’utiliser l’outil ADT pour mettre en package un programme d’installation natif destiné à une application AIR si le fichier descripteur correspondant ne prend pas en charge le profil de bureau. Vous pouvez restreindre l’utilisation de ce profil à l’aide de l’élément supportedProfiles dans le fichier descripteur de l’application. Voir Profils de périphérique et supportedProfiles.

Remarque : les paramètres du fichier descripteur d’application déterminent l’identité d’une application AIR et son chemin d’installation par défaut. Voir Fichiers descripteurs d’applications AIR.

Identifiants d’éditeur

Depuis AIR 1.5.3, les identifiants d’éditeur sont obsolètes. Les nouvelles applications (publiées à l’origine avec AIR 1.5.3 ou version ultérieure) ne requièrent pas d’identifiant d’éditeur et ne doivent pas en spécifier.

Lors de la mise à jour d’applications publiées à l’aide des versions antérieures d’AIR, vous devez spécifier l’identifiant d’éditeur d’origine dans le fichier descripteur d’application, sans quoi la version installée de l’application et la version mise à jour sont traitées comme des applications différentes. Si vous utilisez un autre identifiant d’éditeur ou omettez la balise publisherID, l’utilisateur est contraint de désinstaller la version antérieure pour pouvoir installer la nouvelle.

Pour déterminer l’identifiant d’éditeur original, recherchez le fichier publisherid dans le sous-répertoire META-INF/AIR du répertoire d’installation de l’application originale. La chaîne que contient ce fichier correspond à l’identifiant d’éditeur. Le fichier descripteur de l’application doit stipuler le moteur d’exécution d’AIR 1.5.3 (ou version ultérieure) dans la déclaration d’espace de noms pour que vous puissiez stipuler manuellement l’identifiant d’éditeur.

Dans le cas des applications publiées avant AIR 1.5.3 (ou de celles publiées à l’aide du kit SDK AIR 1.5.3, mais dont l’espace de noms du descripteur spécifie une version antérieure d’AIR), un identifiant d’éditeur est calculé à partir du certificat de signature. Allié à l’identifiant d’application, l’identifiant d’éditeur permet de déterminer l’identité d’une application. S’il existe, l’identifiant d’éditeur est utilisé comme suit :

  • Pour vérifier que le fichier AIR est une mise à jour et non une nouvelle application à installer

  • Dans la clé de chiffrement destinée au magasin local chiffré

  • Dans le chemin du répertoire de stockage d’application

  • Dans la chaîne de connexion associée aux connexions locales

  • Dans la chaîne d’identité destinée à appeler une application par le biais de l’API intégrée au navigateur d’AIR

  • Dans l’OSID (définition d’interface de service ouverte) utilisée lors de la création de programmes d’installation/de désinstallation personnalisés

Préalablement à AIR 1.5.3, l’identifiant d’éditeur d’une application pouvait changer si vous aviez signé la mise à jour de celle-ci par le biais d’une signature de migration utilisant un certificat nouveau ou renouvelé. Toute modification de l’identifiant d’éditeur entraîne un changement de comportement de toute fonctionnalité AIR basée sur celui-ci. Il devient, par exemple, impossible d’accéder aux données stockées dans le magasin local chiffré et la chaîne de connexion associée à toute occurrence de Flash ou d’AIR qui crée une connexion locale à l’application doit contenir le nouvel identifiant.

Dans AIR 1.5.3 ou ultérieur, l’identifiant d’éditeur n’est pas fondé sur le certificat de signature et est uniquement affecté si la balise publisherID figure dans le descripteur d’application. Il est impossible de mettre à jour une application si l’identifiant d’éditeur spécifié pour le package AIR de mise à jour ne correspond pas à l’identifiant d’éditeur actif.

    Mise en package avec l’outil ADT

    L’outil de ligne de commande ADT d’AIR permet de mettre en package une application AIR. Avant la mise en package, il est nécessaire de compiler tout code ActionScript, MXML et code d’extension éventuel. Vous devez également disposer d’un certificat de signature du code.

    Pour consulter des informations de référence détaillées sur les commandes et options de l’outil ADT, voir Outil AIR Developer (ADT).

    Création d’un package AIR

    Pour créer un package AIR, utilisez la commande ADT package et définissez le type de cible sur air pour les versions validées. 

    adt -package -target air -storetype pkcs12 -keystore ../codesign.p12 myApp.air myApp-app.xml myApp.swf icons

    L’exemple part du principe que le chemin d’accès à l’outil ADT figure dans la définition path de l’interface de commande de ligne de commande. (Pour plus d’informations, voir Variables d’environnement path.)

    Vous devez exécuter la commande à partir du répertoire qui contient les fichiers de l’application. Dans l’exemple illustré, les fichiers de l’application sont myApp-app.xml (fichier descripteur de l’application), myApp.swf et un répertoire d’icônes.

    Si vous exécutez la commande comme indiqué, l’outil ADT vous invite à entrer le mot de passe associé au keystore. (Les caractères du mot de passe saisis ne sont pas toujours affichés. Appuyez simplement sur Entrée une fois la saisie terminée.)

    Création d’un package AIR à partir d’un fichier AIRI

    Créer et signer un fichier AIRI permet de créer un package AIR à installer :

    adt -sign -storetype pkcs12 -keystore ../codesign.p12 myApp.airi myApp.air