Como posso suportar meu aplicativo Android para várias lojas do Android?

9

Comecei recentemente a vender meu aplicativo Android no Google Android Market e implementei o esquema de licenciamento de aplicativos para impedir o uso não autorizado do meu aplicativo. Agora estou planejando lançá-lo também para a Amazon App Store Android e quero saber a melhor maneira de manter duas versões do meu aplicativo: uma que implemente o Licenciamento do Android e outra que não seja.

Embora minha solução atual funcione, isso não é o ideal, e estou tentando descobrir maneiras pelas quais outras pessoas lidaram com isso. No momento, implementei duas telas iniciais para meu aplicativo, SplashGoogle.java e SplashAmazon.java. Eu tenho dois arquivos de manifesto correspondentes, GoogleManifest.xml e AmazonManifest.xml. Cada manifesto define um splash diferente como a intenção do iniciador.

Quando quero liberar uma versão do meu aplicativo, renomeio um desses arquivos de manifesto para AndroidManifest.xml, exporte o aplicativo e faça o mesmo para o outro Manifesto. Esta é a minha solução, porque é o melhor que consegui e não sei de outras maneiras de fazer isso. Isso funciona porque a única diferença entre a Amazon e as versões de mercado do meu aplicativo do Google são as classes splash correspondentes, uma que verifica o licenciamento e outra que não.

Mais adiante, posso querer implementar alterações adicionais (ou consolidar para ter apenas uma tela inicial) e estou procurando um meio mais permanente de gerenciar mudanças sutis dentro do mesmo aplicativo.

Eu imagino que problemas semelhantes surgem quando os desenvolvedores criam versões pagas, gratuitas ou com suporte de anúncios de aplicativos pagos.

Notas adicionais:

  1. Para a versão que usa o Android Licensing do Google, solicito a permissão CHECK_LICENSE no arquivo AndroidManifet.xml, enquanto na versão da Amazon isso não é necessário.

Não tenho certeza se isso deve ser considerado um wiki da comunidade, mas, se for, marque-o como se fosse contrário a encerrar a pergunta. Acredito que isso seria útil para muitos desenvolvedores.

    
por finiteloop 03.06.2011 в 00:43
fonte

3 respostas

3

Eu começaria refatorando sua base de código existente em um projeto de biblioteca do Android. Isso é muito fácil de fazer. Certifique-se de ler isto. A documentação é bastante esparsa, mas eu consegui para trabalhar com isso. Tenha o cuidado de seguir exatamente a seção "Declarando os componentes da biblioteca no arquivo de manifesto".

Então, para refatorar em uma biblioteca, você basicamente marca o projeto existente como um projeto de biblioteca. Você só precisa marcar uma caixa nas configurações do projeto (veja o link).

Agora vá para a biblioteca e queremos alterar o nome do pacote para algo diferente. Por exemplo, se o pacote da versão lançada for com.mywebsite.myappname.android_market, eu mudaria o nome para com.mywebsite.myappname.common_code

Você pode clicar com o botão direito do mouse no projeto e selecionar Android Tools- > Renomear pacote de aplicativos. Essa metade funcionou para mim. Eu também tive que renomear manualmente todas as referências no código para minha classe R manaully. Você pode simplesmente usar uma substituição de pesquisa global para renomear de com.mywebsite.myappname.android_market.R para com.mywebsite.myappname.common_code.R

Agora sua biblioteca está pronta

Agora é hora de criar o projeto real que você criará.

Crie um novo projeto Android e nomeie com o nome do pacote para o Android Market, como com.mywebsite.myappname.android_market. Siga as instruções no link para adicionar sua nova biblioteca como uma biblioteca que este pacote usa.

Uma limitação dos Projetos de biblioteca do Android é que o manifesto da biblioteca NÃO será mesclado no manifesto do seu projeto de nível superior. Você precisa colá-lo lá à mão. Além disso (veja o link), você precisa ter certeza de que tudo no seu manifesto usa nomes de pacotes totalmente qualificados. Então, se você costumava ter nomes de atividades como android: name=". SplashScreenActivity" alterá-lo para android: name="com.mywebsite.myappname.common_code.SplashScreenActivity"

Então, novamente, você precisa mesclar tudo manualmente, incluindo permissões, intenções, atividades, etc.

Agora é só construir o projeto principal e você é bom. Crie um wrapper para cada variante que você deseja criar.

Você também pode ter esses novos projetos de nível superior implementando qualquer coisa que seja diferente entre suas diferentes versões. Assim, o wrapper do Android Market pode implementar uma tela inicial e a versão da Amazon, uma tela diferente. Ou você poderia simplesmente usar um enum no seu projeto comum para orientá-lo e manter as duas telas iniciais lá.

Outro recurso interessante é que os recursos no projeto principal substituirão os recursos na biblioteca, se forem fornecidos. Portanto, se você quiser, por exemplo, ter um logotipo da versão da Amazon e um logotipo do Android Market que se altere com base na versão, use apenas o mesmo nome da imagem como em comuns e coloque uma cópia diferente nas duas versões.

    
por w.donahue 03.06.2011 / 02:35
fonte
1

Embora não esteja diretamente relacionado à sua pergunta, encontrei um obstáculo semelhante na criação de versões gratuitas e pagas do meu aplicativo. O Android permite exportar qualquer aplicativo como uma biblioteca. Você pode encontrar essa opção nas propriedades do projeto no Eclipse. Portanto, ao exportar todo o seu aplicativo como uma biblioteca, você poderá incorporá-lo a outros aplicativos. Depois que sua biblioteca for exportada, você poderá criar um aplicativo da Amazon e do Google usando a biblioteca como base. Isso impedirá que você precise renomear os arquivos XML para colocar cada aplicativo em um estado utilizável.

Bibliotecas são boas porque você também pode empacotar recursos com elas. Você pode até mesmo adicionar recursos que contenham o mesmo nome nos aplicativos clientes e estes irão sobrescrever a versão da biblioteca. Assim, você pode ter telas diferentes baseadas no mercado em que seu aplicativo está. As únicas bibliotecas de locais insuficientes para mim eram a inclusão de recursos. Infelizmente, ativos brutos e não processados não serão incluídos em um aplicativo cliente de uma biblioteca.

    
por Sam 03.06.2011 / 00:57
fonte
1

Eu procuraria usar o controle de versão como git e ter três ramificações. Uma ramificação não teria um manifesto, essa ramificação principal teria todo o código comum que você poderia atualizar uma vez. Os outros dois ramos seriam Amazon, Google e o que mais surgisse. Essas ramificações teriam código específico do aplicativo, o manifesto, telas iniciais etc. Quando terminar de trabalhar em sua ramificação principal e quiser enviar atualizações, você poderá criar um núcleo temporário chamado googleRelease (ou algo assim) e mesclar sua ramificação do google.

Este é um exemplo relativamente genérico, git é poderoso e você pode abordá-lo de várias formas.

    
por sgarman 03.06.2011 / 01:30
fonte