Existing modules, either general one or package ones have a single
visibility property, called visibility in general, and
default_visibility on package, that controls access to that module, or
in the case of package sets the default visibility of all modules in
that package. The property is checked and gathered during the similarly
named phases of visibility processing.

The defaults module will be different as it will have two properties.
The first, visibility, will not affect the visibility of the module, it
only affects the visibility of modules that 'extend' the defaults. So,
it will need checking but not parsing. The second property,
defaults_visibility, will affect the visibility of the module and so
will need both checking and parsing.

The current implementation does not handle those cases because:
1) It does not differentiate between the property that affects the
   module and those that do not. It checks and gathers all of them with
   the last property gathered overriding the rules for the previous
   properties.

2) It relies on overriding methods in MethodBase in order to change the
   default behavior for the package module. That works because
   packageModule embeds ModuleBase but will not work for
   DefaultsModuleBase as it does not embed ModuleBase and instead is
   embedded alongside it so attempting to override a method in
   MethodBase leads to ambiguity.

This change addresses the issues as follows:
1) It adds a new visibility() []string method to get access to the
   primary visibility rules, i.e. the ones that affect the module.

2) It adds two fields, 'visibilityPropertyInfo []visibilityProperty'
   to provide information about all the properties that need checking,
   and 'primaryVisibilityProperty visibilityProperty' to specify the
   property that affects the module.

The PackageFactory() and InitAndroidModule(Module) functions are
modified to initialize the fields. The override of the
visibilityProperties() method for packageModule is removed and the
default implementations of visibilityProperties() and visibility()
on ModuleBase return information from the two new fields.

The InitDefaultsModule is updated to also initialize the two new
fields. It uses nil for primaryVisibilityProperty for now but that
will be changed to return defaults_visibility. It also uses the
commonProperties structure created for the defaults directly instead
of having to search for it through properties().

Changed the visibilityProperty to take a pointer to the property that
can be used to retrieve the value rather than a lambda function.

Bug: 130796911
Test: m nothing
Change-Id: Icadd470a5f692a48ec61de02bf3dfde3e2eea2ef

Changes the InitDefaultsModule method from taking a DefaultableModule
to taking a DefaultsModule in preparation for adding visibility support
to defaults modules.

Bug: 130796911
Test: m nothing
Change-Id: I1d459da1017ae7f2654e7eb275cb424e52d85730

Also, removes unnecessary cast from DefaultableModule to Defaultable.

Bug: 130796911
Test: m nothing
Change-Id: I01d8f5186927215a1aa6b7431558041f427d7381

This is done so that prototype tooling can write logs inside the DIST_DIR.

Test: I wrote out all the environment variables being passed to
goma_ctl.py and the output is https://paste.googleplex.com/6663469954760704. It contains both DIST_DIR and other variables.

Change-Id: Ia5c70e58aa1b87db9777c59cf3e5df1c9e20f08c

Test: m
Change-Id: I5b332ce12d70f13eca93b23060620c0ea4f46db7

Test: treehugger
Change-Id: I4953ff6f9ead5ad79519ac7fa71b557807f25851

Just like native libs, a java library that is included in an APEX is
mutated for the APEX. This allows us to infer the context (e.g.
sdk_version, etc.) for building a java library in an APEX.

Bug: 138182343
Test: apex_test added
Change-Id: I9292ea097b98e74a8a794f164bd2bed3921d6337

* changes:
  Fix date on mac builds
  Convert javadoc modules to android.RuleBuilder
  Convert droiddoc modules to android.RuleBuilder
  Add a systemModules utility type
  Convert droidstubs to android.RuleBuilder

1. Update pom2bp to support "host_support" device module.
2. Allow other module type in support library

(The intention is to support the room annotation processor)

Test: m

Bug: 137918883

Change-Id: I9a8fbcff903cc395d5dc38430774202ce389d6bc
Merged-In: I9a8fbcff903cc395d5dc38430774202ce389d6bc
(cherry picked from commit bd7c2f9a)

Export LLNDK_MOVED_TO_APEX_LIBRARIES which is used by make
to filter out LLNDK libs that been migrated to an APEX.
It's used by the ld.config.txt generaton, and to filter out
the vndk_package dependencies.

Test: Build&flashed crosshatch image
Bug: 137320025
Change-Id: I1449dad79edf36a628fa1ac15c35f163dbd8ee2a

