ADT-Befehl „package“

Der Befehl -package- sollte vom Hauptanwendungsordner aus ausgeführt werden. Der Befehl verwendet die folgende Syntax:

Ein AIR-Paket aus den Komponentenanwendungsdateien erstellen: 

adt -package 
    AIR_SIGNING_OPTIONS 
    -target packageType 
    -sampler 
    ‑hideAneLibSymbols 
    NATIVE_SIGNING_OPTIONS 
    output 
    app_descriptor 
    FILE_OPTIONS

Ein natives Paket aus den Komponentenanwendungsdateien erstellen: 

adt -package 
    AIR_SIGNING_OPTIONS 
    -target packageType 
    DEBUGGER_CONNECTION_OPTIONS 
    -airDownloadURL URL 
    NATIVE_SIGNING_OPTIONS 
    output 
    app_descriptor 
    -platformsdk path 
    FILE_OPTIONS

Ein natives Paket, das eine native Erweiterung enthält, aus den Komponentenanwendungsdateien erstellen: 

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

Ein natives Paket aus einer AIR- oder AIRI-Datei erstellen: 

adt -package 
    -target packageType 
    NATIVE_SIGNING_OPTIONS 
    output 
    input_package

Erstellen Sie ein natives Erweiterungspaket aus den nativen Komponentenerweiterungsdateien: 

adt -package 
    AIR_SIGNING_OPTIONS     
    -target ane 
    output 
    ANE_OPTIONS
Hinweis: Sie brauchen eine ANE-Datei nicht zu signieren, deshalb sind die AIR_SIGNING_OPTIONS -Parameter in diesem Beispiel optional.

AIR_SIGNING_OPTIONS Die AIR-Signaturoptionen identifizieren das Zertifikat, mit dem eine AIR-Installationsdatei signiert wird. Die Signaturoptionen werden unter ADT-Optionen zum Signieren von Code ausführlich beschrieben.

-migrate Dieses Flag gibt an, dass die Anwendung neben dem in den AIR_SIGNING_OPTIONS -Parametern festgelegten Zertifikat mit einem Migrationszertifikat signiert wurde. Dieses Flag ist nur gültig, wenn Sie eine Desktopanwendung als natives Installationsprogramm komprimieren und die Anwendung eine native Erweiterung verwendet. In anderen Fällen tritt ein Fehler auf. Die Signaturoptionen für das Migrationszertifikat sind als MIGRATION_SIGNING_OPTIONS -Parameter festgelegt. Diese Signaturoptionen werden unter ADT-Optionen zum Signieren von Code ausführlich beschrieben. Mithilfe des -migrate -Flags können Sie ein Update für eine als natives Installationsprogramm verpackte Anwendung erstellen, die eine native Erweiterung verwendet, und das Codesignaturzertifikat für die Anwendung ändern, z. B. wenn das Originalzertifikat abläuft. Weitere Informationen finden Sie unter Signieren einer aktualisierten Version einer AIR-Anwendung .

Das -migrate -Flag des Befehls -package ist in AIR 3.6 und höher verfügbar.

