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.

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.

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.

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.

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

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).

Definir propriedades de empacotamento

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

Arquivo morto para publicação

Links Relacionados

• Dispositivos de Vários Núcleos e Xamarin.Android
• Arquitetura de CPU
• AOT
• Reduzir Seus Códigos e Recursos
• Configurar aplicativos com mais de 64 mil métodos