Заметка
Доступ к этой странице требует авторизации. Вы можете попробовать войти в систему или изменить каталог.
Доступ к этой странице требует авторизации. Вы можете попробовать сменить директорию.
После того как приложение закодировано и протестировано, необходимо подготовить пакет для распространения. Первая задача при подготовке этого пакета — создать приложение для выпуска, которое в основном влечет за собой настройку некоторых атрибутов приложения.
Выполните следующие действия, чтобы создать приложение для выпуска:
Укажите значок приложения— каждое приложение Xamarin.Android должно иметь указанный значок приложения. Хотя и не требуется технически, некоторые рынки, такие как Google Play, требуют его.
Версия приложения — этот шаг включает инициализацию или обновление сведений о управление версиями. Это важно для будущих обновлений приложений и для обеспечения того, чтобы пользователи знали о какой версии установленного приложения.
Сжатие APK — размер окончательного APK-файла можно значительно уменьшить, используя линкер Xamarin.Android для управляемого кода и ProGuard для байт-кода Java.
Защита приложения — запретить пользователям или злоумышленникам от отладки, изменения или обратной инженерии приложения путем отключения отладки, маскирования управляемого кода, добавления защиты от отладки и защиты от незаконного изменения и использования собственной компиляции.
Настройка свойств упаковки — свойства упаковки управляют созданием пакета приложений Android (APK). Этот шаг оптимизирует APK, защищает свои ресурсы и модульизирует упаковку по мере необходимости. Кроме того, вы можете предоставить пользователям пакет приложений Android, оптимизированный для своих устройств.
Компиляция — этот шаг компилирует код и ресурсы, чтобы убедиться, что он выполняет сборку в режиме выпуска.
Архив для публикации — этот шаг создает приложение и помещает его в архив для подписывания и публикации.
Каждый из этих шагов подробно описан ниже.
Укажите значок приложения
Настоятельно рекомендуется указывать значок каждого приложения Xamarin.Android. Некоторые торговые площадки приложений не позволяют публиковать приложение Android без него. Свойство Icon атрибута используется для указания значка Application приложения для проекта Xamarin.Android.
В Visual Studio 2017 и более поздних версиях укажите значок приложения в разделе манифеста Androidсвойств проекта, как показано на следующем снимке экрана:
В этих примерах @drawable/icon относится к файлу значка, который находится в Resources/drawable/icon.png (обратите внимание, что расширение .png не включено в имя ресурса). Этот атрибут также можно объявить в файле Properties\AssemblyInfo.cs, как показано в этом примере фрагмента кода:
[assembly: Application(Icon = "@drawable/icon")]
Как правило, using Android.App объявляется в начале AssemblyInfo.cs (пространство имен для атрибута ApplicationAndroid.App); однако может потребоваться добавить эту using директиву, если она еще не присутствует.
Версия приложения
Управление версиями важно для обслуживания и распространения приложений Android. Без некоторого рода управления версиями трудно определить, следует ли обновлять приложение. Для поддержки управления версиями Android распознает два различных типа информации:
Номер версии — целочисленное значение (используемое внутри Android и приложением), представляющее версию приложения. Большинство приложений начинают с этого значения, равного 1, после чего оно увеличивается с каждой сборкой. Это значение не имеет связи или сходства с атрибутом имени версии (см. ниже). Приложения и службы публикации не должны отображать это значение пользователям. Это значение хранится в файлеAndroidManifest.xml как
android:versionCode.Имя версии — строка, используемая только для передачи информации пользователю о версии приложения (как установлено на определенном устройстве). Имя версии должно отображаться пользователям или в Google Play. Эта строка не используется внутри Android. Имя версии может быть любым строковым значением, которое поможет пользователю определить сборку, установленную на устройстве. Это значение хранится в файлеAndroidManifest.xml как
android:versionName.
В Visual Studio эти значения можно задать в разделе манифеста Androidсвойств проекта, как показано на следующем снимке экрана:
Уменьшение размера APK
Xamarin.Android APKs можно уменьшить с помощью сочетания компоновщика Xamarin.Android, который удаляет ненужный управляемый код и средство ProGuard из пакета SDK для Android, которое удаляет неиспользуемый байт-код Java. Сначала процесс сборки использует компоновщик Xamarin.Android для оптимизации приложения на уровне управляемого кода (C#), а затем использует ProGuard (если включен) для оптимизации APK на уровне байт-кода Java.
Настройте компоновщик
Режим выпуска отключает общую среду выполнения и включает связывание, чтобы приложение предоставляло только части Xamarin.Android, необходимые во время выполнения. Компоновщик в Xamarin.Android использует статический анализ, чтобы определить, какие сборки, типы и члены типов используются или на которые ссылается приложение Xamarin.Android. Затем компоновщик удаляет все неиспользуемые сборки, типы и элементы, которые не используются (или не ссылаются). Это может привести к значительному сокращению размера пакета. Например, рассмотрим пример HelloWorld , который испытывает сокращение 83% окончательного размера пакета APK:
Конфигурация: Нет — Xamarin.Android 4.2.5 Размер = 17,4 МБ.
Конфигурация: только сборки SDK — Xamarin.Android 4.2.5, размер = 3,0 МБ.
Задайте опции компоновщика в разделе проекта "Параметры Android" в "Свойствах".
Раскрывающееся меню "Связывание" предоставляет следующие параметры для управления компоновщиком:
Нет — это отключает линкер; привязка не будет выполнена.
Только сборки SDK — это будет связывать только сборки, необходимые для Xamarin.Android. Другие сборки не будут связаны.
Пакеты SDK и пользовательские сборки — это связывание всех сборок, необходимых приложению, а не только тех, которые требуются Xamarin.Android.
Связывание может создавать некоторые непреднамеренные побочные эффекты, поэтому важно, чтобы приложение было повторно протестировано в режиме выпуска на физическом устройстве.
ProGuard (инструмент для оптимизации и защиты кода)
ProGuard — это средство пакета SDK для Android, которое связывает и скрывает код Java. ProGuard обычно используется для создания небольших приложений, уменьшая объем больших библиотек (например, Google Play Services) в APK. ProGuard удаляет неиспользуемый байт-код Java, что делает полученное приложение меньше. Например, использование ProGuard в небольших приложениях Xamarin.Android обычно достигает примерно 24% уменьшения размера — использование ProGuard для больших приложений с несколькими зависимостями библиотеки обычно достигает еще большего размера.
ProGuard не является альтернативой компоновщику Xamarin.Android. Компоновщик Xamarin.Android связывает управляемый код, а ProGuard связывает байт-код Java. Сначала процесс сборки использует компоновщик Xamarin.Android для оптимизации управляемого кода (C#) в приложении, а затем использует ProGuard (если включен) для оптимизации APK на уровне байткода Java.
Если установлен флажок Enable ProGuard , Xamarin.Android запускает средство ProGuard на результирующем APK. Файл конфигурации ProGuard создается и используется ProGuard во время сборки. Xamarin.Android также поддерживает пользовательские параметры сборки ProguardConfiguration. Вы можете добавить в проект пользовательский файл конфигурации ProGuard, щелкнуть его правой кнопкой мыши и выбрать его в качестве действия сборки, как показано в этом примере:
ProGuard отключен по умолчанию. Параметр Enable ProGuard доступен только в том случае, если для проекта задан режим выпуска . Все действия сборки ProGuard игнорируются, если не установлен флажок Enable ProGuard . Конфигурация Xamarin.Android ProGuard не маскирует APK, и невозможно включить маскировку даже с пользовательскими файлами конфигурации. Если вы хотите использовать маскировку, см. раздел "Защита приложений" с dotfuscator.
Дополнительные сведения об использовании средства ProGuard см. в разделе ProGuard.
Защита приложения
Выключить отладку
Во время разработки приложения Android отладка выполняется с использованием протокола Java Debug Wire ( JDWP). Это технология, которая позволяет таким средствам, как adb , взаимодействовать с JVM в целях отладки. JDWP включен по умолчанию для отладочных сборок приложения Xamarin.Android. Хотя JDWP важен во время разработки, он может представлять проблему безопасности для выпущенных приложений.
Это важно
Всегда отключать состояние отладки в выпущенном приложении, так как это возможно (через JDWP), чтобы получить полный доступ к процессу Java и выполнить произвольный код в контексте приложения, если это состояние отладки не отключено.
Манифест Android содержит атрибут android:debuggable, который определяет, может ли приложение быть отлажено. Рекомендуется в качестве хорошей практики задать для атрибута android:debuggable значение false. Самый простой способ сделать это заключается в добавлении инструкции условной компиляции в AssemblyInfo.cs:
#if DEBUG
[assembly: Application(Debuggable=true)]
#else
[assembly: Application(Debuggable=false)]
#endif
Обратите внимание, что сборки отладки автоматически задают некоторые разрешения, чтобы упростить отладку (например , Internet и ReadExternalStorage). Однако сборки релиза используют только те разрешения, которые вы настраиваете явно. Если вы обнаружите, что переключение на сборку Release приводит к потере разрешения в приложении, которое было доступно в сборке Debug, убедитесь, что вы явно включили это разрешение в списке необходимых разрешений, как описано в разделе "Разрешения".
Защита приложений с помощью Dotfuscator
Даже при отключенной отладке злоумышленники по-прежнему могут повторно упаковать приложение, добавлять или удалять параметры конфигурации или разрешения. Это позволяет им выполнять обратную инженерию, отладку или изменение приложения. Dotfuscator Community Edition (CE) можно использовать для скрытия управляемого кода и внедрения кода обнаружения состояния безопасности среды выполнения в приложение Xamarin.Android во время сборки для обнаружения и реагирования, если приложение работает на корневом устройстве.
Dotfuscator CE входит в состав Visual Studio 2017. Чтобы использовать Dotfuscator, щелкните Tools > PreEmptive Protection — Dotfuscator.
Чтобы настроить Dotfuscator CE, см. руководство Dotfuscator Community Edition для Xamarin. После настройки Dotfuscator CE автоматически защищает каждую созданную сборку.
Упаковать сборки в исполняемый код
Если этот параметр включен, сборки объединяются в собственную общую библиотеку. Это позволяет сжимать сборки, создавая меньшие .apk файлы. Сжатие сборок также обеспечивает минимальную форму обфускации; на такую обфускацию не следует полагаться.
Этот параметр требует лицензии Enterprise и доступен только при отключении быстрого развертывания . По умолчанию трансляция сборок в машинный код отключена.
Обратите внимание, что параметр "Упаковка в нативный код"не означает, что сборки компилируются в машинный код. Невозможно использовать компиляцию AOT для компиляции сборок в машинный код.
Компиляция AOT
Параметр компиляции AOT (на странице свойств упаковки) включает предварительную компиляцию (AOT) сборок. Если этот параметр включен, стартовые издержки JIT минимизируются путем предварительной компиляции сборок до выполнения программы. Полученный машинный код включается в APK вместе с некомпилируемыми сборками. Это приводит к более короткому времени запуска приложения, но за счет немного большего размера APK.
Для параметра компиляции AOT требуется лицензия Enterprise или более поздняя. Компиляция AOT доступна только в том случае, если проект настроен для режима выпуска и по умолчанию отключен. Дополнительные сведения о компиляции AOT см. в статье AOT.
Оптимизирующий компилятор LLVM
Оптимизирующий компилятор LLVM создаст более компактный и быстрый скомпилированный код и преобразует AOT-сборки в машинный код, но за счет более медленного времени сборки. Компилятор LLVM отключен по умолчанию. Чтобы использовать компилятор LLVM, сначала необходимо включить параметр компиляции AOT (на странице свойств упаковки ).
Замечание
Для опции компилятора оптимизации LLVM требуется лицензия Enterprise.
Задание свойств упаковки
Свойства упаковки можно задать в разделе "Параметры Android" свойств проекта, как показано на следующем снимке экрана:
Многие из этих свойств, таких как использование общей среды выполнения и быстрое развертывание , предназначены для режима отладки. Однако при настройке приложения в режиме выпуска существуют другие параметры, определяющие, как приложение оптимизировано для скорости размера и скорости выполнения, как оно защищено от изменения и как его можно упаковать для поддержки различных архитектур и ограничений размера.
Указание поддерживаемых архитектур
При подготовке приложения Xamarin.Android для выпуска необходимо указать поддерживаемые архитектуры ЦП. Один APK может содержать машинный код для поддержки нескольких различных архитектур. Дополнительные сведения о поддержке нескольких архитектур ЦП см. в разделе " Архитектура ЦП ".
Создайте один пакет (.APK) на выбранный ABI
Если этот параметр включен, для каждого поддерживаемого ABI (выбранного на вкладке "Дополнительно"), как описано в CPU архитектурах), будет создан отдельный APK, а не один большой APK для всех поддерживаемых ABI. Этот параметр доступен только в том случае, если проект настроен для режима выпуска и по умолчанию отключен.
Multi-Dex
Если включен параметр Enable Multi-Dex, инструменты Android SDK используются для обхода ограничения в 65K методов формата файла .dex. Ограничение метода 65K основано на количестве методов Java, на которые ссылается приложение (включая те библиотеки, от которых зависит приложение) — это не зависит от количества методов, написанных в исходном коде. Если приложение определяет только несколько методов, но использует многие (или большие библиотеки), возможно, что ограничение в 65 КБ будет превышено.
Возможно, приложение не использует каждый метод в каждой библиотеке, на которую ссылается ссылка; Поэтому возможно, что средство, например ProGuard (см. выше), может удалить неиспользуемые методы из кода. Рекомендуется включить Multi-Dex только при крайней необходимости, т. е. если приложение по-прежнему ссылается на более чем 65 тыс. методов Java даже после использования ProGuard.
Дополнительные сведения о multi-Dex см. в разделе "Настройка приложений с помощью методов over 64K".
Пакеты приложений Android
Пакеты приложений отличаются от APK, потому что их нельзя развернуть непосредственно на устройстве. Скорее, это формат, который предназначен для загрузки со всем вашим скомпилированным кодом и ресурсами. После того как вы загрузите подписанный пакет приложений, Google Play будет обладать всем необходимым для создания и подписи APK и их предоставления вашим пользователям, используя Dynamic Delivery.
Чтобы включить поддержку пакетов приложений Android, необходимо выбрать bundle значение свойства «Формат пакета Android» в параметрах проекта Android. Прежде чем это сделать, убедитесь, что вы изменили вашу проектную конфигурацию на Release, так как пакеты приложений предназначены только для релизных пакетов.
Теперь вы можете создать пакет приложений, следуя потоку архивирования. Это приведет к созданию пакета приложений для приложения.
Дополнительные сведения о пакетах приложений Android см. в разделе "Пакеты приложений Android".
Компиляция
После завершения всех описанных выше действий приложение готово к компиляции. Выберите Сборка > Перестроить решение, чтобы убедиться, что оно успешно выполняется в режиме Release. Обратите внимание, что этот шаг еще не создает APK.
Подписывание пакета приложений подробно рассматривает вопросы упаковки и подписания.
Архив для публикации
Чтобы начать процесс публикации, щелкните проект правой кнопкой мыши в обозревателе решений и выберите пункт контекстного меню архива...
Архив... запускает диспетчер архивов и начинает процесс архивации пакета приложений, как показано на снимке экрана:
Другой способ создать архив — щелкнуть правой кнопкой мыши решение в обозревателе решений и выбрать "Архив все...", который создает решение и архивирует все проекты Xamarin, которые могут создать архив:
Архив и архив все автоматически запускают диспетчер архивов. Чтобы запустить диспетчер архивов напрямую, щелкните пункт меню Инструменты > Диспетчер архивов...
Можно в любое время получить доступ к архивам решения, щелкнув правой кнопкой мыши по узлу Решение и выбрав Просмотр архивов.
Диспетчер архивов
Диспетчер архивов состоит из области списка решений, списка архивов и панели сведений:
Список решений отображает все решения, имеющие по крайней мере один архивированный проект. Список решений содержит следующие разделы:
- Текущее решение — отображает текущее решение. Обратите внимание, что эта область может быть пустой, если текущее решение не имеет существующего архива.
- Все архивы — отображает все решения, имеющие архив.
- Текстовое поле поиска (в верхней части) — фильтрует решения, перечисленные в списке "Все архивы ", в соответствии со строкой поиска, введенной в текстовом поле.
В списке архивов отображается список всех архивов для выбранного решения. Список архивов содержит следующие разделы:
- Выбранное имя решения — отображает имя решения, выбранного в списке решений. Все сведения, отображаемые в списке архивов , ссылаются на это выбранное решение.
- Фильтр платформ — это поле позволяет фильтровать архивы по типу платформы (например, iOS или Android).
- Архивные элементы — список архивов для выбранного решения. Каждый элемент в этом списке содержит имя проекта, дату создания и платформу. Кроме того, он может отображать дополнительные сведения, такие как ход выполнения, когда элемент архивируется или публикуется.
На панели сведений отображаются дополнительные сведения о каждом архиве. Он также позволяет пользователю запустить рабочий процесс распространения или открыть папку, в которой было создано распределение. В разделе "Комментарии сборки" можно включить комментарии к сборке в архив.
Распределение
Когда архивная версия приложения готова к публикации, выберите архив в диспетчере архива и нажмите кнопку "Распространить...
В диалоговом окне канала распространения отображаются сведения о приложении, индикатор хода выполнения рабочего процесса распространения и выбор каналов распространения. В первом запуске представлены два варианта:
Можно выбрать один из следующих каналов распространения:
Ad-Hoc — сохраняет подписанный APK на диск, который можно загрузить на устройства Android. Продолжайте подписывать пакет приложений , чтобы узнать, как создать удостоверение подписи Android, создать новый сертификат подписи для приложений Android и опубликовать нерегламентную версию приложения на диске. Это хороший способ создания APK для тестирования.
Google Play — публикует подписанный APK в Google Play. Перейдите к публикации в Google Play, чтобы узнать, как подписывать и публиковать APK в магазине Google Play.
