2011-06-02 11 views
9

Recientemente comencé a vender mi aplicación Android en Google Android Market, e implementé su esquema de licencias de aplicaciones para evitar el uso no autorizado de mi aplicación. Ahora planeo lanzarlo para Amazon App Store de Amazon y quiero saber cuál es la mejor forma de mantener dos versiones de mi aplicación: una que implementa Android Licensing y otra que no.¿Cómo puedo admitir mi aplicación Android para múltiples tiendas Android?

Aunque mi solución actual funciona, no es óptima, y ​​estoy tratando de descubrir cómo otras personas han tratado con esto. En este momento, he implementado dos pantallas de presentación para mi aplicación, SplashGoogle.java y SplashAmazon.java. Tengo dos archivos Manifest correspondientes, GoogleManifest.xml y AmazonManifest.xml. Cada manifiesto define un splash diferente como la intención del iniciador.

Cuando deseo liberar una versión de mi aplicación, cambio el nombre de uno de estos archivos de manifiesto a AndroidManifest.xml, exporto la aplicación y luego hago lo mismo con el otro Manifiesto. Esta es mi solución porque es lo mejor que se me ocurre y no conozco otras formas de hacerlo. Funciona porque la única diferencia entre las versiones de Amazon y Google market de mi aplicación son las clases de salpicaduras correspondientes, una que verifica las licencias y la otra que no.

En el camino, es posible que desee implementar cambios adicionales (o consolidar para tener solo una pantalla de inicio) y estoy buscando un medio más permanente de administrar cambios sutiles dentro de la misma aplicación.

Imagino que problemas similares surgen cuando los desarrolladores crean versiones lite, gratuitas o con publicidad de aplicaciones pagas.

Notas adicionales:

  1. Para la versión que utiliza licencias de Android de Google, que solicitan el permiso CHECK_LICENSE en el archivo AndroidManifet.xml, mientras que en la versión de Amazon, esto no es necesario.

No estoy seguro de si esto se debe considerar como una wiki de la comunidad, pero si es así, márquelo como tal, a diferencia de para cerrar la pregunta. Creo que esto sería útil para muchos desarrolladores.

Respuesta

3

Comenzaré refaccionando su base de código existente en un Proyecto de biblioteca de Android. Esto es bastante fácil de hacer. Be sure to read this. La documentación es bastante escasa, pero pude hacer que funcione con ella. Tenga cuidado de seguir exactamente la sección "Declaración de componentes de la biblioteca en el archivo de manifiesto".

Por lo tanto, para refactorizar en una biblioteca, básicamente marca el proyecto existente como un proyecto de biblioteca. Solo tiene que marcar una casilla en la configuración del proyecto (ver el enlace).

Ahora ve a la biblioteca y queremos cambiar el nombre del paquete a algo diferente. Entonces, por ejemplo, si su paquete de versión lanzado es com.mywebsite.myappname.android_market, entonces cambiaría el nombre a com.mywebsite.myappname.common_code

Puede hacer clic con el botón derecho en el Proyecto y seleccionar Herramientas Android-> Cambiar el nombre del paquete de la aplicación. Esta mitad funcionó para mí. También tuve que cambiar manualmente el nombre de todas las referencias en el código a mi clase R manaully. Usted sólo puede usar una búsqueda global sustituir a pesar de que para cambiar el nombre de com.mywebsite.myappname.android_market.R a com.mywebsite.myappname.common_code.R

Ahora su biblioteca está lista

Ahora el tiempo para hacer el real proyecto que construirás.

Crea un nuevo proyecto de Android y un nombre con el nombre del paquete para Android Market como com.mywebsite.myappname.android_market. Siga las instrucciones en el enlace para agregar su nueva biblioteca de commons como biblioteca que usa este paquete.

Una de las limitaciones de Android Library Projects es que el manifiesto de la biblioteca NO se fusionará en el manifiesto de su proyecto de nivel superior. Debes pegarlo allí a mano. También (ver enlace) necesita asegurarse de que todo en su manifiesto utiliza nombres de paquetes totalmente calificados. Entonces, si solía tener nombres de actividades como android: name = ". SplashScreenActivity" cámbielo a android: name = "com.mywebsite.myappname.common_code.SplashScreenActivity"

Así que de nuevo necesita fusionar todo a mano, incluyendo permisos, intenciones, actividades, etc.

Ahora solo crea el proyecto principal y estás bien. Haz un envoltorio para cada variante que quieras construir.

