And everything special-cased on that. Add a warning if USE_NINJA is
set to let users know that it no longer changes anything.
Change-Id: Ib8739151fe26ea6bf8f76b7ac2b8f4097dab0b47
Temporary revert to help out Brillo folks.
It will be resubmitted tomorrow.
This reverts commit 4495f6afb8.
Change-Id: Id378c7d3a6e72e9be50f9404b19d5763568987a5
To return to OpenJDK 7:
export LEGACY_USE_JAVA7=true
And run envsetup.sh/lunch again.
Bug: 25786468
Change-Id: I8e00591a24d13e3b8b6baaafe0fdff6536c58770
This reverts commit c288d65762.
The launch control change that switched various builds
to JDK 8 was reverted so JDK 8 can't be mandatory without
breaking builds.
Change-Id: I5e3feb21488d3bb57c5718cfe105a931eeaa9587
Reverting until all continuous builds that cover branches downstream of master can be updated to use JDK 8.
This reverts commit 1bd16b67c4.
Change-Id: Icb0daa440a6286e07d3cfd9ff8b082b4154ebc21
To return to OpenJDK 7:
export LEGACY_USE_JAVA7=true
And run envsetup.sh/lunch again.
Bug: 25786468
Change-Id: Iba08a9d3cf73bae7124e431dfe87c20ac219591e
With some core classes moved to separate core-oj jar
we need to use the new jar.
(cherry picked from commit 89b94c827f)
Change-Id: I025c0adc70535bf23def3ab0ce28a1bfaef72514
Mac builds use a javadoc tool that fails on more warnings than linux
builds. Add -Xdoclint:none to all java 8 standard doclet javadoc
commands.
Don't add it to javadoc commands that use the com.google.doclava.Doclava
doclet, it doesn't understand -Xdoclint:none.
(cherry-picked from commit 8bf7b5d51a)
Change-Id: Ic5b8431ec2facb7989473b06ebe07246f6d2317f
Mac builds use a javadoc tool that fails on more warnings than linux
builds. Add -Xdoclint:none to all java 8 standard doclet javadoc
commands.
Don't add it to javadoc commands that use the com.google.doclava.Doclava
doclet, it doesn't understand -Xdoclint:none.
Change-Id: I6c2f69555ca64b028d22b06286156491f51ac86c
As we occasionally see java.lang.OutOfMemoryError when running
doc-comment-check-docs.
Bug: 25787786
Change-Id: I6c505c96ec36d09d28d400e03027b169870c49bb
ziptime fails on zip file larger than 2GB.
These zip files won't installed on device and we don't care that much
about their reprodudcibility across builds.
Change-Id: I47062928d075a59eda92dd5333e59502f490d1cb
Pass -X to zip so that Unix UID/GID and extra timestamps aren't
saved into the zip files.
Add a new tool, ziptime, that uses a very stripped down copy of
zipalign. It no longer depends on libandroidfw, and now rewrites the
timestamps in place instead of making a copy of the zipfile. This should
improve speed and reduce disk requirements, especially with the large
packaging zip files.
Bug: 24201956
Change-Id: I50f68669f659da1b4393e964ad40b6aafb00c1e7
This reverts commit 3c2c064c87.
zipalign depends on libandroidfw, and some setups don't include frameworks/base.
Bug: 24201956
Change-Id: I48ee95808924f6b2221f0a49ab205c2565096b1f
Pass -X to zip so that Unix UID/GID and extra timestamps aren't
saved into the zip files.
Add a new option to zipalign, -t, to replace all timestamps with static
timestamps (2008 Jan 1 00:00:00). Use this for all non-APK zip files.
APK zip timestamps are set based on the certificate date in SignApk.
Bug: 24201956
Change-Id: Ifb619fc499ba9d99fc624f2acd5f8de36d78ef8e
Many of these may not make a difference in the output images, but it's a
good idea to keep the make system as repeatable as possible.
Change-Id: I31804b8ad5805148ed08be7426a242a16f4d0df3
Ninja has an implicit dependency on the command being run, and kati will
regenerate the ninja manifest if any read makefile changes, so there is no
need to have dependencies on makefiles.
This won't catch all the cases where LOCAL_ADDITIONAL_DEPENDENCIES contains
a .mk file, because a few users of LOCAL_ADDITIONAL_DEPENDENCIES don't
include base_rules.mk, but it will fix the most common ones.
Bug: 23566977
Change-Id: I66de882421376303ab7233c8ce7274548f6b2199
Instead of using recursive make to change the HOST_OS when building the
windows SDK under linux, add the concept of cross-building to another
host os.
Bug: 23566667
Change-Id: I6dc525b601b6251d458d197c30bf4660d7485502
This moves all of the date references under build/ to using a single
datetime that can be set manually using BUILD_DATETIME.
It also adds an option, OVERRIDE_C_DATE_TIME, that if set to true, will
redefine __DATE__ and __TIME__ for all C/C++ files so that it matches
BUILD_DATETIME.
Bug: 23117013
Change-Id: I7c17a32b794a5adf40b9cd69136fb0ff9f6084ec
This moves all of the date references under build/ to using a single
datetime that can be set manually using BUILD_DATETIME.
It also adds an option, OVERRIDE_C_DATE_TIME, that if set to true, will
redefine __DATE__ and __TIME__ for all C/C++ files so that it matches
BUILD_DATETIME.
Bug: 23117013
Change-Id: I880ef103a26bca86bd7bf42d58e62e740a6228c8
Using $(BUILD_NUMBER) inside a rule causes odd behavior, as the rule
is different every time make is run, but since make doesn't depend
on the command line it only ends up being built with the new value
if some other dependency has changed.
To allow ninja, which does depend on the command line, to provide the
same behavior, store the build number in out/build_number.txt, and
use a shell expansion to cat the file in rules that use it. This will
cause the rule command to stay identical between builds, while still
getting the new build number if the rule is rerun for a dependency.
Also use the same trick for BUILD_FINGERPRINT, and the date in
droiddoc rules.
Change-Id: I6c5e6b6b3ef4c613563d7f5604df0e401575ba5f
When calling droiddoc to generate stubs, if you use
LOCAL_DROIDDOC_STUB_OUT_DIR (instead of "-stubs" to
LOCAL_DROIDDOC_LOCAL_DROIDDOC_OPTIONS), the build system gets the chance
to clean up the stub out directory before calling doclava.
Bug: 22534021
Change-Id: Icb0a73eb51bfb1c1ecd88217ebcd39c27df1de29
This should obviate much of the need for cleanspecs, and also make it
unnecessary to continue adding LOCAL_ADDITIONAL_DEPENDENCIES for this
sort of thing all over the tree.
Change-Id: I97aa8fd280ae868a5f6364f8b7bf3c2fe235d6ce
A module can declare "LOCAL_SDK_VERSION := system_current" to build
against the android system stubs generated from source.
For now this is only supported in platform build.
Change-Id: I1e9bbd159886bc0ea3a02b1dc4cbcb1a56e9cb15
In droiddoc for host, we don't generate classes.jar for
LOCAL_JAVA_LIBRARIES. Switch to refer to the installed jar file instead.
This is consistent with how LOCAL_JAVA_LIBRARIES for host is handled in
base_rules.mk.
Bug: 9176318
Change-Id: If7460b30ca5da28743487d66da0029a44108d556
