Рекомендации по поддержке выпуска приложений для Android

Обычно при сборке и отладке приложения для Android в манифесте указывается debuggable=true, и вы подписываете приложение ключом разработки.

Когда придет время выпустить приложение, вам нужно будет перейти на debuggable=false, подписать своим ключом, при необходимости запустить ProGuard и, возможно, сделать что-то еще.

Некоторые внешние операции, такие как подписание другим ключом, могут быть легко закодированы с помощью Ant. На самом деле эти задачи выходят из коробки. Однако изменения в AndroidManifest.xml, по-видимому, требуется ручное вмешательство каждый раз.

Еще одним аспектом является поддержка версий выпуска приложения. Например, из коробки Android tasks не будет использовать информацию о версии. Maven будет использовать версии моментальных снимков и потребует обновления вручную для выпуска.

Решение всех этих проблем довольно утомительно, и некоторая автоматизация весьма желательна. До сих пор мой подход состоял в том, чтобы создать отдельную ветку в git для выпуска, где я буду хранить окончательный манифест, а также poms с правильная версия.

Но я хотел бы получить несколько советов от других людей о лучших практиках для работы с циклом выпуска Android.

Какие-нибудь рекомендации?

1 4
android android-manifest release-management

1 ответ:

Однако, изменения в AndroidManifest.xml, кажется, требует ручного вмешательства каждый раз.

В тех местах, где нам приходилось вручную обрабатывать xml для наших автоматических сборок Android, мы используем встроенную поддержку XSLT в Ant, используя задачу . Таблица стилей может выглядеть примерно так: 

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:android="http://schemas.android.com/apk/res/android">
  <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>

  <xsl:template match="application[@android:debuggable='true']">
    <xsl:copy>
      <xsl:copy-of select="@*[name(.)!='android:debuggable']" />
      <xsl:apply-templates />
    </xsl:copy>
  </xsl:template>

  <xsl:template match="@*|node()">
    <xsl:copy>
      <xsl:apply-templates select="@*|node()"/>
    </xsl:copy>
  </xsl:template>

</xsl:stylesheet>

Что касается цикла выпуска моментальных снимков: автоматизированный процесс сборки и выпуска Jenkins выполняет его с целью maven, которая будет автоматически выполняться следующие действия:

  1. обновление версий pom (напр., android:versionName/android:versionCode) чтобы удалить "- SNAPSHOT " -- например, x.y.y-SNAPSHOT становится просто x.y.y
  2. зафиксируйте это как "выпуск версии x.y.y"
  3. тег, который выпускается в репо git
  4. обновите версии pom до моментального снимка следующего логического выпуска: x.y.z-SNAPSHOT
  5. зафиксируйте это в качестве начальной точки "подготовка к следующей версии"

На Шаге #3 он также отправляет этот код на общедоступный сервер git (если применимо), и публикует тег release в репозитории плагинов Jenkins, поэтому он становится доступным в виде обновления.

Я бы предположил, что подобный подход для цикла выпуска Android будет довольно тривиальным для сценария.

1