Jede AIR-Anwendung muss mindestens eine Anwendungsdeskriptordatei und eine SWF- oder HTML-Hauptdatei enthalten. Alle anderen Elemente (Bestände), die mit der Anwendung installiert werden sollen, müssen ebenfalls in der AIR-Datei komprimiert werden.
In diesem Abschnitt wird das Komprimieren (Verpacken) einer AIR-Anwendung mit den im SDK enthaltenen Befehlszeilenwerkzeugen beschrieben. Informationen zum Komprimieren einer Anwendung mit einem der Authoringwerkzeuge von Adobe finden Sie hier:
Alle AIR-Installationsdateien müssen mit einem digitalen Zertifikat signiert sein. Das Installationsprogramm von AIR verwendet diese Unterschriften, um sicherzustellen, dass die Datei seit Unterzeichnung nicht mehr verändert wurde. Sie können ein Codesignaturzertifikat von einer Zertifizierungsstelle oder ein selbst signiertes Zertifikat verwenden.
Indem Sie ein von einer vertrauenswürdigen Zertifizierungsstelle ausgestelltes Zertifikat verwenden, vermitteln Sie Ihren Benutzern Vertrauen in Ihre Identität als Herausgeber. Das Installationsdialogfeld bestätigt, dass Ihre Identität von der Zertifizierungsstelle überprüft wurde:
Bestätigungsdialogfeld bei der Installation einer mit einem vertrauenswürdigen Zertifikat signierten Anwendung
Wenn Sie ein selbst signiertes Zertifikat verwenden, können Benutzer Ihre Identität als Unterzeichner nicht überprüfen. Ein selbst signiertes Zertifikat schwächt auch die Versicherung, dass das Paket nicht verändert wurde. (Dies liegt daran, dass eine gültige Installationsdatei durch eine Fälschung ersetzt worden sein könnte, bevor der Benutzer sie erhält.) Das Installationsdialogfeld lässt erkennen, dass die Identität des Ausstellers nicht verifiziert werden kann. Benutzer gehen ein größeres Sicherheitsrisiko ein, wenn sie Ihre Anwendung installieren:
Bestätigungsdialogfeld bei der Installation einer mit einem selbst signierten Zertifikat signierten Anwendung
Mit dem ADT-Befehl
-package
können Sie eine AIR-Datei mit einem einzigen Schritt komprimieren und signieren. Sie können auch in einem Zwischenschritt ein nicht signiertes Paket mit dem Befehl
-prepare
erstellen und dieses in einem weiteren Schritt mit dem Befehl
-sign
signieren.
Hinweis:
In den Java-Versionen 1.5 und höher werden hohe ASCII-Zeichen für Kennwörter, die PKCS12-Zertifikatdateien schützen, nicht akzeptiert. Wenn Sie Ihre Codesignaturzertifikatdatei erstellen oder exportieren, verwenden Sie nur reguläre ASCII-Zeichen für das Kennwort.
Wenn Sie das Installationspaket signieren, kontaktiert ADT automatisch den Zeitstempelserver, um die Zeit zu überprüfen. Die Zeitstempelinformationen werden in die AIR-Datei aufgenommen. Eine AIR-Datei, die einen verifizierten Zeitstempel enthält, kann zu einem beliebigen späteren Zeitpunkt installiert werden. Kann ADT die Verbindung zum Zeitstempelserver nicht herstellen, wird die Komprimierung abgebrochen. Sie können sich über die Zeitstempeloption hinwegsetzen, ohne Zeitstempel sind AIR-Anwendungen jedoch nicht mehr installierbar, wenn das Zertifikat, mit dem die Installationsdatei signiert wurde, abgelaufen ist.
Wenn Sie ein Paket erstellen, um eine vorhandene AIR-Anwendung zu aktualisieren, muss das Paket mit demselben Zertifikat signiert sein wie die Originalanwendung. Wenn das Originalzertifikat in den letzten 180 Tagen erneuert wurde oder abgelaufen ist, oder wenn Sie ein anderes Zertifikat verwenden möchten, können Sie eine Migrationssignatur anwenden. Eine Migrationssignatur beinhaltet das Signieren der Anwendungs-AIR-Datei mit dem neuen und mit dem alten Zertifikat. Verwenden Sie den
-migrate
-Befehl, um die Migrationssignatur anzuwenden wie unter
ADT-Befehl „migrate“
beschrieben.
Wichtig:
Es gibt einen Toleranzzeitraum von 180 Tagen ab Ablaufdatum des Originalzertifikats für die Anwendung einer Migrationssignatur. Ohne Migrationssignatur müssen vorhandene Benutzer ihre vorhandene Anwendung deinstallieren, bevor Sie die neue Version installieren. Der Toleranzzeitraum von Tagen gilt nur für Anwendungen, die AIR Version 1.5.3 oder höher im Namespace des Anwendungsdeskriptors angeben. Wenn das Ziel eine ältere Version der AIR-Laufzeitumgebung ist, gibt es keinen Toleranzzeitraum.
Vor AIR 1.1 wurden keine Migrationssignaturen unterstützt. Sie müssen eine Anwendung mit einem SDK der Version 1.1 oder höher komprimieren, um eine Migrationssignatur anzuwenden.
Anwendungen, die über AIR-Dateien bereitgestellt werden, werden als Desktopprofil-Anwendungen bezeichnet. Sie können ADT nicht verwenden, um ein natives Installationsprogramm für eine AIR-Anwendung zu verpacken, wenn die Anwendungsdeskriptordatei das Desktopprofil nicht unterstützt. Sie können dieses Profil mithilfe des
supportedProfiles
-Element in der Anwendungsdeskriptordatei beschränken. Siehe
Geräteprofile
und
supportedProfiles
.
Hinweis:
Die Einstellungen in der Anwendungsdeskriptordatei legen die Identität einer AIR-Anwendung sowie den Standardinstallationspfad fest. Siehe
AIR-Anwendungsdeskriptordateien
.
Herausgeber-IDs
Ab AIR 1.5.3 sind Herausgeber-IDs veraltet. Neue Anwendungen (mit AIR 1.5.3 oder höher veröffentlicht) brauchen keine Herausgeber-ID und sollten diese auch nicht angeben.
Beim Aktualisieren von Anwendungen, die mit früheren AIR-Versionen veröffentlicht wurden, müssen Sie die ursprüngliche Herausgeber-ID in der Anwendungsdeskriptordatei angeben. Andernfalls werden die installierte Version der Anwendung und die Updateversion als unterschiedliche Anwendungen behandelt. Wenn Sie eine andere ID verwenden oder das publisherID-Tag auslassen, muss ein Benutzer die ältere Version deinstallieren, bevor er die neue Version installieren kann.
Um die Originalherausgeber-ID zu ermitteln, suchen Sie die Datei
publisherid
im Unterverzeichnis META-INF/AIR, in dem die Originalanwendung installiert ist. Der String in dieser Datei ist die Herausgeber-ID. Der Anwendungsdeskriptor muss die AIR 1.5.3-Laufzeitumgebung (oder neuer) in der Namespacedeklaration der Anwendungsdeskriptordatei angeben, damit die Herausgeber-ID manuell spezifiziert werden kann.
Für Anwendungen, die vor AIR 1.5.3 veröffentlicht wurden – oder die mit dem AIR 1.5.3 SDK entwickelt wurden, während im Anwendungsdeskriptor-Namespace eine ältere Version angegeben wurde – wird eine Hersteller-ID basierend auf dem Signaturzertifikat berechnet. Diese ID wird zusammen mit der Anwendungs-ID verwendet, um die Identität einer Anwendung zu bestimmen. Die Herausgeber-ID, sofern vorhanden, wird für die folgenden Zwecke verwendet:
-
Überprüfen, ob eine AIR-Datei eine Update und keine neu zu installierende Anwendung ist
-
Als Teil des Verschlüsselungsschlüssels für den verschlüsselten lokalen Speicher
-
Als Teils des Pfads für das Anwendungsspeicherverzeichnis
-
Als Teil des Verbindungsstrings für lokale Verbindungen
-
Als Teil des Kennungsstrings, der zum Aufrufen einer Anwendung mit der AIR „in browser“-API verwendet wird
-
Als Teil der OSID (verwendet beim Erstellen von benutzerdefinierten Installations-/Deinstallationsprogrammen)
Vor AIR 1.5.3 konnte sich die Herausgeber-ID einer Anwendung ändern, wenn Sie ein Anwendungsupdate mit einer Migrationssignatur signierten, die ein neues oder verlängertes Zertifikat verwendete. Wenn eine Herausgeber-ID geändert wird, ändert sich auch das Verhalten aller AIR-Funktionen, die mit der ID arbeiten. Daten im bestehenden verschlüsselten lokalen Speicher sind zum Beispiel nicht mehr zugänglich und alle Flash- oder AIR-Instanzen, die eine lokale Verbindung zur Anwendung herstellen, müssen die neue ID im Verbindungsstring verwenden.
In AIR 1.5.3 oder höher basiert die Herausgeber-ID nicht auf dem Signaturzertifikat und wird nur zugewiesen, wenn das publisherID-Tag in der Anwendungsdeskriptordatei enthalten ist. Eine Anwendung kann nicht aktualisiert werden, wenn die Herausgeber-ID, die für das Update-AIR-Paket angegeben wurde, nicht mit der aktuellen Herausgeber-ID übereinstimmt.
