The proto handling will modify the set of dependent libraries, but
this was not actually accounted for in dependency handling because
dependencies had already been established.
Change-Id: Iba1582f3c9eeeada19569e4b5358b6ec4168fccc
If LOCAL_WHOLE_STATIC_LIBRARIES contains a library that has
two files that have the same name but are in different
directories, only the first gets included.
This fix detects this case, and uses the m option to ar to force the
duplicate object to the end of the archive. After this, using the p
option gets the correct object file.
Change-Id: I2e183f48cef3c79499d4ab8ff147444611ff938b
In anceint time we didn't have an "sdk" product so that we had to run
"make sdk" in a device product configuration.
Now we have SDK specific product configuration and we don't do "make
sdk" in device product configuration.
Change-Id: I40d58d51261498017bbe7e574c8128afc77e9b96
The transitive symbol resolving causes build breakage when a binary
has indirect dependency on the NDK library.
We only observed such behaviour in the aarch64 toolchain.
Change-Id: I29e01f16bdfa3aa206cd42d6f07c764fd436873a
In commit e9dd9f2bf we moved "include $(BUILD_SYSTEM)/android_manifest.mk"
forward before the variable intermediates.COMMON gets defined. That's a
mistake.
This change replaced the tentative variables
package_expected_intermediates_COMMON and guessed_intermediates with
their proper counterparts defined in base_rules.mk.
If their values differ in the two file, that's an error and we should
fix.
Bug: 18168693
Change-Id: I2bf17b0476b4a7f97810fbb0bde7630eb8878b53
- You can give a .aar as source file to a prebuilt static Java library
module. The build system will set up dependencies and rules to extract
classes.jar and other resource files.
- To build against a prebuilt AAR module, use:
LOCAL_STATIC_JAVA_AAR_LIBRARIES := <module names of aar prebuilt AARs>
The build system will set up rules to merge the library's
AndroidManifest.xml with the main AndroidManifest.xml, add the AAR's
resource dirs and link/merge the AAR's classes.jar.
Bug: 18168693
Change-Id: Ic2c1d20572a93bd98dbc72f8a39e26b459e442c2
(cherry picked from commit e9dd9f2bfc)
Now libart is the only supported runtime and
we don't need the build variables PRODUCT_RUNTIMES and
DALVIK_VM_LIB.
Bug: 18465297
Change-Id: Ibfda931cde0649163d79b584fb5ccad927a9bc2b
We use search LOCAL_DPI_VARIANTS in the list of
"$(PRODUCT_AAPT_PREF_CONFIG) $(PRODUCT_AAPT_PREBUILT_DPI)"
and the first takes precedence.
That way if we don't have a best match, we fall back to the second best,
the way how it worked with PRODUCT_AAPT_CONFIG previously.
Bug: 18388705
Change-Id: I8bd646c52215c65cc6e38c728857af9b64d13469
We had discussed the idea of making all host tools default to using
ASAN. Even if we don't make it the default, this makes it easy for the
user to switch all host binaries over.
Change-Id: I64a5c741b1b4e9aefed3a6be8dcd4f386e06b29c
Pass -fsanitize=address instead of manually specifying asan libraries
and other linker flags.
Note that we enable LOCAL_ALLOW_UNDEFINED_SYMBOLS by default for host
builds because ASAN only links symbols in the final executable, so
there will _always_ be undefined symbols in intermediate libraries.
Bug: 18208352
Change-Id: Ief55ab296e94974560eeb10507ec8d90f0025d5c
