Preparar um aplicativo para lançamento
Depois que um aplicativo tiver sido codificado e testado, será necessário preparar um pacote para distribuição. A primeira tarefa na preparação desse pacote é compilar o aplicativo para a versão, o que envolve principalmente a configuração de alguns atributos do aplicativo.
Use as seguintes etapas para criar o aplicativo para versão:
Especifique o Ícone do Aplicativo – cada aplicativo Xamarin.Android deve ter um ícone de aplicativo especificado. Embora não seja tecnicamente necessário, alguns mercados, como Google Play, exigem isso.
Versão do aplicativo – esta etapa envolve inicializar ou atualizar as informações de controle de versão. Isso é importante para atualizações futuras de aplicativos e para garantir que os usuários saibam qual versão do aplicativo foi instalada.
Reduzir o APK – o tamanho do APK final pode ser substancialmente reduzido usando o vinculador Xamarin.Android no código gerenciado e ProGuard no código de bytes java.
Proteger o aplicativo – impede que usuários ou invasores depurem, adulteram ou engenharia reversa do aplicativo desabilitando a depuração, ofuscando o código gerenciado, adicionando antidepuração e anti-adulteração e usando compilação nativa.
Definir propriedades de empacotamento – as propriedades de empacotamento controlam a criação do APK (pacote de aplicativos Android). Esta etapa otimiza o APK, protege seus ativos e modula o empacotamento conforme necessário. Além disso, você pode fornecer aos usuários um Pacote de Aplicativos Android otimizado para seus dispositivos.
Compilar – esta etapa compila o código e os ativos para verificar se ele é compilado no modo de versão.
Arquivo morto para publicação – esta etapa compila o aplicativo e o coloca em um arquivo morto para assinatura e publicação.
Cada uma dessas etapas é descrita abaixo em mais detalhes.
Especificar o ícone do aplicativo
É altamente recomendável que cada aplicativo Xamarin.Android especifique um ícone de aplicativo. Alguns mercados de aplicativo não permitirão que um aplicativo Android seja ser publicado sem um. O atributo Icon propriedade do Application é usado para especificar o ícone do aplicativo de um projeto Xamarin.Android.
No Visual Studio 2017 e posteriores, especifique o ícone do aplicativo por meio da seção Manifesto do Android das Propriedades do projeto, como é mostrado na seguinte captura de tela:
Nesses exemplos, @drawable/icon refere-se a um arquivo de ícone localizado em Resources/drawable/icon.png (a extensão .png não está incluída no nome do recurso). Esse atributo também pode ser declarado no arquivo Properties\AssemblyInfo.cs, conforme mostrado neste snippet de exemplo:
[assembly: Application(Icon = "@drawable/icon")]
Normalmente, using Android.App é declarado na parte superior de AssemblyInfo.cs (o namespace do atributo Application é Android.App), mas talvez você precisará adicionar esta instrução using se ela ainda não estiver presente.
Controle de versão do aplicativo
Controle de versão é importante para a distribuição e manutenção de aplicativos Android. Sem algum tipo de controle de versão em vigor, é difícil determinar se ou como um aplicativo deve ser atualizado. Para ajudar no controle de versão, o Android reconhece dois tipos diferentes de informação:
Número de versão – um valor inteiro (usado internamente pelo Android e pelo aplicativo) que representa a versão do aplicativo. A maioria dos aplicativos começa com esse valor é definido como 1 e, em seguida, ele é incrementado a cada build. Esse valor não tem relação ou afinidade com o atributo de nome de versão (veja abaixo). Aplicativos e serviços de publicação não devem exibir esse valor para os usuários. Esse valor é armazenado no arquivo AndroidManifest.xml como
android:versionCode.Nome da Versão – uma cadeia de caracteres que é usada apenas para comunicar informações ao usuário sobre a versão do aplicativo (conforme instalado em um dispositivo específico). O nome da versão será exibido aos usuários ou no Google Play. Essa cadeia de caracteres não é usada internamente pelo Android. O nome da versão pode ser qualquer valor de cadeia de caracteres que ajude um usuário a identificar o build instalado no dispositivo. Esse valor é armazenado no arquivo AndroidManifest.xml como
android:versionName.
No Visual Studio, esses valores podem ser definidos na seção Manifesto Android do projeto Propriedades, conforme mostrado na seguinte captura de tela:
Reduzir o APK
APKs do Xamarin.Android podem ficar menores por meio de uma combinação do vinculador Xamarin.Android, que remove código gerenciado desnecessário e a ferramenta ProGuard do SDK do Android, que remove código de bytes Java não utilizado. O processo de build primeiro usa o vinculador do Xamarin.Android para otimizar o aplicativo no nível do código gerenciado (C#) e posteriormente usa o ProGuard (se habilitado) para otimizar o APK no nível do código de bytes Java.
Configurar o vinculador
O modo Versão desativa o runtime compartilhado e ativa a vinculação para que o aplicativo seja fornecido apenas com as partes necessárias do Xamarin.Android em runtime. O vinculador no Xamarin.Android usa análise estática para determinar quais assemblies, tipos e membros de tipo são usados ou referenciados por um aplicativo Xamarin.Android. O vinculador, em seguida, descarta todos os assemblies, tipos e membros que não são usados (ou referenciados). Isso pode resultar em uma redução significativa no tamanho do pacote. Considere o exemplo HelloWorld, que apresenta uma redução 83% no tamanho final de seu APK:
Configuração: Nenhum – Tamanho do Xamarin.Android 4.2.5 = 17,4 MB.
Configuração: somente assemblies do SDK – tamanho do Xamarin.Android 4.2.5 = 3,0 MB.
Defina opções de vinculador por meio da seção Opções do Android das Propriedades do projeto:
O menu suspenso Vinculação fornece as seguintes opções para controlar o vinculador:
Nenhum – desativa o vinculador; nenhuma vinculação será executada.
Somente assemblies do SDK – isso vinculará apenas os assemblies exigidos pelo Xamarin.Android. Outros assemblies não serão vinculados.
Assemblies de usuário e SDK – isso vinculará todos os assemblies exigidos pelo aplicativo e não apenas os exigidos pelo Xamarin.Android.
A vinculação pode produzir alguns efeitos colaterais indesejados, portanto, é importante que um aplicativo seja testado novamente no modo Liberação em um dispositivo físico.
ProGuard
ProGuard é uma ferramenta de SDK do Android que vincula e ofusca o código Java. O ProGuard normalmente é usado para criar aplicativos menores, reduzindo a superfície de grandes bibliotecas incluídas (como Google Play Services) em seu APK. O ProGuard remove códigos de bytes Java não utilizados, o que torna o aplicativo menor. Por exemplo, o uso do ProGuard em aplicativos Xamarin.Android pequenos geralmente atinge uma redução de cerca de 24% no tamanho – o uso do ProGuard em aplicativos maiores com várias dependências de biblioteca normalmente atinge uma redução de tamanho ainda maior.
O ProGuard é não uma alternativa ao vinculador do Xamarin.Android. O vinculador do Xamarin.Android vincula código gerenciado, enquanto o ProGuard vincula código de bytes Java. O processo de build primeiro usa o vinculador do Xamarin.Android para otimizar o código (C#) gerenciado no aplicativo e posteriormente usa o ProGuard (se habilitado) para otimizar o APK no código de bytes Java.
Quando Habilitar ProGuard está marcado, o Xamarin.Android executa a ferramenta ProGuard no APK resultante. Um arquivo de configuração do ProGuard é gerado e usado pelo ProGuard no momento da build. O Xamarin. Android também dá suporte a ações de build personalizadas em ProguardConfiguration. Você pode adicionar um arquivo de configuração ProGuard personalizado ao projeto, clicar com o botão direito do mouse nele e selecioná-lo como uma ação de build, conforme mostrado neste exemplo:
O ProGuard é desabilitado por padrão. A opção Habilitar o ProGuard só está disponível quando o projeto é definido para o modo Versão. Todas as ações de build do ProGuard serão ignoradas, a menos que Habilitar ProGuard esteja marcada. A configuração de ProGuard do Xamarin.Android não ofusca o APK e não é possível habilitar a ofuscação, mesmo com arquivos de configuração personalizados. Se você quiser usar ofuscação, consulte Proteção de aplicativo com o Dotfuscator.
Para obter mais informações sobre como usar a ferramenta do ProGuard, consulte ProGuard.
Proteger o aplicativo
Desabilitar a depuração
Durante o desenvolvimento de um aplicativo Android, a depuração é realizada com o uso do JDWP (Java Debug Wire Protocol). Esta é uma tecnologia que permite que ferramentas como adb se comuniquem com uma JVM para fins de depuração. O JDWP é ativado por padrão para compilações de depuração de um aplicativo Xamarin.Android. Embora JDWP seja importante durante o desenvolvimento, pode representar um problema de segurança em aplicativos lançados.
Importante
Sempre desabilite o estado de depuração em um aplicativo lançado na medida do possível (via JDWP) para obter acesso completo ao processo de Java e executar código arbitrário no contexto do aplicativo se esse estado de depuração não estiver desabilitado.
O manifesto do Android contém o atributo android:debuggable, que controla se o aplicativo pode ou não ser depurado. Ele é considerado uma prática recomendada para definir o atributo android:debuggable como false. A maneira mais simples de fazer isso é adicionar uma instrução de compilação condicional ao AssemblyInfo.cs:
#if DEBUG
[assembly: Application(Debuggable=true)]
#else
[assembly: Application(Debuggable=false)]
#endif
Observe que as compilações de depuração definem automaticamente algumas permissões para facilitar a depuração (como Internet e ReadExternalStorage). Compilações de versão, no entanto, usam apenas permissões explicitamente configuradas. Se você achar que alternar para o build de versão faz com que o aplicativo perca uma permissão que estava disponível no build de depuração, verifique se habilitou essa permissão explicitamente na lista Permissões necessárias conforme descrito em Permissões.
Proteção de aplicativo com o Dotfuscator
Mesmo com depuração desabilitada, os invasores ainda poderão reempacotar um aplicativo, adicionando ou removendo permissões ou opções de configuração. Isso permite que eles façam engenharia reversa, depurem ou adulterem o aplicativo. O Dotfuscator Community Edition (CE) poderá ser usado para ofuscar o código gerenciado e injetar código de detecção do estado de segurança de runtime em um aplicativo Xamarin.Android no momento da compilação para detectar e responder se o aplicativo estiver em execução em um dispositivo desbloqueado por rooting.
O Dotfuscator CE está incluído no Visual Studio 2017. Para usar o Dotfuscator, clique em Ferramentas > Proteção Preemptiva – Dotfuscator.
Para configurar o Dotfuscator CE, consulte Using Dotfuscator Community Edition with Xamarin (Como usar o Dotfuscator Community Edition com o Xamarin). Quando estiver configurado, o Dotfuscator CE protegerá automaticamente cada build criado.
Agrupar assemblies em código nativo
Quando essa opção é habilitada, os assemblies são agrupados em uma biblioteca compartilhada nativa. Isso permite que os assemblies sejam compactados, permitindo arquivos menores .apk . A compactação de assembly também confere uma forma mínima de ofuscação; tal ofuscação não deve ser confiada.
Essa opção requer uma licença corporativa e só está disponível quando a opção Usar Implantação Rápida está desabilitada. Agrupar assemblies em código nativo é desabilitada por padrão.
Observe que a opção Agrupar em Código Nativonão significa que os assemblies são compilados em código nativo. Não é possível usar a Compilação AOT para compilar assemblies em código nativo.
Compilação AOT
A opção Compilação AOT (na página Propriedades de Empacotamento) permite compilação AOT (Ahead-of-Time) de assemblies. Quando essa opção é habilitada, a sobrecarga de inicialização JIT (Just In Time) é minimizada pela pré-compilação de assemblies antes do runtime. O código nativo resultante está incluído no APK juntamente com os assemblies não compilados. Isso resulta em menor tempo de inicialização do aplicativo, mas às custas de tamanhos um pouco maiores de APK.
A opção Compilação AOT requer uma licença Enterprise ou superior. Compilação AOT só está disponível quando o projeto é configurado para o modo Versão e é desabilitada por padrão. Para obter mais informações sobre Compilação AOT, consulte AOT.
Compilador de otimização de LLVM
O compilador de otimização LLVM criará código compilado mais rápido e menor e converterá os assemblies compilados AOT em código nativo, mas às custas de tempos de compilação mais lentos. O compilador LLVM é desabilitado por padrão. Para usar o compilador LLVM, a opção Compilação AOT deve ser habilitada primeiro (na página Propriedades de Empacotamento).
Observação
A opção Compilador de otimização LLVM requer uma licença Enterprise.
Definir propriedades de empacotamento
As propriedades de empacotamento podem ser definidas na seção Opções do Android das Propriedades do projeto, conforme mostrado na seguinte captura de tela:
Muitas dessas propriedades, como Usar Runtime Compartilhado e Usar Implantação Rápida, destinam-se ao modo de Depuração. No entanto, quando o aplicativo é configurado para modo Versão, existem outras configurações que determinam como o aplicativo é otimizado para velocidade de execução e tamanho, como é protegido contra violação e como pode ser empacotado para dar suporte a restrições de tamanho e arquiteturas diferentes.
Especificar arquiteturas com suporte
Ao preparar um aplicativo Xamarin.Android para a versão, é necessário especificar as arquiteturas de CPU com suporte. Um único APK pode conter código de computador para dar suporte a várias arquiteturas diferentes. Consulte Arquiteturas de CPU para obter detalhes sobre o suporte a várias arquiteturas de CPU.
Gerar um pacote (. APK) por ABI selecionado
Quando essa opção é habilitada, um APK é criado para cada ABI com suporte (selecionado na guia Avançado, conforme descrito em arquiteturas de CPU) em vez de um único e grande APK para todas as ABIs com suporte. Essa opção só está disponível quando o projeto é configurado para o modo Versão e é desabilitada por padrão.
Multi-Dex
Quando a opção Habilitar Multi-Dex é habilitada, as ferramentas de SDK do Android são usadas para ignorar o limite de método de 65K do formato de arquivo .dex. A limitação do método 65K baseia-se no número de métodos Java que um aplicativo faz referência (incluindo aqueles em qualquer biblioteca da qual o aplicativo depende) – não se baseia no número de métodos escritos no código-fonte. Se um aplicativo apenas definir alguns métodos, mas usar muitos (ou grandes bibliotecas), é possível que o limite de 65K seja excedido.
É possível que um aplicativo não use todos os métodos em cada biblioteca referenciada, portanto, é possível que uma ferramenta como o ProGuard (veja acima) possa remover métodos não utilizados do código. A prática recomendada será habilitar Habilitar Multi-Dex somente se for absolutamente necessário, ou seja, o aplicativo ainda faz referência a mais métodos Java de 65K, mesmo após usar o ProGuard.
Para obter mais informações sobre Multi-Dex, consulte Configurar aplicativos com métodos acima de 64K.
Pacotes de aplicativos Android
Os pacotes de aplicativos diferem das APKs, pois não podem ser implantados diretamente em um dispositivo. Em vez disso, é um formato que se destina a ser carregado com todos os seus códigos e recursos compilados. Depois de carregar o pacote do aplicativo assinado, o Google Play terá tudo o que precisa para criar e assinar apKs do aplicativo e atendê-los aos usuários usando a Entrega Dinâmica.
Para habilitar o suporte para Pacotes de Aplicativos Android, você precisará aceitar o bundle valor da propriedade Formato de Pacote do Android nas opções de projeto do Android. Antes de fazer isso, certifique-se de alterar seu projeto para uma Release configuração, pois os pacotes de aplicativos são destinados apenas a pacotes de lançamento.
Agora você pode gerar um pacote de aplicativos seguindo o Fluxo de Arquivos. Isso gerará um pacote de aplicativos para seu aplicativo.
Para obter mais informações sobre pacotes de aplicativos Android, consulte Pacotes de Aplicativos Android.
Compilar
Depois de concluir todas as etapas acima, o aplicativo estará pronto para build. Selecione Compilar > Recompilar Solução para verificar se ela é compilada com êxito no modo Liberação. Observe que esta etapa ainda não produz um APK.
Assinatura do Pacote do Aplicativo trata do empacotamento e da assinatura em mais detalhes.
Arquivo morto para publicação
Para iniciar o processo de publicação, clique com o botão direito do mouse no projeto em Gerenciador de Soluções e selecione o item de menu de contexto Arquivar...:
Arquivo... inicia o Gerenciador de Arquivos e inicia o processo de arquivamento do pacote de aplicativos, conforme mostrado nesta captura de tela:
Outra maneira de criar um arquivo morto é clicar com o botão direito do mouse na Solução no Gerenciador de Soluções e selecionar Arquivar Tudo..., que cria a solução e arquiva todos os projetos do Xamarin que podem gerar um arquivo morto:
Tanto Arquivar quanto Arquivar Tudo inicializam automaticamente o Gerenciador de Arquivo Morto. Para iniciar o Gerenciador de Arquivos diretamente, clique no item de menu Gerenciador de Arquivos de Ferramentas > ... :
Acesse os arquivos mortos da solução a qualquer momento clicando com o botão direito do mouse no nó Solução e selecionando Exibir Arquivos Mortos:
O Gerenciador de Arquivo Morto
O Gerenciador de Arquivo Morto é composto por um painel de Lista de Soluções, uma Lista de Arquivos Mortos e um Painel de Detalhes:
A Lista de Soluções exibe todas as soluções que têm pelo menos um projeto arquivado. A Lista de Soluções inclui as seguintes seções:
- Solução Atual – exibe a solução atual. Observe que essa área poderá estar vazia se a solução atual não tiver um arquivo morto existente.
- Todos os Arquivos – exibe todas as soluções que têm um arquivo morto.
- Caixa de texto de pesquisa (na parte superior) – Filtra as soluções listadas na lista Todos os Arquivos de acordo com a cadeia de caracteres de pesquisa inserida na caixa de texto.
O Lista de Arquivos Mortos exibe a lista de todos os arquivos mortos para a solução selecionada. O Lista de Arquivos Mortos inclui as seguintes seções:
- Nome da solução selecionada – exibe o nome da solução selecionada na Lista de Soluções. Todas as informações mostradas na Lista Arquivos Mortos refere-se a essa solução selecionada.
- Filtro de Plataformas – esse campo possibilita filtrar arquivos por tipo de plataforma (como iOS ou Android).
- Arquivar Itens – lista de arquivos para a solução selecionada. Cada item da lista inclui o nome do projeto, a data de criação e a plataforma. Também pode mostrar informações adicionais, como o progresso quando um item está sendo arquivado ou publicado.
O Painel de Detalhes exibe informações adicionais sobre cada arquivo morto. Também permite que o usuário iniciar o fluxo de trabalho de distribuição ou abra a pasta na qual a distribuição foi criada. A seção Comentários de Build torna possível incluir comentários de build no arquivo morto.
Distribuição
Quando uma versão arquivada do aplicativo estiver pronta para publicação, selecione o arquivo morto no Gerenciador de Arquivos e clique no botão Distribuir... :
A caixa de diálogo Canal de Distribuição mostra informações sobre o aplicativo, uma indicação de progresso do fluxo de trabalho de distribuição e uma variedade de canais de distribuição. Na primeira execução, são apresentadas duas opções:
É possível escolher um dos seguintes canais de distribuição:
Ad-Hoc – salva um APK assinado em disco que pode ser carregado em dispositivos Android. Prossiga para a Assinatura do Pacote do Aplicativo para aprender a criar um identidade de assinatura do Android, criar um novo certificado de autenticação para aplicativos Android e publicar uma versão ad hoc do aplicativo no disco. Essa é uma boa maneira de criar um APK para teste.
Google Play – publica um APK assinado no Google Play. Prossiga para Publicar no Google Play para saber como assinar e publicar um APK na Google Play Store.
