Сборка нескольких проектов Android с помощью основного файла сборки ANT - PullRequest
3 голосов
/ 10 января 2012

У меня есть основной файл сборки, который я использую для создания серии проектов Android.Каждый из этих проектов Android ссылается на один и тот же проект библиотеки Android (я назову его CoreLibrary ).Ниже приводится мое задание:

 <target name="build" description="Builds (only) all applications">
    <subant>
        <target name="debug" />
        <fileset refid="all-applications" />
    </subant>
</target>

Вопрос : Есть ли что-то, что я могу сделать, чтобы предотвратить повторную сборку CoreLibrary для каждого проекта Android ввсе-приложения набор файлов моей задачи?Это значительно ускорило бы моё время сборки, поэтому я надеюсь, что смогу кое-что сделать.

Ответы [ 3 ]

6 голосов
/ 18 апреля 2012

На самом деле, я только недавно выяснил способ решения этой проблемы. Основная идея заключается в том, что мой ANT-файл находит все проекты библиотеки, сначала строит их, а затем создает остальные мои проекты с целью nodeps. Это эффективно предотвращает ситуацию, когда CoreLibrary постоянно перекомпилируется.

<?xml version="1.0" encoding="UTF-8"?>
<project name="MasterBuild">

 <!-- A property for the name of the file that contains 'android.library=true' (which is how we find library projects) -->
<property name="library.setting.file.name" value="project.properties" />

<filelist id="normal-projects" dir=".">
    <!-- You want to add your own projects here -->
    <file name="./MyProject/build.xml" />
    <file name="./MyProject2/build.xml" />
    <file name="./MyProject3/build.xml" />
</filelist>

<fileset id="all-libraries-properties" dir=".">
    <include name="*/${library.setting.file.name}" />
    <contains casesensitive="true" text="android.library=true" />
</fileset>

<pathconvert property="all-libraries" refid="all-libraries-properties">
    <globmapper from="*${library.setting.file.name}" to="*build.xml" />
</pathconvert>    

<target name="-set-debug-mode">
    <property name="build.target" value="debug" />
    <property name="install.target" value="installd" />
</target>

<target name="-set-release-mode">
    <property name="build.target" value="release" />
    <property name="install.target" value="installr" />
</target>

<target name="-build-dependencies" unless="built.dependencies">
    <property name="built.dependencies" value="true" />
    <subant buildpath="${all-libraries}" target="${build.target}" inheritall="false" />
</target>

<target name="-build-normal-projects" depends="-build-dependencies">
    <subant inheritall="false">
        <target name="nodeps" />
        <target name="${build.target}" />
        <resources refid="normal-projects" />
    </subant>
</target>

<target name="-install-normal-projects">
    <subant inheritall="false">
        <target name="${install.target}" />
        <resources refid="normal-projects" />
    </subant>
</target>

<target name="debug" depends="-set-debug-mode, -build-normal-projects" description="Builds (only) a debug-key signed application" />
<target name="release" depends="-set-release-mode, -build-normal-projects" description="Builds (only) a release-key signed application" />

<target name="installd" depends="-set-debug-mode, -install-normal-projects" description="Installs (only) a debug-key signed application" />
<target name="installr" depends="-set-release-mode, -install-normal-projects" description="Installs (only) a release-key signed application" />

</project>

Примечание Это решение могло бы быть улучшено, если бы я написал задачу, которая фактически нашла порядок зависимости библиотек, чтобы я мог создавать библиотеки с целью nodeps. Кроме того, возможно, есть способ автоматически определять «нормальные проекты», но мне это пока не нужно. Наконец, я развернул довольно много вещей из моего обычного файла ANT, чтобы перенести это сюда, надеюсь, я ничего не пропустил. Концепция, однако, присутствует.

1 голос
/ 25 апреля 2012

Если вы используете плагин Android Maven, вы можете просто собрать все соответствующие части по отдельности или в виде модулей и повторно использовать свою базовую библиотеку как jar или как apklib (если у них есть ресурсы и тому подобное). Встроенный механизм зависимостей Maven позаботится об интеграции различных библиотек.

Посмотрите, например, RoboGuice или ActionBarSherlock и их примеры приложений, чтобы увидеть, как это работает.

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

0 голосов
/ 05 апреля 2012

Если ваши библиотечные проекты предназначены только для java (без ресурсов), вы уже можете распространять их как jar, а затем управлять проблемами с помощью задачи ivy + ivy ant для разрешения зависимостей в файле сборки. но они все равно будут собираться из классов в файлы dex.

...