Before, the values were often simply ignored. If bad values are provided
now, we should be able to catch them.
Bug: 119771576
Test: relying on this for AIDL/HIDL
Change-Id: I8d2ff26da0b2d01ebe7f78c26d69c7b618a65367
To build the platform for ASAN, we do
`m && SANITIZE_TARGET='addresss' m`
However, at the end of the second build, the system partition could have
conflicting APEXes; prebuilt APEXes from the first build and
source-built APEXes from the second build. Since the file names for the
prebuilt and the source-built are different (e.g.
com.google.android.media.apex v.s. com.android.media.apex), we end up
having two files for the same APEX. This is confusing apexd at runtime
and the device fails to boot.
To fix this, when building a non-prebuilt APEX, the prebuilt APEX might
have been installed by the previous build is deleted.
Bug: 138146044
Test: lunch aosp_cf_x86_pasan; m && SANITIZE_TARGET='address' m
check that out/target/product/vsoc_x86/system/apex has
com.android.*.apex only.
Change-Id: Ib5a021a297cf0173ea5a3b50e9398b1cf295c558
Use Kythe (https://kythe.io) to build cross reference for the Android
source code. ~generate the input for it during the build. This is done
on demand: if XREF_CORPUS environment variable is set, build emits a
Ninja rule to generate Kythe input for each compilation rule. It
also emits two consolidation rules (`xref_cxx` and `xref_java`),
that depend on all Kythe input generation rules for C++ and Java.
The value of the XREF_CORPUS environment variable is recorded in the
generated files and thus passed to Kythe. For the AOSP master branch it is
`android.googlesource.com/platform/superproject`, so the command to build
all input for Kythe on that branch is:
```
XREF_CORPUS=android.googlesource.com/platform/superproject m xref_cxx xref_java
```
Each Kythe input generation rule generates a single file with .kzip
extension. Individual .kzip files have a lot of common information, so
there will be a post-build consolidation step run to combine them.
The consolidated .kzip file is then passed to Kythe backend.
The tools to generate .kzip files are provided by Kythe (it calls them
'extractors'). We are going to build them in toolbuilding branches
(clang-tools and build-tools) and check them in as binaries into master
and other PDK branches:
For C++, `prebuilts/clang-tools/linux-x86/bin/cxx_extractor`
for Java, `prebuilts/build-tools/common/framework/javac_extractor.jar`
Bug: 121267023
Test: 1) When XREF_CORPUS is set, build generates Ninja rules to create
.kzip files; 2) When XREF_CORPUS is set, building
`xref_cxx`/`xref_java` creates .kzip files; 3) Unless XREF_CORPUS is
set, build generates the same Ninja rules as before
Change-Id: If957b35d7abc82dbfbb3665980e7c34afe7c789e
* changes:
Add defaults_visibility support
Refactor visibility to support visibility on defaults modules
Add DefaultsModule interface
Improve documentation of defaults mechanism
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
* 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
This reverts commit ff3d72f0bf.
Repplies original change now that issue causing build breakage has been
resolved.
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: I4c802ef25ef56f0f9b0b5e9d75531ea6f7475714
Since aosp/872653 and aosp/904233 landed, prebuilt_etc_xml has been broken.
aosp/872653: Enable arch variant properties in prebuilt_etc.
aosp/904233: Add a prebuilt module type for usr/share.
This change fixes
1) pass baseDir "etc" to initialize PrebuiltEtc struct
2) change "multlib" argument to MultilibFirst to reflect aosp/872653
Bug: 138082739
Test: m com.google.vr.platform.xml && see if it is installed in /system/etc
Change-Id: I4802107fd8ccf28a1170d7d165700c92df32e341
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
The droiddoc rules are ripe for converting to android.RuleBuilder,
they conditionally use many input files which is hard to track
with the standard blueprint.Rule style, as the argument and the
dependency have to be handled independently. Start converting
to android.RuleBuilder by converting the droidstubs module.
Test: m docs
Test: m checkapi
Test: m updateapi
Change-Id: I08713e91149471e88a40115f69824cf5eaf88fb6
Test: Built aosp_arm-user with and without USE_RBE. USE_RBE uses
a proxy script in place of rewrapper.
Change-Id: I5bf008a940513872d70b5b215bd6209f759826ae
