Comando package do ADT

O comando -package deve ser executado do diretório principal do aplicativo. O comando usa as seguintes sintaxes:

Crie um pacote do AIR a partir dos arquivos de aplicativo do componente: 

adt -package 
    AIR_SIGNING_OPTIONS 
    -target packageType 
    -sampler 
    ‑hideAneLibSymbols 
    NATIVE_SIGNING_OPTIONS 
    output 
    app_descriptor 
    FILE_OPTIONS

Crie um pacote nativo a partir de arquivos do aplicativo do componente: 

adt -package 
    AIR_SIGNING_OPTIONS 
    -target packageType 
    DEBUGGER_CONNECTION_OPTIONS 
    -airDownloadURL URL 
    NATIVE_SIGNING_OPTIONS 
    output 
    app_descriptor 
    -platformsdk path 
    FILE_OPTIONS

Crie um pacote nativo que inclua uma extensão nativa dos arquivos componentes do aplicativo: 

adt -package 
    AIR_SIGNING_OPTIONS 
    -migrate MIGRATION_SIGNING_OPTIONS 
    -target packageType 
    DEBUGGER_CONNECTION_OPTIONS 
    -airDownloadURL URL 
    NATIVE_SIGNING_OPTIONS 
    output 
    app_descriptor 
    -platformsdk path 
    FILE_OPTIONS

Crie um pacote nativo de um arquivo AIR ou AIRI: 

adt -package 
    -target packageType 
    NATIVE_SIGNING_OPTIONS 
    output 
    input_package

Crie um pacote de extensão nativa dos arquivos de extensão nativa do componente: 

adt -package 
    AIR_SIGNING_OPTIONS     
    -target ane 
    output 
    ANE_OPTIONS
Nota: Não é necessário assinar um arquivo ANE, pois os parâmetros AIR_SIGNING_OPTIONS são opcionais neste exemplo.

AIR_SIGNING_OPTIONS As opções de assinatura do AIR identificam o certificado usado para assinar um arquivo de instalação do AIR. As opções de assinatura são totalmente descritas em Opções de assinatura de código ADT .

-migrate Este sinalizador especifica que o aplicativo é assinado com um certificado de migração, além do certificado especificado nos parâmetros AIR_SIGNING_OPTIONS . Este sinalizador é válido apenas se você estiver empacotando um aplicativo de desktop como um instalador nativo e o aplicativo usar uma extensão nativa. Em outros casos ocorre um erro. As opções de assinatura para o certificado de migração são especificados como os parâmetros MIGRATION_SIGNING_OPTIONS . Essas opções de assinatura são descritas por completo nas Opções de assinatura de código ADT . Usar o sinalizador -migrate permite que você crie uma atualização para um instalador de aplicativo de desktop nativo que use uma extensão nativa e altera o código do certificado de assinatura do aplicativo, como quando expira o certificado original. Para obter mais informações, consulte Assinatura de uma versão atualizada de um aplicativo do AIR .

O sinalizador -migrate do comando -package está disponível no AIR 3.6 e posterior.

