Что бы я хотел прочитать здесь:

• “Что где и зачем?” - краткое руководство по инфраструктуре и рабочему процессу / сценариям.
• Как “обновить метаданные на gitlab.com/fdroid/fdroiddata”.

Целевая группа - разработчик/менеджер по выпуску приложений и для “внешнего заинтересованного пользователя”, который просто замечает, что появилась новая версия приложения - но еще не в системе F-Droid. “Что я должен сделать, чтобы вызвать обновление?”

@Tverrbjelke: (Если s.o. проинструктирует меня, я бы потратил часть своего времени, чтобы записать это. Люблю F-Droid, и ненавижу видеть, что такой простой и нужный вопрос еще не готов. :-) )

@daithib8: Предполагая, что все настроено и пользователь знаком со сборкой через fdroid … (в этих инструкциях используется терминальный подход. Вы можете управлять с помощью веб-браузера, но потребуется немало времени, чтобы изучить расположение распространенных веб-сайтов с исходным кодом. Для сложных приложений, которые ребазируют код и используют много ветвей, я часто посещаю сайт исходного кода).

• Обратите внимание на текущую версию по данным разработчика – подсказка часто написана над CurrentVersion в метаданных. Чтобы быстро зайти в Google Play и узнать там название версии, установите w3m и добавьте эту функцию gplay() { w3m play.google.com/store/apps/details/?id="$@" ;} в ваш bashrc. Затем вы можете просто выполнить gplay package-name. Если вы обнаружите, что версия больше, чем CurrentVersion в метаданных, сразу же обновите ее (если в настоящее время не активированы бета- или тестовые сборки)
• Если CurrentVersion в метаданных (особенно в случае режима проверки обновлений RepoManifest) больше, чем в Google Play или на странице загрузки, возможно, вам не нужно обновлять и можно просто добавить фиктивную версию сборки, например Build Version:1.2,34,!not published by the developer,subdir=main
• Клонирование репозитория исходного кода, если у вас его еще нет, путем сборки уже существующей версии (которую вы можете прекратить, как только сборка будет начата)
• Измените вход в репозиторий: pushd build/package-name
• la, чтобы напомнить себе тип VCS. Предположим, что это Mercurial (с которым я почти не знаком)
• hg revert -a; hg pull; hg up, чтобы получить последний код из репозитория. Обратите внимание на новые теги
• hg log |less и прочитайте однострочные описания назад к предыдущей версии, чтобы получить быстрое представление о последних изменениях и найти ревизию или тег, соответствующий текущей версии, отмеченной ранее
• hg up "tag" для перехода к тегу или ревизии (чтобы убедиться, что вы проверяете именно то, что будет создано)
• hg log -p например, libs | build.xml | AndroidManifest.xml | project.properties | res/raw | assets | .gitmodules | .classpath для более детального рассмотрения изменений в некоторых важных файлах (в части обновления). Если найдены новые банки (или новые версии старых), то их необходимо проверить, чтобы убедиться, что они были найдены из канонических источников и свободны с исходным кодом; первое, что нужно сделать, это открыть банку, чтобы увидеть имена классов (unzip -l) и посетить, например, http://central.maven.org/maven2/io/netty/, где вы найдете контрольные суммы для сравнения. Обратите внимание на такие банки, как bugsense или ACRA, которые используются для отчетов об ошибках
• Если вы найдете несвободные файлы, добавьте фиктивную версию сборки в метаданные с несколькими словами о причине, добавьте NoSourceSince в нижнюю часть и строку к описанию, начинающуюся со Status:, объясняющую причину, по которой приложение не может быть обновлено
• find . -type f -executable, чтобы найти любые скрипты и вещи. Обратите внимание, что ant также выполнит все, что найдет в build.xml и custom_rules.xml!
• $find . -name '\*' | xargs file --mime | grep executable|shared-lib, чтобы проверить, есть ли среди них пребилды. Они часто обнаруживаются fdroid в любом случае и обычно находятся в res/raw/ , assets/ или jni/.
• Откройте в редакторе некоторые файлы, например, README, лицензии, возможно, файлы в res/xml, которые будут содержать журналы изменений, project.properties; запустите git submodule, если это применимо. Все это даст подсказки о том, что может потребоваться изменить по сравнению с предыдущей сборкой. Вполне возможно, что никакой информации о библиотеках Android не будет, поэтому вам придется искать другие подсказки, например, в журнале фиксации. Если все остальное не помогает: cd ../srclibs/ActionLibrary и просмотрите последний код, чтобы найти подходящий коммит.
• При необходимости напишите патч, хотя sed в метаданных обычно является лучшим вариантом: mkdir ../../metadata/package-name; hg diff > ../../metadata/package-name.diff
• popd; vi metadata/package-name.txt для добавления новой версии сборки
• Проверьте с помощью fdroid build -p package-name -t -l -v | less (используйте скрипт завершения в fdroidserver) N.B –install в настоящее время не предупреждает, если имена/коды версий отличаются от метаданных. Также не включен proguard (так как это отладочная сборка); также он не предупредит вас, если он не был установлен по какой-то причине.
• Подпишите отладочным ключом jarsigner -keystore \~/.android/debug.keystore -digestalg SHA1 -sigalg SHA1withRSA tmp/com.seawolfsanctuary.keepingtracks_20130727.apk androiddebugkey
• adb install tmp/com.seawolfsanctuary.keepingtracks_20130727.apk -a и посмотрите на результат. В частности, посмотрите на экран “О программе”. Если используются библиотеки отчетов об ошибках, проверьте, не включено ли оповещение о сбоях (здесь может помочь манифест Android). Если сообщение о сбоях включено по умолчанию, приложению нужна анти-функция. То же самое касается рекламы.
• Добавьте любую информацию для следующего раза над AutoUpdateMode и посмотрите, нужно ли подправить режим проверки обновления.
• Просмотрите описание и ссылки, чтобы понять, нужно ли что-то обновить
• Зафиксировать новые srclibs и extlibs git commit build/extlibs/volley/\* и включить файл source.txt, если jar находится в новом местоположении
• Если нет ничего особенного, зафиксируйте непосредственно с помощью скрипта commitupdates. Если нет, включите как можно больше информации в тело git-коммита

Много всего нужно сделать, но опыт показывает, что надо быть бдительным и, конечно, со временем процесс пойдет быстрее… Удачи!