This change fixes a bug that a symlink in the bin/* directory of an APEX
is not added to the fs_config file.

Bug: 137918291
Test: choosecombo aosp_x86_arm
TARGET_FLATTEN_APEX=false m com.android.runtime.debug is successful

Change-Id: Ib10b635f08e03b18e8ad5407d8de6bac2c85326d

We already link the shared prebuilt from the toolchain. This is
redundant and the wrong version.

Test: make checkbuild
Bug: http://b/74067984
Change-Id: I4b5d23514158eebfb4eea2aa6761e076131c3224

Adds a new StartsWith(string) ValueMatcher along with
With[Out]Matcher(...) methods to support new restrictions that prevent
any paths into runtime module repositories from being added to the
include_dirs.

Test: m nothing
Bug: 35624006
Change-Id: Ib954998e5fc190d8a11a8c6ac5f810cad927aac3

Make it easy to add additional ways of matching property values. Needed
to add support for a 'starts with' matcher that can be used to restrict
allowable values in include_dir.

Test: m nothing
Bug: 35624006
Change-Id: I82e7d95f08847bf294aac311968e1d9f3e4b385d

Newer llvm-strip no longer accepts single dash for multi-character
arguments.

Test: TreeHugger
Bug: 131328001
Change-Id: I4ca862d480860c00e7f8f644f79e300cb523dad0

If a test module with a `test_per_src` property set to `true` is
included in an APEX module, add all the variants for mutator
`test_per_src` as dependencies of the APEX module (not just the
first one).

This is done by adding variation "" of mutator `test_per_src` when
adding a test dependency to an APEX module, which creates an indirect
dependency of the APEX module on all the `test_per_src` variants of
the test module. When generating outputs for the APEX bundle, fetch
and include the set of test outputs from the "" variant.

Test: m (`apex/apex_test.go` amended)
Bug: 129534335
Change-Id: I1c99855971a8a9b2fc5b964a420e882b6791d4e6

Have `cc.testPerSrcMutator` create an additional variation named "",
having no sources (and generating no output file), but depending on
all other `test_per_src` variations and collecting their output files
in a new field named `cc.Module.testPerSrcOutputFiles`. This is useful
in the case where a module depends on all the `test_per_src`
variations of a test module.

Test: m
Bug: 129534335
Change-Id: I905decc0b9417f47cee9113466677d3bb61ad7b6

* changes:
  aidl include paths are exported to droiddoc
  filegroup.path is used to specify the include path for aidl files

This change fixes a bug that aidl include paths are not exported when a
java lib is used by a droiddoc module.

Bug: 135922046
Test: N/A
Change-Id: I367695677f60bfb4f324b788c7d09cd926cb75bb

filegroup {
    name: "foo",
    srcs: ["srcs/aidl/com/android/**/*.aidl"],
    path: "srcs/aidl",
}

cc_library { // or java_library, etc.
    name: "bar",
    srcs: [":foo"],
}

automatically adds "-Ipath/to/foo/srcs/aidl" when compiling the aidl
files from foo for bar. This allows us to omit aidl include path
when using sources in other places via file group.

Bug: 135922046
Test: m (unit tests added)
Change-Id: I9b42f316f2858fb6da72c2f58a314f391416e809

The fuzzer runtime is not present for darwin host modules, disable
cc_fuzz modules when targeting darwin.

Test: m on darwin
Change-Id: I9da319e00e36c3e0a5912329de7890a6409f1a55

date on mac takes a -r argument that expects seconds, date on linux
takes a -d argument that expects a date string.  Prefixing the date
string with @ makes date on linux treat the time as seconds, but is
incorrect for date on mac.

Test: m docs
Change-Id: Ic2a585eaac4c25b7b471caa581d7f25827c3a6b3

Test: m docs
Test: m checkapi
Test: m updateapi
Change-Id: I11ccabc46302ca06298240683ab686134e2e5b8a

Test: m docs
Test: m checkapi
Test: m updateapi
Change-Id: Icc932c4a9a3fc642c96ab9cbd8df3229b5ab86d3

Storing system modules in a classpath is clumsy, as there should
only ever be one system modules, and it needs to store both a
directory to pass as the argument and a set of generated files
to use as dependencies.  Store them in a separate systemModules
type instead.

Test: m checkbuild
Change-Id: I020556c736bd5091865bcca51dc0fb9e4db6b45b