These shouldn't be changed by anyone after this point, and this will
prevent random Android.mk from re-including this file.
Test: m nothing
Test: failed on hikey w/o https://android-review.googlesource.com/662764
Change-Id: I7ba4db3594af5b18b98fafee81b64531a40df396
Vendor apks should be able to reference native vendor libraries.
Vendor apks have worked around this by building without
LOCAL_SDK_VERSION, which then allowed to use all libs. However,
since vendor apks now needs to be built with SystemSDK, that
workaround can no longer be used.
Bug: 76398918
Test: BOARD_SYSTEMSDK_VERSION=P m -j
Merged-In: Idb13d5db71f4dfd542658483b6a24e7ece18ce26
Change-Id: Idb13d5db71f4dfd542658483b6a24e7ece18ce26
(cherry picked from commit 49a5b9785f)
* Current default is not using lld.
* When USE_CLANG_LLD or LOCAL_USE_CLANG_LLD is true or 1,
* Use *GLOBAL_LLDFLAGS instead of *GLOBAL_LDFLAGS.
GLOBAL_LLDFLAGS should call lld and with correct lld flags.
* set my_pack_module_relocations to false.
Bug: 73768157
Test: make checkbuild
Change-Id: I3e63cf8ae0865d01d2bc1f36e9304f4a5d092cb8
Vendor apks should be able to reference native vendor libraries.
Vendor apks have worked around this by building without
LOCAL_SDK_VERSION, which then allowed to use all libs. However,
since vendor apks now needs to be built with SystemSDK, that
workaround can no longer be used.
Bug: 76398918
Test: BOARD_SYSTEMSDK_VERSION=P m -j
Change-Id: Idb13d5db71f4dfd542658483b6a24e7ece18ce26
This change allows removing some vendor properties from
(vendor|system/vendor)/build.prop file based on a blacklist.
For WearOS Unified Builds, which can change the product name depending on
the chosen locale, we use runtime-generated value for ro.build.fingerprint,
but since the ro.vendor.build.fingerprint cannot be generated the same way,
we always hit a "Mismatched fingerprints" error.
Bug: 71555551
Test: manual
Change-Id: Ifad793187e930a28fbf9325b03468c7ea86076b7
Currently the build system will automatically attribute a NOTICE
file with the target of $(BUILD_PHONY_PACKAGE). This shouldn't
be the case.
Disable notice file inclusion for fake targets so that the
/fake_packages/blah_blah-timestamp paths don't show up in
NOTICE.xml.gz.
Bug: 77910458
Test: NOTICE files are not attributed to fake targets.
Change-Id: Ia942cac41b750efbd5a23d896d85ac0820ee8b4e
We've had these warnings for a while, but we've still got a lot of
warnings that people have been trained to ignore. Lets just silence them
for now.
The Merged-In is just a random change from AOSP that isn't in pi-dev, to
stop this from being merged to master, where I'm just fixing the
warnings.
Bug: 77883700
Test: m <fewer warnings>
Change-Id: I00d8173a527760d62dca5837bcc86d5f03b87e83
Merged-In: I78ca65e6f0c81f09e7da848eda797b3a8f97a521
There is an extra ) in the implicit output path for R.txt, which causes
the rule to rerun every time because of a missing output file. There
is already an implicit output for R.txt on line 180 (which is why
the incorrect path didn't cause an immediate "No rule to generate R.txt"
error), so just remove the incorrect one.
Bug: 77244156
Test: m checkbuild && m checkbuild
Change-Id: Id960ee211b89a9a5f5104cdcac23bc3124742145
Merged-In: Id960ee211b89a9a5f5104cdcac23bc3124742145
(cherry picked from commit ac48f41ba5)
Instead of passing the entire contents of
$(COMPATIBILITY.$(suite).FILES) to eval, which may keep that string
around, delay the evaluation of that, and the new files until inside the
eval.
This saves ~2.8GB: 7.4GB -> 4.6GB of ckati max resident memory for a
relatively small internal build. It also saves ~10% of the makefile
loading time (81 -> 73 seconds).
Bug: 77879502
Test: build-aosp_arm.ninja is identical
Change-Id: If45a4796f1bbf6d67dff388ea877a6115a4e06f4
Merged-In: If45a4796f1bbf6d67dff388ea877a6115a4e06f4
(cherry picked from commit a4155e8512)
There is an extra ) in the implicit output path for R.txt, which causes
the rule to rerun every time because of a missing output file. There
is already an implicit output for R.txt on line 180 (which is why
the incorrect path didn't cause an immediate "No rule to generate R.txt"
error), so just remove the incorrect one.
Bug: 77244156
Test: m checkbuild && m checkbuild
Change-Id: Id960ee211b89a9a5f5104cdcac23bc3124742145
I'm making some changes to it, and found the names are scattered
in various places. Make a macro and re-use the logic instead.
Bug: 77525052
Test: make droid
Change-Id: I0f2da80b8b4d427353509b27ec720d024eee7a6e
Instead of passing the entire contents of
$(COMPATIBILITY.$(suite).FILES) to eval, which may keep that string
around, delay the evaluation of that, and the new files until inside the
eval.
This saves ~2.8GB: 7.4GB -> 4.6GB of ckati max resident memory for a
relatively small internal build. It also saves ~10% of the makefile
loading time (81 -> 73 seconds).
Test: build-aosp_arm.ninja is identical
Change-Id: If45a4796f1bbf6d67dff388ea877a6115a4e06f4
Many boards have warnings like this, saying that we defined a build
rule, but later something else came in and overrode it with something
else:
art/build/Android.gtest.mk:677: warning: overriding commands for target `test-art-target-gtest-cmdline_parser_test'
art/build/Android.gtest.mk:674: warning: ignoring old commands for target `test-art-target-gtest-cmdline_parser_test'
Beyond the obvious problem of replacing the rule with something else,
target-specific variables can be combined as well, leading to some very
strange problems.
Since so many boards still have problems like this, but we don't
currently have any global problems, add a flag so that we can mark
boards as not broken. This should prevent regressions while we clean up
the individual problems.
Once the non-broken devices number significantly more than the broken
devices, we'll switch this default. And once they're all cleaned up this
variable will become obsolete, and these warnings will always be errors.
Bug: 77611511
Test: lunch aosp_arm-eng; m nothing
Test: lunch aosp_marlin-eng; m nothing
Test: build_test on all downstream branches
Change-Id: I43b645658f468c23a5b9ebcfcd9d4516537db540
Our binary was rather old, and for a variety of reasons we haven't kept
it updated. We've been running into a handful of reliability issues that
would have been fixed with an update, and a few reproducibility /
correctness issues that may or may not be fixed with newer versions.
For local no-change full rebuilds, ccache can still save ~35% of the
build time (but adds a few minutes to initially populate the cache). But
most local uses should be using incremental builds anyways, not clean
rebuilds. Or you're doing builds of different configurations, which
wouldn't be cache hits either, and would make your cache even larger.
At a large scale, we haven't seen a significant performance difference
between having ccache on or off. This may be different if you've got
very good build locality, or a very large cache -- but if you've got
good build locality, it's reasonable to do incremental builds (not for
release builds, and while running `m installclean` in between builds).
So for our cases, we'd prefer the stability and correctness of not using
ccache, but if you still want to use ccache, continue setting USE_CCACHE
and also set CCACHE_EXEC to the path of your ccache executable.
Bug: 32748498
Bug: 72408185
Test: performance testing of USE_CCACHE=false vs true locally
Test: turned off ccache for a collection of targets
Test: CCACHE_EXEC=/usr/bin/ccache USE_CCACHE=true m
Change-Id: I7117fe3107bd98521051ae343038a38f7e855502
LOCAL_VINTF_FRAGMENTS/vintf_fragments are
used to specify what manifest fragments should be installed
by a target.
Test: fragments get installed to the right location
Test: broken fragment gets detected
Test: boot device and verify service is working and manifest is updated
Test: verify OTA package contains fragments
Bug: 66917623
Change-Id: I21abe65a31b8c3d255c8ccd80e102ff3acb23105
Andreas Gampe