Cada aplicación de AIR debe incluir, como mínimo, un archivo descriptor de la aplicación y un archivo SWF o HTML principal. Cualquier otro recurso que se vaya a instalar con la aplicación se debe empaquetar también en el archivo de AIR.
En este artículo se analiza el empaquetado de una aplicación de AIR utilizando las herramientas de la línea de comandos incluidas con el SDK. Para obtener información sobre el empaquetado de una aplicación mediante una de las herramientas de edición de Adobe, consulte la siguiente referencia:
Todos los archivos instaladores de AIR deben firmarse con un certificado digital. El instalador de AIR utiliza la firma para verificar que el archivo de la aplicación no ha sido modificado desde que se firmó. Puede utilizar un certificado de firma de código de una entidad emisora de certificados o un certificado con firma automática.
Cuando se utiliza un certificado emitido por una autoridad de certificación de confianza, se ofrece a los usuarios de la aplicación cierta seguridad respecto de su identidad como editor de la aplicación. El cuadro de diálogo de instalación refleja el hecho de que su identidad se verifica mediante la entidad emisora de certificados:
Cuadro de diálogo de confirmación de instalación firmado por un certificado de confianza
Cuando se utiliza un certificado con firma automática, los usuarios no pueden verificar su identidad como firmante. Un certificado con firma automática también debilita la garantía de que el paquete no se haya modificado. (Esto se debe a que un archivo de instalación de confianza se puede sustituir por una falsificación antes de que llegue al usuario.) El cuadro de diálogo de instalación refleja que la identidad del editor no puede comprobarse. Los usuarios están arriesgando más su seguridad cuando instalan la aplicación:
Cuadro de diálogo de confirmación de instalación firmado por un certificado con firma automática
Se puede empaquetar y firmar un archivo de AIR en un solo paso con el comando
-package
de ADT. También se puede crear un paquete intermedio sin firmar con el comando
-prepare
, firmando después el paquete intermedio con el comando
-sign
en un paso separado.
Nota:
las versiones de Java 1.5 y posteriores no aceptan caracteres ASCII superior en contraseñas utilizadas para proteger archivos de certificado PKCS12. Cuando se cree o se exporte el archivo de certificado de firma de código, utilice solamente caracteres ASCII normales en la contraseña.
Al firmar el paquete de instalación, ADT se pone en contacto automáticamente con el servidor de una autoridad de marcas de hora para verificar la hora. La marca de hora se incluye en el archivo de AIR. Un archivo de AIR que incluya una marca de hora verificada podrá instalarse en el futuro en cualquier momento. Si ADT no puede conectarse al servidor de marcas de hora, se cancela el empaquetado. La opción de marca de hora puede pasarse por alto, pero sin marca de hora la aplicación de AIR ya no podrá instalarse una vez caducado el certificado que se utilizó para firmar el archivo de instalación.
Si se está creando un paquete para actualizar una aplicación de AIR existente, el paquete se debe firmar con el mismo certificado que la aplicación original. Si el certificado original se ha renovado o ha caducado en los últimos 180 días, o bien, si se desea cambiar a un nuevo certificado, se puede aplicar una firma de migración. La firma de migración implica firmar el archivo de AIR de la aplicación tanto con el nuevo como con el antiguo certificado. Utilice el comando
-migrate
para aplicar la firma de migración tal y como se describe en
Comando migrate de ADT
.
Importante:
existe un estricto periodo de gracia de 180 días para aplicar una firma de migración una vez caducado el certificado original. Sin la firma de migración, los usuarios existentes deben desinstalar su aplicación existente antes de instalar la nueva versión. El periodo de gracia de días solo se aplica a las aplicaciones que especifican la versión de AIR 1.5.3, o superior, en el espacio de nombres del descriptor de la aplicación. No hay periodo de gracia cuando se utilizan versiones anteriores del motor de ejecución de AIR.
Antes de AIR 1.1, no se admitían las firmas de migración. La aplicación se debe empaquetar con un SDK de versión 1.1 o posterior para aplicar una firma de migración.
Las aplicaciones implementadas utilizando archivos de AIR se denominan aplicaciones de perfil de escritorio. No es posible utilizar ADT para empaquetar un instalador nativo para una aplicación de AIR si el archivo descriptor de la aplicación no admite el perfil de escritorio. Este perfil se puede restringir utilizando el elemento
supportedProfiles
en el archivo descriptor de la aplicación. Consulte
Perfiles de dispositivo
y
supportedProfiles
.
ID de editor
A partir de AIR 1.5.3, los de editor quedan desfasados. Las nuevas aplicaciones (publicadas en un principio con AIR 1.5.3 o superior) no necesitan ni deben especificar un ID de editor.
Al actualizar las aplicaciones publicadas con versiones anteriores de AIR, se debe especificar el ID de editor original en el archivo descriptor de la aplicación. De lo contrario, la versión instalada de la aplicación y la versión de actualización se tratan como aplicaciones diferentes. Si se utiliza un ID distinto o se omite la etiqueta publisherID, un usuario debe desinstalar la versión anterior antes de instalar la nueva.
Para determinar el ID de editor original, localice el archivo
publisherid
en el subdirectorio META-INF/AIR donde se instaló la aplicación original. La cadena de este archivo es el ID de editor. El descriptor de la aplicación debe especificar el motor de ejecución de AIR 1.5.3 (o posterior) en la declaración del espacio de nombres del archivo descriptor de la aplicación con el fin de especificar el ID de editor manualmente.
Para las aplicaciones publicadas antes de AIR 1.5.3, o que se publican con el SDK de AIR 1.5.3, al especificar una versión anterior de AIR en el espacio de nombres del descriptor de la aplicación, se calcula un ID de editor en función del certificado de firma. Este ID se utiliza, junto con el ID de la aplicación, para determinar la identidad de una aplicación. El ID de editor, cuando se encuentra presente, se emplea para lo siguiente:
-
Comprobar que un archivo de AIR es una actualización en lugar de una nueva aplicación para instalar.
-
Como parte de la clave de cifrado para el almacén local cifrado.
-
Como parte de la ruta para el directorio de almacenamiento de la aplicación.
-
Como parte de la cadena de conexión para conexiones locales.
-
Como parte de la cadena de identidad utilizada para invocar una aplicación la API en navegador de AIR.
-
Como parte de OSID (utilizado al crear programas personalizados de instalación y desinstalación).
Antes de AIR 1.5.3, el ID de editor de una aplicación podía cambiar si se firmaba una actualización de la aplicación con una firma de migración utilizando un certificado nuevo o renovado. Cuando cambia un ID de editor, el comportamiento de cualquier función de AIR basada en el ID también cambia. Por ejemplo, ya no se puede acceder a los datos del almacén local cifrado existente y cualquier instancia de Flash o AIR que cree una conexión local con la aplicación debe utilizar el nuevo ID en la cadena de conexión.
En AIR 1.5.3 o posterior, el ID de editor no se basa en el certificado de firma y solo se asigna si la etiqueta publisherID se incluye en el descriptor de la aplicación. Una aplicación no puede actualizarse si el ID de editor especificado para el paquete de AIR de actualización no coincide con su ID de editor actual.
