2012-07-05 13 views
5

Las instrucciones en http://developer.android.com/tools/publishing/preparing.html indican que debo exportar mi aplicación de Android antes de liberarla al público. ¿Cuáles son los pasos que se realizan en la exportación?¿Qué significa exportar una aplicación de Android exactamente?

Esto es lo que sé sobre: ​​

  1. androide: depurable en < Aplicación > se establece en false en el AndroidManifest.xml
  2. El APK está firmado por la clave del desarrollador (mi), en lugar de la integrado de depuración clave
  3. zipalign se ejecuta en el firmado APK

    puse androide: depurable en false de forma manual en mi AndroidManifest.xml, y se compara una depuración y se exporta apk. Estos son los únicos archivos que eran diferentes:

    Binary files ../../release/x//classes.dex and x/classes.dex differ
    Binary files ../../release/x//META-INF/CERT.RSA and x/META-INF/CERT.RSA differ
    diff -r ../../release/x//META-INF/CERT.SF x/META-INF/CERT.SF
    diff -r ../../release/x//META-INF/MANIFEST.MF x/META-INF/MANIFEST.MF

    también mi lista anterior incluye todo? ¿O las diferentes clases.dex indican que existe alguna otra diferencia entre una depuración y una aplicación exportada?

    Gracias a un error del 454 respuesta a continuación, me encontré en el archivo baksmali classes.dex en cada apk, y me encontré con una diferencia:

    diff -r out/xx/xx/xx/BuildConfig.smali ../../../release/x/out//xx/xx/xx/BuildConfig.smali
    7c7
    < .field public static final DEBUG:Z = true
    ---
    > .field public static final DEBUG:Z

    Así que supongo que podría agregar un cuarto elemento a esta lista:

  4. En la clase BuildConfig (gen /.../ BuildConfig.java), DEPURACIÓN se establece en falso.

Respuesta

0

¿O es que los diferentes classes.dex indican que hay alguna otra diferencia entre un depurar y apk exportados?

Incluso con un código idéntico, las clases.dex resultantes no tienen que ser binarias idénticas a las versiones previamente compiladas. Eso se debe a las diferentes formas en que el compilador optimiza el código AFAIK.

5

Además de lo que ha enumerado, proguard también se ejecuta durante la exportación.

Si usted es muy curioso acerca de la naturaleza de la diferencia en classes.dex, se puede agarrar baksmali, descomprimir el archivo APK y descompilar el archivo classes.dex:

java -jar baksmali-1.3.3.jar classes.dex 

Esto creará un out/carpeta con los contenidos que puedes diferenciar entre antiguo/nuevo.

El motivo de BuildConfig.DEBUG bandera es diferente es debido a que la exportación de una versión de lanzamiento contra una versión de depuración como se explica en el SDK Release Notes Revision 17:

añadido una característica que le permite ejecutar algún código sólo en el modo de depuración. Las compilaciones ahora generan una clase llamada BuildConfig que contiene una constante DEBUG que se establece automáticamente de acuerdo con su tipo de compilación. Usted puede verificar la constante (BuildConfig.DEBUG) en su código para ejecutar funciones de depuración.

+0

Gracias. Ejecuté Baksmali y enmendé mi pregunta. – craig65535

+0

BuildConfig se agregó en SDK Revisión 17 http://developer.android.com/tools/sdk/tools-notes.html –

1

Hay una serie de pasos que se dan para una generación, si el objetivo es debug o release. Esta no es una respuesta directa, pero sugiero mirar android-sdk/tools/ant/build.xml

Una vez que tenga el archivo abierto, haga una búsqueda por target name="release". Verá el atributo depends que enumera otros destinos en el mismo archivo al que se llamará. Puede comparar los objetivos que se ejecuta release en comparación con el objetivo debug. Dentro de cada objetivo, puede ver específicamente qué se ejecuta (como algunas de las utilidades en android-sdk/platform-tools), junto con lo que determina si se ejecuta algo.

También puede ver qué parámetros pasan a las utilidades externas durante una llamada de destino, lo que le permite leer la documentación sobre esos parámetros de la utilidad para ver específicamente lo que está ocurriendo para un paso en particular.

Y para tener en cuenta, aunque podría estar exportando la aplicación en eclipse, investigar el build.xml de hormiga proporciona una forma de identificar sistemáticamente cada paso que se realizará para una compilación completa.

Como ejemplo de lo complejo que podría ser esto, si mira el objetivo -set-release-mode, puede ver una instancia donde se puede generar un paquete de depuración firmado con las claves de liberación en lugar de la clave de depuración.

Cuestiones relacionadas