Lines Matching refs:to

5 In order to construct correct class loader context for dexpreopt, build system
6 needs to know about the shared library dependencies of Java modules listed in
8 access to the manifest contents, that information must be present in the build
9 files. In simple cases Soong is able to infer it from its knowledge of Java SDK
11 necessary to add the missing information in Android.bp/Android.mk manually.
18 If a library is in `libs`, it usually should *not* be added to the above
19 properties, and Soong should be able to infer the `<uses-library>` tag. But
24 cases it is possible to tell the build system that the library provides a
26 deprecated in the future, and it is recommended to fix the underlying problem):
31 It is possible to disable the check on a per-module basis. When doing that it is
32 also recommended to disable dexpreopt, as disabling a failed check will result
39 Finally, it is possible to globally disable the check:
44 The environment variable overrides the product variable, so it is possible to
47 ## `LOCAL_REQUIRED_MODULES` requires listed modules to exist {#BUILD_BROKEN_MISSING_REQUIRED_MODULE…
50 `LOCAL_TARGET_REQUIRED_MODULES` need to exist unless `ALLOW_MISSING_DEPENDENCIES`
61 System properties for each of the partition is supposed to be set via following
139 the first one. To go back to the original behavior for compatability reason,
153 Define prebuilt modules and add them to `PRODUCT_PACKAGES` instead.
154 To temporarily relax this check and restore the behavior prior to this change,
159 We've considered `BUILD_COPY_HEADERS`/`LOCAL_COPY_HEADERS` to be deprecated for
160 a long time, and the places where it's been able to be used have shrinked over
164 how best to handle headers in Android.
183 With `ALLOW_NINJA_ENV=false` (soon to be the default), ninja, and all the
184 rules/actions executed within it will only have access to a limited number of
186 in order to trigger rebuilds, so changing behavior based on arbitrary variables
190 you'd embed any environment variables that you need to use within the command
195 environment to restore the previous behavior, or set
197 to allow specific variables to be passed through until you've fixed the rules.
201 Include directories are expected to be within the source tree (or in the output
206 turn these errors into warnings temporarily. I don't expect this to last more
207 than a release, since they're fairly easy to clean up.
214 This has been checked since Oreo. The common reason to hit this is because a
219 ### Using `../` to leave the source/output directories
223 relative to the top of the source tree) acts like `LOCAL_SRC_FILES` (which is
224 relative to `LOCAL_PATH`).
244 `PRODUCT_STATIC_BOOT_CONTROL_HAL` was the workaround to allow sideloading with
249 image, similar to the ones installed for normal boot. See the change to
266 Previously, adding a module to `PRODUCT_PACKAGES` that supported both the host
268 in Android.mk) would cause both to be built and installed. In many cases you
269 only want either the host or target versions to be built/installed by default,
270 and would be over-building with both. So `PRODUCT_PACKAGES` will be changing to
279 * `PRODUCT_HOST_PACKAGES` requires listed modules to exist, and be host
283 `PRODUCT_PACKAGES` to make installation decisions, but verifies that if we used
286 necessary in `PRODUCT_*PACKAGES`, and tended to be over-built (especially the
289 Future changes will switch installation decisions to `PRODUCT_HOST_PACKAGES`
296 In Android.mk files, you used to be able to change LOCAL_ARM_MODE for each
297 source file by appending `.arm` to the end of the filename in
301 files to be split out into a separate static library that chooses `arm` over
312 modules to specify that they should always be installed on `-eng`, or `-eng`
313 and `-userdebug` builds. This conflicted with the ability for products to
314 specify which modules should be installed, effectively making it impossible to
320 Core android packages like `su` got added to the list in
322 there are often better base product makefiles to use instead.
326 `USER` will soon be `nobody` in many cases due to the addition of a sandbox
327 around the Android build. Most of the time you shouldn't need to know the
337 trigger them to be re-read every time the `BUILD_NUMBER` changes (which it does
346 That will expand out to a subshell that will read the current `BUILD_NUMBER`
355 a PHONY goal, and a list of files to copy to `$DIST_DIR`. Whenever `dist` is
379 There are several new warnings/errors meant to ensure the proper use of
380 `.PHONY` targets in order to improve the speed and reliability of incremental
383 `.PHONY`-marked targets are often used as shortcuts to provide "friendly" names
384 for real files to be built, but any target marked with `.PHONY` is also always
385 considered dirty, needing to be rebuilt every build. This isn't a problem for
400 ...mk:42: warning: writing to readonly directory: "kernel-modules"
405 1. The target isn't intended to be a real file, and should be marked with
409    otherwise `m clean` is unable to clean the build, and future builds may not
416 If the first target isn't intended to be a real file, then it should be marked
418 example, as we require `.PHONY` targets not to have '/' in them.
428 have enough dependencies to know when to run the other build system again
431 We recommend to build these outside of Android, and deliver prebuilts into the
435 In cases where that's not desired, to preserve the speed of Android
445 level of incremental build assurances as the Android Build is attempting to do
447 In order to fix this, our recommendation is to do clean builds for each of
450 you're not trying to actively debug the kernel.
457 Device specific configuration should not be able to affect common core build
458 steps -- we're looking at triggering build steps to be invalidated if the set
460 configuration is allowed to change those, switching devices with the same
465 that they are being used incorrectly. Attempting to change the environment for
468 It is not recommended to just move the environment variable setting outside of
470 We expect to limit the environment variables that the build respects in the
471 future, others will be cleared. (There will be methods to get custom variables
472 into the build, just not to every build step)
482 If you want to set many environment variables, and/or use them many times,
483 write them out to a script and source the script:
532 If this causes multiple modules to be named the same, use unique module names
533 and `LOCAL_MODULE_STEM` to change the installed file name:
567 You just need to make sure that any other references (`PRODUCT_PACKAGES`,
568 `LOCAL_REQUIRED_MODULES`, etc) are converted to the new names.
572 We've adopted lexical requirements very similar to [Bazel's
575 characters `_.+-=,@~`. This currently applies to `LOCAL_PACKAGE_NAME`,
579 expect this to have a large effect.
591 message. This is expected to become more restrictive over time.
596 command and arguments used, and the process tree in order to help locate the
599 In order to fix any issues brought up by these checks, the best way to fix them
600 is to use tools checked into the tree -- either as prebuilts, or building them
604 in your environment to temporarily turn off the error checks and allow any tool
605 to be used (with logging). Beware that GCC didn't work well with the interposer
610 It is not required to source envsetup.sh before running a build. Many scripts,
616 Many of these variables also include absolute path names, which we'd like to
617 keep out of the generated files, so that you don't need to do a full rebuild if
623 particular variable, we'll switch it to obsolete, and any references will become
638 need an absolute variable, convert it to absolute during a rule, so that it's
650 $TOP is hardcoded to), or removed entirely. If you need an absolute path, see
655 This isn't only set by envsetup.sh, but it is modified by it. Due to that it's
656 rather easy for this to change between different shells, and it's not ideal to
659 In most cases, you shouldn't need to touch PATH at all. When you need to have a
661 it's preferrable to just use the path to the file itself (since you should
664 Depending on the rule, passing the file path itself may not be feasible due to
665 layers of unchangable scripts/binaries. In that case, be sure to add the
675 Like PATH, this isn't only set by envsetup.sh, but it is modified by it. Due to
676 that it's rather easy for this to change between different shells, and it's not
677 ideal to reread the makefiles every time.
679 The best solution here is to start switching to Soong's python building support,
685 * [frameworks/base/data/fonts/Android.mk] to execute the python binary
687 If you still need to use PYTHONPATH, do so within the rule itself, just like
697 attribute to the root element `<manifest>`. If `PRODUCT_COMPATIBILITY_MATRIX_LEVEL_OVERRIDE`
698 is 26 or 27, you can add `"target-level"="1"` to your device manifest instead.
703 for this option to exist.
714 the makefile system. If you need one of them, you'll have to set up your own