Per ciascuna applicazione AIR devono essere presenti, quanto meno, un file descrittore dell'applicazione e un file principale SWF o HTML. Tutte le altre risorse da installare con l'applicazione devono essere incluse nel pacchetto del file AIR.
Questo articolo descrive la creazione del pacchetto di un'applicazione AIR mediante i tool della riga di comando inclusi nel kit SDK. Per informazioni sulla creazione del pacchetto di un'applicazione mediante uno degli strumenti di authoring di Adobe, vedete:
Tutti i file di installazione di AIR devono essere firmati mediante un certificato digitale. Il programma di installazione di AIR utilizza la firma per verificare che il file dell'applicazione non sia stato alterato dal momento in cui è stato firmato. Potete usare un certificato per la firma del codice rilasciato da un'autorità di certificazione oppure un certificato autofirmato.
Utilizzando un certificato rilasciato da un'autorità di certificazione attendibile, offrite garanzie sulla vostra identità di editore agli utenti dell'applicazione. Nella finestra di dialogo di installazione viene segnalato il fatto che la vostra identità è stata verificata dall'autorità di certificazione:
Finestra di conferma dell'installazione per un'applicazione firmata con un certificato attendibile
Se utilizzate un certificato autofirmato, gli utenti non possono verificare la vostra identità di firmatario. Un certificato autofirmato, inoltre, offre minori garanzie che il pacchetto non sia stato alterato poiché un file di installazione legittimo potrebbe essere stato sostituito da uno contraffatto prima di raggiungere l'utente. Nella finestra di dialogo di installazione viene segnalato il fatto che non è possibile verificare l'identità dell'editore. Installando l'applicazione, gli utenti si assumono un rischio di sicurezza maggiore:
Finestra di conferma dell'installazione per un'applicazione firmata con un certificato autofirmato
Per creare un pacchetto e firmare un file AIR in un unico passaggio, è possibile utilizzare il comando
-package
di ADT. È inoltre possibile creare un pacchetto intermedio, non firmato, mediante il comando
-prepare
, quindi firmarlo mediante il comando
-sign
in un passaggio separato.
Nota:
le versioni Java dalla 1.5 in poi non accettano i caratteri high-ASCII nelle password utilizzate per proteggere i file di certificato PKCS12. Quando create o esportate il file del certificato per la firma del codice, utilizzate solo caratteri ASCII standard nella password.
Quando si appone la firma sul pacchetto di installazione, ADT contatta automaticamente il server di un'autorità di indicazione di data e ora per la verifica dell'ora. Le informazioni di indicazione di data e ora vengono incluse nel file AIR. Un file AIR che include un'indicazione di data e ora verificata può essere installato in qualsiasi momento. Se ADT non è in grado di connettersi al server di indicazione di data e ora, la creazione del pacchetto viene annullata. È possibile ignorare l'opzione di indicazione di data e ora, ma senza un indicatore di data e ora un'applicazione AIR non è più installabile dopo che il certificato utilizzato per la firma del file di installazione è scaduto.
Se create un pacchetto per aggiornare un'applicazione AIR esistente, il pacchetto deve essere firmato con lo stesso certificato dell'applicazione originale. Se il certificato originale è stato rinnovato o è scaduto negli ultimi 180 giorni, oppure desiderate passare a un nuovo certificato, potete applicare una firma di migrazione. La firma di migrazione prevede che il file dell'applicazione AIR venga firmato sia con il certificato nuovo che con quello vecchio. Utilizzate il comando
-migrate
per applicare la firma di migrazione, come descritto in
Comando ADT migrate
.
Importante:
dopo la scadenza del certificato originale è previsto un tassativo periodo di tolleranza di 180 giorni per l'applicazione della firma di migrazione. Senza una firma di migrazione, gli utenti esistenti devono disinstallare la versione corrente dell'applicazione prima di installare la nuova versione. Il periodo di tolleranza vale solo per le applicazioni nelle quali è specificato AIR 1.5.3 (o una versione successiva) nello spazio dei nomi del descrittore dell'applicazione. Per le versioni precedenti del runtime AIR non è previsto alcun periodo di tolleranza.
Prima di AIR 1.1, le firme di migrazione non erano supportate. Per applicare una firma di migrazione dovete creare il pacchetto dell'applicazione con SDK 1.1 o versione successiva.
Le applicazioni distribuite mediante file AIR sono dette applicazioni con profilo desktop. Non è possibile utilizzare ADT per creare il pacchetto di un programma di installazione nativo per un'applicazione AIR se il file descrittore dell'applicazione non supporta il profilo desktop. Potete assegnare una restrizione a questo profilo utilizzando l'elemento
supportedProfiles
nel file descrittore dell'applicazione. Vedete
Profili dispositivo
e
supportedProfiles
.
Nota:
le impostazioni nel file descrittore dell'applicazione determinano l'identità di un'applicazione AIR e il relativo percorso di installazione predefinito. Vedete
File descrittori delle applicazioni AIR
.
ID editore
A partire da AIR 1.5.3, gli ID editore sono stati dichiarati obsoleti. Per le nuove applicazioni (originariamente pubblicate con AIR 1.5.3 o successivo) l'ID editore non è necessario e non deve essere specificato.
Quando aggiornate le applicazioni pubblicate con versioni precedenti di AIR, dovete specificare l'ID editore originale nel file descrittore dell'applicazione. In caso contrario, la versione installata e la versione di aggiornamento dell'applicazione verranno gestite come applicazioni distinte. Se utilizzate un ID differente oppure omettete il tag publisherID, l'utente dovrà disinstallare la versione precedente prima di installare la nuova versione.
Per determinare l'ID editore originale, individuate il file
publisherid
nella sottodirectory META-INF/AIR in cui è installata l'applicazione originale. La stringa contenuta in questo file è l'ID editore. Per specificare manualmente l'ID editore, dovete specificare il runtime AIR 1.5.3 (o successivo) nella dichiarazione namespace del file descrittore dell'applicazione.
Per le applicazioni pubblicate prima di AIR 1.5.3 (o le applicazioni pubblicate con l'SDK di AIR 1.5.3 specificando una versione precedente di AIR nello spazio dei nomi del descrittore dell'applicazione) viene calcolato un ID editore sulla base del certificato di firma. Questo ID viene utilizzato insieme all'ID applicazione per determinare l'identità dell'applicazione. L'ID editore, se presente, viene utilizzato per i seguenti scopi:
-
Come indicazione del fatto che un file AIR è un aggiornamento e non una nuova applicazione da installare
-
Come parte della chiave di crittografia per l'archivio locale crittografato
-
Come parte del percorso della directory di archiviazione dell'applicazione
-
Come parte della stringa di connessione per le connessioni locali
-
Come parte della stringa di identità utilizzata per chiamare un'applicazione con l'API AIR interna al browser
-
Come parte dell'identificatore OSID (utilizzato per la creazione di programmi di installazione/disinstallazione personalizzati)
Prima di AIR 1.5.3, l'ID editore di un'applicazione poteva cambiare se un aggiornamento dell'applicazione veniva firmato con una firma di migrazione utilizzando un certificato nuovo o rinnovato. Quando un ID editore viene modificato, cambia anche il comportamento delle funzioni AIR associate all'ID. Ad esempio, non è più possibile accedere ai dati presenti nell'archivio locale crittografato, ed eventuali istanze Flash o AIR che creano una connessione locale all'applicazione devono usare il nuovo ID nella stringa di connessione.
In AIR 1.5.3 o successivo, l'ID editore non si basa sul certificato di firma e viene assegnato solo se il descrittore dell'applicazione include il tag publisherID. Non è possibile aggiornare un'applicazione se l'ID editore specificato per il pacchetto AIR di aggiornamento non corrisponde all'ID editore corrente dell'applicazione.
