Cada aplicativo do AIR deve, no mínimo, possuir um arquivo do descritor do aplicativo e um arquivo principal do SWF ou HTML. Quaisquer outros ativos a instalar com o aplicativo devem ser também empacotados no arquivo AIR.
Este artigo descreve como compactar um aplicativo do AIR usando as ferramentas de linha de comando incluídas com o SDK. Para obter informações sobre como compactar um aplicativo usando uma das ferramentas de criação da Adobe, consulte o seguinte:
Todos os arquivos do instalador do AIR devem ser assinados usando um certificado digital. O instalador do AIR usa a assinatura para verificar que seu arquivo de aplicativo não foi alterado desde que você o assinou. Você pode usar um certificado de assinatura de código de uma autoridade de certificação ou um certificado autoassinado.
Quando você usa um certificado emitido por uma autoridade de certificação confiável fornece aos usuários do seu aplicativo alguma garantia da sua identidade como editor. A caixa de diálogo da instalação reflete o fato de que sua identidade é verificada pela autoridade de certificação:
Caixa de diálogo da confirmação da instalação assinada por certificado confiável
Quando você usa um certificado autoassinado, os usuários não podem verificar sua identidade como signatário Um certificado autoassinado também enfraquece a garantia de que o pacote não foi alterado. (Isto ocorre porque um arquivo de instalação legítimo pode ter sido substituído por uma falsificação antes de chegar ao usuário.) A caixa de diálogo da instalação reflete o fato de que a identidade do publicador não pode ser verificada. Os usuários assumem um risco de segurança maior quando instalam o seu aplicativo.
Exibir gráfico inteiro
A caixa de diálogo da confirmação da instalação do aplicativo, assinada por certificado autoassinado.
Você pode empacotar e assinar um arquivo AIR em uma única etapa usando o comando
-package
do ADT. Você também pode criar um pacote intermediário, não assinado com o comando
-prepare
e assinar o pacote intermediário com o comando
-sign
em uma etapa separada.
Nota:
Versões do Java 1.5 e acima não aceitam caracteres ASCII superiores nas senhas usadas para proteger arquivos de certificado PKCS12. Ao criar ou exportar seu código assinando um arquivo de certificado, use apenas caracteres ASCII comuns na senha.
Ao assinar o pacote de instalação, o ADT automaticamente entra em contato com um servidor de autoridade com carimbo de data/hora para verificar a hora. As informações de carimbo de data/hora estão incluídas no arquivo AIR. Um arquivo AIR que inclui um carimbo de data/hora verificado pode ser instalado em qualquer momento do futuro. Se o ADT não puder se conectar ao servidor de carimbo de data/hora, o empacotamento será cancelado. Você pode substituir a opção de carimbo de data/hora, mas sem um carimbo de data/hora, um aplicativo do AIR deixa de poder ser instalado após o certificado usado para assinar o arquivo de instalação expirar.
Se você estiver criando um pacote para atualizar um aplicativo do AIR existente, o pacote deverá ser assinado com o mesmo certificado do aplicativo original. Se o certificado original foi renovado ou expirou nos últimos 180 dias ou se você quiser mudar para um novo certificado, poderá aplicar uma assinatura de migração. Uma assinatura de migração envolve a assinatura do arquivo AIR do aplicativo tanto com o certificado novo quanto com o antigo. Use o comando
-migrate
para aplicar a assinatura de migração como descrito em
Comando migrate do ADT
.
Importante:
É dado um período de graça improrrogável de 180 dias para solicitar a assinatura de migração depois da expiração do certificado original. Sem uma assinatura de migração, os usuários existentes deverão instalar seus aplicativos existentes antes de instalar a nova versão do desenvolvedor. O período de graça abrange somente aplicativos que especificam o AIR versão 1.5.3 ou superior no namespace de descrição do aplicativo. Não existe período de graça destinado a versões do runtime do AIR.
Antes do AIR 1.1, as assinaturas de migração não eram suportadas. Você deve fazer um pacote que englobe um aplicativo e um SDK da versão 1.1 ou superior para solicitar uma assinatura de migração.
As aplicações implementadas com arquivos AIR são conhecidas como aplicações de perfil de desktop. Você não poderá usar ADT para empacotar um programa de instalação nativo para um aplicativo do AIR se o arquivo de descrição do aplicativo não suportar o perfil de desktop. Você pode restringir este perfil usando o elemento
supportedProfiles
no arquivo de descrição do aplicativo. Consulte
Perfis de dispositivo
e
supportedProfiles
.
IDs do publicador
Como no AIR 1.5.3, os IDs de publicador são deprecados. Os novos aplicativos (originalmente publicados com o AIR 1.5.3 ou superior) não precisam e não devem especificar um ID de publicador.
Ao atualizar os aplicativos publicados com versões mais antigas do AIR, você deve especificar o ID do publicador original no arquivo de descrição do aplicativo. Do contrário, a versão instalada do seu aplicativo e a versão atualizada serão tratados como aplicativos diferentes. Se você usar um ID diferente ou omitir a marca publisherID, um usuário deverá desinstalar a versão antiga antes de instalar a versão nova.
Para descobrir o ID do editor original, localize o arquivo
publisherid
no subdiretório META-INF/AIR onde o aplicativo original está instalado. A sequência de caracteres no arquivo é o ID do editor. O descritor o aplicativo deve especificar o runtime AIR 1.5.3 (ou posterior) na declaração de espaço de nome do arquivo descritor do aplicativo para especificar o ID do editor manualmente.
Para aplicativos antes do AIR 1.5.3 — ou que são publicados com o SDK AIR 1.5.3, enquanto especificam um versão mais antiga do AIR no namespace de descrição do aplicativo — um ID de publicador é computado com base no certificado de assinatura. Este ID é usado com o ID do aplicativo para determinar a identidade de um aplicativo. O ID do editor, quando existir, é utilizado para os seguintes fins:
-
Como verificar se um arquivo AIR é uma atualização em vez de um novo aplicativo a ser instalado
-
Como parte da chave de criptografia o armazenamento local criptografado
-
Como parte o caminho para o diretório de armazenamento do aplicativo
-
Como parte da sequência de caracteres de conexão para conexões locais
-
Como parte da sequência de caracteres de identidade utilizada para chamar o aplicativo com a API interna de navegador AIR
-
Como parte o OSID (utilizado na criação de programas personalizados de instalação/desinstalação)
Antes do AIR 1.5.3, o ID de publicador de um aplicativo podia ser alterado se você assinasse uma atualização do aplicativo com uma assinatura de migração que usasse um certificado novo ou renovado. Quando um ID de editor muda, o comportamento de qualquer recurso AIR dependente do ID também muda. Por exemplo, os dados existentes no armazenamento local criptografado não podem mais ser acessados e qualquer instância do Flash ou AIR que cria uma conexão local para o aplicativo deve utilizar o novo ID na sequência de caracteres de conexão.
NO AIR 1.5.3 ou superior, o ID de publicador não se baseia no certificado de assinatura, mas é atribuído exclusivamente quando a marca publisherID é incluída na descrição do aplicativo. Um aplicativo não poderá ser atualizado se o ID de publicador especificado para o pacote AIR atualizado não corresponder ao ID de publicador atual.
