Несколько файлов приложений .pk для Android приложений из одного исходного кода

Я хотел бы, чтобы система сборки Android, командная строка или Eclipse, генерировали несколько файлов .apk из одной исходной кодовой базы. Некоторые общие причины этого – наличие конкретных версий для рынков с различными требованиями или бесплатная и платная версия.

Этот вопрос НЕ ОБ ЭТОМ:

Google говорит: «Вам, вероятно, нужно создать отдельные проекты Android для каждого APK, который вы собираетесь опубликовать, чтобы вы могли соответствующим образом развить их отдельно. Вы можете сделать это, просто дублируя свой существующий проект и дадите ему новое имя». Затем они любезно предлагают использовать библиотеки, которые я понимаю. Затем они упоминают в точности то, что я хочу: «система сборки, которая может выводить различные ресурсы на основе конфигурации сборки»

  • Я знаю, что для выполнения условной компиляции в JAVA можно выделить переменную «public static final». Существует пример настройки такого значения в файле build.xml. Какой-нибудь более полный пример конфигурации сборки Android Ant для этого или ссылки на проект OSS, выполняющий это сейчас, пожалуйста? BTW, build.xml автоматически генерируется, но я видел, как люди его взломали, так как это работает?

  • С именем пакета, объявленным в Manifest.xml как package = “com.example.appname”, если нужно испускать несколько .apks, которые меняют это имя, застрял ли отдельный проект для каждого?

    Я генерирую 2 разных APK (демо и производство) из одного дерева источников с тремя небольшими модификациями:

    1) Я public static final DEMO=true; //false; public static final DEMO=true; //false; в моем classе Application и в зависимости от этого значения я использовал для переключения кода между демонстрационными / производственными функциями

    2) Существует 2 основных вида деятельности:

     package mypackage; public class MyProduction extends Activity { //blah-blah } package mypackage.demo; public class MyDemoActivity extends mypackage.MyProductionActivity { //blah-blah } 

    3) И в конце 2 отдельные файлы AndroidManifest.xml которые указывают на разные действия запуска в зависимости от демонстрационного / производственного переключателя

    Я переключаюсь между двумя APK вручную, но не вижу ничего сложного в написании маленькой задачи ANT, чтобы переключаться между ними автоматически

    Один из способов сделать это – поддерживать два отдельных AndroidManifest.xml, по одному для каждой конфигурации. Вы можете переключаться между ними либо вручную (копирование), либо автоматически (скрипт сборки).

    [edit] У этого человека есть система, чтобы делать такие вещи: http://blog.elsdoerfer.name/2010/04/29/android-build-multiple-versions-of-a-project/

    Ответ на этот крик Gradle , как объясняется на этом сайте . Он официально встроен в Android Studio и приветствуется.

    Это потрясающе; Я создал 3 отдельных приложения, используя один и тот же исходный код, с настраиваемым текстом и графикой без специального кодирования. Требуется только какой-то каталог и настройка Gradle , а другие мои сообщения могут быть найдены с ответами на оба.

    Кажется, это объясняет все основы очень хорошо. Для ответа на ваш конкретный вопрос найдите раздел « Product Flavors в разделе « Build Variants , где описывается определение различных вкусов.

    Как поясняет веб-сайт, часть цели этого дизайна заключалась в том, чтобы сделать его более динамичным и более легко позволять создавать несколько APK с использованием, по сути, одного и того же кода, который звучит точно так же, как и то, что вы делаете.

    Я, вероятно, не объяснил это лучше всего, но этот сайт действительно неплохо работает.

    Несмотря на вашу настойчивость в том, что речь идет не о упаковке общего кода в библиотеки Android, это своего рода. Вы заявили, что рынки могут иметь разные требования или иметь бесплатную и платную версию. В каждом из этих примеров ваши два конечных выходных APK имеют другое поведение и / или ресурсы. Вы можете разместить подавляющее большинство своего кода в общей библиотеке Android, а затем сохранить различия в своих реальных проектах.

    Например, я работал над приложениями, где их нужно выпускать как на Android Market, так и в AppStore Amazon. Amazon AppStore требует, чтобы, если вы ссылаетесь на рыночную страницу для приложения, это должен быть Amazon (в отличие от страницы Android Market). Вы можете сохранить URL-адрес в ресурсе в библиотеке и использовать его в своем коде, но затем переопределить этот ресурс в проекте Amazon, чтобы указать на соответствующий URL-адрес Amazon.

    Если вы правильно структурируете это, вы можете делать подобные вещи в коде, потому что ваша отправная точка – это ваш объект приложения, с которым вы можете подclassы и делать разные вещи.

    Тем не менее, если вы хотите добавить шаг Ant, который изменяет имя пакета в манифесте, это просто XML. Это не должно быть сложно изменить как шаг предварительной компиляции.

    В этой статье есть хорошее представление о том, как изменить файлы конфигурации во время сборки; см., в частности, раздел « Настройка сборки и использования файлов конфигурации Java» . Обратите внимание, что некоторая информация о build.xml и ant немного устарела.

    У меня была такая же проблема, но упаковка всего в одном проекте с флагами не для меня. Я написал пример, как это сделать с Maven:

    Как создать несколько файлов apk для Android из одной базы кода, организованной проектом Maven multi module.

    Моя команда построила 2 разных сборки, используя единую базу кода + дополнительный код. Поскольку assembly android основана на ant-скрипте, я использую ant-скрипт для выполнения этой работы.

    Я использовал xmltask для управления манифестным файлом xml и многими ant task (regexp, copy ..) для редактирования исходного кода.

    Я подготовил шаблон шаблона проекта (включая build.xml, default.properties, local.properties) и скопировал новый исходный код в эти шаблоны проектов. когда копия завершена, запустите build.xml параллельно, чтобы сократить время сборки. при завершении сборки я получаю несколько файлов apk.

    Вот наша ситуация: у нас есть одна кодовая база, из которой мы выпускаем несколько клиентов. Каждый из них имеет различные требования в отношении названий, фона и других ресурсов в приложении (не говоря уже об именах пакетов).

    Build обрабатывается скриптом Ruby, который модифицирует AndroidManifest , копирует / заменяет определенные ресурсы из клиентских папок и затем переходит к стандартной программе Android. После завершения сборки сценарий сбрасывает файлы обратно в исходное состояние «по умолчанию».

    Ну … Может быть, это не оптимально и определенно не зависит от Android, но мы это делаем.

    Я думаю, что лучше всего использовать libray для общих источников и два разных Android-проекта для демонстрационного и производственного пакета. Это потому, что в Java очень просто сделать обратную обработку от apk к источникам. Если вы используете одни и те же источники для демонстрации и производства, кто-то может взломать ваш apk, загружая демонстрационный пакет, извлекая из него источники java и разблокируя источники, изменяющие переменную, чтобы использовать их в качестве производственной версии. С помощью библиотеки вы можете сохранить часть источников в производственном пакете, таким образом, нет возможности использовать демонстрационный пакет в качестве производственного пакета.

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

    Проверьте здесь, чтобы получить более подробную информацию.

    Давайте будем гением компьютера.