Lines Matching refs:to

10 in board config to disable this behavior.
14 Partition builds used to include everything in their staging directories, and building an
15 individual module will install it to the staging directory. Thus, previously, `m mymodule` followed
16 by `m` would cause `mymodule` to be presinstalled on the device, even if it wasn't listed in
23 Manually adding make rules that build to the staging directories without going through the make
29 Each Soong plugin will require manual work to migrate to Bazel. In order to
30 minimize the manual work outside of build/soong, we are restricting plugins to
33 If you need to extend the build system via a plugin, please reach out to the
38 space-separated list of plugins to omit from the validation. This must be set
41 ## Python 2 to 3 migration
43 The path set when running builds now makes the `python` executable point to python 3,
44 whereas on previous versions it pointed to python 2. If you still have python 2 scripts,
45 you can change the shebang line to use `python2` explicitly. This only applies for
48 variable to `true`. It's only an environment variable and not a product config variable
53 variable to `true`.
59 For the migration to Bazel, we are no longer mapping sysprop_library targets
60 to their generated `cc_library` counterparts when dependning on them from a
81 Failure to do this will result in an error about a missing variant.
85 To migrate all gensrcs to Bazel, we are restricting the use of depfile property
133 `BUILD_BROKEN_DEPFILE` can be used to allowlist usage of depfile in `gensrcs`.
142 To better specify the inputs to the build, we are restricting use of directories
143 as inputs to genrules.
145 To fix existing uses, change inputs to specify the inputs and update the command
168 `BUILD_BROKEN_INPUT_DIR_MODULES` can be used to allowlist specific directories
173 In order to construct correct class loader context for dexpreopt, build system
174 needs to know about the shared library dependencies of Java modules listed in
176 access to the manifest contents, that information must be present in the build
177 files. In simple cases Soong is able to infer it from its knowledge of Java SDK
179 necessary to add the missing information in Android.bp/Android.mk manually.
186 If a library is in `libs`, it usually should *not* be added to the above
187 properties, and Soong should be able to infer the `<uses-library>` tag. But
192 cases it is possible to tell the build system that the library provides a
194 deprecated in the future, and it is recommended to fix the underlying problem):
199 It is possible to disable the check on a per-module basis. When doing that it is
200 also recommended to disable dexpreopt, as disabling a failed check will result
207 Finally, it is possible to globally disable the check:
212 The environment variable overrides the product variable, so it is possible to
215 ## `LOCAL_REQUIRED_MODULES` requires listed modules to exist {#BUILD_BROKEN_MISSING_REQUIRED_MODULE…
218 `LOCAL_TARGET_REQUIRED_MODULES` need to exist unless `ALLOW_MISSING_DEPENDENCIES`
229 System properties for each of the partition is supposed to be set via following
307 the first one. To go back to the original behavior for compatability reason,
321 Define prebuilt modules and add them to `PRODUCT_PACKAGES` instead.
322 To temporarily relax this check and restore the behavior prior to this change,
327 We've considered `BUILD_COPY_HEADERS`/`LOCAL_COPY_HEADERS` to be deprecated for
328 a long time, and the places where it's been able to be used have shrinked over
332 how best to handle headers in Android.
351 With `ALLOW_NINJA_ENV=false` (soon to be the default), ninja, and all the
352 rules/actions executed within it will only have access to a limited number of
354 in order to trigger rebuilds, so changing behavior based on arbitrary variables
358 you'd embed any environment variables that you need to use within the command
363 environment to restore the previous behavior, or set
365 to allow specific variables to be passed through until you've fixed the rules.
369 Include directories are expected to be within the source tree (or in the output
374 turn these errors into warnings temporarily. I don't expect this to last more
375 than a release, since they're fairly easy to clean up.
382 This has been checked since Oreo. The common reason to hit this is because a
387 ### Using `../` to leave the source/output directories
391 relative to the top of the source tree) acts like `LOCAL_SRC_FILES` (which is
392 relative to `LOCAL_PATH`).
412 `PRODUCT_STATIC_BOOT_CONTROL_HAL` was the workaround to allow sideloading with
417 image, similar to the ones installed for normal boot. See the change to
434 Previously, adding a module to `PRODUCT_PACKAGES` that supported both the host
436 in Android.mk) would cause both to be built and installed. In many cases you
437 only want either the host or target versions to be built/installed by default,
438 and would be over-building with both. So `PRODUCT_PACKAGES` will be changing to
447 * `PRODUCT_HOST_PACKAGES` requires listed modules to exist, and be host
451 `PRODUCT_PACKAGES` to make installation decisions, but verifies that if we used
454 necessary in `PRODUCT_*PACKAGES`, and tended to be over-built (especially the
457 Future changes will switch installation decisions to `PRODUCT_HOST_PACKAGES`
464 In Android.mk files, you used to be able to change LOCAL_ARM_MODE for each
465 source file by appending `.arm` to the end of the filename in
469 files to be split out into a separate static library that chooses `arm` over
480 modules to specify that they should always be installed on `-eng`, or `-eng`
481 and `-userdebug` builds. This conflicted with the ability for products to
482 specify which modules should be installed, effectively making it impossible to
488 Core android packages like `su` got added to the list in
490 there are often better base product makefiles to use instead.
494 `USER` will soon be `nobody` in many cases due to the addition of a sandbox
495 around the Android build. Most of the time you shouldn't need to know the
505 trigger them to be re-read every time the `BUILD_NUMBER` changes (which it does
514 That will expand out to a subshell that will read the current `BUILD_NUMBER`
523 a PHONY goal, and a list of files to copy to `$DIST_DIR`. Whenever `dist` is
549 If you just want to append `BUILD_NUMBER` at the end of basename, use
565 There are several new warnings/errors meant to ensure the proper use of
566 `.PHONY` targets in order to improve the speed and reliability of incremental
569 `.PHONY`-marked targets are often used as shortcuts to provide "friendly" names
570 for real files to be built, but any target marked with `.PHONY` is also always
571 considered dirty, needing to be rebuilt every build. This isn't a problem for
586 ...mk:42: warning: writing to readonly directory: "kernel-modules"
591 1. The target isn't intended to be a real file, and should be marked with
595    otherwise `m clean` is unable to clean the build, and future builds may not
602 If the first target isn't intended to be a real file, then it should be marked
604 example, as we require `.PHONY` targets not to have '/' in them.
614 have enough dependencies to know when to run the other build system again
617 We recommend to build these outside of Android, and deliver prebuilts into the
621 In cases where that's not desired, to preserve the speed of Android
631 level of incremental build assurances as the Android Build is attempting to do
633 In order to fix this, our recommendation is to do clean builds for each of
636 you're not trying to actively debug the kernel.
643 Device specific configuration should not be able to affect common core build
644 steps -- we're looking at triggering build steps to be invalidated if the set
646 configuration is allowed to change those, switching devices with the same
651 that they are being used incorrectly. Attempting to change the environment for
654 It is not recommended to just move the environment variable setting outside of
656 We expect to limit the environment variables that the build respects in the
657 future, others will be cleared. (There will be methods to get custom variables
658 into the build, just not to every build step)
668 If you want to set many environment variables, and/or use them many times,
669 write them out to a script and source the script:
718 If this causes multiple modules to be named the same, use unique module names
719 and `LOCAL_MODULE_STEM` to change the installed file name:
753 You just need to make sure that any other references (`PRODUCT_PACKAGES`,
754 `LOCAL_REQUIRED_MODULES`, etc) are converted to the new names.
758 We've adopted lexical requirements very similar to [Bazel's
761 characters `_.+-=,@~`. This currently applies to `LOCAL_PACKAGE_NAME`,
765 expect this to have a large effect.
777 message. This is expected to become more restrictive over time.
782 command and arguments used, and the process tree in order to help locate the
785 In order to fix any issues brought up by these checks, the best way to fix them
786 is to use tools checked into the tree -- either as prebuilts, or building them
790 in your environment to temporarily turn off the error checks and allow any tool
791 to be used (with logging). Beware that GCC didn't work well with the interposer
796 It is not required to source envsetup.sh before running a build. Many scripts,
802 Many of these variables also include absolute path names, which we'd like to
803 keep out of the generated files, so that you don't need to do a full rebuild if
809 particular variable, we'll switch it to obsolete, and any references will become
824 need an absolute variable, convert it to absolute during a rule, so that it's
836 $TOP is hardcoded to), or removed entirely. If you need an absolute path, see
841 This isn't only set by envsetup.sh, but it is modified by it. Due to that it's
842 rather easy for this to change between different shells, and it's not ideal to
845 In most cases, you shouldn't need to touch PATH at all. When you need to have a
847 it's preferrable to just use the path to the file itself (since you should
850 Depending on the rule, passing the file path itself may not be feasible due to
851 layers of unchangable scripts/binaries. In that case, be sure to add the
861 Like PATH, this isn't only set by envsetup.sh, but it is modified by it. Due to
862 that it's rather easy for this to change between different shells, and it's not
863 ideal to reread the makefiles every time.
865 The best solution here is to start switching to Soong's python building support,
871 * [frameworks/base/data/fonts/Android.mk] to execute the python binary
873 If you still need to use PYTHONPATH, do so within the rule itself, just like
883 attribute to the root element `<manifest>`. If `PRODUCT_COMPATIBILITY_MATRIX_LEVEL_OVERRIDE`
884 is 26 or 27, you can add `"target-level"="1"` to your device manifest instead.
889 for this option to exist.
907 To fix any build errors, use bpmodify to either
932 the makefile system. If you need one of them, you'll have to set up your own
937 ### Soong config string variables must list all values they can be set to
939 In order to facilitate the transition to bazel, all soong_config_string_variables
940 must only be set to a value listed in their `values` property, or an empty string.