am: 1cafe66be2
* commit '1cafe66be274a5a8bbbc3a0dcab9d4e8f6e5ae61':
Revert "Sign APKs using SHA-256 instead of SHA-1 when possible." This is breaking CTS.
am: 01ac26d942
* commit '01ac26d9422d8d54d3992ba9dd4506896c8556dd':
Revert "Sign APKs using SHA-256 instead of SHA-1 when possible." This is breaking CTS.
Brillo does not require Java. Add a JAVA_NOT_REQUIRED
flag to the build system to make the jdk requirment optional
Also don't build signapk for Brillo
BUG: 25281898
Change-Id: I31e68cc7d076bf6c234699c77c0ea1ea428be4f5
Previously, the timestamp was one hour ahead of NotBefore of the
signer's certificate, adjusted for the current timezone. With this
change the MS-DOS timestamp in output APK/ZIP files is
Jan 1 2009 00:00:00.
Bug: 26864066
Change-Id: Id6263c38ac7042489ab695454f8e0fb2d85a3958
The copy is handled by the common rule, so JAVA_dependency_template
really only needs to add the extra dependencies. Otherwise we were
getting duplicate rule warnings.
This may extract more files than necessary, but that's better than not
enough.
Bug: 26510884
Change-Id: I022f3cc6ddd1982af3f948740917ac03e795f4c5
This changes the build system to provide the signapk tool with the
minSdkVersion of the APK being signed. signapk in turn will then use
SHA-256 instead of SHA-1 if minSdkVersion is 18 (JB MR2) or higher
(see c2c49ed0c1).
To avoid increasing incremental OTA update package sizes for already
released platforms, release build scripts disable the above logic when
signing target files ZIPs for pre-N platforms.
Bug: 25643280
(cherry picked from commit de5bc04717)
Change-Id: I4b100750e47788ab6ed897a0a5abfd33542e8676
Broke the sdk build. Requires changes in development that aren't available for submission yet.
This reverts commit cdfbe4a852.
Change-Id: Ibb655daa05de55c3c947141ddf96a32ca1d87de4
This change enables build rules to specify:
LOCAL_JAVA_LANGUAGE_VERSION := 1.8
to enable -source 1.8 -target 1.8 for javac and
equivalent flags for Jack.
Bug: 26753820
Change-Id: I7991fafe4978485354663f091f4d78a0cc73ba26
This is similar to 2e45fd036a
but this CL is for generated java code.
For C++ code llvm-rs-cc defines two targets but it defines
three targets for Java. The sed script was updated to handle
both cases appropriately.
Bug: 26839129
Change-Id: I5c7705c67f3c65c4c14f74558e603f8ec9f35879
We have been reordering objects to the linker based on how they were
generated. In soong, they're ordered based on the order listed in the
src_files.
Keep track of which source files created which object files so that we
can create the ordered list. Optionally change the order, based on
BINARY_OBJECTS_ORDER. That way we can compare make and soong builds.
Since we're keeping track of the used source files, warn when an entry
in LOCAL_SRC_FILES is not used. (whether it is an unused file like a
header, or a typo)
LOCAL_GENERATED_SOURCES is not verified, since it is valid to add
headers and other files in that list (to set up dependencies).
Change-Id: I1dfbbb3aa570c11c1db3b7133e46ed0b8c3b8989