-target Der Typ des zu erstellenden Pakets. Die folgenden Pakettypen werden unterstützt:

  • air – ein AIR-Paket. Der Standardwert ist „air“ und der -target-Kennzeichner muss nicht angegeben werden, wenn Sie AIR- oder AIRI-Dateien erstellen.

  • airn – ein natives Anwendungspaket für Geräte im erweiterten TV-Profil.

  • ane – ein natives AIR-Erweiterungspaket

  • Ziele von Android-Paketen:

    • apk – ein Android-Paket. Ein mit diesem Ziel erstelltes Paket kann nur auf einem Android-Gerät, nicht auf einem Emulator installiert werden.

    • apk‑captive‑runtime – ein Android-Paket, das sowohl die Anwendung als auch die gekoppelte Version der AIR-Laufzeitumgebung enthält. Ein mit diesem Ziel erstelltes Paket kann nur auf einem Android-Gerät, nicht auf einem Emulator installiert werden.

    • apk-debug – ein Android-Paket mit zusätzlichen Debugging-Informationen. (Die SWF-Dateien in der Anwendung müssen ebenfalls mit Debugging-Unterstützung kompiliert werden.)

    • apk-emulator – ein Android-Paket zur Verwendung mit einem Emulator ohne Debugging-Unterstützung. (Verwenden Sie das apk-debug-Ziel, um das Debugging sowohl auf dem Emulator als auch auf Geräten zuzulassen.)

    • apk-profile – ein Android-Paket, das Anwendungsleistung und Speicherprofilerstellung unterstützt.

  • Ziele von iOS-Paketen:

    • ipa-ad-hoc – ein iOS-Paket für die Ad-hoc-Verteilung.

    • ipa-app-store – ein iOS-Paket zur Bereitstellung im Apple App Store.

    • ipa-debug – ein iOS-Paket mit zusätzlichen Debugging-Informationen. (Die SWF-Dateien in der Anwendung müssen ebenfalls mit Debugging-Unterstützung kompiliert werden.)

    • ipa-test – ein iOS-Paket, das ohne Optimierungs- oder Debugging-Informationen kompiliert wurde.

    • ipa-debug-interpreter – entspricht von der Funktion her einem debug-Paket, die Kompilierung ist jedoch schneller. Der ActionScript-Bytecode wird interpretiert und nicht in Computercode übersetzt. Deshalb wird der Code langsamer ausgeführt als in einem interpreter-Paket.

    • ipa-debug-interpreter-simulator – entspricht von der Funktion her ipa-debug-interpreter, wird jedoch für den iOS Simulator verpackt. Nur für Macintosh. Wenn Sie diese Option verwenden, müssen Sie auch die Option -platformsdk einschließen, um den Pfad zum iOS Simulator SDK anzugeben.

    • ipa-test-interpreter – entspricht von der Funktion her einem test-Paket, die Kompilierung ist jedoch schneller. Der ActionScript-Bytecode wird interpretiert und nicht in Computercode übersetzt. Deshalb wird der Code langsamer ausgeführt als in einem interpreter-Paket.

    • ipa-test-interpreter-simulator – entspricht von der Funktion her ipa-test-interpreter, wird jedoch für den iOS Simulator verpackt. Nur für Macintosh. Wenn Sie diese Option verwenden, müssen Sie auch die Option -platformsdk einschließen, um den Pfad zum iOS Simulator SDK anzugeben.

  • native – ein natives Desktopinstallationsprogramm. Der Typ der produzierten Datei ist das native Installationsformat des Betriebssystems, auf dem der Befehl ausgeführt wird:

    • EXE – Windows

    • DMG – Mac

    • DEB – Ubuntu Linux (AIR 2.6 oder früher)

    • RPM – Fedora oder OpenSuse Linux (AIR 2.6 oder früher)

    Weitere Informationen finden Sie unter Komprimieren eines nativen Desktopinstallationsprogramms .

-sampler (nur iOS, AIR 3.4 und höher) Aktiviert den telemetriegestützten ActionScript-Sampler in iOS-Anwendungen. Wenn Sie dieses Flag verwenden, können Sie die Anwendung mit Adobe Scout profilieren. Zwar kann Scout alle Flash-Plattform-Inhalte profilieren, durch die Aktivierung ausführlicher Telemetrie erhalten Sie jedoch tiefen Einblick in ActionScript-Funktionstiming, DisplayList, Stage3D-Rendern und mehr. Beachten Sie, dass die Verwendung dieses Kennzeichners sich leicht negativ auf die Leistung auswirkt; Sie sollten ihn also nicht für Produktionsanwendungen einsetzen.

-hideAneLibSymbols (nur iOS, AIR 3.4 und höher) Anwendungsentwickler können mehrere native Erweiterungen aus mehreren Quellen verwenden. Wenn die ANE-Dateien einen Symbolnamen gemeinsam verwenden, generiert das ADT einen Fehler („doppeltes Symbol in Objektdatei“). Unter Umständen kann sich dieser Fehler zur Laufzeit als Absturz bemerkbar machen. Mit der hideAneLibSymbols -Option können Sie angeben, ob die Symbole der ANE-Bibliothek nur für die Quellen dieser Bibliothek sichtbar sein sollen („yes“) oder global sichtbar sein sollen („no“):

  • yes – Verbirgt ANE-Symbole, wodurch unbeabsichtigte Symbolkonflikte gelöst werden.

  • no – (Standardvorgabe) Verbirgt ANE-Symbole nicht. Dies ist das Verhalten aus Versionen vor AIR 3.4.

-embedBitcode (nur iOS, AIR 25 und höher) App-Entwickler können die Option embedBitcode verwenden, um anzugeben, ob Bitcode in die iOS-App eingebettet werden soll, indem sie „Ja“ oder „Nein“ wählen. Der Standardwert dieses Schalters bei fehlender Angabe ist „Nein“.

DEBUGGER_CONNECTION_OPTIONS Die Debugger-Verbindungsoptionen geben an, ob ein Debug-Paket versuchen soll, eine Verbindung zu einem Remote-Debugger auf einem anderen Computer herzustellen, oder ob es auf eine Verbindung von einem Remote-Debugger warten soll. Dieser Optionssatz wird zurzeit nur für mobile Debug-Pakte unterstützt (Ziele apk-debug und ipa-debug). Diese Optionen werden unter Debugger-Verbindungsoptionen beschrieben.

