Elke AIR-toepassing moet minimaal een descriptorbestand van de toepassing en een SWF- of HTML-hoofdbestand bevatten. Eventuele overige elementen die bij de toepassing geïnstalleerd moeten worden moeten ook in het AIR-bestand worden verpakt.
In dit artikel wordt het verpakken van een AIR-toepassing met gebruik van de opdrachtsregelhulpmiddelen binnen de SDK besproken. Zie voor informatie over het verpakken van een toepassing met een van de ontwerpgereedschappen van Adobe de volgende pagina's:
Alle AIR-installatiebestanden moeten zijn ondertekend met een digitaal certificaat. Het AIR-installatieprogramma gebruikt de handtekening om te verifiëren of uw toepassingsbestand niet is gewijzigd sinds u het hebt ondertekend. U kunt een certificaat voor ondertekening van programmacode van een certificeringsinstantie of een zelfondertekend certificaat gebruiken.
Wanneer u een certificaat gebruikt dat door een vertrouwde certificeringsinstantie is uitgegeven, hebben gebruikers van uw toepassing enige garantie dat u de uitgever bent. Het installatiedialoogvenster geeft aan dat uw identiteit is gecontroleerd door de certificeringsinstantie:
Installatiedialoogvenster voor bevestiging voor toepassing die met een vertrouwd certificaat is ondertekend
Wanneer u een zelfondertekend certificaat gebruikt, kunnen gebruikers uw identiteit als ondertekenaar niet controleren. Een zelfondertekend certificaat vermindert ook de zekerheid dat het pakket ongewijzigd is. (De reden hiervoor is dat een geldig installatieprogramma vervangen zou kunnen zijn door een vervalsing voordat het de gebruiker bereikt.) Het installatiedialoogvenster weerspiegelt het feit dat de identiteit van de uitgever niet kan worden gecontroleerd. Gebruikers nemen een groter beveiligingsrisico wanneer zij uw toepassing installeren:
Installatiedialoogvenster voor bevestiging voor toepassing die met een zelfondertekend certificaat is ondertekend
U kunt een AIR-bestand in één stap in een pakket plaatsen en ondertekenen met de ADT-opdracht
-package
. U kunt ook een tussentijds, niet-ondertekend pakket maken met de opdracht
-prepare
en het tussentijdse pakket in een afzonderlijke stap ondertekenen met de opdracht
-sign
.
Opmerking:
bij Java versie 1.5 en later worden hoge ASCII-tekens in wachtwoorden voor de beveiliging van PKCS12-certificatiebestanden niet geaccepteerd. Wanneer u uw code maakt of exporteert en ondertekent met een certificaatbestand, kunt u alleen gewone ASCII-tekens in het wachtwoord gebruiken.
Bij het ondertekenen van het installatiepakket neemt ADT automatisch contact op met een tijdstempelserver om de tijd te verifiëren. De tijdstempelinformatie wordt opgenomen in het AIR-bestand. Een AIR-bestand dat een geverifieerd tijdstempel bevat, kan op een willekeurig moment in de toekomst worden geïnstalleerd. Als ADT geen verbinding kan maken met de tijdstempelserver, wordt het maken van het pakket geannuleerd. U kunt de tijdstempeloptie uitschakelen, maar zonder tijdstempel kan een AIR-toepassing niet worden geïnstalleerd nadat het certificaat is verlopen waarmee het installatiebestand is ondertekend.
Als u een pakket maakt om een bestaande AIR-toepassing bij te werken, moet het pakket worden ondertekend met hetzelfde certificaat als de oorspronkelijke toepassing. Als het oorspronkelijke certificaat is vernieuwd of minder dan 180 dagen geleden is verlopen, of als u wilt overstappen op een nieuw certificaat, kunt u een migratiehandtekening toepassen. Een migratiehandtekening houdt in dat het AIR-toepassingsbestand wordt ondertekend met zowel het oude als het nieuwe certificaat. Gebruik de opdracht
-migrate
om de migratiehandtekening toe te passen, zoals beschrijven in
ADT-opdracht voor migreren
.
Belangrijk:
een migratiehandtekening kan alleen binnen 180 dagen nadat het oorspronkelijke certificaat verloopt worden toegepast. Zonder migratiehandtekening moeten bestaande gebruikers de bestaande versie verwijderen voordat de nieuwe versie geïnstalleerd kan worden. De periode van 180 dagen geldt alleen voor toepassingen waarbij AIR versie 1.5.3. of hoger is opgegeven in de naamruimte van de het descriptorbestand van de toepassing. Bij oudere versies van de AIR-runtime geldt deze beperking niet.
Migratiehandtekeningen worden pas vanaf AIR 1.1 ondersteund. U kunt alleen een migratiehandtekening toepassen op toepassingen die met SDK versie 1.1 of hoger zijn verpakt.
Toepassingen die zijn geïmplementeerd met AIR-bestanden zijn toepassingen van het profiel Desktop. ADT kan niet worden gebruikt om een eigen installatieprogramma voor een AIR-toepassing te verpakken als het descriptorbestand van de toepassing het profiel Desktop niet ondersteunt. U kunt dit profiel beperken met het element
supportedProfiles
in het toepassingsdescriptorbestand. Zie
Apparaatprofielen
en
supportedProfiles
.
Opmerking:
de identiteit en het standaardinstallatiepad van een AIR-toepassing worden bepaald door de instellingen in het toepassingsdescriptorbestand. Zie
AIR-toepassingsdescriptorbestanden
.
Uitgevers-id's
Vanaf AIR 1.5.3 worden uitgevers-id's niet meer gebruikt. Voor nieuwe toepassingen (die aanvankelijk met AIR 1.5.3 of hoger zijn gepubliceerd) hoeft en moet geen uitgevers-id worden opgegeven.
Wanneer u toepassingen bijwerkt die oorspronkelijk met oudere versies van AIR zijn gepubliceerd, moet u de oorspronkelijke uitgevers-id opgeven in het descriptorbestand van de toepassing. Als u dat niet doet, worden de geïnstalleerde versie van de toepassing en de bijgewerkte versie als verschillende toepassingen beschouwd. Als u een andere id gebruikt of de tag voor de uitgevers-id weglaat, moet een gebruiker de oudere versie verwijderen voordat de nieuwe versie geïnstalleerd kan worden.
Als u de oorspronkelijke gebruikers-id wilt bepalen, moet u zoeken naar het bestand
publisherid
in de submap META-INF/AIR waar de oorspronkelijke toepassing is geïnstalleerd. De uitgevers-id wordt aangegeven door de tekenreeks in dit bestand. Als u de uitgevers-id handmatig wilt kunnen opgeven, moet versie 1.5.3 (of hoger) van de AIR-runtime worden opgeven in de naamruimtedeclaratie van het descriptorbestand van de toepassing.
Voor toepassingen die zijn gepubliceerd vóór AIR 1.5.3, of die zijn gepubliceerd met de SDK van AIR 1.5.3 en waarvoor een oudere versie van AIR is opgegeven in de naamruimte van het descriptorbestand van de toepassing, wordt een uitgevers-id berekend op basis van het handtekeningcertificaat. Deze id wordt tezamen met de toepassings-id gebruikt om de identiteit van een toepassing te bepalen. Indien aanwezig wordt de uitgevers-id gebruikt voor de volgende doeleinden:
-
Controleren of een AIR-bestand een update is en geen nieuwe toepassing
-
Als onderdeel van de coderingssleutel voor de gecodeerde lokale opslagruimte
-
Als onderdeel van het pad voor de opslagmap van de toepassing
-
Als onderdeel van de verbindingstekenreeks voor lokale verbindingen
-
Als onderdeel van de identiteitstekenreeks waarmee een toepassing wordt aangeroepen met de AIR in-browser API
-
Als onderdeel van de OSID (gebruikt bij het maken van aangepaste programma's voor het installeren/verwijderen van software)
Vóór AIR 1.5.3 kon de uitgevers-id van een toepassing veranderen als een toepassingsupdate met een nieuw of vernieuwd certificaat werd voorzien van een migratiehandtekening. Wanneer u een uitgevers-id wijzigt, wordt ook het gedrag gewijzigd van de AIR-functies die afhankelijk zijn van de id. Zo zijn de gegevens in de bestaande gecodeerde lokale opslagruimte niet meer toegankelijk en moeten alle Flash- of AIR-instanties die een lokale verbinding maken met de toepassing ook gebruikmaken van de nieuwe id in de verbindingstekenreeks.
In AIR 1.5.3 of hoger is de uitgevers-id niet gebaseerd op het handtekeningcertificaat en wordt deze alleen toegewezen als de tag publisherID in het descriptorbestand van de toepassing is opgenomen. Een toepassing kan alleen worden bijgewerkt als de uitgevers-id die is opgegeven voor het AIR-pakket met de update overeenkomt met de huidige uitgevers-id.
