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
Currently emulator is using software keymaster
and this module will be removed soon.
Based on the suggestion of keymaster team,
the puresoftware keymaster should be used instead.
removing keystore.goldfish and keystore.ranchu
so puresoftware keymaster can be used.
BUG: 73378534
Test: build sdk_gphone_x86-userdebug
make -j
emulator
boots to homescreen
and pass majority of CtsKeystoreTestCases
failures drop from 100+ to 40+
Change-Id: I5093f5a0989e8aad0a69bbae3e8d789d8d8ae1bb
- tests are out of maintainence
- the checks were general functional tests on comms related
areas and should be covered by the same tests across physical
and virtual devices
Bug: 77496099
Test: build `make -j droid tests dist`
Change-Id: I72c88ebb82c43209cb2d9a2aad24a20562989c46
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
This is a partial revert of I43b645658f468c23a5b9ebcfcd9d4516537db540
On at least a generic_x86 build internally:
art/build/Android.gtest.mk:121: error: overriding commands for target `Uncompressed', previously defined at art/build/Android.gtest.mk:101
Bug: 77611511
Test: none
Change-Id: I78ca65e6f0c81f09e7da848eda797b3a8f97a521
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
The install filter is speed-profile in order to enable the use of profiles
from the dex metadata files. Note that if a profile is not provided or if
it is empty speed-profile is equivalent to (quicken + empty app image).
Test: build & install an app
Bug: b/30934496
(cherry picked from commit b5dadc3a18)
Merged-Id: I6671792b6c846c570a45d3c6a9b9677bcc424b17
Change-Id: I6eb81934a0b7cbaec4ff4471bf465cd40967d40b
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
Elliott Hughes