Múltiples paquetes de aplicaciones Android .APK de código fuente único

Me gustaría que un sistema de compilación de Android, la línea de comandos o Eclipse, generara varios archivos .apk desde una única base de código fuente. Algunas razones comunes para esto – tener versiones específicas para los mercados con diferentes requisitos o una versión gratuita y de pago.

Esta pregunta NO ES ACERCA DE:

Empaquetar código compartido en librerías de Android o en jarras de Java externas
Producción de una depuración vs. lanzamiento firmado .apk

Google dice que "probablemente necesites crear proyectos Android separados para cada APK que tengas la intención de publicar, para que puedas desarrollarlos de forma apropiada, simplemente puedes duplicar tu proyecto existente y darle un nuevo nombre". Luego, sugieren usar bibliotecas, que yo entiendo. Luego, mencionan de pasada exactamente lo que quiero: "un sistema de compilación que puede generar diferentes recursos basados en la configuración de construcción"

Sé que para lograr la compilación condicional en JAVA se puede desactivar una variable 'final pública estática'. Hay un ejemplo de ajuste de tal valor en build.xml. Cualquier ejemplo más completo de una configuración de compilación de Android Ant para esto o un enlace a un proyecto de OSS que lo haga ahora, por favor? BTW, build.xml es generado automáticamente, pero he visto a gente hacking, así que ¿cómo funciona?
Con el nombre del paquete declarado en Manifest.xml como package = "com.example.appname", si se necesita emitir múltiples .apks que varían ese nombre, ¿se queda uno con un proyecto separado para cada uno?

Estoy generando 2 diferentes APK (demo y producción) de un único árbol de la fuente con 3 pequeñas modificaciones:

1) Tengo public static final DEMO=true; //false; public static final DEMO=true; //false; En mi clase de Application y dependiendo de ese valor que utiliza para cambiar el código entre las funciones de demostración / producción

2) Hay 2 actividades principales, como:

 package mypackage; public class MyProduction extends Activity { //blah-blah } package mypackage.demo; public class MyDemoActivity extends mypackage.MyProductionActivity { //blah-blah }

3) Y al final 2 archivos separados de AndroidManifest.xml que apunta a diferentes actividades de lanzamiento dependiendo de la demostración / interruptor de producción

Estoy cambiando entre 2 APK manualmente, pero no veo nada difícil en la tarea de escritura pequeña ANT para cambiar entre ellos automáticamente

Una forma de hacerlo sería mantener dos AndroidManifest.xml separados, uno para cada configuración. Puede alternar entre ambos manualmente (copia) o automáticamente (script de compilación).

[Edit] Esta persona aquí tiene un sistema para hacer este tipo de cosas: http://blog.elsdoerfer.name/2010/04/29/android-build-multiple-versions-of-a-project/

La respuesta a esto grita Gradle , como se explica en este sitio web . Está oficialmente incorporado en Android Studio y se recomienda.

Es asombroso; He construido 3 aplicaciones distintas utilizando el mismo código fuente, con texto y gráficos personalizados, sin ninguna codificación especial. Sólo algunos directorio y la configuración de Gradle es necesario, y otros puestos de mina se puede encontrar con respuestas a ambos.

Parece explicar todo lo básico muy bien. Para la respuesta a su pregunta específica, busque la sección Product Flavors bajo Build Variants , donde se describe la especificación de diferentes sabores.

Como explica el sitio web, parte del propósito detrás de este diseño era hacerlo más dinámico y permitir más fácilmente la creación de múltiples APK con esencialmente el mismo código, lo que suena exactamente como lo que estás haciendo.

Probablemente no lo explique lo mejor, pero ese sitio web hace un buen trabajo.

A pesar de su insistencia de que esto no se trata de empaquetar el código compartido en las bibliotecas de Android, que tipo de es. Usted ha declarado que los mercados pueden tener requisitos diferentes o tener una versión gratuita y una pagada. En cada uno de estos ejemplos, sus dos APK de salida final tienen comportamiento y / o recursos diferentes. Puede colocar la gran mayoría de su código en una biblioteca de Android compartida y, a continuación, mantener las diferencias en sus proyectos reales.

Por ejemplo, he trabajado en aplicaciones en las que deben publicarse tanto en el Android Market como en la Amazon AppStore. La AppStore de Amazon requiere que si se vincule a una página de mercado para la aplicación, debe ser de Amazon (en contraposición a la página de Android Market). Puede almacenar una URL en un recurso de la biblioteca y utilizarla en el código, pero luego reemplazarla en el proyecto de Amazon para apuntar a la URL de Amazon apropiada.

Si lo estructura bien, puede hacer cosas similares en código porque su punto de partida es su objeto de aplicación que puede subclase y hacer cosas diferentes con.

Dicho esto, si desea agregar un paso Ant que cambia el nombre del paquete en el manifiesto, es sólo XML. No debe ser difícil de modificar como un paso de precompilación.

Este artículo tiene un buen walk-through con ejemplos de cómo modificar archivos de configuración en tiempo de construcción; Consulte en particular las secciones Customizing the build y Using a Java configuration file . Tenga en cuenta que parte de la información sobre build.xml y ant es un poco fuera de fecha ahora.

Tuve el mismo problema, pero el embalaje en un proyecto con banderas no es una solución para mí. Escribí un ejemplo de cómo hacerlo con Maven:

Cómo crear múltiples archivos apk de Android desde una base de código organizada por un proyecto Maven multi módulo.

Mi equipo construye 2 compilaciones diferentes utilizando una sola base de código + código adicional. Como la construcción de android se basa en el script de hormigas, yo uso script hormiga para hacer este trabajo.

He utilizado xmltask para manipular el archivo de manifiesto xml y muchas hormigas tarea (regexp, copy ..) para editar el código fuente.

Preparé la plantilla de proyecto de plantilla (incluyendo build.xml, default.properties, local.properties) y copié el nuevo código fuente en las plantillas de proyecto. Cuando se complete la copia, ejecute build.xml paralelo para acortar el tiempo de compilación. Cuando la construcción terminó, consigo varios archivos apk.

Aquí está nuestra situación: tenemos una única base de código desde la que lanzamos para varios clientes. Cada uno de ellos tiene varios requisitos con respecto a los títulos, fondos y otros recursos en la aplicación (y mucho menos nombres de paquetes).

La compilación se maneja mediante una secuencia de comandos de Ruby que modifica AndroidManifest , copia / reemplaza determinados recursos de las carpetas específicas del cliente y luego pasa a la rutina de compilación estándar de Android. Una vez completada la compilación, el script restablece los archivos cambiados de nuevo a su estado original, 'predeterminado'.

Bueno … Tal vez no es óptimo y definitivamente no es específico de Android, pero así es como lo hacemos.

Creo que la mejor manera de seguir utilizando libray para las fuentes comunes y dos diferentes proyectos de Android demo y paquete de producción. Esto porque en Java es muy simple hacer una ingeniería inversa de apk a fuentes. Si usas las mismas fuentes para la demostración y la producción, alguien podría hackear tu apk descargando el paquete de demostración, extrayendo las fuentes de Java y desbloqueando las fuentes cambiando la variable para usarla como versión de producción. Con la biblioteca puede conservar parte de las fuentes en el paquete de producción, de esta manera no hay manera de utilizar el paquete de demostración como paquete de producción.

Es fácil de lograr su objetivo mediante el uso de Android Studio construir variantes que utilizan graddle como el sistema de construcción.

Compruebe aquí para obtener información más detallada.