-target O tipo de pacote a ser criado. Os tipos de pacotes disponíveis são:

  • air — um pacote do AIR. “air” é o valor padrão e o sinalizador -target não precisa ser especificado ao criar arquivos do AIR ou AIRI.

  • airn — um pacote de aplicativo nativo para dispositivos no perfil televisão estendida.

  • ane —um pacote de extensão nativa do AIR

  • Destinos dos pacotes Android:

    • apk — um pacote do Android. Um pacote produzido com este destino só pode ser instalado em um dispositivo Android e não em um emulador.

    • apk-captive‑runtime — um pacote Android que inclui a versão aplicativo e uma versão cativa do AIR runtime. Um pacote produzido com este destino só pode ser instalado em um dispositivo Android e não em um emulador.

    • apk-debug — um pacote do Android com informações extras de depuração. (Os arquivos SWF no aplicativo também devem ser compilados com o suporte de depuração.)

    • apk-emulator — um pacote do Android para o uso em um emulador sem suporte de depuração. (Use o destino apk-debug para permitir a depuração dos emuladores e dos dispositivos.)

    • apk-profile — um pacote Android disponível para desempenho do aplicativo e determinação de perfis da memória.

  • Destinos dos pacotes iOS:

    • ipa-ad-hoc — um pacote do iOS para distribuição ad hoc.

    • ipa-app-store — um pacote do iOS para distribuição à App Store da Apple

    • ipa-debug — um pacote do Android com informações extras de depuração. (Os arquivos SWF no aplicativo também devem ser compilados com o suporte de depuração.)

    • ipa-test — um pacote de IOS compilado sem otimização ou informações de depuração.

    • ipa-debug-interpreter — funcionalmente igual a um pacote de depuração, mas compila mais rapidamente. No entanto, o ActionScript bytecode é interpretado e não convertido para código de máquina. Como resultado, a execução do código é mais lenta num pacote do intérprete.

    • ipa-debug-interpreter-simulator — de funcionalidade equivalente ao ipa-debug-interpreter, mas empacotado para o simulador iOS. Somente Macintosh. Se você usar esta opção, poderá incluir também a opção -platformsdk, especificando o caminho para o SDK do simulador iOS.

    • ipa-debug-interpreter — funcionalmente igual a um pacote de teste, mas compila mais rapidamente. No entanto, o ActionScript bytecode é interpretado e não convertido para código de máquina. Como resultado, a execução do código é mais lenta num pacote do intérprete.

    • ipa-test-interpreter-simulator — de funcionalidade equivalente ao ipa-test-interpreter, mas empacotado para o simulador iOS. Somente Macintosh. Se você usar esta opção, poderá incluir também a opção -platformsdk, especificando o caminho para o SDK do simulador iOS.

  • native — um instalador desktop nativo. O tipo de arquivo produzido é o formato de instalação nativo do sistema operacional no qual o comando é executado:

    • EXE — Windows

    • DMG — Mac

    • DEB — Ubuntu Linux (AIR 2.6 ou anterior)

    • RPM — Fedora ou Linux OpenSuse (AIR 2.6 ou anterior)

    Para obter mais informações, consulte Compactação de um instalador desktop nativo .

-amostra (apenas iOS, AIR 3.4 ou superior) Ativa a amostra baseada em telemetria do ActionScript em aplicativos iOS. O uso desse sinalizador permite que você crie o perfil do aplicativo com o Adobe Scout. Embora o Scout possa criar o perfil de qualquer conteúdo da plataforma Flash, a ativação de telemetria detalhada oferece uma visão mais profunda da temporização de função do ActionScript, do DisplayList, da renderização do Stage3D e muito mais. Observe que o uso desse sinalizador terá um pequeno impacto no desempenho, portanto, não use em aplicativos de produção.

-hideAneLibSymbols (apenas iOS, AIR 3.4 ou superior). Os desenvolvedores de aplicativos podem usar várias extensões nativas de diferentes fontes e, se o ANE compartilhar um nome de símbolo comum, o ADT gerará um erro de "símbolo duplicado no arquivo do objeto". Em alguns casos, esse erro pode se manifestar até mesmo como um travamento no runtime. Você pode usar a opção hideAneLibSymbols para especificar se os símbolos da biblioteca ANE ficarão visíveis apenas para as fontes da biblioteca (yes) ou para todos (no):

  • yes — Oculta os símbolos ANE, que resolvem qualquer conflito de símbolo indesejado.

  • no — (Padrão) Não oculta os símbolos ANE. Este é o comportamento antes do AIR 3.4.

Os desenvolvedores de aplicativos -embedBitcode (apenas iOS, AIR 25 ou versões mais recentes) podem usar a opção embedBitcode para especificar se desejam ou não incorporar os bitcodes ao aplicativo iOS. O valor padrão deste switch, caso a opção não especificada seja não.

DEBUGGER_CONNECTION_OPTIONS As opções de conexão do depurador especificam se um pacote de depuração deverá tentar se conectar a um depurador remoto que esteja executando num computador ou se deverá ficar na escuta de uma conexão a partir de um depurador remoto. Este conjunto de opções é suportado somente para pacotes de depuração móveis (destinos apk-debug e ipa-debug). Essas opções são descritas em Opções de conexão do depurador .

-airDownloadURL Especifica um URL alternativo para baixar e instalar o runtime do AIR em dispositivos Android. Se não for especificado, um aplicativo do AIR redirecionará o usuário para um runtime do AIR no Android Market se o runtime ainda não estiver instalado.

