Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Depois de uma aplicação ter sido codificada e testada, é necessário preparar um pacote para distribuição. A primeira tarefa na preparação deste pacote é construir o aplicativo para lançamento, o que envolve principalmente a definição de alguns atributos do aplicativo.
Use as seguintes etapas para criar o aplicativo para lançamento:
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 o Google Play, exigem-no.
Versão do aplicativo – Esta etapa envolve a inicialização ou atualização das informações de controle de versão. Isso é importante para futuras atualizações de aplicativos e para garantir que os usuários estejam cientes de qual versão do aplicativo eles instalaram.
Shrink the APK – O tamanho do APK final pode ser substancialmente reduzido usando o linker Xamarin.Android no código gerenciado e ProGuard no bytecode Java.
Proteja o aplicativo – Impeça que usuários ou invasores depurem, adulterem ou façam engenharia reversa do aplicativo desabilitando a depuração, ofuscando o código gerenciado, adicionando antidepuração e antiadulteração e usando compilação nativa.
Definir propriedades de empacotamento – As propriedades de empacotamento controlam a criação do pacote de aplicativos Android (APK). Esta etapa otimiza o APK, protege seus ativos e modulariza a embalagem conforme necessário. Além disso, você pode fornecer aos usuários um Android App Bundle otimizado para seus dispositivos.
Compilar – Esta etapa compila o código e os recursos para verificar se compila no modo de lançamento.
Arquivo para publicação – Esta etapa cria o aplicativo e o coloca em um arquivo para assinatura e publicação.
Cada uma dessas etapas é descrita abaixo com mais detalhes.
Especifique o ícone do aplicativo
É altamente recomendável que cada aplicativo Xamarin.Android especifique um ícone de aplicativo. Alguns mercados de aplicativos não permitirão que um aplicativo Android seja publicado sem um. A Icon propriedade do atributo é usada para especificar o ícone do Application aplicativo para um projeto Xamarin.Android.
No Visual Studio 2017 e posterior, especifique o ícone do aplicativo por meio da seção Manifesto do Android das Propriedades do projeto, conforme mostrado na captura de tela a seguir:
Nesses exemplos, @drawable/icon refere-se a um arquivo de ícone que está localizado em Resources/drawable/icon.png (observe que 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 trecho de exemplo:
[assembly: Application(Icon = "@drawable/icon")]
Normalmente, using Android.App é declarado na parte superior do AssemblyInfo.cs (o namespace do Application atributo é Android.App); no entanto, talvez seja necessário adicionar essa using instrução se ela ainda não estiver presente.
Versão do aplicativo
O controle de versão é importante para a manutenção e distribuição de aplicativos Android. Sem algum tipo de controle de versão, é difícil determinar se ou como um aplicativo deve ser atualizado. Para ajudar com o controle de versão, o Android reconhece dois tipos diferentes de informações:
Número da 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 compilação. Esse valor não tem relação ou afinidade com o atributo de nome da 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 destina-se a ser apresentado aos utilizadores ou no Google Play. Esta string 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 a compilação instalada em seu dispositivo. Esse valor é armazenado no arquivo AndroidManifest.xml como
android:versionName.
No Visual Studio, esses valores podem ser definidos na seção Manifesto do Android das Propriedades do projeto, conforme mostrado na captura de tela a seguir:
Reduzir o APK
Os APKs Xamarin.Android podem ser reduzidos através de uma combinação do vinculador Xamarin.Android, que remove código gerenciado desnecessário, e da ferramenta ProGuard do Android SDK, que remove bytecode Java não utilizado. O processo de compilação primeiro usa o vinculador Xamarin.Android para otimizar o aplicativo no nível de código gerenciado (C#) e, em seguida, usa o ProGuard (se ativado) para otimizar o APK no nível de bytecode Java.
Configurar o vinculador
O modo de liberação desativa o tempo de execução compartilhado e ativa a vinculação para que o aplicativo envie apenas as partes do Xamarin.Android necessárias no tempo de execução. 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. Em seguida, o vinculador descarta todos os assemblies, tipos e membros que não são utilizados ou referenciados. Isso pode resultar em uma redução significativa no tamanho da embalagem. Por exemplo, considere a amostra HelloWorld , que experimenta uma redução de 83% no tamanho final de seu APK:
Configuração: Nenhum – Xamarin.Android 4.2.5 Tamanho = 17,4 MB.
Configuração: Somente assemblies SDK – Xamarin.Android 4.2.5 Tamanho = 3,0 MB.
Defina as opções do vinculador através 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 – Isso desliga o vinculador; nenhuma vinculação será realizada.
Somente bibliotecas SDK – Isto vinculará apenas as bibliotecas necessárias pelo Xamarin.Android. Outras assembleias não serão vinculadas.
Sdk e User Assemblies – Isso vinculará todos os assemblies que são exigidos pelo aplicativo, e não apenas os exigidos pelo Xamarin.Android.
A vinculação pode produzir alguns efeitos colaterais não intencionais, por isso é importante que um aplicativo seja testado novamente no modo de liberação em um dispositivo físico.
ProGuarda
O ProGuard é uma ferramenta SDK do Android que vincula e ofusca o código Java. O ProGuard é normalmente usado para criar aplicativos menores, reduzindo a pegada de grandes bibliotecas incluídas (como o Google Play Services) no seu APK. O ProGuard remove o bytecode Java não utilizado, o que torna o aplicativo resultante menor. Por exemplo, o uso do ProGuard em aplicativos Xamarin.Android pequenos geralmente alcança uma redução de tamanho de cerca de 24% – usar o ProGuard em aplicativos maiores com várias dependências de biblioteca normalmente alcança uma redução de tamanho ainda maior.
O ProGuard não é uma alternativa ao vinculador Xamarin.Android. O vinculador Xamarin.Android vincula o código gerenciado , enquanto o ProGuard vincula o bytecode Java. O processo de compilação primeiro usa o vinculador Xamarin.Android para otimizar o código gerenciado (C#) no aplicativo e, em seguida, usa o ProGuard (se ativado) para otimizar o APK no nível de bytecode Java.
Quando a opção Ativar ProGuard está marcada, 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 compilação. O Xamarin.Android também suporta ações de compilação personalizadas do ProguardConfiguration . Você pode adicionar um arquivo de configuração personalizado do ProGuard ao seu projeto, clicar com o botão direito do mouse nele e selecioná-lo como uma ação de compilação, conforme mostrado neste exemplo:
O ProGuard está desativado por padrão. A opção Ativar ProGuard está disponível somente quando o projeto está definido para o modo Release. Todas as ações de compilação do ProGuard são ignoradas, a menos que a opção Ativar o ProGuard esteja marcada. A configuração do Xamarin.Android ProGuard não ofusca o APK e não é possível ativar a ofuscação, mesmo com arquivos de configuração personalizados. Se você deseja usar ofuscação, consulte Proteção de aplicativo com Dotfuscator.
Para obter informações mais detalhadas sobre como usar a ferramenta ProGuard, consulte ProGuard.
Proteja o aplicativo
Desativar depuração
Durante o desenvolvimento de um aplicativo Android, a depuração é realizada com o uso do Java Debug Wire Protocol (JDWP). Esta é uma tecnologia que permite que ferramentas como adb se comuniquem com uma JVM para fins de depuração. O JDWP está ativado por padrão para compilações de depuração de um aplicativo Xamarin.Android. Embora o JDWP seja importante durante o desenvolvimento, ele pode representar um problema de segurança para aplicativos lançados.
Importante
Sempre desative o estado de depuração em um aplicativo liberado, pois é possível (via JDWP) obter acesso total ao processo Java e executar código arbitrário no contexto do aplicativo se esse estado de depuração não estiver desativado.
O Manifest do Android contém o atributo android:debuggable, que controla se a aplicação pode ou não ser depurada. É considerado uma boa prática definir o android:debuggable atributo como false. A maneira mais simples de fazer isso é adicionando uma instrução de compilação condicional em 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). As compilações de versão, no entanto, usam apenas as permissões que você configura explicitamente. Se você achar que alternar para a compilação Release faz com que seu aplicativo perca uma permissão que estava disponível na compilação Depurar, verifique se você habilitou explicitamente essa permissão na lista Permissões necessárias , conforme descrito em Permissões.
Proteção de aplicativos com Dotfuscator
Mesmo com a depuração desativada, ainda é possível que os invasores reempacotem um aplicativo, adicionando ou removendo opções de configuração ou permissões. Isso permite que eles façam engenharia reversa, depurem ou adulterem o aplicativo. O Dotfuscator Community Edition (CE) pode ser usado para ofuscar o código gerenciado e injetar código de deteção de estado de segurança em tempo de execução em um aplicativo Xamarin.Android no momento da compilação para detetar e responder se o aplicativo estiver sendo executado em um dispositivo rooteado.
O Dotfuscator CE está incluído no Visual Studio 2017. Para usar o Dotfuscator, clique em Tools > PreEmptive Protection - Dotfuscator.
Para configurar o Dotfuscator CE, consulte Usando o Dotfuscator Community Edition com o Xamarin. Uma vez configurado, o Dotfuscator CE protegerá automaticamente cada compilação criada.
Agrupar assemblies em código nativo
Quando essa opção está habilitada, os assemblies são agrupados em uma biblioteca compartilhada nativa. Isso permite que os componentes sejam compactados, permitindo ficheiros .apk mais pequenos. A compressão da montagem também confere uma forma mínima de ofuscação; tal ofuscação não deve ser considerada confiável.
Esta opção requer uma licença Enterprise e só está disponível quando a opção Usar Implementação Rápida está desativada. Agrupar assemblies em código nativo é desabilitado por padrão.
Observe que a opção Bundle into Native Codenã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 a compilação Antecipada (AOT) de assemblies. Quando essa opção está habilitada, a sobrecarga de inicialização Just In Time (JIT) é minimizada pela pré-compilação de assemblies antes do tempo de execução. O código nativo resultante é incluído no APK junto com os assemblies não compilados. Isso resulta em menor tempo de inicialização do aplicativo, mas às custas de tamanhos APK um pouco maiores.
A opção AOT Compilation requer uma licença Enterprise ou superior. A compilação AOT está disponível somente quando o projeto está configurado para o modo Release e é desabilitado por padrão. Para obter mais informações sobre a compilação AOT, consulte AOT.
LLVM otimizando compilador
O LLVM Optimizing Compiler criará código compilado menor e mais rápido e converterá assemblies compilados pela AOT em código nativo, mas às custas de tempos de compilação mais lentos. O compilador LLVM está desativado por padrão. Para usar o compilador LLVM, a opção AOT Compilation deve primeiro ser habilitada (na página Packaging Properties ).
Observação
A opção LLVM Optimizing Compiler requer uma licença Enterprise.
Definir propriedades de empacotamento
As propriedades de empacotamento podem ser definidas na seção Opções do Android de Propriedades do projeto, conforme mostrado na captura de tela a seguir:
Muitas dessas propriedades, como Usar Tempo de Execução Compartilhado e Usar Implantação Rápida , destinam-se ao modo de Depuração. No entanto, quando o aplicativo é configurado para o modo de versão, há outras configurações que determinam como o aplicativo é otimizado para tamanho e velocidade de execução, como ele é protegido contra adulteração e como ele pode ser empacotado para suportar diferentes arquiteturas e restrições de tamanho.
Especificar arquiteturas suportadas
Ao preparar um aplicativo Xamarin.Android para lançamento, é necessário especificar as arquiteturas de CPU suportadas. Um único APK pode conter código de máquina para suportar várias arquiteturas diferentes. Consulte Arquiteturas de CPU para obter detalhes sobre o suporte a várias arquiteturas de CPU.
Gere um pacote (.APK) por cada ABI selecionado
Quando esta opção estiver ativada, será criado um APK para cada um dos ABI suportados (selecionado na guia Avançado , conforme descrito em Arquiteturas de CPU) em vez de um único APK grande para todos os ABI suportados. Essa opção está disponível somente quando o projeto está configurado para o modo de versão e é desabilitada por padrão.
Multi-Dex
Quando a opção Ativar Multi-Dex está ativada, as ferramentas SDK do Android são usadas para ignorar o limite do método 65K do formato de arquivo .dex . A limitação do método 65K é baseada no número de métodos Java aos quais um aplicativo faz referência (incluindo aqueles em quaisquer bibliotecas das quais o aplicativo depende) – não se baseia no número de métodos escritos no código-fonte. Se um aplicativo define apenas alguns métodos, mas usa muitos (ou grandes bibliotecas), é possível que o limite de 65K seja excedido.
É possível que um aplicativo não esteja usando todos os métodos em todas as bibliotecas referenciadas; portanto, é possível que uma ferramenta como o ProGuard (veja acima) possa remover os métodos não utilizados do código. A melhor prática é habilitar o Enable Multi-Dex somente se for absolutamente necessário, ou seja, o aplicativo ainda faz referência a mais de 65K métodos Java, mesmo depois de usar o ProGuard.
Para obter mais informações sobre Multi-Dex, consulte Configurar aplicativos com mais de 64K métodos.
Pacotes de aplicativos para Android
Os pacotes de aplicativos diferem dos APKs, pois não podem ser implantados diretamente em um dispositivo. Em vez disso, é um formato que se destina a ser carregado com todo o seu código compilado e recursos. Depois de carregar seu pacote de aplicativos assinado, o Google Play terá tudo o que precisa para criar e assinar os APKs do seu aplicativo e apresentá-los aos seus usuários usando a Entrega Dinâmica.
Para habilitar o suporte para Android App Bundles, você precisará aceitar o bundle valor da propriedade Android Package Format nas opções do seu projeto Android. Antes de fazer isso, certifique-se de alterar seu projeto para uma Release configuração, pois os pacotes de aplicativos destinam-se apenas a pacotes de versão.
Agora você pode gerar um pacote de aplicativos seguindo o Fluxo de Arquivamento. Isso gerará um pacote de aplicativos para seu aplicativo.
Para obter mais informações sobre Android App Bundles, consulte Android App Bundles.
Compilar
Depois que todas as etapas acima forem concluídas, o aplicativo estará pronto para compilação. Selecione Build > Rebuild Solution para verificar se a compilação foi bem-sucedida no modo de Release. Observe que esta etapa ainda não produz um APK.
Assinar o pacote de aplicativos aborda o empacotamento e a assinatura com mais detalhes.
Arquivo para Publicação
Para iniciar o processo de publicação, clique com o botão direito do mouse no projeto no Gerenciador de Soluções e selecione o item de menu de contexto Arquivar...
Arquivo... inicia o Archive Manager e inicia o processo de arquivamento do pacote de aplicativos, conforme mostrado nesta captura de tela:
Outra maneira de criar um arquivo é 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 Xamarin que podem gerar um arquivo:
Tanto o Archivecomo o Archive All iniciam automaticamente o Archive Manager. Para iniciar o Archive Manager diretamente, clique no item de menu Tools > Archive Manager...
Os arquivos da solução a qualquer momento clicando com o botão direito do mouse no nó Solução e selecionando Exibir arquivos:
O Gestor de Arquivo
O Archive Manager é composto por um painel Lista de Soluções , uma Lista de Arquivos e um Painel de Detalhes:
A Lista de Soluções exibe todas as soluções com 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 pode estar vazia se a solução atual não tiver um arquivo existente.
- All Archives – Exibe todas as soluções que possuem um arquivo.
- Caixa de texto de pesquisa (na parte superior) – Filtra as soluções listadas na lista Todos os arquivos de acordo com a cadeia de pesquisa inserida na caixa de texto.
A Lista de Arquivos exibe a lista de todos os arquivos da solução selecionada. A Lista de Arquivos inclui as seguintes secções:
- Nome da solução selecionada – Exibe o nome da solução selecionada na Lista de Soluções. Todas as informações apresentadas na Lista de Arquivos referem-se a esta solução selecionada.
- Filtro de Plataformas – Este campo permite filtrar arquivos por tipo de plataforma (como iOS ou Android).
- Itens de Arquivo – Lista de arquivos para a solução selecionada. Cada item nesta lista inclui o nome do projeto, a data de criação e a plataforma. Ele 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. Ele também permite que o usuário inicie o fluxo de trabalho de distribuição ou abra a pasta onde a distribuição foi criada. A seção Build Comments torna possível incluir comentários de compilação no arquivo.
Distribuição
Quando uma versão arquivada do aplicativo estiver pronta para publicação, selecione o arquivo 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 do progresso do fluxo de trabalho de distribuição e uma escolha de canais de distribuição. Na primeira execução, são oferecidas duas opções:
É possível escolher um dos seguintes canais de distribuição:
Ad-Hoc – Salva um APK assinado no disco que pode ser instalado manualmente em dispositivos Android. Continue para Assinar o pacote do aplicativo para saber como criar uma identidade de assinatura do Android, criar um novo certificado de assinatura para aplicativos Android e publicar uma versão ad hoc do aplicativo no disco. Esta é uma boa maneira de criar um APK para teste.
Google Play – Publica um APK assinado para o Google Play. Continue para Publicar no Google Play para saber como assinar e publicar um APK na loja Google Play.