También podría hacer que estos nuevos proyectos de nivel superior implementen algo que sea diferente entre sus diferentes versiones. Por lo tanto, su contenedor de Android Market podría implementar una pantalla de presentación y su versión de Amazon una pantalla de presentación diferente. O simplemente podría usar una enumeración en su proyecto común para conducirlo y mantener ambas pantallas de bienvenida allí.

Otra buena característica es que los recursos en el proyecto superior anularán los recursos en la biblioteca si se proporcionan. Entonces, si quiere, por ejemplo, en su presentación, tener un logotipo de la versión de Amazon y un logotipo de Android Market que cambie según la versión, simplemente use el mismo nombre de imagen que en el commons y coloque una copia diferente en las dos versiones.

+0

¡Esto suena genial! Lo único que me impide implementarlo para mi situación particular es que requiere archivos AndroidManifest.xml duplicados, entre otros archivos, los principales problemas que estoy tratando de evitar en primer lugar. Sin embargo, ciertamente haré esto si alguna vez creo versiones de aplicaciones gratuitas/pagas, y me gustaría agradecerle la explicación. – finiteloop

+0

¿Hay alguna manera de tener una clase definida en un proyecto superior para anular lo que está en el código común? – finiteloop

+0

Me gustaría hacer esto porque quiero que mi proyecto de biblioteca compile sin errores, pero tenga variables establecidas para cada proyecto – finiteloop

1

Aunque no está directamente relacionado con su pregunta, me encontré con un obstáculo similar en la creación de versiones gratuitas y de pago de mi aplicación. Android le permite exportar cualquier aplicación como una biblioteca. Puede encontrar esta opción dentro de las propiedades del proyecto en Eclipse. Entonces, al exportar toda su aplicación como una biblioteca, puede incorporarla a otras aplicaciones. Una vez que se haya exportado su biblioteca, puede crear una aplicación de Amazon y Google utilizando la biblioteca como base. Esto evitará que tenga que cambiar el nombre de los archivos XML para obtener cada aplicación en un estado utilizable.

Las bibliotecas son agradables porque también puede empaquetar recursos con ellas. Incluso puede agregar recursos que contengan el mismo nombre en las aplicaciones del cliente y estos sobrescribirán la versión de la biblioteca. Por lo tanto, podría tener diferentes pantallas de presentación basadas en el mercado en el que se encuentra su aplicación. El único lugar donde las bibliotecas me faltaban incluía activos. Lamentablemente, los activos no procesados ​​sin procesar no se incluirán en una aplicación cliente de una biblioteca.

+0

Esto también parece posible. Entonces, ¿está diciendo que la funcionalidad principal de mi aplicación se guardará como un proyecto de biblioteca y luego creará dos proyectos de "envoltura" que usan esta biblioteca? – finiteloop

+0

Utilizo esto también para controlar el lanzamiento de mi aplicación. Tengo la misma aplicación con licencia múltiple, como mercado libre, Android y Amazon Market. Solo uso una enumeración en el proyecto principal de la biblioteca para elegir qué enfoque de licencia utilizar. Luego envolví la biblioteca con un envoltorio para cada proyecto de lanzamiento. Cada proyecto de envoltura tiene su propio control de versiones y nombre de paquete. Así que puedo hacer un lanzamiento seleccionando la enumeración apropiada y construyendo el proyecto de envoltura correspondiente. –

+0

@metalideath esto suena como una gran solución, una que podría justificar su propia publicación de respuestas. Estaría muy interesado en ver su solución explicada con un poco más de detalle. – finiteloop

1

Me gustaría utilizar el control de versiones como git y tener tres ramas. Una rama no tendría un manifiesto, esta rama central tendría todos los códigos comunes que podría actualizar una vez. Las otras dos ramas serían Amazon, Google y cualquier otra cosa que surja.Estas ramas tendrían código específico para la aplicación, el manifiesto, pantallas emergentes, etc. Cuando haya terminado de trabajar en su rama principal y quiera enviar actualizaciones, puede hacer una rama temporal fuera del núcleo llamada googleRelease (o algo así) y fusionar su sucursal de Google.

Este es un ejemplo relativamente genérico, git es poderoso y puede abordarlo de varias maneras.

+0

Esto suena factible. Ya tengo mi código bajo svn, ¿hay un mecanismo similar para svn? Mi única preocupación es que esto suena como que requiere mucho trabajo entre lanzamientos. – finiteloop

+0

No puedo ayudarte con svn, no es muy familiar con él. En cuanto a git y trabajo relacionado es tan simple como: git checkout core. git branch releaseGoogle. git checkout releaseGoogle. git merge google. Y eso es. – sgarman

Cuestiones relacionadas