Clean up build scripts to make it harder to fail.
* Don't apply android plugin in root project
This results in the root project being treated like and Android project.
That is, gradle will expect an AndroidManifest, a targetSdk property, and
all sorts of stuff that is not relevant to the root project.
Perhaps more importantly, this breaks integration with Android Studio,
which is the tool that many potential contributors will be using.
Finally, it also allows runing gradle tasks in the root project, rather
than having to cd into the F-Droid directory, which is a minor nicety.
The reason it was there in the first place was to make it so that we could
find the location of the Android SDK using the same mechanism that the
plugin used. To deal with this, this commit adapts the SDK finding code
from the gradle plugin.
* Make gradle error out when missing depenencies.
The support v4 library requires some obsolte SDKs that are likely
not installed. It caused non-intuitive errors to come up for me,
so I've made gradle tell the user when this occurs.
* Documented the main build.gradle file
This is primarily to explain the hacks we use in order to build the
Android support libraries.
2014-12-27 21:53:30 +11:00
|
|
|
/**
|
|
|
|
* This is *NOT* the main build script for F-Droid. The main build.gradle
|
|
|
|
* is in F-Droid/build.gradle. Usually multi-project builds don't have a
|
|
|
|
* build.gradle in the top level directory (http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Dependencies-Android-Libraries-and-Multi-project-setup).
|
|
|
|
*
|
|
|
|
* This build script contains miscellaneous hacks to ensure that all of
|
|
|
|
* F-Droids dependencies can be built from source.
|
|
|
|
* Each hack should be documented, and in the future, may need to be changed
|
|
|
|
* in order to ensure that we keep pace with any changes upstream makes to
|
|
|
|
* their build processes.
|
|
|
|
*
|
|
|
|
* - Some subprojects don't have gradle build scripts, so they are setup here.
|
|
|
|
*
|
|
|
|
* - The android support libraries make a lot of dependencies about the project
|
|
|
|
* two folders up from themselves, which we will have to provide for them.
|
|
|
|
*/
|
|
|
|
|
2013-11-27 15:47:13 +01:00
|
|
|
buildscript {
|
2014-11-15 22:14:14 +01:00
|
|
|
repositories {
|
Default to binary dependencies, with option for source builds.
NOTE: This commit does not touch the ant build system at all,
only gradle.
There are currently 23 gradle projects which require configuration,
let alone building, in order to build F-Droid. This takes a non-trivial
amount of time/memory/cpu. Additionally, it also provides difficulties
when importing the project into Android Studio - which is the IDE that
many potential contributors will be using. Finally, I have over 100mb
of data in the extern/ folder, and the support libraries require almost
every single Android SDK to be installed, which is several GB. This is
not a friendly environment to encourage people to submit merge requests.
However, I'm very mindful of the need for an open source project such
as F-Droid to be able to be built from source. So to make sure we have
the best of both worlds, I've ensured that building all dependencies
from source is still possible.
The F-Droid/libs/README.md file explains in greater detail how to
do this (i.e. "gradle -PsourceDeps build").
As much as possible, I've tried to make the binary dependencies fetched
from jcenter. However there are still libraries which either haven't
integrated required changes for F-Droid back upstream, or don't have
mavenCentral/jcenter binaries available.
Android preference fragment has been changed to the original
upstream repository. The one we had before was because upstream
hadn't merged a MR for gradfle support yet. However, that has
now been merged. This version still doesn't exist in jcenter though.
In order for libsuperuser to build from upstream, using
`gradle -PsourceDeps`, we need to include a few gradle plugins
from jcenter which are never actually used (used by upstream to
release to jcenter).
Even though support-v4 is included through jcenter, it is kept in
the libs directory, so that ./ant-prepare.sh can use it.
Update support preference fragment to newer version. There has been
bugfixes commited, so lets include them in the version we are using.
2015-03-01 10:20:19 +11:00
|
|
|
jcenter()
|
2014-11-15 22:14:14 +01:00
|
|
|
}
|
|
|
|
dependencies {
|
2015-01-04 00:32:30 +01:00
|
|
|
classpath 'com.android.tools.build:gradle:1.0.0'
|
Default to binary dependencies, with option for source builds.
NOTE: This commit does not touch the ant build system at all,
only gradle.
There are currently 23 gradle projects which require configuration,
let alone building, in order to build F-Droid. This takes a non-trivial
amount of time/memory/cpu. Additionally, it also provides difficulties
when importing the project into Android Studio - which is the IDE that
many potential contributors will be using. Finally, I have over 100mb
of data in the extern/ folder, and the support libraries require almost
every single Android SDK to be installed, which is several GB. This is
not a friendly environment to encourage people to submit merge requests.
However, I'm very mindful of the need for an open source project such
as F-Droid to be able to be built from source. So to make sure we have
the best of both worlds, I've ensured that building all dependencies
from source is still possible.
The F-Droid/libs/README.md file explains in greater detail how to
do this (i.e. "gradle -PsourceDeps build").
As much as possible, I've tried to make the binary dependencies fetched
from jcenter. However there are still libraries which either haven't
integrated required changes for F-Droid back upstream, or don't have
mavenCentral/jcenter binaries available.
Android preference fragment has been changed to the original
upstream repository. The one we had before was because upstream
hadn't merged a MR for gradfle support yet. However, that has
now been merged. This version still doesn't exist in jcenter though.
In order for libsuperuser to build from upstream, using
`gradle -PsourceDeps`, we need to include a few gradle plugins
from jcenter which are never actually used (used by upstream to
release to jcenter).
Even though support-v4 is included through jcenter, it is kept in
the libs directory, so that ./ant-prepare.sh can use it.
Update support preference fragment to newer version. There has been
bugfixes commited, so lets include them in the version we are using.
2015-03-01 10:20:19 +11:00
|
|
|
|
|
|
|
// libsuperuser submodule requires these plugins, even though
|
|
|
|
// the F-Droid build process never invokes code from them. It
|
|
|
|
// would be nice to do away with this in the future, so we don't
|
|
|
|
// force people do download stuff they wont use.
|
|
|
|
classpath 'com.jfrog.bintray.gradle:gradle-bintray-plugin:1.0'
|
|
|
|
classpath 'com.github.dcendents:android-maven-plugin:1.2'
|
2014-11-15 22:14:14 +01:00
|
|
|
}
|
2013-11-27 15:47:13 +01:00
|
|
|
}
|
|
|
|
|
Default to binary dependencies, with option for source builds.
NOTE: This commit does not touch the ant build system at all,
only gradle.
There are currently 23 gradle projects which require configuration,
let alone building, in order to build F-Droid. This takes a non-trivial
amount of time/memory/cpu. Additionally, it also provides difficulties
when importing the project into Android Studio - which is the IDE that
many potential contributors will be using. Finally, I have over 100mb
of data in the extern/ folder, and the support libraries require almost
every single Android SDK to be installed, which is several GB. This is
not a friendly environment to encourage people to submit merge requests.
However, I'm very mindful of the need for an open source project such
as F-Droid to be able to be built from source. So to make sure we have
the best of both worlds, I've ensured that building all dependencies
from source is still possible.
The F-Droid/libs/README.md file explains in greater detail how to
do this (i.e. "gradle -PsourceDeps build").
As much as possible, I've tried to make the binary dependencies fetched
from jcenter. However there are still libraries which either haven't
integrated required changes for F-Droid back upstream, or don't have
mavenCentral/jcenter binaries available.
Android preference fragment has been changed to the original
upstream repository. The one we had before was because upstream
hadn't merged a MR for gradfle support yet. However, that has
now been merged. This version still doesn't exist in jcenter though.
In order for libsuperuser to build from upstream, using
`gradle -PsourceDeps`, we need to include a few gradle plugins
from jcenter which are never actually used (used by upstream to
release to jcenter).
Even though support-v4 is included through jcenter, it is kept in
the libs directory, so that ./ant-prepare.sh can use it.
Update support preference fragment to newer version. There has been
bugfixes commited, so lets include them in the version we are using.
2015-03-01 10:20:19 +11:00
|
|
|
if ( hasProperty( 'sourceDeps' ) ) {
|
|
|
|
|
2014-03-22 11:44:27 +01:00
|
|
|
project(':extern:UniversalImageLoader:library') {
|
2014-11-15 22:14:14 +01:00
|
|
|
|
|
|
|
apply plugin: 'android-library'
|
|
|
|
|
|
|
|
android {
|
|
|
|
compileSdkVersion 16
|
Clean up build scripts to make it harder to fail.
* Don't apply android plugin in root project
This results in the root project being treated like and Android project.
That is, gradle will expect an AndroidManifest, a targetSdk property, and
all sorts of stuff that is not relevant to the root project.
Perhaps more importantly, this breaks integration with Android Studio,
which is the tool that many potential contributors will be using.
Finally, it also allows runing gradle tasks in the root project, rather
than having to cd into the F-Droid directory, which is a minor nicety.
The reason it was there in the first place was to make it so that we could
find the location of the Android SDK using the same mechanism that the
plugin used. To deal with this, this commit adapts the SDK finding code
from the gradle plugin.
* Make gradle error out when missing depenencies.
The support v4 library requires some obsolte SDKs that are likely
not installed. It caused non-intuitive errors to come up for me,
so I've made gradle tell the user when this occurs.
* Documented the main build.gradle file
This is primarily to explain the hacks we use in order to build the
Android support libraries.
2014-12-27 21:53:30 +11:00
|
|
|
buildToolsVersion '21.1.2'
|
2014-11-15 22:14:14 +01:00
|
|
|
|
|
|
|
sourceSets {
|
|
|
|
main {
|
|
|
|
manifest.srcFile 'AndroidManifest.xml'
|
|
|
|
java.srcDirs = ['src']
|
|
|
|
resources.srcDirs = ['src']
|
|
|
|
aidl.srcDirs = ['src']
|
|
|
|
renderscript.srcDirs = ['src']
|
|
|
|
res.srcDirs = ['res']
|
|
|
|
assets.srcDirs = ['assets']
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2014-02-15 12:31:15 +01:00
|
|
|
}
|
|
|
|
|
Clean up build scripts to make it harder to fail.
* Don't apply android plugin in root project
This results in the root project being treated like and Android project.
That is, gradle will expect an AndroidManifest, a targetSdk property, and
all sorts of stuff that is not relevant to the root project.
Perhaps more importantly, this breaks integration with Android Studio,
which is the tool that many potential contributors will be using.
Finally, it also allows runing gradle tasks in the root project, rather
than having to cd into the F-Droid directory, which is a minor nicety.
The reason it was there in the first place was to make it so that we could
find the location of the Android SDK using the same mechanism that the
plugin used. To deal with this, this commit adapts the SDK finding code
from the gradle plugin.
* Make gradle error out when missing depenencies.
The support v4 library requires some obsolte SDKs that are likely
not installed. It caused non-intuitive errors to come up for me,
so I've made gradle tell the user when this occurs.
* Documented the main build.gradle file
This is primarily to explain the hacks we use in order to build the
Android support libraries.
2014-12-27 21:53:30 +11:00
|
|
|
// The support-annotations build.gradle uses the mavenDeployer method, which requires
|
|
|
|
// this plugin. Even though no artifacts are being deployed, this is still required
|
|
|
|
// for the build script to work.
|
2014-12-27 11:10:43 +11:00
|
|
|
project(':support-annotations') {
|
|
|
|
|
|
|
|
apply plugin: 'maven'
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2014-05-23 11:06:32 +02:00
|
|
|
project(':extern:zipsigner') {
|
|
|
|
|
2014-11-15 22:14:14 +01:00
|
|
|
apply plugin: 'java'
|
2014-05-23 11:06:32 +02:00
|
|
|
|
2014-11-15 22:14:14 +01:00
|
|
|
dependencies {
|
|
|
|
compile project(':extern:spongycastle:core')
|
|
|
|
compile project(':extern:spongycastle:pkix')
|
|
|
|
compile project(':extern:spongycastle:prov')
|
|
|
|
}
|
2014-05-23 11:06:32 +02:00
|
|
|
}
|
|
|
|
|
2014-11-15 22:14:14 +01:00
|
|
|
project(':support-v4') {
|
2014-11-05 21:36:35 +01:00
|
|
|
|
2014-11-15 22:14:14 +01:00
|
|
|
apply plugin: 'maven'
|
2014-05-18 12:54:21 +02:00
|
|
|
|
2014-12-30 23:48:36 +01:00
|
|
|
// The support-v4 library assumes certain things are defined in the
|
|
|
|
// root project (which is usually the android-support project, but
|
2014-11-15 22:14:14 +01:00
|
|
|
// this time it is the F-Droid project.
|
|
|
|
rootProject.ext.supportRepoOut = ""
|
2014-06-04 23:12:49 -04:00
|
|
|
|
2013-11-27 15:47:13 +01:00
|
|
|
}
|
2014-05-27 06:30:09 +09:30
|
|
|
|
Default to binary dependencies, with option for source builds.
NOTE: This commit does not touch the ant build system at all,
only gradle.
There are currently 23 gradle projects which require configuration,
let alone building, in order to build F-Droid. This takes a non-trivial
amount of time/memory/cpu. Additionally, it also provides difficulties
when importing the project into Android Studio - which is the IDE that
many potential contributors will be using. Finally, I have over 100mb
of data in the extern/ folder, and the support libraries require almost
every single Android SDK to be installed, which is several GB. This is
not a friendly environment to encourage people to submit merge requests.
However, I'm very mindful of the need for an open source project such
as F-Droid to be able to be built from source. So to make sure we have
the best of both worlds, I've ensured that building all dependencies
from source is still possible.
The F-Droid/libs/README.md file explains in greater detail how to
do this (i.e. "gradle -PsourceDeps build").
As much as possible, I've tried to make the binary dependencies fetched
from jcenter. However there are still libraries which either haven't
integrated required changes for F-Droid back upstream, or don't have
mavenCentral/jcenter binaries available.
Android preference fragment has been changed to the original
upstream repository. The one we had before was because upstream
hadn't merged a MR for gradfle support yet. However, that has
now been merged. This version still doesn't exist in jcenter though.
In order for libsuperuser to build from upstream, using
`gradle -PsourceDeps`, we need to include a few gradle plugins
from jcenter which are never actually used (used by upstream to
release to jcenter).
Even though support-v4 is included through jcenter, it is kept in
the libs directory, so that ./ant-prepare.sh can use it.
Update support preference fragment to newer version. There has been
bugfixes commited, so lets include them in the version we are using.
2015-03-01 10:20:19 +11:00
|
|
|
}
|
|
|
|
|
2014-05-27 06:30:09 +09:30
|
|
|
/**
|
Clean up build scripts to make it harder to fail.
* Don't apply android plugin in root project
This results in the root project being treated like and Android project.
That is, gradle will expect an AndroidManifest, a targetSdk property, and
all sorts of stuff that is not relevant to the root project.
Perhaps more importantly, this breaks integration with Android Studio,
which is the tool that many potential contributors will be using.
Finally, it also allows runing gradle tasks in the root project, rather
than having to cd into the F-Droid directory, which is a minor nicety.
The reason it was there in the first place was to make it so that we could
find the location of the Android SDK using the same mechanism that the
plugin used. To deal with this, this commit adapts the SDK finding code
from the gradle plugin.
* Make gradle error out when missing depenencies.
The support v4 library requires some obsolte SDKs that are likely
not installed. It caused non-intuitive errors to come up for me,
so I've made gradle tell the user when this occurs.
* Documented the main build.gradle file
This is primarily to explain the hacks we use in order to build the
Android support libraries.
2014-12-27 21:53:30 +11:00
|
|
|
* Finds a reference to the prefered Android SDK directory.
|
|
|
|
* Ideally we'd use "android.plugin.sdkFolder" to find this, however this is
|
|
|
|
* only possible if we apply the android application plugin. This is not ideal,
|
2014-12-30 23:48:36 +01:00
|
|
|
* because it will add a bunch of tasks to do with building an android app,
|
Clean up build scripts to make it harder to fail.
* Don't apply android plugin in root project
This results in the root project being treated like and Android project.
That is, gradle will expect an AndroidManifest, a targetSdk property, and
all sorts of stuff that is not relevant to the root project.
Perhaps more importantly, this breaks integration with Android Studio,
which is the tool that many potential contributors will be using.
Finally, it also allows runing gradle tasks in the root project, rather
than having to cd into the F-Droid directory, which is a minor nicety.
The reason it was there in the first place was to make it so that we could
find the location of the Android SDK using the same mechanism that the
plugin used. To deal with this, this commit adapts the SDK finding code
from the gradle plugin.
* Make gradle error out when missing depenencies.
The support v4 library requires some obsolte SDKs that are likely
not installed. It caused non-intuitive errors to come up for me,
so I've made gradle tell the user when this occurs.
* Documented the main build.gradle file
This is primarily to explain the hacks we use in order to build the
Android support libraries.
2014-12-27 21:53:30 +11:00
|
|
|
* even tnough this build.gradle is not here to build F-Droid, it is here to
|
|
|
|
* apply hacks to play nicely with various upstream projects.
|
2014-12-30 23:48:36 +01:00
|
|
|
*
|
Clean up build scripts to make it harder to fail.
* Don't apply android plugin in root project
This results in the root project being treated like and Android project.
That is, gradle will expect an AndroidManifest, a targetSdk property, and
all sorts of stuff that is not relevant to the root project.
Perhaps more importantly, this breaks integration with Android Studio,
which is the tool that many potential contributors will be using.
Finally, it also allows runing gradle tasks in the root project, rather
than having to cd into the F-Droid directory, which is a minor nicety.
The reason it was there in the first place was to make it so that we could
find the location of the Android SDK using the same mechanism that the
plugin used. To deal with this, this commit adapts the SDK finding code
from the gradle plugin.
* Make gradle error out when missing depenencies.
The support v4 library requires some obsolte SDKs that are likely
not installed. It caused non-intuitive errors to come up for me,
so I've made gradle tell the user when this occurs.
* Documented the main build.gradle file
This is primarily to explain the hacks we use in order to build the
Android support libraries.
2014-12-27 21:53:30 +11:00
|
|
|
* Adapted from https://android.googlesource.com/platform/tools/base/+/c8b776289ace4189406b59a9a9c8c9de63271cb0/build-system/gradle/src/main/groovy/com/android/build/gradle/internal/SdkHandler.java
|
|
|
|
* Copyright (C) 2014 The Android Open Source Project
|
2014-12-30 23:48:36 +01:00
|
|
|
* Licensed under the Apache License, Version 2.0
|
Clean up build scripts to make it harder to fail.
* Don't apply android plugin in root project
This results in the root project being treated like and Android project.
That is, gradle will expect an AndroidManifest, a targetSdk property, and
all sorts of stuff that is not relevant to the root project.
Perhaps more importantly, this breaks integration with Android Studio,
which is the tool that many potential contributors will be using.
Finally, it also allows runing gradle tasks in the root project, rather
than having to cd into the F-Droid directory, which is a minor nicety.
The reason it was there in the first place was to make it so that we could
find the location of the Android SDK using the same mechanism that the
plugin used. To deal with this, this commit adapts the SDK finding code
from the gradle plugin.
* Make gradle error out when missing depenencies.
The support v4 library requires some obsolte SDKs that are likely
not installed. It caused non-intuitive errors to come up for me,
so I've made gradle tell the user when this occurs.
* Documented the main build.gradle file
This is primarily to explain the hacks we use in order to build the
Android support libraries.
2014-12-27 21:53:30 +11:00
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0i
|
2014-05-27 06:30:09 +09:30
|
|
|
*/
|
Clean up build scripts to make it harder to fail.
* Don't apply android plugin in root project
This results in the root project being treated like and Android project.
That is, gradle will expect an AndroidManifest, a targetSdk property, and
all sorts of stuff that is not relevant to the root project.
Perhaps more importantly, this breaks integration with Android Studio,
which is the tool that many potential contributors will be using.
Finally, it also allows runing gradle tasks in the root project, rather
than having to cd into the F-Droid directory, which is a minor nicety.
The reason it was there in the first place was to make it so that we could
find the location of the Android SDK using the same mechanism that the
plugin used. To deal with this, this commit adapts the SDK finding code
from the gradle plugin.
* Make gradle error out when missing depenencies.
The support v4 library requires some obsolte SDKs that are likely
not installed. It caused non-intuitive errors to come up for me,
so I've made gradle tell the user when this occurs.
* Documented the main build.gradle file
This is primarily to explain the hacks we use in order to build the
Android support libraries.
2014-12-27 21:53:30 +11:00
|
|
|
def findSdkPath() {
|
2014-12-30 23:48:36 +01:00
|
|
|
|
Clean up build scripts to make it harder to fail.
* Don't apply android plugin in root project
This results in the root project being treated like and Android project.
That is, gradle will expect an AndroidManifest, a targetSdk property, and
all sorts of stuff that is not relevant to the root project.
Perhaps more importantly, this breaks integration with Android Studio,
which is the tool that many potential contributors will be using.
Finally, it also allows runing gradle tasks in the root project, rather
than having to cd into the F-Droid directory, which is a minor nicety.
The reason it was there in the first place was to make it so that we could
find the location of the Android SDK using the same mechanism that the
plugin used. To deal with this, this commit adapts the SDK finding code
from the gradle plugin.
* Make gradle error out when missing depenencies.
The support v4 library requires some obsolte SDKs that are likely
not installed. It caused non-intuitive errors to come up for me,
so I've made gradle tell the user when this occurs.
* Documented the main build.gradle file
This is primarily to explain the hacks we use in order to build the
Android support libraries.
2014-12-27 21:53:30 +11:00
|
|
|
Properties properties = new Properties()
|
|
|
|
File propFile = file("local.properties")
|
|
|
|
if (propFile.exists()) {
|
|
|
|
propFile.withReader { properties.load(it) }
|
|
|
|
}
|
2014-12-30 23:48:36 +01:00
|
|
|
|
Clean up build scripts to make it harder to fail.
* Don't apply android plugin in root project
This results in the root project being treated like and Android project.
That is, gradle will expect an AndroidManifest, a targetSdk property, and
all sorts of stuff that is not relevant to the root project.
Perhaps more importantly, this breaks integration with Android Studio,
which is the tool that many potential contributors will be using.
Finally, it also allows runing gradle tasks in the root project, rather
than having to cd into the F-Droid directory, which is a minor nicety.
The reason it was there in the first place was to make it so that we could
find the location of the Android SDK using the same mechanism that the
plugin used. To deal with this, this commit adapts the SDK finding code
from the gradle plugin.
* Make gradle error out when missing depenencies.
The support v4 library requires some obsolte SDKs that are likely
not installed. It caused non-intuitive errors to come up for me,
so I've made gradle tell the user when this occurs.
* Documented the main build.gradle file
This is primarily to explain the hacks we use in order to build the
Android support libraries.
2014-12-27 21:53:30 +11:00
|
|
|
String sdkDirProp = properties.getProperty("sdk.dir");
|
|
|
|
if (sdkDirProp != null) {
|
|
|
|
return new File(sdkDirProp)
|
|
|
|
}
|
|
|
|
|
|
|
|
String envVar = System.getenv("ANDROID_HOME");
|
|
|
|
if (envVar != null) {
|
|
|
|
return new File(envVar);
|
|
|
|
}
|
2014-12-30 23:48:36 +01:00
|
|
|
|
Clean up build scripts to make it harder to fail.
* Don't apply android plugin in root project
This results in the root project being treated like and Android project.
That is, gradle will expect an AndroidManifest, a targetSdk property, and
all sorts of stuff that is not relevant to the root project.
Perhaps more importantly, this breaks integration with Android Studio,
which is the tool that many potential contributors will be using.
Finally, it also allows runing gradle tasks in the root project, rather
than having to cd into the F-Droid directory, which is a minor nicety.
The reason it was there in the first place was to make it so that we could
find the location of the Android SDK using the same mechanism that the
plugin used. To deal with this, this commit adapts the SDK finding code
from the gradle plugin.
* Make gradle error out when missing depenencies.
The support v4 library requires some obsolte SDKs that are likely
not installed. It caused non-intuitive errors to come up for me,
so I've made gradle tell the user when this occurs.
* Documented the main build.gradle file
This is primarily to explain the hacks we use in order to build the
Android support libraries.
2014-12-27 21:53:30 +11:00
|
|
|
String property = System.getProperty("android.home");
|
|
|
|
if (property != null) {
|
|
|
|
return new File(property);
|
|
|
|
}
|
|
|
|
|
|
|
|
def error = """
|
|
|
|
Couldn't find Android SDK. Looked for (in order of precedence):
|
|
|
|
* sdk.dir in $propFile
|
|
|
|
* ANDROID_HOME environment variable
|
|
|
|
* android.home Java property
|
|
|
|
"""
|
|
|
|
|
|
|
|
throw new RuntimeException(error)
|
2014-05-27 06:30:09 +09:30
|
|
|
}
|
2014-11-15 22:14:14 +01:00
|
|
|
|
Clean up build scripts to make it harder to fail.
* Don't apply android plugin in root project
This results in the root project being treated like and Android project.
That is, gradle will expect an AndroidManifest, a targetSdk property, and
all sorts of stuff that is not relevant to the root project.
Perhaps more importantly, this breaks integration with Android Studio,
which is the tool that many potential contributors will be using.
Finally, it also allows runing gradle tasks in the root project, rather
than having to cd into the F-Droid directory, which is a minor nicety.
The reason it was there in the first place was to make it so that we could
find the location of the Android SDK using the same mechanism that the
plugin used. To deal with this, this commit adapts the SDK finding code
from the gradle plugin.
* Make gradle error out when missing depenencies.
The support v4 library requires some obsolte SDKs that are likely
not installed. It caused non-intuitive errors to come up for me,
so I've made gradle tell the user when this occurs.
* Documented the main build.gradle file
This is primarily to explain the hacks we use in order to build the
Android support libraries.
2014-12-27 21:53:30 +11:00
|
|
|
// Used by the support-v4 libraries build script.
|
2014-11-15 22:14:14 +01:00
|
|
|
FileCollection getAndroidPrebuilt(String apiLevel) {
|
Clean up build scripts to make it harder to fail.
* Don't apply android plugin in root project
This results in the root project being treated like and Android project.
That is, gradle will expect an AndroidManifest, a targetSdk property, and
all sorts of stuff that is not relevant to the root project.
Perhaps more importantly, this breaks integration with Android Studio,
which is the tool that many potential contributors will be using.
Finally, it also allows runing gradle tasks in the root project, rather
than having to cd into the F-Droid directory, which is a minor nicety.
The reason it was there in the first place was to make it so that we could
find the location of the Android SDK using the same mechanism that the
plugin used. To deal with this, this commit adapts the SDK finding code
from the gradle plugin.
* Make gradle error out when missing depenencies.
The support v4 library requires some obsolte SDKs that are likely
not installed. It caused non-intuitive errors to come up for me,
so I've made gradle tell the user when this occurs.
* Documented the main build.gradle file
This is primarily to explain the hacks we use in order to build the
Android support libraries.
2014-12-27 21:53:30 +11:00
|
|
|
|
|
|
|
def file = new File("${findSdkPath()}/platforms/android-$apiLevel/android.jar")
|
|
|
|
if (!file.exists()) {
|
|
|
|
def msg = """
|
|
|
|
Android SDK for android-$apiLevel not found (required for building support library).
|
|
|
|
Expected to find it at $file.
|
|
|
|
Do you have that SDK installed?
|
|
|
|
(If it is not visible in the Android SDK Manager, "Packages -> Show Obsolete Packages")
|
|
|
|
"""
|
|
|
|
throw new RuntimeException(msg)
|
|
|
|
}
|
|
|
|
|
|
|
|
return files(file)
|
|
|
|
|
2014-11-15 22:14:14 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
subprojects {
|
|
|
|
|
|
|
|
// This is the hacky way which we force the subprojects to use the same build tools:
|
|
|
|
// http://stackoverflow.com/a/21032272
|
|
|
|
afterEvaluate {
|
Clean up build scripts to make it harder to fail.
* Don't apply android plugin in root project
This results in the root project being treated like and Android project.
That is, gradle will expect an AndroidManifest, a targetSdk property, and
all sorts of stuff that is not relevant to the root project.
Perhaps more importantly, this breaks integration with Android Studio,
which is the tool that many potential contributors will be using.
Finally, it also allows runing gradle tasks in the root project, rather
than having to cd into the F-Droid directory, which is a minor nicety.
The reason it was there in the first place was to make it so that we could
find the location of the Android SDK using the same mechanism that the
plugin used. To deal with this, this commit adapts the SDK finding code
from the gradle plugin.
* Make gradle error out when missing depenencies.
The support v4 library requires some obsolte SDKs that are likely
not installed. It caused non-intuitive errors to come up for me,
so I've made gradle tell the user when this occurs.
* Documented the main build.gradle file
This is primarily to explain the hacks we use in order to build the
Android support libraries.
2014-12-27 21:53:30 +11:00
|
|
|
if ( it.hasProperty( 'android' ) ) {
|
|
|
|
android {
|
|
|
|
|
|
|
|
// The android build task only lets you configure the buildToolsVersion once, so if
|
|
|
|
// we execute the closure below to configure our subprojects, it will fail when it
|
|
|
|
// hits the second subproject. Therefore, we will only do it once, and I guess the
|
|
|
|
// android plugin will re-use the existing value I set.
|
|
|
|
// https://android.googlesource.com/platform/tools/build/+/master/gradle/src/main/groovy/com/android/build/gradle/BaseExtension.groovy
|
|
|
|
try {
|
|
|
|
buildToolsVersion '21.1.2'
|
|
|
|
logger.info("Set buildToolsVersion to '21.1.2'")
|
|
|
|
} catch (GradleException e) {
|
|
|
|
logger.info("Tried to set the buildToolsVersion, however we were not allowed to: $e.message")
|
|
|
|
}
|
2015-01-19 15:07:52 +01:00
|
|
|
|
|
|
|
// don't abort build on lint errors
|
|
|
|
// http://stackoverflow.com/a/25149514
|
|
|
|
configure(android.lintOptions) {
|
|
|
|
abortOnError false
|
|
|
|
}
|
2014-11-15 22:14:14 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|