Se o seu aplicativo for distribuído por meio de um marketplace alternativo (diferente do Android Market administrado pelo Google), então você poderá precisar especificar o URL para baixar o runtime do AIR do mercado. Alguns mercados alternativos não permitem que os aplicativos solicitem um download de fora do mercado. Essa opção só é suportada para pacotes Android.

NATIVE_SIGNING_OPTIONS As opções de assinatura nativa identificam o certificado usado para assinar um arquivo de pacote nativo. Estas opções de assinatura são usadas para aplicar uma assinatura utilizada pelo sistema operacional nativo, não o AIR. As opções são idênticas às AIR_SIGNING_OPTIONS e são completamente descritas em Opções de assinatura de código ADT .

Assinaturas nativas estão disponíveis no Windows e no Android. No Windows, as opções de assinatura do AIR e as nativas devem ser especificadas. No Android apenas as opções de assinatura nativa podem ser especificadas.

Em muitos casos, você pode usar o mesmo certificado de assinatura de código para aplicar tanto uma assinatura do AIR e uma nativa. Contudo, isso não é verdade em todos os casos. Por exemplo, a política do Google para aplicativos enviados ao Android Market determina que todos os aplicativos devam ser assinados com um certificado válido pelo menos até 2033. Isto significa que um certificado emitido por uma autoridade de certificação conhecida, recomendado quando se aplica uma assinatura do AIR, não deve ser usado para assinar um aplicativo do Android. (Nenhuma autoridade de certificação emitirá um certificado de assinatura de código com este longo período de validade).

output O nome do arquivo do pacote a ser criado. A especificação da extensão do arquivo é opcional. Se não especificada, é adicionada uma extensão adequada para o valor -target e para o sistema operacional atual.

app_descriptor O caminho para o arquivo do descritor do aplicativo. O caminho pode ser especificado em relação ao diretório atual ou como um caminho absoluto. (O arquivo de descritor do aplicativo é renomeado como application.xml no arquivo do AIR.)

-platformsdk O caminho para a plataforma SDK do dispositivo de destino:

  • Android - O AIR 2.6+ SDK inclui as ferramentas do Android SDK necessárias para implementar os comandos relevantes do ADT. Somente defina este valor para usar uma versão diferente do Android SDK. Além disso, o caminho SDK da plataforma não precisa ser fornecido na linha do comando se a variável de ambiente AIR_ANDROID_SDK_HOME já estiver definida. (Se ambos estiverem definidos, o caminho fornecido na linha de comando é usado.)

  • iOS - O AIR SDK é enviado com um iOS SDK cativo. A opção -platformsdk permite que você empacote aplicativos com um SDK externo para que não fique restrito ao iOS SDK cativo. Por exemplo, se você criou uma extensão com o iOS SDK mais recente, você pode especificar esse SDK ao empacotar seu aplicativo. Além disso, ao usar o ADT com o simulador iOS, você precisa sempre incluir a opção -platformsdk especificando o caminho do SDK do simulador iOS.

-arch Os desenvolvedores de aplicativos podem usar este argumento para criar um APK para plataformas x86. Ele usa os valores a seguir:

  • armv7: o ADT cria pacotes APK para a plataforma Android armv7.

  • x86: o ADT cria pacotes APK para a plataforma Android x86.

armv7 é o valor padrão quando nenhum valor é especificado

FILE_OPTIONS Identifica os arquivos do aplicativo a serem incluídos no pacote. As opções de arquivo estão descritas na íntegra em Opções de caminho e arquivo . Não especifique as opções de arquivo ao criar um pacote nativo de um arquivo do AIR ou AIRI.

input_airi Especifique ao criar um pacote nativo de um arquivo do AIRI. As AIR_SIGNING_OPTIONS são necessárias se o destino for air (ou se nenhum destino for especificado).

input_airi Especifique ao criar um pacote nativo de um arquivo do AIR. Não especifique AIR_SIGNING_OPTIONS.

ANE_OPTIONS Identifica as opções e arquivos para criar um pacote de extensão nativa. As opções de pacote de extensão são descritas em detalhes em Opções de extensão nativas .

Exemplos do comando ADT-package

Arquivos de aplicativo específico ao pacote no diretório atual para um aplicativo do AIR baseado em SWF: 

adt –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml myApp.swf components.swc

Arquivos de aplicativo específico ao pacote no diretório atual para um aplicativo do AIR baseado em HTML: 

adt –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml myApp.html AIRAliases.js image.gif

