2012-05-21 11:12:37 +00:00
|
|
|
# This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
|
# License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
|
# file, You can obtain one at http://mozilla.org/MPL/2.0/.
|
2011-11-18 18:28:17 +00:00
|
|
|
|
2012-08-31 13:31:29 +00:00
|
|
|
MOZ_APP_BUILDID=$(shell cat $(DEPTH)/config/buildid)
|
|
|
|
|
|
2015-09-11 22:05:56 +00:00
|
|
|
# Set the appropriate version code, based on the existance of the
|
|
|
|
|
# MOZ_APP_ANDROID_VERSION_CODE variable.
|
|
|
|
|
ifdef MOZ_APP_ANDROID_VERSION_CODE
|
|
|
|
|
ANDROID_VERSION_CODE:=$(MOZ_APP_ANDROID_VERSION_CODE)
|
|
|
|
|
else
|
|
|
|
|
ANDROID_VERSION_CODE:=$(shell $(PYTHON) \
|
|
|
|
|
$(topsrcdir)/python/mozbuild/mozbuild/android_version_code.py \
|
|
|
|
|
--verbose \
|
|
|
|
|
--with-android-cpu-arch=$(ANDROID_CPU_ARCH) \
|
|
|
|
|
$(if $(MOZ_ANDROID_MIN_SDK_VERSION),--with-android-min-sdk=$(MOZ_ANDROID_MIN_SDK_VERSION)) \
|
|
|
|
|
$(if $(MOZ_ANDROID_MAX_SDK_VERSION),--with-android-max-sdk=$(MOZ_ANDROID_MAX_SDK_VERSION)) \
|
|
|
|
|
$(MOZ_APP_BUILDID))
|
|
|
|
|
endif
|
2011-11-18 18:28:17 +00:00
|
|
|
|
|
|
|
|
DEFINES += \
|
2013-05-16 03:08:43 +00:00
|
|
|
-DANDROID_VERSION_CODE=$(ANDROID_VERSION_CODE) \
|
2013-10-10 23:08:58 +00:00
|
|
|
-DMOZ_ANDROID_SHARED_ID="$(MOZ_ANDROID_SHARED_ID)" \
|
|
|
|
|
-DMOZ_ANDROID_SHARED_ACCOUNT_TYPE="$(MOZ_ANDROID_SHARED_ACCOUNT_TYPE)" \
|
2013-10-13 04:50:38 +00:00
|
|
|
-DMOZ_ANDROID_SHARED_FXACCOUNT_TYPE="$(MOZ_ANDROID_SHARED_FXACCOUNT_TYPE)" \
|
2013-05-16 03:08:43 +00:00
|
|
|
-DMOZ_APP_BUILDID=$(MOZ_APP_BUILDID) \
|
2011-11-18 18:28:17 +00:00
|
|
|
$(NULL)
|
|
|
|
|
|
|
|
|
|
GARBAGE += \
|
|
|
|
|
classes.dex \
|
2012-06-11 21:54:17 +00:00
|
|
|
gecko.ap_ \
|
|
|
|
|
res/values/strings.xml \
|
2014-10-02 06:23:29 +00:00
|
|
|
res/raw/browsersearch.json \
|
2014-05-09 08:39:14 +00:00
|
|
|
res/raw/suggestedsites.json \
|
2013-11-12 04:39:16 +00:00
|
|
|
.aapt.deps \
|
2013-02-08 21:42:13 +00:00
|
|
|
javah.out \
|
|
|
|
|
jni-stubs.inc \
|
2015-07-11 03:41:36 +00:00
|
|
|
GeneratedJNINatives.h \
|
2013-09-09 12:57:37 +00:00
|
|
|
GeneratedJNIWrappers.cpp \
|
|
|
|
|
GeneratedJNIWrappers.h \
|
2011-11-18 18:28:17 +00:00
|
|
|
$(NULL)
|
|
|
|
|
|
2013-11-12 04:39:16 +00:00
|
|
|
GARBAGE_DIRS += classes db jars res sync services generated
|
2011-11-18 18:28:17 +00:00
|
|
|
|
2014-12-05 19:50:48 +00:00
|
|
|
# The bootclasspath is functionally identical to the classpath, but allows the
|
|
|
|
|
# classes given to redefine classes in core packages, such as java.lang.
|
|
|
|
|
# android.jar is here as it provides Android's definition of the Java Standard
|
|
|
|
|
# Library. The compatability lib here tweaks a few of the core classes to paint
|
|
|
|
|
# over changes in behaviour between versions.
|
|
|
|
|
JAVA_BOOTCLASSPATH := \
|
2014-06-11 18:00:17 +00:00
|
|
|
$(ANDROID_SDK)/android.jar \
|
|
|
|
|
$(NULL)
|
|
|
|
|
|
|
|
|
|
JAVA_BOOTCLASSPATH := $(subst $(NULL) ,:,$(strip $(JAVA_BOOTCLASSPATH)))
|
|
|
|
|
|
Bug 1108782 - Part 2: Explode AAR files at configure time. r=glandium
This gets us a limited version of AAR support: we can consume static
AAR libraries, where here static does not refer to linking, but to
static assets that are fixed at build-backend time and not modified
(or produced) during the build. This lets us pin our dependencies
(and move to Google's versioned Maven repository packages, away from
Google's unversioned ad-hoc packages).
By restricting to static AAR libraries, we avoid having to handle
truly complicated dependency trees, as changing parts of generated AAR
files require delicate rebuilding of the APKs (and internal libraries)
that depend on the AAR files.
It is possible that we will generate AARs in the tree at some time.
Right now, we don't do that, even for GeckoView: the AARs produced are
assembled as artifacts at package time and are intended for external
consumption. We might want this for GeckoView and Fennec at some
time; we should consider using Gradle everywhere at that point.
The patch itself does the simplest possible thing (which has precedent
from Gradle and other build systems): it simply "explodes" the AAR
into the object directory and uses existing mechanisms to refer to the
exploded pieces.
AARs have both required and optional components. Each component is
defined with an expected and required flag. If a component is expected
and not present, or not expected and is present, an error is raised.
If the component is expected and present, autoconf's ifelse() macro is
used to define the relevant AAR_* component variables. If the
component is not expected and not present, no action is taken. A
consuming build backend therefore can guard all AAR_* component
variables with just the top-level AAR variable.
Many AAR files have empty assets/ directories. This patch doesn't
explode empty assets/ directories, protecting against trivial changes
to AAR files that don't impact the build.
There's a lot not to like in this approach, including:
* We need to manually reference internal AAR libs;
* I haven't separated the pinned version numbers out of configure.in.
However, it's closer to what we want than what we have!
--HG--
extra : commitid : 11kUhDAkCn5
extra : rebase_source : 2454c9842ab3296d53ca5fa394a5a962aa382c8d
extra : histedit_source : e2f97502d215016925e93500b8fd93f8b32fba3a
2015-09-22 17:04:26 +00:00
|
|
|
JAVA_CLASSPATH += \
|
|
|
|
|
$(ANDROID_SUPPORT_ANNOTATIONS_JAR_LIB) \
|
|
|
|
|
$(ANDROID_SUPPORT_V4_AAR_LIB) \
|
|
|
|
|
$(ANDROID_SUPPORT_V4_AAR_INTERNAL_LIB) \
|
2015-09-28 10:10:42 +00:00
|
|
|
$(ANDROID_APPCOMPAT_V7_AAR_LIB) \
|
Bug 1108782 - Part 2: Explode AAR files at configure time. r=glandium
This gets us a limited version of AAR support: we can consume static
AAR libraries, where here static does not refer to linking, but to
static assets that are fixed at build-backend time and not modified
(or produced) during the build. This lets us pin our dependencies
(and move to Google's versioned Maven repository packages, away from
Google's unversioned ad-hoc packages).
By restricting to static AAR libraries, we avoid having to handle
truly complicated dependency trees, as changing parts of generated AAR
files require delicate rebuilding of the APKs (and internal libraries)
that depend on the AAR files.
It is possible that we will generate AARs in the tree at some time.
Right now, we don't do that, even for GeckoView: the AARs produced are
assembled as artifacts at package time and are intended for external
consumption. We might want this for GeckoView and Fennec at some
time; we should consider using Gradle everywhere at that point.
The patch itself does the simplest possible thing (which has precedent
from Gradle and other build systems): it simply "explodes" the AAR
into the object directory and uses existing mechanisms to refer to the
exploded pieces.
AARs have both required and optional components. Each component is
defined with an expected and required flag. If a component is expected
and not present, or not expected and is present, an error is raised.
If the component is expected and present, autoconf's ifelse() macro is
used to define the relevant AAR_* component variables. If the
component is not expected and not present, no action is taken. A
consuming build backend therefore can guard all AAR_* component
variables with just the top-level AAR variable.
Many AAR files have empty assets/ directories. This patch doesn't
explode empty assets/ directories, protecting against trivial changes
to AAR files that don't impact the build.
There's a lot not to like in this approach, including:
* We need to manually reference internal AAR libs;
* I haven't separated the pinned version numbers out of configure.in.
However, it's closer to what we want than what we have!
--HG--
extra : commitid : 11kUhDAkCn5
extra : rebase_source : 2454c9842ab3296d53ca5fa394a5a962aa382c8d
extra : histedit_source : e2f97502d215016925e93500b8fd93f8b32fba3a
2015-09-22 17:04:26 +00:00
|
|
|
$(ANDROID_RECYCLERVIEW_V7_AAR_LIB) \
|
|
|
|
|
$(NULL)
|
2015-06-16 17:52:44 +00:00
|
|
|
|
2014-12-05 19:50:48 +00:00
|
|
|
# If native devices are enabled, add Google Play Services and some of the v7
|
|
|
|
|
# compat libraries.
|
2014-07-09 18:59:36 +00:00
|
|
|
ifdef MOZ_NATIVE_DEVICES
|
2014-06-11 18:00:17 +00:00
|
|
|
JAVA_CLASSPATH += \
|
Bug 1108782 - Part 2: Explode AAR files at configure time. r=glandium
This gets us a limited version of AAR support: we can consume static
AAR libraries, where here static does not refer to linking, but to
static assets that are fixed at build-backend time and not modified
(or produced) during the build. This lets us pin our dependencies
(and move to Google's versioned Maven repository packages, away from
Google's unversioned ad-hoc packages).
By restricting to static AAR libraries, we avoid having to handle
truly complicated dependency trees, as changing parts of generated AAR
files require delicate rebuilding of the APKs (and internal libraries)
that depend on the AAR files.
It is possible that we will generate AARs in the tree at some time.
Right now, we don't do that, even for GeckoView: the AARs produced are
assembled as artifacts at package time and are intended for external
consumption. We might want this for GeckoView and Fennec at some
time; we should consider using Gradle everywhere at that point.
The patch itself does the simplest possible thing (which has precedent
from Gradle and other build systems): it simply "explodes" the AAR
into the object directory and uses existing mechanisms to refer to the
exploded pieces.
AARs have both required and optional components. Each component is
defined with an expected and required flag. If a component is expected
and not present, or not expected and is present, an error is raised.
If the component is expected and present, autoconf's ifelse() macro is
used to define the relevant AAR_* component variables. If the
component is not expected and not present, no action is taken. A
consuming build backend therefore can guard all AAR_* component
variables with just the top-level AAR variable.
Many AAR files have empty assets/ directories. This patch doesn't
explode empty assets/ directories, protecting against trivial changes
to AAR files that don't impact the build.
There's a lot not to like in this approach, including:
* We need to manually reference internal AAR libs;
* I haven't separated the pinned version numbers out of configure.in.
However, it's closer to what we want than what we have!
--HG--
extra : commitid : 11kUhDAkCn5
extra : rebase_source : 2454c9842ab3296d53ca5fa394a5a962aa382c8d
extra : histedit_source : e2f97502d215016925e93500b8fd93f8b32fba3a
2015-09-22 17:04:26 +00:00
|
|
|
$(ANDROID_PLAY_SERVICES_BASE_AAR_LIB) \
|
2015-10-05 12:59:53 +00:00
|
|
|
$(ANDROID_PLAY_SERVICES_BASEMENT_AAR_LIB) \
|
Bug 1108782 - Part 2: Explode AAR files at configure time. r=glandium
This gets us a limited version of AAR support: we can consume static
AAR libraries, where here static does not refer to linking, but to
static assets that are fixed at build-backend time and not modified
(or produced) during the build. This lets us pin our dependencies
(and move to Google's versioned Maven repository packages, away from
Google's unversioned ad-hoc packages).
By restricting to static AAR libraries, we avoid having to handle
truly complicated dependency trees, as changing parts of generated AAR
files require delicate rebuilding of the APKs (and internal libraries)
that depend on the AAR files.
It is possible that we will generate AARs in the tree at some time.
Right now, we don't do that, even for GeckoView: the AARs produced are
assembled as artifacts at package time and are intended for external
consumption. We might want this for GeckoView and Fennec at some
time; we should consider using Gradle everywhere at that point.
The patch itself does the simplest possible thing (which has precedent
from Gradle and other build systems): it simply "explodes" the AAR
into the object directory and uses existing mechanisms to refer to the
exploded pieces.
AARs have both required and optional components. Each component is
defined with an expected and required flag. If a component is expected
and not present, or not expected and is present, an error is raised.
If the component is expected and present, autoconf's ifelse() macro is
used to define the relevant AAR_* component variables. If the
component is not expected and not present, no action is taken. A
consuming build backend therefore can guard all AAR_* component
variables with just the top-level AAR variable.
Many AAR files have empty assets/ directories. This patch doesn't
explode empty assets/ directories, protecting against trivial changes
to AAR files that don't impact the build.
There's a lot not to like in this approach, including:
* We need to manually reference internal AAR libs;
* I haven't separated the pinned version numbers out of configure.in.
However, it's closer to what we want than what we have!
--HG--
extra : commitid : 11kUhDAkCn5
extra : rebase_source : 2454c9842ab3296d53ca5fa394a5a962aa382c8d
extra : histedit_source : e2f97502d215016925e93500b8fd93f8b32fba3a
2015-09-22 17:04:26 +00:00
|
|
|
$(ANDROID_PLAY_SERVICES_CAST_AAR_LIB) \
|
|
|
|
|
$(ANDROID_MEDIAROUTER_V7_AAR_LIB) \
|
|
|
|
|
$(ANDROID_MEDIAROUTER_V7_AAR_INTERNAL_LIB) \
|
2014-06-11 18:00:17 +00:00
|
|
|
$(NULL)
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
JAVA_CLASSPATH := $(subst $(NULL) ,:,$(strip $(JAVA_CLASSPATH)))
|
2011-11-18 18:28:17 +00:00
|
|
|
|
2014-12-05 19:50:48 +00:00
|
|
|
# Library jars that we're bundling: these are subject to Proguard before inclusion
|
|
|
|
|
# into classes.dex.
|
|
|
|
|
java_bundled_libs := \
|
Bug 1108782 - Part 2: Explode AAR files at configure time. r=glandium
This gets us a limited version of AAR support: we can consume static
AAR libraries, where here static does not refer to linking, but to
static assets that are fixed at build-backend time and not modified
(or produced) during the build. This lets us pin our dependencies
(and move to Google's versioned Maven repository packages, away from
Google's unversioned ad-hoc packages).
By restricting to static AAR libraries, we avoid having to handle
truly complicated dependency trees, as changing parts of generated AAR
files require delicate rebuilding of the APKs (and internal libraries)
that depend on the AAR files.
It is possible that we will generate AARs in the tree at some time.
Right now, we don't do that, even for GeckoView: the AARs produced are
assembled as artifacts at package time and are intended for external
consumption. We might want this for GeckoView and Fennec at some
time; we should consider using Gradle everywhere at that point.
The patch itself does the simplest possible thing (which has precedent
from Gradle and other build systems): it simply "explodes" the AAR
into the object directory and uses existing mechanisms to refer to the
exploded pieces.
AARs have both required and optional components. Each component is
defined with an expected and required flag. If a component is expected
and not present, or not expected and is present, an error is raised.
If the component is expected and present, autoconf's ifelse() macro is
used to define the relevant AAR_* component variables. If the
component is not expected and not present, no action is taken. A
consuming build backend therefore can guard all AAR_* component
variables with just the top-level AAR variable.
Many AAR files have empty assets/ directories. This patch doesn't
explode empty assets/ directories, protecting against trivial changes
to AAR files that don't impact the build.
There's a lot not to like in this approach, including:
* We need to manually reference internal AAR libs;
* I haven't separated the pinned version numbers out of configure.in.
However, it's closer to what we want than what we have!
--HG--
extra : commitid : 11kUhDAkCn5
extra : rebase_source : 2454c9842ab3296d53ca5fa394a5a962aa382c8d
extra : histedit_source : e2f97502d215016925e93500b8fd93f8b32fba3a
2015-09-22 17:04:26 +00:00
|
|
|
$(ANDROID_SUPPORT_V4_AAR_LIB) \
|
|
|
|
|
$(ANDROID_SUPPORT_V4_AAR_INTERNAL_LIB) \
|
2015-09-28 10:10:42 +00:00
|
|
|
$(ANDROID_APPCOMPAT_V7_AAR_LIB) \
|
Bug 1108782 - Part 2: Explode AAR files at configure time. r=glandium
This gets us a limited version of AAR support: we can consume static
AAR libraries, where here static does not refer to linking, but to
static assets that are fixed at build-backend time and not modified
(or produced) during the build. This lets us pin our dependencies
(and move to Google's versioned Maven repository packages, away from
Google's unversioned ad-hoc packages).
By restricting to static AAR libraries, we avoid having to handle
truly complicated dependency trees, as changing parts of generated AAR
files require delicate rebuilding of the APKs (and internal libraries)
that depend on the AAR files.
It is possible that we will generate AARs in the tree at some time.
Right now, we don't do that, even for GeckoView: the AARs produced are
assembled as artifacts at package time and are intended for external
consumption. We might want this for GeckoView and Fennec at some
time; we should consider using Gradle everywhere at that point.
The patch itself does the simplest possible thing (which has precedent
from Gradle and other build systems): it simply "explodes" the AAR
into the object directory and uses existing mechanisms to refer to the
exploded pieces.
AARs have both required and optional components. Each component is
defined with an expected and required flag. If a component is expected
and not present, or not expected and is present, an error is raised.
If the component is expected and present, autoconf's ifelse() macro is
used to define the relevant AAR_* component variables. If the
component is not expected and not present, no action is taken. A
consuming build backend therefore can guard all AAR_* component
variables with just the top-level AAR variable.
Many AAR files have empty assets/ directories. This patch doesn't
explode empty assets/ directories, protecting against trivial changes
to AAR files that don't impact the build.
There's a lot not to like in this approach, including:
* We need to manually reference internal AAR libs;
* I haven't separated the pinned version numbers out of configure.in.
However, it's closer to what we want than what we have!
--HG--
extra : commitid : 11kUhDAkCn5
extra : rebase_source : 2454c9842ab3296d53ca5fa394a5a962aa382c8d
extra : histedit_source : e2f97502d215016925e93500b8fd93f8b32fba3a
2015-09-22 17:04:26 +00:00
|
|
|
$(ANDROID_RECYCLERVIEW_V7_AAR_LIB) \
|
2014-12-05 19:50:48 +00:00
|
|
|
$(NULL)
|
|
|
|
|
|
|
|
|
|
ifdef MOZ_NATIVE_DEVICES
|
|
|
|
|
java_bundled_libs += \
|
Bug 1108782 - Part 2: Explode AAR files at configure time. r=glandium
This gets us a limited version of AAR support: we can consume static
AAR libraries, where here static does not refer to linking, but to
static assets that are fixed at build-backend time and not modified
(or produced) during the build. This lets us pin our dependencies
(and move to Google's versioned Maven repository packages, away from
Google's unversioned ad-hoc packages).
By restricting to static AAR libraries, we avoid having to handle
truly complicated dependency trees, as changing parts of generated AAR
files require delicate rebuilding of the APKs (and internal libraries)
that depend on the AAR files.
It is possible that we will generate AARs in the tree at some time.
Right now, we don't do that, even for GeckoView: the AARs produced are
assembled as artifacts at package time and are intended for external
consumption. We might want this for GeckoView and Fennec at some
time; we should consider using Gradle everywhere at that point.
The patch itself does the simplest possible thing (which has precedent
from Gradle and other build systems): it simply "explodes" the AAR
into the object directory and uses existing mechanisms to refer to the
exploded pieces.
AARs have both required and optional components. Each component is
defined with an expected and required flag. If a component is expected
and not present, or not expected and is present, an error is raised.
If the component is expected and present, autoconf's ifelse() macro is
used to define the relevant AAR_* component variables. If the
component is not expected and not present, no action is taken. A
consuming build backend therefore can guard all AAR_* component
variables with just the top-level AAR variable.
Many AAR files have empty assets/ directories. This patch doesn't
explode empty assets/ directories, protecting against trivial changes
to AAR files that don't impact the build.
There's a lot not to like in this approach, including:
* We need to manually reference internal AAR libs;
* I haven't separated the pinned version numbers out of configure.in.
However, it's closer to what we want than what we have!
--HG--
extra : commitid : 11kUhDAkCn5
extra : rebase_source : 2454c9842ab3296d53ca5fa394a5a962aa382c8d
extra : histedit_source : e2f97502d215016925e93500b8fd93f8b32fba3a
2015-09-22 17:04:26 +00:00
|
|
|
$(ANDROID_PLAY_SERVICES_BASE_AAR_LIB) \
|
2015-10-05 12:59:53 +00:00
|
|
|
$(ANDROID_PLAY_SERVICES_BASEMENT_AAR_LIB) \
|
Bug 1108782 - Part 2: Explode AAR files at configure time. r=glandium
This gets us a limited version of AAR support: we can consume static
AAR libraries, where here static does not refer to linking, but to
static assets that are fixed at build-backend time and not modified
(or produced) during the build. This lets us pin our dependencies
(and move to Google's versioned Maven repository packages, away from
Google's unversioned ad-hoc packages).
By restricting to static AAR libraries, we avoid having to handle
truly complicated dependency trees, as changing parts of generated AAR
files require delicate rebuilding of the APKs (and internal libraries)
that depend on the AAR files.
It is possible that we will generate AARs in the tree at some time.
Right now, we don't do that, even for GeckoView: the AARs produced are
assembled as artifacts at package time and are intended for external
consumption. We might want this for GeckoView and Fennec at some
time; we should consider using Gradle everywhere at that point.
The patch itself does the simplest possible thing (which has precedent
from Gradle and other build systems): it simply "explodes" the AAR
into the object directory and uses existing mechanisms to refer to the
exploded pieces.
AARs have both required and optional components. Each component is
defined with an expected and required flag. If a component is expected
and not present, or not expected and is present, an error is raised.
If the component is expected and present, autoconf's ifelse() macro is
used to define the relevant AAR_* component variables. If the
component is not expected and not present, no action is taken. A
consuming build backend therefore can guard all AAR_* component
variables with just the top-level AAR variable.
Many AAR files have empty assets/ directories. This patch doesn't
explode empty assets/ directories, protecting against trivial changes
to AAR files that don't impact the build.
There's a lot not to like in this approach, including:
* We need to manually reference internal AAR libs;
* I haven't separated the pinned version numbers out of configure.in.
However, it's closer to what we want than what we have!
--HG--
extra : commitid : 11kUhDAkCn5
extra : rebase_source : 2454c9842ab3296d53ca5fa394a5a962aa382c8d
extra : histedit_source : e2f97502d215016925e93500b8fd93f8b32fba3a
2015-09-22 17:04:26 +00:00
|
|
|
$(ANDROID_PLAY_SERVICES_CAST_AAR_LIB) \
|
|
|
|
|
$(ANDROID_MEDIAROUTER_V7_AAR_LIB) \
|
|
|
|
|
$(ANDROID_MEDIAROUTER_V7_AAR_INTERNAL_LIB) \
|
2014-12-05 19:50:48 +00:00
|
|
|
$(NULL)
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
java_bundled_libs := $(subst $(NULL) ,:,$(strip $(java_bundled_libs)))
|
|
|
|
|
|
|
|
|
|
# All the jars we're compiling from source. (not to be confused with
|
|
|
|
|
# java_bundled_libs, which holds the jars which we're including as binaries).
|
2013-04-04 11:48:02 +00:00
|
|
|
ALL_JARS = \
|
2014-11-24 23:37:30 +00:00
|
|
|
constants.jar \
|
2014-03-05 16:57:09 +00:00
|
|
|
gecko-R.jar \
|
2013-10-24 22:38:22 +00:00
|
|
|
gecko-browser.jar \
|
|
|
|
|
gecko-mozglue.jar \
|
2014-09-26 12:29:14 +00:00
|
|
|
gecko-thirdparty.jar \
|
2013-10-24 22:38:22 +00:00
|
|
|
gecko-util.jar \
|
|
|
|
|
sync-thirdparty.jar \
|
2015-06-18 04:47:29 +00:00
|
|
|
../javaaddons/javaaddons-1.0.jar \
|
2013-04-04 11:48:02 +00:00
|
|
|
$(NULL)
|
|
|
|
|
|
|
|
|
|
ifdef MOZ_WEBRTC
|
2013-10-24 22:38:22 +00:00
|
|
|
ALL_JARS += webrtc.jar
|
2013-04-04 11:48:02 +00:00
|
|
|
endif
|
|
|
|
|
|
2014-06-30 18:21:50 +00:00
|
|
|
ifdef MOZ_ANDROID_SEARCH_ACTIVITY
|
|
|
|
|
ALL_JARS += search-activity.jar
|
|
|
|
|
endif
|
|
|
|
|
|
2014-07-15 20:50:21 +00:00
|
|
|
ifdef MOZ_ANDROID_MLS_STUMBLER
|
|
|
|
|
ALL_JARS += ../stumbler/stumbler.jar
|
|
|
|
|
endif
|
|
|
|
|
|
2015-04-09 05:49:16 +00:00
|
|
|
ifdef MOZ_INSTALL_TRACKING
|
|
|
|
|
ALL_JARS += gecko-thirdparty-adjust_sdk.jar
|
|
|
|
|
endif
|
|
|
|
|
|
2014-12-05 19:50:48 +00:00
|
|
|
# The list of jars in Java classpath notation (colon-separated).
|
|
|
|
|
all_jars_classpath := $(subst $(NULL) ,:,$(strip $(ALL_JARS)))
|
2011-11-18 18:28:17 +00:00
|
|
|
|
2014-12-05 19:50:48 +00:00
|
|
|
include $(topsrcdir)/config/config.mk
|
2013-12-03 09:39:56 +00:00
|
|
|
|
2014-12-05 19:50:48 +00:00
|
|
|
library_jars := \
|
|
|
|
|
$(ANDROID_SDK)/android.jar \
|
2014-06-11 18:00:17 +00:00
|
|
|
$(NULL)
|
|
|
|
|
|
|
|
|
|
library_jars := $(subst $(NULL) ,:,$(strip $(library_jars)))
|
|
|
|
|
|
2014-02-11 17:55:47 +00:00
|
|
|
classes.dex: .proguard.deps
|
|
|
|
|
$(REPORT_BUILD)
|
2014-12-05 19:50:48 +00:00
|
|
|
$(DX) --dex --output=classes.dex jars-proguarded
|
2013-11-19 01:30:00 +00:00
|
|
|
|
2013-12-09 12:21:38 +00:00
|
|
|
ifdef MOZ_DISABLE_PROGUARD
|
|
|
|
|
PROGUARD_PASSES=0
|
2013-11-19 01:30:00 +00:00
|
|
|
else
|
2013-12-09 12:21:38 +00:00
|
|
|
ifdef MOZ_DEBUG
|
2014-05-14 05:20:36 +00:00
|
|
|
PROGUARD_PASSES=1
|
2013-12-09 12:21:38 +00:00
|
|
|
else
|
2014-05-14 05:20:36 +00:00
|
|
|
ifndef MOZILLA_OFFICIAL
|
|
|
|
|
PROGUARD_PASSES=1
|
|
|
|
|
else
|
|
|
|
|
PROGUARD_PASSES=6
|
|
|
|
|
endif
|
2013-12-09 12:21:38 +00:00
|
|
|
endif
|
2013-11-19 01:30:00 +00:00
|
|
|
endif
|
|
|
|
|
|
2014-12-05 19:50:48 +00:00
|
|
|
proguard_config_dir=$(topsrcdir)/mobile/android/config/proguard
|
|
|
|
|
|
2014-11-14 21:15:17 +00:00
|
|
|
# This stanza ensures that the set of GeckoView classes does not depend on too
|
|
|
|
|
# much of Fennec, where "too much" is defined as the set of potentially
|
|
|
|
|
# non-GeckoView classes that GeckoView already depended on at a certain point in
|
|
|
|
|
# time. The idea is to set a high-water mark that is not to be crossed.
|
|
|
|
|
classycle_jar := $(topsrcdir)/mobile/android/build/classycle/classycle-1.4.1.jar
|
|
|
|
|
.geckoview.deps: geckoview.ddf $(classycle_jar) $(ALL_JARS)
|
2015-06-30 15:18:01 +00:00
|
|
|
$(JAVA) -cp $(classycle_jar) \
|
2014-11-14 21:15:17 +00:00
|
|
|
classycle.dependency.DependencyChecker \
|
|
|
|
|
-mergeInnerClasses \
|
|
|
|
|
-dependencies=@$< \
|
|
|
|
|
$(ALL_JARS)
|
|
|
|
|
@$(TOUCH) $@
|
|
|
|
|
|
2014-12-05 19:50:48 +00:00
|
|
|
# First, we delete debugging information from libraries. Having line-number
|
|
|
|
|
# information for libraries for which we lack the source isn't useful, so this
|
|
|
|
|
# saves us a bit of space. Importantly, Proguard has a bug causing it to
|
|
|
|
|
# sometimes corrupt this information if present (which it does for some of the
|
|
|
|
|
# included libraries). This corruption prevents dex from completing, so we need
|
|
|
|
|
# to get rid of it. This prevents us from seeing line numbers in stack traces
|
|
|
|
|
# for stack frames inside libraries.
|
|
|
|
|
#
|
|
|
|
|
# This step can occur much earlier than the main Proguard pass: it needs only
|
|
|
|
|
# gecko-R.jar to have been compiled (as that's where the library R.java files
|
|
|
|
|
# end up), but it does block the main Proguard pass.
|
|
|
|
|
.bundled.proguard.deps: gecko-R.jar $(proguard_config_dir)/strip-libs.cfg
|
|
|
|
|
$(REPORT_BUILD)
|
|
|
|
|
@$(TOUCH) $@
|
2015-06-30 15:18:01 +00:00
|
|
|
$(JAVA) \
|
2014-12-05 19:50:48 +00:00
|
|
|
-Xmx512m -Xms128m \
|
|
|
|
|
-jar $(ANDROID_SDK_ROOT)/tools/proguard/lib/proguard.jar \
|
|
|
|
|
@$(proguard_config_dir)/strip-libs.cfg \
|
|
|
|
|
-injars $(subst ::,:,$(java_bundled_libs))\
|
|
|
|
|
-outjars bundled-jars-nodebug \
|
|
|
|
|
-libraryjars $(library_jars):gecko-R.jar
|
|
|
|
|
|
Bug 979388 - Make aapt invocation rebuild R.java. r=glandium
This commit adds an empty recipe to dependencies of .aapt.deps, which
forces the appropriate gecko-R.jar rebuild. This is because Make treats
targets with no recipe at all differently than targets with an empty
recipe, in a way that defeats our dependencies.
What appeared to be happening is the following:
Touch a resource. On the next build, .aapt.deps is stale, so aapt is
invoked, which generates R.java, and we touch .aapt.deps.
Now R.java depends on .aapt.deps, but this does not appear to force Make
to consider targets that depend on R.java to be stale. A target that
depends on R.java (such as gecko-R.jar) itself compares timestamps and
finds that gecko-R.jar is newer than R.java (from the previous build),
and this comparison appears to happen before aapt is invoked. So even
though .aapt.deps is seen to be stale, and by transitivity R.java is
stale, this does not mark gecko-R.jar as stale. The timestamp check
between R.java and gecko-R.jar appears to happen *before* aapt is
invoked.
On the second build following the update, the R.java generated in the
previous build is newer than gecko-R.jar, triggering the observed
rebuild of gecko-R.jar.
2014-03-13 00:22:27 +00:00
|
|
|
# We touch the target file before invoking Proguard so that Proguard's
|
|
|
|
|
# outputs are fresher than the target, preventing a subsequent
|
|
|
|
|
# invocation from thinking Proguard's outputs are stale. This is safe
|
|
|
|
|
# because Make removes the target file if any recipe command fails.
|
2014-12-05 19:50:48 +00:00
|
|
|
.proguard.deps: .geckoview.deps .bundled.proguard.deps $(ALL_JARS) $(proguard_config_dir)/proguard.cfg
|
2014-02-11 17:55:47 +00:00
|
|
|
$(REPORT_BUILD)
|
Bug 979388 - Make aapt invocation rebuild R.java. r=glandium
This commit adds an empty recipe to dependencies of .aapt.deps, which
forces the appropriate gecko-R.jar rebuild. This is because Make treats
targets with no recipe at all differently than targets with an empty
recipe, in a way that defeats our dependencies.
What appeared to be happening is the following:
Touch a resource. On the next build, .aapt.deps is stale, so aapt is
invoked, which generates R.java, and we touch .aapt.deps.
Now R.java depends on .aapt.deps, but this does not appear to force Make
to consider targets that depend on R.java to be stale. A target that
depends on R.java (such as gecko-R.jar) itself compares timestamps and
finds that gecko-R.jar is newer than R.java (from the previous build),
and this comparison appears to happen before aapt is invoked. So even
though .aapt.deps is seen to be stale, and by transitivity R.java is
stale, this does not mark gecko-R.jar as stale. The timestamp check
between R.java and gecko-R.jar appears to happen *before* aapt is
invoked.
On the second build following the update, the R.java generated in the
previous build is newer than gecko-R.jar, triggering the observed
rebuild of gecko-R.jar.
2014-03-13 00:22:27 +00:00
|
|
|
@$(TOUCH) $@
|
2015-06-30 15:18:01 +00:00
|
|
|
$(JAVA) \
|
2014-09-18 23:23:55 +00:00
|
|
|
-Xmx512m -Xms128m \
|
|
|
|
|
-jar $(ANDROID_SDK_ROOT)/tools/proguard/lib/proguard.jar \
|
2014-12-05 19:50:48 +00:00
|
|
|
@$(proguard_config_dir)/proguard.cfg \
|
2014-02-11 17:55:47 +00:00
|
|
|
-optimizationpasses $(PROGUARD_PASSES) \
|
2014-12-05 19:50:48 +00:00
|
|
|
-injars $(subst ::,:,$(all_jars_classpath)):bundled-jars-nodebug \
|
2014-02-11 17:55:47 +00:00
|
|
|
-outjars jars-proguarded \
|
2014-06-11 18:00:17 +00:00
|
|
|
-libraryjars $(library_jars)
|
2011-11-18 18:28:17 +00:00
|
|
|
|
2013-02-08 21:42:14 +00:00
|
|
|
CLASSES_WITH_JNI= \
|
|
|
|
|
org.mozilla.gecko.GeckoAppShell \
|
2013-04-26 17:24:28 +00:00
|
|
|
org.mozilla.gecko.GeckoJavaSampler \
|
2015-10-14 00:51:50 +00:00
|
|
|
org.mozilla.gecko.GeckoSmsManager \
|
2013-04-26 17:24:28 +00:00
|
|
|
org.mozilla.gecko.gfx.NativePanZoomController \
|
2013-02-08 21:42:14 +00:00
|
|
|
$(NULL)
|
|
|
|
|
|
2015-08-13 04:53:38 +00:00
|
|
|
jni-stubs.inc: gecko-browser.jar constants.jar gecko-mozglue.jar gecko-util.jar sync-thirdparty.jar
|
2013-02-08 21:42:14 +00:00
|
|
|
$(JAVAH) -o javah.out -bootclasspath $(JAVA_BOOTCLASSPATH) -classpath $(subst $(NULL) $(NULL),:,$^) $(CLASSES_WITH_JNI)
|
2013-02-07 14:37:06 +00:00
|
|
|
$(PYTHON) $(topsrcdir)/mobile/android/base/jni-generator.py javah.out $@
|
|
|
|
|
|
2013-10-10 00:05:37 +00:00
|
|
|
ANNOTATION_PROCESSOR_JAR_FILES := $(DEPTH)/build/annotationProcessors/annotationProcessors.jar
|
2013-09-09 12:57:37 +00:00
|
|
|
|
2015-07-11 03:41:36 +00:00
|
|
|
# This annotation processing step also generates
|
|
|
|
|
# GeneratedJNIWrappers.h and GeneratedJNINatives.h
|
2013-10-10 00:05:37 +00:00
|
|
|
GeneratedJNIWrappers.cpp: $(ANNOTATION_PROCESSOR_JAR_FILES)
|
|
|
|
|
GeneratedJNIWrappers.cpp: $(ALL_JARS)
|
2015-08-13 04:53:38 +00:00
|
|
|
$(JAVA) -classpath constants.jar:$(JAVA_BOOTCLASSPATH):$(JAVA_CLASSPATH):$(ANNOTATION_PROCESSOR_JAR_FILES) org.mozilla.gecko.annotationProcessors.AnnotationProcessor $(ALL_JARS)
|
2013-09-09 12:57:37 +00:00
|
|
|
|
2013-11-12 04:39:16 +00:00
|
|
|
manifest := \
|
|
|
|
|
AndroidManifest.xml.in \
|
2015-06-15 18:34:51 +00:00
|
|
|
fennec_ids.txt.in \
|
2012-05-03 10:22:33 +00:00
|
|
|
$(NULL)
|
|
|
|
|
|
2013-11-12 04:39:16 +00:00
|
|
|
PP_TARGETS += manifest
|
|
|
|
|
|
|
|
|
|
# Certain source files need to be preprocessed. This special rule
|
|
|
|
|
# generates these files into generated/org/mozilla/gecko for
|
|
|
|
|
# consumption by the build system and IDEs.
|
|
|
|
|
|
2014-11-20 22:25:52 +00:00
|
|
|
# The list in moz.build looks like
|
|
|
|
|
# 'preprocessed/org/mozilla/gecko/AppConstants.java'. The list in
|
|
|
|
|
# constants_PP_JAVAFILES looks like
|
|
|
|
|
# 'generated/preprocessed/org/mozilla/gecko/AppConstants.java'. We
|
|
|
|
|
# need to write AppConstants.java.in to
|
|
|
|
|
# generated/preprocessed/org/mozilla/gecko.
|
|
|
|
|
preprocessed := $(addsuffix .in,$(subst generated/preprocessed/org/mozilla/gecko/,,$(filter generated/preprocessed/org/mozilla/gecko/%,$(constants_PP_JAVAFILES))))
|
2013-11-12 04:39:16 +00:00
|
|
|
|
2014-11-20 22:25:52 +00:00
|
|
|
preprocessed_PATH := generated/preprocessed/org/mozilla/gecko
|
2013-11-12 04:39:16 +00:00
|
|
|
preprocessed_KEEP_PATH := 1
|
2014-10-11 14:22:55 +00:00
|
|
|
preprocessed_FLAGS := --marker='//\\\#'
|
2013-11-12 04:39:16 +00:00
|
|
|
|
2015-04-09 05:49:16 +00:00
|
|
|
ifdef MOZ_INSTALL_TRACKING
|
|
|
|
|
ifdef MOZ_INSTALL_TRACKING_ADJUST_SDK_APP_TOKEN
|
|
|
|
|
# The value of MOZ_INSTALL_TRACKING_ADJUST_SDK_APP_TOKEN is sensitive: we don't
|
|
|
|
|
# want to expose it in build logs. Following the model set by
|
|
|
|
|
# toolkit/components/urlformatter/Makefile.in, we expose it to AppConstants.java
|
|
|
|
|
# quietly here. Be aware that the included line's marker needs to agree with
|
|
|
|
|
# --marker above.
|
|
|
|
|
|
|
|
|
|
adjust_sdk_app_token:
|
|
|
|
|
@echo '//#define MOZ_INSTALL_TRACKING_ADJUST_SDK_APP_TOKEN $(MOZ_INSTALL_TRACKING_ADJUST_SDK_APP_TOKEN)' > $@
|
|
|
|
|
|
|
|
|
|
export:: adjust_sdk_app_token
|
|
|
|
|
|
|
|
|
|
preprocessed_FLAGS += -I adjust_sdk_app_token
|
|
|
|
|
endif # MOZ_INSTALL_TRACKING
|
|
|
|
|
endif # MOZ_INSTALL_TRACKING_ADJUST_SDK_APP_TOKEN
|
|
|
|
|
|
|
|
|
|
GARBAGE += adjust_sdk_app_token
|
|
|
|
|
|
2013-11-12 04:39:16 +00:00
|
|
|
PP_TARGETS += preprocessed
|
|
|
|
|
|
2013-12-12 05:20:07 +00:00
|
|
|
include $(topsrcdir)/config/rules.mk
|
2012-11-21 19:53:25 +00:00
|
|
|
|
2014-02-05 16:51:48 +00:00
|
|
|
not_android_res_files := \
|
|
|
|
|
*.mkdir.done* \
|
|
|
|
|
*.DS_Store* \
|
2014-03-13 00:22:27 +00:00
|
|
|
*\#* \
|
2014-03-14 22:19:57 +00:00
|
|
|
*.rej \
|
|
|
|
|
*.orig \
|
2014-02-05 16:51:48 +00:00
|
|
|
$(NULL)
|
|
|
|
|
|
2013-12-12 05:20:07 +00:00
|
|
|
# This uses the fact that Android resource directories list all
|
|
|
|
|
# resource files one subdirectory below the parent resource directory.
|
2014-02-05 16:51:48 +00:00
|
|
|
android_res_files := $(filter-out $(not_android_res_files),$(wildcard $(addsuffix /*,$(wildcard $(addsuffix /*,$(ANDROID_RES_DIRS))))))
|
|
|
|
|
|
2013-12-12 05:20:07 +00:00
|
|
|
$(ANDROID_GENERATED_RESFILES): $(call mkdir_deps,$(sort $(dir $(ANDROID_GENERATED_RESFILES))))
|
2012-06-11 21:54:17 +00:00
|
|
|
|
2013-12-12 05:20:07 +00:00
|
|
|
# [Comment 1/3] We don't have correct dependencies for strings.xml at
|
|
|
|
|
# this point, so we always recursively invoke the submake to check the
|
|
|
|
|
# dependencies. Sigh. And, with multilocale builds, there will be
|
|
|
|
|
# multiple strings.xml files, and we need to rebuild gecko.ap_ if any
|
|
|
|
|
# of them change. But! mobile/android/base/locales does not have
|
|
|
|
|
# enough information to actually build res/values/strings.xml during a
|
|
|
|
|
# language repack. So rather than adding rules into the main
|
|
|
|
|
# makefile, and trying to work around the lack of information, we
|
|
|
|
|
# force a rebuild of gecko.ap_ during packaging. See below.
|
2011-11-18 18:28:17 +00:00
|
|
|
|
2014-05-09 08:39:14 +00:00
|
|
|
# Since the sub-Make is forced, it doesn't matter that we touch the
|
|
|
|
|
# target file before the command. If in the future we stop forcing
|
|
|
|
|
# the sub-Make, touching the target file first is better, because the
|
|
|
|
|
# sub-Make outputs will be fresher than the target, and not require
|
|
|
|
|
# rebuilding. This is all safe because Make removes the target file
|
|
|
|
|
# if any recipe command fails. It is crucial that the sub-Make touch
|
|
|
|
|
# the target files (those depending on .locales.deps) only when there
|
|
|
|
|
# contents have changed; otherwise, this will force rebuild them as
|
|
|
|
|
# part of every build.
|
|
|
|
|
.locales.deps: FORCE
|
|
|
|
|
$(TOUCH) $@
|
2013-07-02 19:57:16 +00:00
|
|
|
$(MAKE) -C locales
|
2011-12-20 15:28:12 +00:00
|
|
|
|
2014-06-11 18:00:17 +00:00
|
|
|
|
2014-05-09 08:39:14 +00:00
|
|
|
# This .deps pattern saves an invocation of the sub-Make: the single
|
2014-10-02 06:23:29 +00:00
|
|
|
# invocation generates strings.xml, browsersearch.json, and
|
|
|
|
|
# suggestedsites.json. The trailing semi-colon defines an empty
|
|
|
|
|
# recipe: defining no recipe at all causes Make to treat the target
|
|
|
|
|
# differently, in a way that defeats our dependencies.
|
2014-05-09 08:39:14 +00:00
|
|
|
res/values/strings.xml: .locales.deps ;
|
2014-10-02 06:23:29 +00:00
|
|
|
res/raw/browsersearch.json: .locales.deps ;
|
2014-05-09 08:39:14 +00:00
|
|
|
res/raw/suggestedsites.json: .locales.deps ;
|
|
|
|
|
|
2013-07-18 22:09:03 +00:00
|
|
|
all_resources = \
|
2015-08-20 22:10:34 +00:00
|
|
|
$(abspath $(CURDIR)/AndroidManifest.xml) \
|
2013-12-12 05:20:07 +00:00
|
|
|
$(android_res_files) \
|
2013-10-09 23:19:00 +00:00
|
|
|
$(ANDROID_GENERATED_RESFILES) \
|
2013-07-18 22:09:03 +00:00
|
|
|
$(NULL)
|
|
|
|
|
|
2014-03-13 00:22:27 +00:00
|
|
|
# For GeckoView, we want a zip of an Android res/ directory that
|
|
|
|
|
# merges the contents of all the ANDROID_RES_DIRS. The inner res/
|
|
|
|
|
# directory must have the Android resource two-layer hierarchy.
|
|
|
|
|
|
|
|
|
|
# The following helper zips files in a directory into a zip file while
|
|
|
|
|
# maintaining the directory structure rooted below the directory.
|
|
|
|
|
# (adding or creating said file as appropriate). For example, if the
|
|
|
|
|
# dir contains dir/subdir/file, calling with directory dir would
|
|
|
|
|
# create a zip containing subdir/file. Note: the trailing newline is
|
|
|
|
|
# necessary.
|
|
|
|
|
|
|
|
|
|
# $(1): zip file to add to (or create).
|
|
|
|
|
# $(2): directory to zip contents of.
|
|
|
|
|
define zip_directory_with_relative_paths
|
2015-06-25 19:59:16 +00:00
|
|
|
cd $(2) && zip -q $(1) -r * -x $(subst *,\*,$(not_android_res_files))
|
2014-03-13 00:22:27 +00:00
|
|
|
|
|
|
|
|
endef
|
|
|
|
|
|
2015-06-25 23:48:15 +00:00
|
|
|
ifndef MOZ_DISABLE_GECKOVIEW
|
2014-05-12 22:08:49 +00:00
|
|
|
# We delete the archive before updating so that resources removed from
|
|
|
|
|
# the filesystem are removed from the archive.
|
2014-03-13 00:22:27 +00:00
|
|
|
geckoview_resources.zip: $(all_resources) $(GLOBAL_DEPS)
|
2014-05-12 22:08:49 +00:00
|
|
|
$(REPORT_BUILD)
|
|
|
|
|
$(RM) -rf $@
|
2014-03-13 00:22:27 +00:00
|
|
|
$(foreach dir,$(ANDROID_RES_DIRS),$(call zip_directory_with_relative_paths,$(CURDIR)/$@,$(dir)))
|
2015-06-25 23:48:15 +00:00
|
|
|
endif
|
2014-03-13 00:22:27 +00:00
|
|
|
|
2013-12-12 05:20:07 +00:00
|
|
|
# All of generated/org/mozilla/gecko/R.java, gecko.ap_, and R.txt are
|
Bug 979388 - Make aapt invocation rebuild R.java. r=glandium
This commit adds an empty recipe to dependencies of .aapt.deps, which
forces the appropriate gecko-R.jar rebuild. This is because Make treats
targets with no recipe at all differently than targets with an empty
recipe, in a way that defeats our dependencies.
What appeared to be happening is the following:
Touch a resource. On the next build, .aapt.deps is stale, so aapt is
invoked, which generates R.java, and we touch .aapt.deps.
Now R.java depends on .aapt.deps, but this does not appear to force Make
to consider targets that depend on R.java to be stale. A target that
depends on R.java (such as gecko-R.jar) itself compares timestamps and
finds that gecko-R.jar is newer than R.java (from the previous build),
and this comparison appears to happen before aapt is invoked. So even
though .aapt.deps is seen to be stale, and by transitivity R.java is
stale, this does not mark gecko-R.jar as stale. The timestamp check
between R.java and gecko-R.jar appears to happen *before* aapt is
invoked.
On the second build following the update, the R.java generated in the
previous build is newer than gecko-R.jar, triggering the observed
rebuild of gecko-R.jar.
2014-03-13 00:22:27 +00:00
|
|
|
# produced by aapt; this saves aapt invocations. The trailing
|
|
|
|
|
# semi-colon defines an empty recipe; defining no recipe at all causes
|
|
|
|
|
# Make to treat the target differently, in a way that defeats our
|
|
|
|
|
# dependencies.
|
2013-11-12 04:39:16 +00:00
|
|
|
|
2014-06-11 18:00:17 +00:00
|
|
|
generated/org/mozilla/gecko/R.java: .aapt.deps ;
|
|
|
|
|
|
|
|
|
|
# If native devices are enabled, add Google Play Services, build their resources
|
Bug 1108782 - Part 2: Explode AAR files at configure time. r=glandium
This gets us a limited version of AAR support: we can consume static
AAR libraries, where here static does not refer to linking, but to
static assets that are fixed at build-backend time and not modified
(or produced) during the build. This lets us pin our dependencies
(and move to Google's versioned Maven repository packages, away from
Google's unversioned ad-hoc packages).
By restricting to static AAR libraries, we avoid having to handle
truly complicated dependency trees, as changing parts of generated AAR
files require delicate rebuilding of the APKs (and internal libraries)
that depend on the AAR files.
It is possible that we will generate AARs in the tree at some time.
Right now, we don't do that, even for GeckoView: the AARs produced are
assembled as artifacts at package time and are intended for external
consumption. We might want this for GeckoView and Fennec at some
time; we should consider using Gradle everywhere at that point.
The patch itself does the simplest possible thing (which has precedent
from Gradle and other build systems): it simply "explodes" the AAR
into the object directory and uses existing mechanisms to refer to the
exploded pieces.
AARs have both required and optional components. Each component is
defined with an expected and required flag. If a component is expected
and not present, or not expected and is present, an error is raised.
If the component is expected and present, autoconf's ifelse() macro is
used to define the relevant AAR_* component variables. If the
component is not expected and not present, no action is taken. A
consuming build backend therefore can guard all AAR_* component
variables with just the top-level AAR variable.
Many AAR files have empty assets/ directories. This patch doesn't
explode empty assets/ directories, protecting against trivial changes
to AAR files that don't impact the build.
There's a lot not to like in this approach, including:
* We need to manually reference internal AAR libs;
* I haven't separated the pinned version numbers out of configure.in.
However, it's closer to what we want than what we have!
--HG--
extra : commitid : 11kUhDAkCn5
extra : rebase_source : 2454c9842ab3296d53ca5fa394a5a962aa382c8d
extra : histedit_source : e2f97502d215016925e93500b8fd93f8b32fba3a
2015-09-22 17:04:26 +00:00
|
|
|
generated/android/support/v4/R.java: .aapt.deps ;
|
2014-06-11 18:00:17 +00:00
|
|
|
generated/android/support/v7/appcompat/R.java: .aapt.deps ;
|
|
|
|
|
generated/android/support/v7/mediarouter/R.java: .aapt.deps ;
|
2015-06-16 17:52:44 +00:00
|
|
|
generated/android/support/v7/recyclerview/R.java: .aapt.deps ;
|
2014-06-11 18:00:17 +00:00
|
|
|
generated/com/google/android/gms/R.java: .aapt.deps ;
|
2015-10-05 12:59:53 +00:00
|
|
|
generated/com/google/android/gms/base/R.java: .aapt.deps ;
|
Bug 1108782 - Part 2: Explode AAR files at configure time. r=glandium
This gets us a limited version of AAR support: we can consume static
AAR libraries, where here static does not refer to linking, but to
static assets that are fixed at build-backend time and not modified
(or produced) during the build. This lets us pin our dependencies
(and move to Google's versioned Maven repository packages, away from
Google's unversioned ad-hoc packages).
By restricting to static AAR libraries, we avoid having to handle
truly complicated dependency trees, as changing parts of generated AAR
files require delicate rebuilding of the APKs (and internal libraries)
that depend on the AAR files.
It is possible that we will generate AARs in the tree at some time.
Right now, we don't do that, even for GeckoView: the AARs produced are
assembled as artifacts at package time and are intended for external
consumption. We might want this for GeckoView and Fennec at some
time; we should consider using Gradle everywhere at that point.
The patch itself does the simplest possible thing (which has precedent
from Gradle and other build systems): it simply "explodes" the AAR
into the object directory and uses existing mechanisms to refer to the
exploded pieces.
AARs have both required and optional components. Each component is
defined with an expected and required flag. If a component is expected
and not present, or not expected and is present, an error is raised.
If the component is expected and present, autoconf's ifelse() macro is
used to define the relevant AAR_* component variables. If the
component is not expected and not present, no action is taken. A
consuming build backend therefore can guard all AAR_* component
variables with just the top-level AAR variable.
Many AAR files have empty assets/ directories. This patch doesn't
explode empty assets/ directories, protecting against trivial changes
to AAR files that don't impact the build.
There's a lot not to like in this approach, including:
* We need to manually reference internal AAR libs;
* I haven't separated the pinned version numbers out of configure.in.
However, it's closer to what we want than what we have!
--HG--
extra : commitid : 11kUhDAkCn5
extra : rebase_source : 2454c9842ab3296d53ca5fa394a5a962aa382c8d
extra : histedit_source : e2f97502d215016925e93500b8fd93f8b32fba3a
2015-09-22 17:04:26 +00:00
|
|
|
generated/com/google/android/gms/cast/R.java: .aapt.deps ;
|
2014-06-11 18:00:17 +00:00
|
|
|
|
Bug 979388 - Make aapt invocation rebuild R.java. r=glandium
This commit adds an empty recipe to dependencies of .aapt.deps, which
forces the appropriate gecko-R.jar rebuild. This is because Make treats
targets with no recipe at all differently than targets with an empty
recipe, in a way that defeats our dependencies.
What appeared to be happening is the following:
Touch a resource. On the next build, .aapt.deps is stale, so aapt is
invoked, which generates R.java, and we touch .aapt.deps.
Now R.java depends on .aapt.deps, but this does not appear to force Make
to consider targets that depend on R.java to be stale. A target that
depends on R.java (such as gecko-R.jar) itself compares timestamps and
finds that gecko-R.jar is newer than R.java (from the previous build),
and this comparison appears to happen before aapt is invoked. So even
though .aapt.deps is seen to be stale, and by transitivity R.java is
stale, this does not mark gecko-R.jar as stale. The timestamp check
between R.java and gecko-R.jar appears to happen *before* aapt is
invoked.
On the second build following the update, the R.java generated in the
previous build is newer than gecko-R.jar, triggering the observed
rebuild of gecko-R.jar.
2014-03-13 00:22:27 +00:00
|
|
|
gecko.ap_: .aapt.deps ;
|
|
|
|
|
R.txt: .aapt.deps ;
|
2013-12-12 05:20:07 +00:00
|
|
|
|
|
|
|
|
# [Comment 2/3] This tom-foolery provides a target that forces a
|
|
|
|
|
# rebuild of gecko.ap_. This is used during packaging to ensure that
|
|
|
|
|
# resources are fresh. The alternative would be complicated; see
|
|
|
|
|
# [Comment 1/3].
|
|
|
|
|
|
Bug 979388 - Make aapt invocation rebuild R.java. r=glandium
This commit adds an empty recipe to dependencies of .aapt.deps, which
forces the appropriate gecko-R.jar rebuild. This is because Make treats
targets with no recipe at all differently than targets with an empty
recipe, in a way that defeats our dependencies.
What appeared to be happening is the following:
Touch a resource. On the next build, .aapt.deps is stale, so aapt is
invoked, which generates R.java, and we touch .aapt.deps.
Now R.java depends on .aapt.deps, but this does not appear to force Make
to consider targets that depend on R.java to be stale. A target that
depends on R.java (such as gecko-R.jar) itself compares timestamps and
finds that gecko-R.jar is newer than R.java (from the previous build),
and this comparison appears to happen before aapt is invoked. So even
though .aapt.deps is seen to be stale, and by transitivity R.java is
stale, this does not mark gecko-R.jar as stale. The timestamp check
between R.java and gecko-R.jar appears to happen *before* aapt is
invoked.
On the second build following the update, the R.java generated in the
previous build is newer than gecko-R.jar, triggering the observed
rebuild of gecko-R.jar.
2014-03-13 00:22:27 +00:00
|
|
|
gecko-nodeps/R.java: .aapt.nodeps ;
|
|
|
|
|
gecko-nodeps.ap_: .aapt.nodeps ;
|
|
|
|
|
gecko-nodeps/R.txt: .aapt.nodeps ;
|
2013-12-12 05:20:07 +00:00
|
|
|
|
2014-03-13 00:22:27 +00:00
|
|
|
# This ignores the default set of resources ignored by aapt, plus
|
|
|
|
|
# files starting with '#'. (Emacs produces temp files named #temp#.)
|
|
|
|
|
# This doesn't actually set the environment variable; it's used as a
|
2014-03-14 22:19:57 +00:00
|
|
|
# parameter in the aapt invocation below. Consider updating
|
|
|
|
|
# not_android_res_files as well.
|
2014-03-13 00:22:27 +00:00
|
|
|
|
2014-03-14 22:19:57 +00:00
|
|
|
ANDROID_AAPT_IGNORE := !.svn:!.git:.*:<dir>_*:!CVS:!thumbs.db:!picasa.ini:!*.scc:*~:\#*:*.rej:*.orig
|
2014-03-13 00:22:27 +00:00
|
|
|
|
2013-12-12 05:20:07 +00:00
|
|
|
# 1: target file.
|
|
|
|
|
# 2: dependencies.
|
|
|
|
|
# 3: name of ap_ file to write.
|
|
|
|
|
# 4: directory to write R.java into.
|
|
|
|
|
# 5: directory to write R.txt into.
|
Bug 979388 - Make aapt invocation rebuild R.java. r=glandium
This commit adds an empty recipe to dependencies of .aapt.deps, which
forces the appropriate gecko-R.jar rebuild. This is because Make treats
targets with no recipe at all differently than targets with an empty
recipe, in a way that defeats our dependencies.
What appeared to be happening is the following:
Touch a resource. On the next build, .aapt.deps is stale, so aapt is
invoked, which generates R.java, and we touch .aapt.deps.
Now R.java depends on .aapt.deps, but this does not appear to force Make
to consider targets that depend on R.java to be stale. A target that
depends on R.java (such as gecko-R.jar) itself compares timestamps and
finds that gecko-R.jar is newer than R.java (from the previous build),
and this comparison appears to happen before aapt is invoked. So even
though .aapt.deps is seen to be stale, and by transitivity R.java is
stale, this does not mark gecko-R.jar as stale. The timestamp check
between R.java and gecko-R.jar appears to happen *before* aapt is
invoked.
On the second build following the update, the R.java generated in the
previous build is newer than gecko-R.jar, triggering the observed
rebuild of gecko-R.jar.
2014-03-13 00:22:27 +00:00
|
|
|
# We touch the target file before invoking aapt so that aapt's outputs
|
|
|
|
|
# are fresher than the target, preventing a subsequent invocation from
|
|
|
|
|
# thinking aapt's outputs are stale. This is safe because Make
|
|
|
|
|
# removes the target file if any recipe command fails.
|
2014-09-06 04:10:23 +00:00
|
|
|
|
2015-07-07 16:35:09 +00:00
|
|
|
CONSTRAINED_AAPT_CONFIGURATIONS := hdpi
|
2014-11-04 21:23:16 +00:00
|
|
|
|
2013-12-12 05:20:07 +00:00
|
|
|
define aapt_command
|
|
|
|
|
$(1): $$(call mkdir_deps,$(filter-out ./,$(dir $(3) $(4) $(5)))) $(2)
|
Bug 979388 - Make aapt invocation rebuild R.java. r=glandium
This commit adds an empty recipe to dependencies of .aapt.deps, which
forces the appropriate gecko-R.jar rebuild. This is because Make treats
targets with no recipe at all differently than targets with an empty
recipe, in a way that defeats our dependencies.
What appeared to be happening is the following:
Touch a resource. On the next build, .aapt.deps is stale, so aapt is
invoked, which generates R.java, and we touch .aapt.deps.
Now R.java depends on .aapt.deps, but this does not appear to force Make
to consider targets that depend on R.java to be stale. A target that
depends on R.java (such as gecko-R.jar) itself compares timestamps and
finds that gecko-R.jar is newer than R.java (from the previous build),
and this comparison appears to happen before aapt is invoked. So even
though .aapt.deps is seen to be stale, and by transitivity R.java is
stale, this does not mark gecko-R.jar as stale. The timestamp check
between R.java and gecko-R.jar appears to happen *before* aapt is
invoked.
On the second build following the update, the R.java generated in the
previous build is newer than gecko-R.jar, triggering the observed
rebuild of gecko-R.jar.
2014-03-13 00:22:27 +00:00
|
|
|
@$$(TOUCH) $$@
|
2014-06-11 18:00:17 +00:00
|
|
|
$$(AAPT) package -f -m \
|
|
|
|
|
-M AndroidManifest.xml \
|
|
|
|
|
-I $(ANDROID_SDK)/android.jar \
|
2014-09-06 04:10:23 +00:00
|
|
|
$(if $(MOZ_ANDROID_MAX_SDK_VERSION),--max-res-version $(MOZ_ANDROID_MAX_SDK_VERSION),) \
|
2013-12-12 05:20:07 +00:00
|
|
|
--auto-add-overlay \
|
|
|
|
|
$$(addprefix -S ,$$(ANDROID_RES_DIRS)) \
|
2015-08-12 18:04:03 +00:00
|
|
|
$$(addprefix -A ,$$(ANDROID_ASSETS_DIRS)) \
|
2015-08-15 01:13:11 +00:00
|
|
|
$(if $(ANDROID_EXTRA_PACKAGES),--extra-packages $$(subst $$(NULL) ,:,$$(strip $$(ANDROID_EXTRA_PACKAGES)))) \
|
|
|
|
|
$(if $(ANDROID_EXTRA_RES_DIRS),$$(addprefix -S ,$$(ANDROID_EXTRA_RES_DIRS))) \
|
2014-06-11 18:00:17 +00:00
|
|
|
--custom-package org.mozilla.gecko \
|
|
|
|
|
--non-constant-id \
|
2013-12-12 05:20:07 +00:00
|
|
|
-F $(3) \
|
|
|
|
|
-J $(4) \
|
2014-03-13 00:22:27 +00:00
|
|
|
--output-text-symbols $(5) \
|
2014-11-04 21:23:16 +00:00
|
|
|
$(if $(MOZ_ANDROID_RESOURCE_CONSTRAINED),-c $(CONSTRAINED_AAPT_CONFIGURATIONS),) \
|
2014-03-13 00:22:27 +00:00
|
|
|
--ignore-assets "$$(ANDROID_AAPT_IGNORE)"
|
2013-12-12 05:20:07 +00:00
|
|
|
endef
|
|
|
|
|
|
|
|
|
|
# [Comment 3/3] The first of these rules is used during regular
|
|
|
|
|
# builds. The second writes an ap_ file that is only used during
|
|
|
|
|
# packaging. It doesn't write the normal ap_, or R.java, since we
|
|
|
|
|
# don't want the packaging step to write anything that would make a
|
|
|
|
|
# further no-op build do work. See also
|
|
|
|
|
# toolkit/mozapps/installer/packager.mk.
|
|
|
|
|
|
|
|
|
|
# .aapt.deps: $(all_resources)
|
2014-06-11 18:00:17 +00:00
|
|
|
$(eval $(call aapt_command,.aapt.deps,$(all_resources),gecko.ap_,generated/,./))
|
2013-12-12 05:20:07 +00:00
|
|
|
|
2015-08-20 22:10:34 +00:00
|
|
|
# .aapt.nodeps: $(abspath $(CURDIR)/AndroidManifest.xml) FORCE
|
|
|
|
|
$(eval $(call aapt_command,.aapt.nodeps,$(abspath $(CURDIR)/AndroidManifest.xml) FORCE,gecko-nodeps.ap_,gecko-nodeps/,gecko-nodeps/))
|
2013-11-12 04:39:16 +00:00
|
|
|
|
|
|
|
|
# Override the Java settings with some specific android settings
|
|
|
|
|
include $(topsrcdir)/config/android-common.mk
|
2013-05-20 18:39:49 +00:00
|
|
|
|
2014-11-13 18:47:24 +00:00
|
|
|
update-generated-wrappers:
|
|
|
|
|
@cp $(CURDIR)/jni-stubs.inc $(topsrcdir)/mozglue/android
|
2015-07-11 03:41:36 +00:00
|
|
|
@cp $(CURDIR)/GeneratedJNIWrappers.cpp $(CURDIR)/GeneratedJNIWrappers.h $(CURDIR)/GeneratedJNINatives.h $(topsrcdir)/widget/android
|
|
|
|
|
@echo Updated generated JNI code
|
2014-11-13 18:47:24 +00:00
|
|
|
|
|
|
|
|
.PHONY: update-generated-wrappers
|
|
|
|
|
|
2014-11-10 21:47:30 +00:00
|
|
|
# This target is only used by IDE integrations. It rebuilds resources
|
|
|
|
|
# that end up in omni.ja, does most of the packaging step, and then
|
|
|
|
|
# updates omni.ja in place. If you're not using an IDE, you should be
|
|
|
|
|
# using |mach build mobile/android && mach package|.
|
2014-06-25 02:14:36 +00:00
|
|
|
$(abspath $(DIST)/fennec/$(OMNIJAR_NAME)): FORCE
|
|
|
|
|
$(REPORT_BUILD)
|
|
|
|
|
$(MAKE) -C ../locales
|
|
|
|
|
$(MAKE) -C ../chrome
|
|
|
|
|
$(MAKE) -C ../components
|
|
|
|
|
$(MAKE) -C ../modules
|
|
|
|
|
$(MAKE) -C ../app
|
|
|
|
|
$(MAKE) -C ../themes/core
|
|
|
|
|
$(MAKE) -C ../installer stage-package
|
2015-08-18 17:51:10 +00:00
|
|
|
$(MKDIR) -p $(@D)
|
2014-06-25 02:14:36 +00:00
|
|
|
rsync --update $(DIST)/fennec/$(notdir $(OMNIJAR_NAME)) $@
|
|
|
|
|
$(RM) $(DIST)/fennec/$(notdir $(OMNIJAR_NAME))
|
|
|
|
|
|
2014-11-10 21:47:30 +00:00
|
|
|
# Targets built very early during a Gradle build.
|
2015-10-20 00:01:26 +00:00
|
|
|
gradle-targets: $(foreach f,$(constants_PP_JAVAFILES),$(f))
|
|
|
|
|
gradle-targets: $(abspath AndroidManifest.xml)
|
|
|
|
|
gradle-targets: $(ANDROID_GENERATED_RESFILES)
|
2014-11-10 21:47:30 +00:00
|
|
|
|
2014-11-25 17:54:31 +00:00
|
|
|
gradle-omnijar: $(abspath $(DIST)/fennec/$(OMNIJAR_NAME))
|
|
|
|
|
|
|
|
|
|
.PHONY: gradle-targets gradle-omnijar
|
2014-11-10 21:47:30 +00:00
|
|
|
|
2015-06-25 23:48:15 +00:00
|
|
|
ifndef MOZ_DISABLE_GECKOVIEW
|
|
|
|
|
libs:: geckoview_resources.zip
|
2014-02-05 16:51:48 +00:00
|
|
|
$(INSTALL) geckoview_resources.zip $(FINAL_TARGET)
|
2015-06-25 23:48:15 +00:00
|
|
|
endif
|
|
|
|
|
|
2015-07-11 03:41:36 +00:00
|
|
|
# GeneratedJNIWrappers.cpp target also generates
|
|
|
|
|
# GeneratedJNIWrappers.h and GeneratedJNINatives.h
|
2015-06-25 23:48:15 +00:00
|
|
|
libs:: classes.dex jni-stubs.inc GeneratedJNIWrappers.cpp $(CURDIR)/fennec_ids.txt
|
2012-06-11 21:54:17 +00:00
|
|
|
$(INSTALL) classes.dex $(FINAL_TARGET)
|
2015-07-11 03:41:36 +00:00
|
|
|
@(diff jni-stubs.inc $(topsrcdir)/mozglue/android/jni-stubs.inc >/dev/null && \
|
|
|
|
|
diff GeneratedJNIWrappers.cpp $(topsrcdir)/widget/android/GeneratedJNIWrappers.cpp >/dev/null && \
|
|
|
|
|
diff GeneratedJNIWrappers.h $(topsrcdir)/widget/android/GeneratedJNIWrappers.h >/dev/null && \
|
|
|
|
|
diff GeneratedJNINatives.h $(topsrcdir)/widget/android/GeneratedJNINatives.h >/dev/null) || \
|
2014-03-25 18:40:36 +00:00
|
|
|
(echo '*****************************************************' && \
|
|
|
|
|
echo '*** Error: The generated JNI code has changed ***' && \
|
|
|
|
|
echo '* To update generated code in the tree, please run *' && \
|
|
|
|
|
echo && \
|
2014-11-13 18:47:24 +00:00
|
|
|
echo ' make -C $(CURDIR) update-generated-wrappers' && \
|
2014-03-25 18:40:36 +00:00
|
|
|
echo && \
|
|
|
|
|
echo '* Repeat the build, and check in any changes. *' && \
|
|
|
|
|
echo '*****************************************************' && \
|
|
|
|
|
exit 1)
|