Лучшие практики для поддержки выпуска приложений Android - PullRequest
Новая
       66

Лучшие практики для поддержки выпуска приложений Android

4 голосов
/ 14 июня 2011

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

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

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

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

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

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

Любая рекомендация?

1 Ответ

1 голос
/ 14 июня 2011

Однако изменения в 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>

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

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

На шаге 3 он также передает этот код на общедоступный git-сервер (если это применимо) и публикует тег выпуска в хранилище плагинов Jenkins, поэтому он становится доступным в качестве обновления.

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

...