Empacote todos os arquivos e subdiretórios no diretório de trabalho atual: 

adt –package -storetype pkcs12 -keystore ../cert.p12 myApp.air myApp.xml .
Nota: O arquivo de armazenamento de chaves contém a chave privada usada para assinar seu aplicativo. Nunca inclua o certificado de assinatura no pacote do AIR! Se você usar caracteres curinga no comando do ADT, coloque o arquivo de armazenamento de chaves em um local diferente para que ele não seja incluído no pacote. Neste exemplo, o arquivo de armazenamento de chaves, cert.p12, reside no diretório pai.

Empacote apenas os arquivos principais e um subdiretório de imagens: 

adt –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml myApp.swf images

Empacote um aplicativo baseado em HTML e todos os arquivos nos subdiretórios de HTML, scripts e imagens: 

adt –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml index.html AIRALiases.js html scripts images

Empacote o arquivo application.xml e o SWF principal localizados em um diretório de trabalho (release/bin): 

adt –package -storetype pkcs12 -keystore cert.p12 myApp.air release/bin/myApp.xml –C release/bin myApp.swf

Empacote ativos de mais de um lugar no seu sistema de arquivo de criação. Neste exemplo, os ativos do aplicativo são localizados nas seguintes pastas antes do empacotamento: 

/devRoot 
    /myApp 
        /release 
            /bin 
                myApp-app.xml 
                myApp.swf or myApp.html 
    /artwork 
        /myApp 
            /images 
                image-1.png 
                ... 
                image-n.png 
    /libraries 
        /release 
            /libs 
                lib-1.swf 
                lib-2.swf 
                lib-a.js 
                AIRAliases.js

Executar o seguinte comando do ADT do diretório /devRoot/myApp: 

adt –package -storetype pkcs12 -keystore cert.p12 myApp.air release/bin/myApp-app.xml  
    –C release/bin myApp.swf (or myApp.html) 
    –C ../artwork/myApp images  
    –C ../libraries/release libs

Resulta na seguinte estrutura de pacote: 

/myAppRoot 
    /META-INF 
        /AIR 
            application.xml 
            hash 
    myApp.swf or myApp.html 
    mimetype 
    /images 
        image-1.png 
        ... 
        image-n.png 
    /libs 
        lib-1.swf 
        lib-2.swf 
        lib-a.js 
        AIRAliases.js

Execute ADT como um programa Java para um aplicativo simples baseado em SWF (sem configurar o classpath): 

java –jar {AIRSDK}/lib/ADT.jar –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml myApp.swf

Execute ADT como um programa Java para um aplicativo simples baseado em HTML (sem configurar o classpath): 

java –jar {AIRSDK}/lib/ADT.jar –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml myApp.html AIRAliases.js

Execute o ADT como um programa Java (com o caminho da classe Java definido para incluir o pacote ADT.jar): 

java -com.adobe.air.ADT –package -storetype pkcs12 -keystore cert.p12 myApp.air myApp.xml myApp.swf

Execute o ADT como uma tarefa Java no Apache Ant (embora seja melhor usar o comando diretamente nos scripts Ant). Os caminhos mostrados no exemplo são para o Windows: 

<property name="SDK_HOME" value="C:/AIRSDK"/> 
<property name="ADT.JAR" value="${SDK_HOME}/lib/adt.jar"/> 
 
target name="package"> 
    <java jar="${ADT.JAR}" fork="true" failonerror="true"> 
        <arg value="-package"/> 
        <arg value="-storetype"/> 
        <arg value="pkcs12"/> 
        <arg value="-keystore"/> 
        <arg value="../../ExampleCert.p12"/> 
        <arg value="myApp.air"/> 
        <arg value="myApp-app.xml"/> 
        <arg value="myApp.swf"/> 
        <arg value="icons/*.png"/> 
    </java> 
</target>
Nota: Em alguns sistemas de computadores, os caracteres de bytes duplos nos caminhos do sistema de arquivos pode ser mal-interpretado. Se isto acontecer, tente definir o JRE usado para executar o ADT para usar o conjunto de caracteres UTF-8. Isso é feito por padrão no script usado para iniciar o ADT no Mac e no Linux. No arquivo adt.bat do Windows, ou ao executar o ADT diretamente do Java, especifique a opção -Dfile.encoding=UTF-8 na linha de comando Java.