Rather than use an unsupported flag setting that the user likely
doesn't even realize is being used, we immediately stop the build.
This error message is more verbose, mentioning 'lunch', because
it's anticipated a lot more users will hit this issue when first
switching to trunk stable, and more details will hopefully help
them out.
We have some complication in that some internal commands set
TARGET_RELEASE to an empty string. We put in logic to allow
that path.
Since $(error) immediately stops the build, we also get rid of
some 'else' logic and indentation, to hopefully offset some of
the complication we've added.
Bug: 307946156
Test: 'lunch' (still) works; A build attempt without `TARGET_RELEASE` set (now) fails
Change-Id: I2f667668c6688e501a3536981b7bae5fdbf962a0
These files don't have anything to do with bazel, they just use starlark as a configuration
language. Bazel recently introduced the scl file extension to use for this format, which doesn't
have any bazel-specific symbols. Use that extension for our pure starlark files as well.
Bug: 309686282
Test: Presubmits
Change-Id: I7b08f342e7fb94405a52af0918ae6a7d542f3282
- Introduce a new directory for some specific proguard rules.
kotlin.flags:
- Remove DebugMetadata
- Don't warn about missing non-runtime annotations
Test: build AOSP & test on internal
Bug: 309023911
Change-Id: Iee740b61a2afeba3482ff4e1f8213bd4cf46174a
Allow a build flag definition to indicate that its value should be the
concatentation of assignements, rather than the final assigned value. In
this case, the "default" value from the flag definition is always
present as the start of the list.
The initial use case for this is RELEASE_ACONFIG_VALUE_SETS, where we
need apply multiple definition files that should be processed to arrive
at the final value.
Bug: b/302593603, b/304814040, b/309477343
Test: manual
Change-Id: I58eb71f2ee6d8f08f11a432993f23157831ec93c
1. release config maps now specify where the flag definitions are found.
2. PRODUCT_RELEASE_CONFIG_MAPS specifies additional release config map
files to use.
This allows product config to specify build flags, which can then be
specified by users of that product.
Bug: b/302593603, b/309477343
Test: manual
Change-Id: Ic1f0512ec4b06ac94dd3f29eadd6a03ba8ebf6d2
Previously, the 16K/4K boot options OTAs are full OTAs, resulting in
file size of ~20MB each, and ~40M for both OTAs. To reduce the space
usage, use incremental OTAs instead.
Test: th
Bug: 302759296
Bug: 293313353
Change-Id: I61cc84c6c13f151dd6bc5ff37dd31daa5fb31abd
This is a new mechanism for asserting properties about your product
config. See the documentation in product_validation_checks.mk for
more information.
Test: Manually
Change-Id: I698dea899441f3773f839ea2ba1a2a6cfe59b57b
* changes:
Remove code related to unused LOCAL_* variables
Delete unused variables from clear_vars.mk
Remove obsolete ide.mk and related code
Removed unused license code
Remove obsolete uses of LOCAL_MODULE_TAGS
LOCAL_JETIFIER_ENABLED, LOCAL_NO_PIC, LOCAL_PREBUILT_STRIP_COMMENTS,
LOCAL_RMTYPEDEFS, and *.vts sources are never used. Remove them
and the code related to them.
Test: no change to out/build-aosp_cf_x86_64_phone.ninja
Change-Id: I2ca9e674602057cc163b8bc28b0c57a0b7cc4361
Kati analysis in AOSP spends around 6 seconds in clear_vars.mk.
Delete any variables in clear_vars.mk that are not referenced anywhere
else in build/make/core.
Test: no change to build-aosp_cf_x86_64_phone.ninja
Change-Id: I7e0db3c02d297de825acbfbd1a0f05724d1e846d
The code to generate an eclipse classpath is obsolete, remove it and
related code.
Test: no change to out/build-aosp_cf_x86_64_phone.ninja
Change-Id: I7e1b6268b98ecbb7be88db8945dd7b30acc695ba
Nothing ever reads ALL_DEPS.*.LICENSE, and its an ever-growing list
that is sorted every time, which is extremely expensive.
notice_target is never set after I4cddf9a381a1258bdc2b1b42be72c447df10d234,
remove all the related code.
Test: no change to out/build-aosp_cf_x86_64_phone.ninja
Change-Id: I0fa6a46e62ef8aa78873b43d3064b57b1c54de51
Only LOCAL_MODULE_TAGS := tests is used is meaningful in the current
implementation. "optional" and "samples" both exist in the tree, but
are meaningless. "gnu", "user", "eng" and "debug" are no longer used,
and are already forbidden by the unusual tags check. The info from the
"module" target is now available in module-info.json. Delete all the
irrelevant code.
Test: no change to out/build-aosp_cf_x86_64_phone.ninja
Change-Id: I04e8178a362e382a1a4bd997c1b4c3a480db7714
Allow a build flag definition to indicate that its value should be the
concatentation of assignements, rather than the final assigned value. In
this case, the "default" value from the flag definition is always
present as the start of the list.
The initial use case for this is RELEASE_ACONFIG_VALUE_SETS, where we
need apply multiple definition files that should be processed to arrive
at the final value.
This reverts commit b05eaac092.
Bug: b/302593603, b/304814040
Test: manual
Change-Id: I7370c509ceb3952f7feb2351673d8f2ba86d704b
1. release config maps now specify where the flag definitions are found.
2. PRODUCT_RELEASE_CONFIG_MAPS specifies additional release config map
files to use.
This allows product config to specify build flags, which can then be
specified by users of that product.
This reverts commit 75bfc37ef4.
Bug: b/302593603
Test: manual
Change-Id: I031a00459893644d7f67b63b982db9ae9015ae4d
Until we have updated art mainline module, we must provide
ro.product.vndk.version to use product namespace for product apks.
This can be removed when art mainline module is updated.
Bug: 308676119
Test: See if product apps uses product-clns namespace in
cf_x86_64_phone-next-userdebug
Change-Id: I5030fb0f82c80e0cb94c89179e6c71df119368da
Revert submission 2787001-product-build-flags
Reason for revert: Possible cause of b/308849337
Reverted changes: /q/submissionid:2787001-product-build-flags
Bug: 302593603
Bug: 308849337
Change-Id: I01b5905a0a20a1401dcc1267e7fafc893e57d637
Revert submission 2787001-product-build-flags
Reason for revert: Possible cause of b/308849337
Reverted changes: /q/submissionid:2787001-product-build-flags
Bug: 302593603
Bug: 308849337
Change-Id: I6246d20201e674ba99faf6b880ecdc7ef934c653
The new docker image contains all en_*.UTF-8 locales to ensure Java (and
other) actions produce the correct bytes.
Bug: b/300624128
Test: Ran an android build and verified there are no encoding issues in
metalava outputs.
Change-Id: Id1eab37edfc71b3b56f4ac38259407c0a1b10667
This exports a map of build flags used in this release config to Soong.
Bug: b/302514918
Test: manual
Change-Id: Ia93195f09dee4945f07326eb7a5973c2ce2e025b
Instead of listing all apexes in the source tree, now each apex emits
its own fragment for apexkeys.txt, which is pointed by
LOCAL_APEX_KEYS_FILE. Makefile collects apexkeys.txt from installed apex
files. This is to avoid listing unrelated apexes (not installed,
testdata, unexported namespaces, etc.)
Bug: 304914238
Test: m apexkeys.txt
Test: m blueprint-tests
Change-Id: I6b5601609d16452a0717f09ecaa703ee09693094
Instrumentation test config created by autogen is still using python script
auto_gen_test_config.py, which doesn't support extra_runner_options yet.
Bug: 308627607
Test: m FrameworksCorePackageInstallerSessionsTests
Change-Id: Ib3bef791a9d1b3e0b68f5845dc20d2c5ec5791ec
layoutlib.jar, from module layoutlib
icu*.data, from module icu-data_host_i18n_apex
libicuuc_stubdata.dll, from module libicuuc_stubdata
libicuuc-host.dll, from module libicuuc
See https://cs.android.com/search?q=%22targets:%20%5B%5C%22layoutlib%5C%22%5D%22&ss=android%2Fplatform%2Fsuperproject%2Fmain
The static dependencies of java_library and cc_library have not been included and will be handled in later CLs.
Bug: 303905932
Bug: 303904827
Bug: 303905759
Test: lunch sdk_phone64_arm64-userdebug && m layoutlib dist; CIs
Change-Id: I0c04fed2872b674a460a4a08880e67a6311890c4
Allow a build flag definition to indicate that its value should be the
concatentation of assignements, rather than the final assigned value. In
this case, the "default" value from the flag definition is always
present as the start of the list.
The initial use case for this is RELEASE_ACONFIG_VALUE_SETS, where we
need apply multiple definition files that should be processed to arrive
at the final value.
Bug: b/302593603, b/304814040
Test: manual
Change-Id: I2474cdf23341f9b1682affce6cc784281557655d
1. release config maps now specify where the flag definitions are found.
2. PRODUCT_RELEASE_CONFIG_MAPS specifies additional release config map
files to use.
This allows product config to specify build flags, which can then be
specified by users of that product.
Bug: b/302593603
Test: manual
Change-Id: I660a3d88c2aaecc14d6f370bebb0d05a8cc224f2