-airDownloadURL Gibt eine alternative URL zum Herunterladen und Installieren der AIR-Laufzeitumgebung auf Android-Geräten an. Wird diese Option nicht angegeben, leitet die AIR-Anwendung den Benutzer zur AIR-Laufzeitumgebung auf dem Android Market, falls die Laufzeitumgebung noch nicht installiert ist.

Wenn Ihre Anwendung auf anderem Wege (nicht über den von Google verwalteten Android Market) verteilt wird, müssen Sie ggf. die URL zum Herunterladen der AIR-Laufzeitumgebung von diesem alternativen Markt angeben. Einige alternative Märkte lassen es nicht zu, dass Anwendungen einen Download von außerhalb des jeweiligen Markts erfordern. Diese Option wird nur für Android-Pakete unterstützt.

NATIVE_SIGNING_OPTIONS Die nativen Signaturoptionen identifizieren das Zertifikat, das zum Signieren einer nativen Paketdatei verwendet wird. Mit diesen Signaturoptionen wird eine Signatur angewendet, die vom nativen Betriebssystem, nicht von der AIR-Laufzeitumgebung verwendet wird. Davon abgesehen sind die Optionen identisch mit den AIR_SIGNING_OPTIONS und werden ausführlich unter ADT-Optionen zum Signieren von Code beschrieben.

Native Signaturen werden unter Windows und Android unterstützt. Unter Windows sollten sowohl AIR-Signaturoptionen als auch native Signaturoptionen angegeben werden. Unter Android genügt es, nur die nativen Signaturoptionen anzugeben.

In vielen Fällen können Sie dasselbe Codesignaturzertifikat verwenden, um eine AIR-Signatur und eine native Signatur anzuwenden. Dies ist jedoch nicht immer der Fall. Die Google-Richtlinie zum Übermitteln von Apps an den Android Market sieht zum Beispiel vor, dass alle Apps mit einen Zertifikat signiert werden, das mindestens bis zum Jahr 2033 gültig ist. Das bedeutet, dass ein Zertifikat einer bekannten Zertifizierungsstelle, die für das Anwenden einer AIR-Signatur empfohlen wird, nicht zum Signieren einer Android-App verwendet werden sollte. (Keine Zertifizierungsstelle gibt Codesignaturzertifikate mit einer derart langen Gültigkeitsdauer aus.)

output Der Name der zur erstellenden Paketdatei. Die Angabe der Dateierweiterung ist optional. Wenn keine angegeben ist, wird eine Erweiterung hinzugefügt, die zum -target-Wert und zum aktuellen Betriebssystem passt.

app_descriptor Der Pfad zur Anwendungsdeskriptordatei. Der Pfad kann relativ zum aktuellen Verzeichnis oder als absoluter Pfad angegeben werden. (Die Anwendungsdeskriptordatei wird in der AIR-Datei in application.xml umbenannt.)

-platformsdk Der Pfad zum Plattform-SDK für das Zielgerät:

  • Android – Das AIR SDK ab Version 2.6 enthält die Werkzeuge aus dem Android SDK, die zum Implementieren der relevanten ADT-Befehle erforderlich sind. Legen Sie diesen Wert nur fest, um eine andere Version des Android SDK zu verwenden. Das Plattform-SDK muss nicht in der Befehlszeile angegeben werden, wenn bereits die Umgebungsvariable AIR_ANDROID_SDK_HOME gesetzt wurde. (Falls beide angegeben werden, wird der in der Befehlszeile angegebene Pfad verwendet.)

  • iOS – Das AIR SDK wird mit einem gekoppelten iOS SDK geliefert. Mit der Option -platformsdk können Sie Anwendungen mit einem externen SDK verpacken, sodass Sie nicht auf die Verwendung des gekoppelten iOS SDK angewiesen sind. Wenn Sie zum Beispiel eine Erweiterung mit dem neuesten iOS SDK erstellt haben, können Sie dieses SDK angeben, wenn Sie Ihre Anwendung verpacken. Außerdem müssen Sie bei Verwendung von ADT mit dem iOS Simulator immer die Option -platformsdk mit einschließen, um dem Pfad zum iOS Simulator SDK anzugeben.

-arch -Anwendungsentwickler können dieses Argument verwenden, um die APK-Datei für x86-Plattformen zu erstellen und müssen folgende Werte verwenden:

  • armv7 - ADT verpackt APK für die Android-armv7-Plattform.

  • x86 - ADT verpackt APK für die Android-x86-Plattform.

armv7 ist der Standardwert, wenn kein Wert angegeben wird

FILE_OPTIONS Identifiziert die Anwendungsdateien, die in das Paket eingeschlossen werden sollen. Die Dateioptionen werden ausführlich unter Datei- und Pfadoptionen beschrieben. Geben Sie keine Dateioptionen an, wenn Sie ein natives Paket aus einer AIR- oder AIRI-Datei erstellen.

input_airi Geben Sie dies an, wenn Sie ein natives Paket aus einer AIRI-Datei erstellen. Die AIR_SIGNING_OPTIONS sind erforderlich, wenn das Ziel air ist (oder kein Ziel angegeben wird).

input_air Geben Sie dies an, wenn Sie ein natives Paket aus einer AIR-Datei erstellen. Geben Sie keine AIR_SIGNING_OPTIONS an.

ANE_OPTIONS Identifiziert die Optionen und Dateien zum Erstellen eines nativen Erweiterungspakets. Die Optionen für Erweiterungspakete sind unter Optionen für native Erweiterungen vollständig beschrieben.

Beispiele für -package-ADT-Befehle

Paketspezifische Anwendungsdateien im aktuellen Verzeichnis für eine SWF-basierte AIR-Anwendung: 

adt –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml myApp.swf components.swc

Paketspezifische Anwendungsdateien im aktuellen Verzeichnis für eine HTML-basierte AIR-Anwendung: 

adt –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml myApp.html AIRAliases.js image.gif

Komprimieren aller Dateien und Unterverzeichnisse im aktuellen Arbeitsverzeichnis: 

adt –package -storetype pkcs12 -keystore ../cert.p12 myApp.air myApp.xml .
Hinweis: Die Keystore-Datei enthält den privaten Schlüssel, mit dem die Anwendung signiert wurde. Geben Sie das signierende Zertifikat niemals innerhalb des AIR-Pakets an! Wenn Sie Platzhalter im ADT-Befehl verwenden, speichern Sie die Keystore-Datei an einer anderen Adresse, sodass sie nicht in das Paket aufgenommen wird. In diesem Beispiel befindet sich die Keystore-Datei „cert.p12“ im übergeordneten Verzeichnis.

Komprimieren der Hauptdateien und eines images-Unterverzeichnisses: 

adt –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml myApp.swf images

Komprimieren einer HTML-basierten Anwendung und aller Dateien in den HTML-, scripts- und images-Unterverzeichnissen: 

adt –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml index.html AIRALiases.js html scripts images

Komprimieren der Datei „application.xml“ und der Haupt-SWF im Arbeitsverzeichnis (release/bin): 

adt –package -storetype pkcs12 -keystore cert.p12 myApp.air release/bin/myApp.xml –C release/bin myApp.swf

Komprimieren von Beständen von mehreren Speicheradressen in Ihrem Dateisystem. In diesem Beispiel befinden sich die Anwendungsbestände vor dem Komprimieren in den folgenden Ordnern: 

/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

Die Ausführung des folgenden ADT-Befehls vom Verzeichnis „/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

Führt zur folgenden Paketstruktur: 

/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

Führen Sie ADT als ein Java-Programm für eine einfache SWF-basierte Anwendung aus (ohne den Klassenpfad festzulegen): 

java –jar {AIRSDK}/lib/ADT.jar –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml myApp.swf

Führen Sie ADT als ein Java-Programm für eine einfache HTML-basierte Anwendung aus (ohne den Klassenpfad festzulegen): 

java –jar {AIRSDK}/lib/ADT.jar –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml myApp.html AIRAliases.js

Führen Sie ADT als Java-Programm aus (mit Java-Klassenpfadeinstellung, die das ADT.jar-Paket enthält): 

java -com.adobe.air.ADT –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml myApp.swf

Führen Sie ADT als Java-Task in Apache Ant aus (obwohl es normalerweise am besten ist, den ADT-Befehl direkt in Ant-Skripten zu verwenden). Die im Beispiel genannten Pfade gelten für 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>
Hinweis: Bei einigen Computersystemen können Doppel-Byte-Zeichen in den Dateisystempfaden falsch interpretiert werden. Versuchen Sie in diesem Fall, die zum Ausführen von ADT verwendete JRE so einzustellen, dass der UTF-8-Zeichensatz verwendet wird. Auf dem Mac und unter Linux erfolgt dies standardmäßig im Skript, mit dem ADT gestartet wird. In der Windows-adt.bat-Datei oder beim Ausführen von ADT direkt aus Java legen Sie die Option -Dfile.encoding=UTF-8 in der Java-Befehlszeile fest.