Checking apex_available was missing some corner cases.
For example, the deps of share deps of cc_library modules are missed
while those from cc_library_shared are correctly tracked.
This was due to..
* calling DepIsInSameApex in WalkDeps: both work fine separately, but
when they are used together, it fails to work. It's due to how WalkDeps
works. (We might fix this bug too risky since it is used very widely)
* incorrect receiver for DepIsInSameApex in apex_deps mutator: receiver
is supposed to be parent, but child was used before. Interestingly lots
of deps are within the same group of module types(cc to cc, java to
java), it has worked. (note that receiver's DepIsInSameApex
implementation can be different).
This change fixes them by..
* walkPayloadDeps is now relying on ApexVariation, which is calculated
correctly by TopDown apex_deps mutator.
* use correct receiver for DepIsInSameApex in apex_deps mutator, which
requires for java.SdkLibrary to override the method and for
java.Library/Import to use passed dep instead of receiver to check its
membership of sdk.
Exempt-From-Owner-Approval: cherry-pick from aosp/master
Bug: 151071238
Test: build/boot
Merged-In: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
(cherry picked from commit 5e9013be22)
Change-Id: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
If an sdk variant is disabled (e.g. say windows) then it should not
add dependencies on corresponding sdk member variants as if those
variants have not been created then the build breaks unnecessarily.
This is needed to make progress on unbundling art which provides at
least one host tool (dex2oat) that is not supported on all platforms
and some (hiddenapi) that only produce 64 bit versions.
Initially, the art prebuilts will only support building 64 bit
versions of linux host tools.
Bug: 142935992
Test: m art-module-sdk art-module-host-exports art-module-test-exports
Change-Id: Idfbb40bb3cabc6eb731a2b38f045ed14f0a713cc
While it is invalid to mix //visibility:public with other rules in the
visibility property in a .bp file tt was possible, by overriding
defaults, to have //visibility:public mixed in with other rules in the
effective visibility rules. That caused problems when those effective
rules were used in an sdk snapshot.
This change replaces any set of rules that include //visibility:public
with just the //visibility:public rule. That simplifies those rules,
making them cheaper to process and ensures that the effective rules are
valid in the visibility property.
Adding test support required some refactoring of the
effectiveVisibilityRules(BaseModuleContext, ...) and underlying methods
to take a Config instead of BaseModuleContext as the tests do not have
access to BaseModuleContext.
Bug: 142935992
Test: m nothing - new tests failed without change, work with it
Add dex2oat to art-module-host-exports, build it and check the
generated Android.bp file in the snapshot to ensure the
visibility property for the dex2oat prebuilt does not mix
//visibility:public with other rules.
Change-Id: I08e7f0dcb40838d426fe88fedf69eae27b77473c
Move the NDK modules defined in app_test.go into cc/testing.go in
preparation for using sdk_version: "current" in more tests.
Test: all soong tests
Change-Id: I80bc31225fb4562fce42781219cefbbd6affae06
Internal sdk members are used by an sdk member but not exported by the
sdk. The exported sdk members are those listed explicitly in one of the
sdk member list properties, e.g. java_header_libs.
The prebuilts of an internal sdk member use a unique name so that they
do not clash with the source module. The use of the module internally
is an implementation detail that must not have any effect outside the
snapshot. Having the same name as the source module could cause it to
override the source module, hence why it needs a unique name.
Similarly, they are marked as private so as to prevent their accidental
use from outside the snapshot.
Bug: 142940300
Test: m nothing
Change-Id: Id5364b410be0592f65666afb3e40e9d3f020251c
Adds an SdkMemberType implementation for java_system_modules. It
specifies that java_system_modules can be used with sdk as well as
module_exports, and also that the libs property should be included
as transitive members in the sdk.
It also adds support for treating appropriate tagged properties in
the snapshot prebuilts module as references to sdk members so that
they are correctly transformed when creating the versioned modules.
Bug: 142940300
Test: m nothing
Change-Id: Ic10b5a6d5b92b6018334fe876f06feaf79cc55e9
Allow an sdk member type to treat some of its dependencies as being
members of the sdk.
Needed for the java_system_modules type whose libs property are an
implementation detail of the system module and so should not be
explicitly listed in the sdk module but still have to be included in
the sdk snapshot.
Bug: 142940300
Test: m nothing
Change-Id: I90f37dae269ef64a6fe9debd0bbaf29a64dd74d8
This change fixes a bug that apex_available is not enforced for static
dependencies. For example, a module with 'apex_available:
["//apex_available:platform"]' was able to be statically linked to any
APEX. This was happening because the check was done on the modules that
are actually installed to an APEX. Static dependencies of the modules
were not counted as they are not installed to the APEX as files.
Fixing this bug by doing the check by traversing the tree in the method
checkApexAvailability.
This change includes a few number of related changes:
1) DepIsInSameApex implementation for cc.Module was changed as well.
Previuosly, it returned false only when the dependency is actually a
stub variant of a lib. Now, it returns false when the dependency has one
or more stub variants. To understand why, we need to recall that when
there is a dependency to a lib having stubs, we actually create two
dependencies: to the non-stub variant and to the stub variant during the
DepsMutator phase. And later in the build action generation phase, we
choose one of them depending on the context. Also recall that an APEX
variant is created only when DepIsInSameApex returns true. Given these,
with the previous implementatin of DepIsInSameApex, we did create apex
variants of the non-stub variant of the dependency, while not creating
the apex variant for the stub variant. This is not right; we needlessly
created the apex variant. The extra apex variant has caused no harm so
far, but since the apex_available check became more correct, it actually
breaks the build. To fix the issue, we stop creating the APEX variant
both for non-stub and stub variants.
2) platform variant is created regardless of the apex_available value.
This is required for the case when a library X that provides stub is in
an APEX A and is configured to be available only for A. In that case,
libs in other APEX can't use the stub library since the stub library is
mutated only for apex A. By creating the platform variant for the stub
library, it can be used from outside as the default dependency variation
is set to the platform variant when creating the APEX variations.
3) The ApexAvailableWhitelist is added with the dependencies that were
revealed with this change.
Exempt-From-Owner-Approval: cherry-pick from internal
Bug: 147671264
Test: m
Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
(cherry picked from commit fa89944c79)
Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
Moves the struct to android/sdk.go and abstracts it behind a factory
method and interface. That allows it to be used outside the sdk
package.
This change is in preparation for adding support for module types that
have transitive sdk members.
Bug: 142940300
Test: m nothing
Change-Id: I71e5e0adf839b28a3a0952f82637637887f02688
This is preparation for enhancing the versioning tranformer to support
applying per property transformations. Specifically, to allow
properties to reference other libraries within the sdk.
Bug: 142940300
Test: m nothing
Change-Id: I99cdff4b407763ed395ff358d8110a63c6cf5589
Moves the code for transforming an unversioned module into a
versioned module into a transformer.
This is preparation for enhancing the versioning tranformer to support
applying per property transformations. Specifically, to allow
properties to reference other libraries within the sdk.
Bug: 142940300
Test: m nothing
Change-Id: Ia6b5cff8e1b5cd7232e031769d9fc0019e815fcb
Adds support for transforming a bpModule using a bpTransformer
instance. Rewrites the deepCopy code as a transformer.
This is preparation for allowing the update process to perform
per property transformations when transforming an unversioned
prebuilt module to a versioned prebuilt module for use by a
versioned snapshot.
Bug: 142940300
Test: m nothing
Change-Id: I0f438509df23bbb8a5862541b6fbfb1d5fbc06f6
Previously, only a shallow copy was made so the copy ends up sharing
some contents with the original. That was a potential source of bugs
as the copy was being made in order to be mutated.
This change switches to a deep copy; renaming the methods from
copy -> deepCopy to clarify the intent.
Makes the bpPropertySet member of bpModule a *bpPropertySet to avoid
unnecessary copying of bpPropertySet.
Bug: 142940300
Test: m nothing
Change-Id: I3f2eaa9fffab4e61d5a7cec81aa42fee9fdfec44
This means everything that goes into apexes need to be
explicitly labeled to be available for apex.
Whitelist the current offenders. This list should be
trimmed down.
Bug: 147364041
Test: m
Test: multiproduct_kati -only-soong
Exempt-From-Owner-Approval: cherry-pick from internal
Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
(cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
The implicit dependency from an unversioned sdk member to the snapshot
versions should be excluded from visibility enforcement as it provides
no benefit and would require snapshot members to be visible to their
original source modules which would complicate visibility handling.
Also, corrects a spelling mistake in sdkMemberVersionedDepTag.
Bug: 142940300
Test: m nothing
Change-Id: Ib7ea6a3d3904d042dca0ea12f6b9196d40de970b
Adds java_test_import module type for use by the sdk snapshot and
adds java_tests property to the sdk and sdk_snapshot module type.
This is needed for the conscrypt test sdk.
Bug: 143678475
Test: m nothing
Change-Id: Ied4c56c978dac2f92a9b3bc34b3235d7eeba2fd3
By default SdkMemberTypes are only supported on module_exports module
type. Support for sdk module type has to be explicitly specified.
The java_header_libs, native_shared_libs and stubs_sources are
supported on sdk. The latter is required to provide the stubs source
for an API specified in java_header_libs as they should be kept in
sync.
Bug: 146341462
Test: m nothing
Change-Id: I19b9e60792780a797458d4a9e489506602b13144
The cc library and cc binary (and other cc module types) are all
instances of cc.Module. So, to differentiate between them and make
sure that only appropriate library instances can be added to
native_shared/static_libs this adds a special sdkMemberTypes field to
Module which if set specifies the SdkMemberTypes the module supports.
If it is not set then the module type cannot be used in the sdk at all.
Corrects an issue with one of the tests where a prebuilt cc
library was added to the sdk instead of a source cc library.
Adds a new test to ensure that cc_library_(shared|static)_host module
types work with the sdk as well and another test to ensure that
cc_library can be used as either.
Bug: 142918168
Test: m checkbuild
Change-Id: I359cdbdd15328ca571f276d2b6ce9a229ebb2c86
Changes prebuilt_stubs_sources to generate a .srcjar from its input
instead of just exposing the srcs it is given. This ensures that it can
be used as a drop in replacement for a droidstubs module.
Updates the test for prebuilt_stubs_sources to be more representative
of the actual use made of it by sdk snapshot which outputs a directory
not a glob pattern. Added some documentation of the
prebuilts_stubs_sources srcs property to make it clear that it is
supposed to be a set of directories.
Extracts common code from sdk/testing.go for normalizing path/paths
for testing.
Bug: 143678475
Test: m conscrypt-module-sdk conscrypt-module-host-sdk conscrypt-module-test-sdk
unzip those in place of external/conscrypt
build core-current-stubs-source which expects it to provide a .srcjar.
Change-Id: I8204a022557a9b0b45e19eac79ecba98ff95213d
This fixes an issue that arises when deduping cc build component
registration code.
The sanitize_runtime_deps and sanitize_runtime post deps mutators were
not previously added when running cc tests. That meant the tests were
not actually testing the same behavior as at runtime.
Adding the mutators breaks the TestFuzzTarget test as the mutator adds
libclang_rt.ubsan_standalone-aarch64-android as a dependency of libc++
and the former is not available.
This fixes the test by adding the missing dependency as a cc prebuilt
shared library.
Test: m checkbuild
Bug: 146540677
Change-Id: Ie13c7e6fcefef7d9cb1cc5364be3dc563ce40de5
The cc.GatherRequiredDepsForTest() method returns some default module
definitions that are required when using cc module types like
cc_library. Previously, the registration of the module types and
mutators needed to process those default definitions was duplicated
in the test config initialization.
This change removes that duplicated code and replaces it with calls
to cc.RegisterRequiredBuildComponentsForTest(ctx) which registers all
the required build components.
Test: m checkbuild
Bug: 146540677
Change-Id: I80b6913c5691ff164ce9d308b9e1da24940f2d42
Some tests were changed as they were using the wrong name for the
droiddoc_exported_dir module type.
Test: m checkbuild
Bug: 146540677
Change-Id: If57404760d2df3757c93e237696359355cf0c96e
The registration of module types and singletons is duplicated between
init() functions that register them for use in the build runtime and
test context creation code that registers them for testing.
This is a proof of concept for a mechanism that will allow the code
to be shared. It defines a RegistrationContext interface that is
implemented by both the TestContext and the new initRegistrationContext
type. An instance of the the latter is available through the
InitRegistrationContext variable.
The intent is that the registration of the module types and singleton
types will be extracted from the init() function into a separate
function that takes a RegistrationContext parameter. That method is
called from init() passing in the InitRegistrationContext and from a
test passing in the TestContext. Something like this:
func init() {
RegisterBuildComponents(android.InitRegistrationContext)
}
func RegisterBuildComponents(ctx android.RegistrationContext) {
ctx.RegisterModuleType(....)
....
}
A test would do something like this:
ctx := android.NewTestContext()
RegisterBuildComponents(ctx)
Test: m nothing
Change-Id: I97173cabb6d6cf7ce98fdb5f73418438b1997b35
The filesystem object was available through ModuleContext.Fs(), but
gives too much access to the filesystem without enforicing correct
dependencies. In order to support sandboxing the soong_build
process move the filesystem into the Config. The next change will
make it private.
Bug: 146437378
Test: all Soong tests
Change-Id: I5d3ae9108f120fd335b21efd612aefa078378813
Use the empty string for the core image variant so that modules
added to imageMutator do not change their build directory.
Bug: 142286466
Test: m checkbuild
Change-Id: Ida4534d9a4d6176236aaa480fed359ce27acfaa1
Merged-In: Ida4534d9a4d6176236aaa480fed359ce27acfaa1
(cherry picked from commit 72d685ee7f45e5393be44ae4159edf083ac918de)
Previously, adding a new SdkMemberType would require adding a new
sdkMemberListProperty instance to the sdkMemberListProperties as well
as adding a new property into the sdkProperties struct. They are
potential sources of conflict and couple the sdk code with all the
packages that add members to it. This change switched to a
registration model that allows each package to register its sdk
member types decoupling them from the sdk code.
Adds an SdkPropertyName() method to SdkMemberType that specifies the
name of the property to use in the sdk/sdk_snapshot. Also provides
an SdkMemberTypeBase struct to be used by providers of SdkMemberType
implementations.
SdkMemberType instances are registered using the
RegisterSdkMemberType() func which sorts the registered instances
by their SdkPropertyName() to ensure the behavior is consistent and
not affected by order of registration.
When creating a new sdk module a dynamicSdkMemberTypes instance is
created that contains the following:
* A properties struct is created dynamically that contains a field for
each registered SdkMemberType, corresponding to that type's
SdkPropertyName().
* A list of sdkMemberListProperty instances is also created, one for
each registered SdkMemberType.
The dynamicSdkMemberTypes instance is cached using a key that uniquely
identifies the set of registered types just in case new types are
registered after one has been created, e.g. by tests.
Bug: 142918168
Test: m checkbuild
Change-Id: I4bf2bf56a2a49025aa41454048bc1e8ccc6baca2
The exported include dirs includes both source and generated
directories (e.g. containing aidl generated headers). The latter are
always arch specific so if they are present they make all the include
directories arch specific.
This change separates the source and generated include dirs so that
the source include dirs (which are probably not arch specific) can be
optimized separately from the arch specific generated include dirs.
The FilterPathList() func was refactored to extract the more general
FilterPathListPredicate() func.
A number of tests needed to be updated to reflect the more optimal
snapshot creation.
Bug: 142918168
Test: m checkbuild
Change-Id: Id1a23d35a45b250ae2168834f9c2a65c86a5fd77
Previously, code that attempted to optimize the generated .bp rules
treated the properties structure as a single entity. So, a single arch
specific value would cause all properties to be treated as arch
specific. Also, that code was specific to one structure type.
This generalizes the optimization to work with any properties structure
which will be helpful for other multi-variant module types. It also
treats each property separately.
The hasArchSpecificFlags field has been removed from nativeLibInfo and
a commonProperties field has been added instead into which the common
values will be found. File path creation that conditionally prefixed a
path with archType has been replaced with general code that relies on
archType being "" for common properties and filepath.Join(..) ignoring
empty string components.
The common and arch variant properties are always processed. The first
within the context of the .bp module's property set and the latter
within an arch specific property set. There are always some properties
that are arch specific, e.g. outputFile, so there is no need to worry
about an empty arch property set being created.
The archSpecificNativeLibInfo type was renamed nativeLibInfoProperties
as it may not be arch specific.
The printExportedDirCopyCommandsForNativeLibs variable was renamed to
addExportedDirCopyCommandsForNativeLibs as it no longer does any
printing.
Bug: 142918168
Test: m checkbuild
Change-Id: Iad45913299c37fd76fe03ed0ca68bdc68ed76431
Parameterized the cc.librarySdkMemberType to allow it to support
both static and shared libraries. Created two instances, one for shared
and one for static libraries. A follow up change will add support for
libraries that can be both.
Added *librarySdkMemberType to nativeMemberInfo as information from
there is needed when generating the snapshot.
Made organizeVariants() func a method of *librarySdkMemberType so that
it can initialize the new field. Moved it to be with all the other
methods of that type.
Added host and device tests for the new module type.
Bug: 142918168
Test: m nothing
Change-Id: I00b1e8424b9d81f7d15edc4883971d10668ec2cc
Header include directories are copied into the snapshot separately for
each cc library that exports them. However, the same include
directories can be exported by multiple libraries which caused ninja
error because two separate rules (albeit identical) were defined to
create the same files.
This avoids the duplicate ninja rules by detecting and discarding
duplicate copies, i.e. where the source and destination are the same.
It will also report an error if two or more different source files are
copied to the same destination.
Bug: 142918168
Test: m nothing
added test and verified it produced two identical copy rules
fixed code and verified duplicate copy rules had been eliminated
Change-Id: I39e37405035bee5093f96e03248e9e29ed30962c
AndroidMkEntries now returns multiple AndroidMkEntires so that a module
can emit multiple Make modules if needed.
Bug: 128708192
Test: m
Change-Id: I56b6f76d22943b80329951c5acb80a1b932441ad
Prevents the META-INF/MANIFEST.MF file from the source jar from being
copied to the snapshot zip file.
Bug: 143678475
Test: m conscrypt-module-sdk
manually check contents of generated zip
Change-Id: I6eca1435dfc25b562e49de46b049fa81cf8daf90
Exports visibility and package mutator registration functions so they
can be used in sdk testing. Updates sdk test to support visibility and
package modules.
Adds EffectiveVisibility(...)[]string function to make the effective
visibility rules available to sdk snapshot creation.
Extracts compositeRule.Strings() []string from compositeRule.String()
method so that it can be used by above func.
Adds visibility property to sdk snapshot and prebuilt modules along
with a test to ensure it works properly.
Adds dir parameter to CheckSnapshot so that it can check the snapshot
generated for a non-root package. That is required in order to ensure
that visibility of :__subpackages__ on a source module in package
<pkg> is resolved to an effective visibility of
//<pkg>:__subpackages__ on its corresponding prebuilt.
Test: m conscrypt-module-sdk
Bug: 143678475
Change-Id: Icaacac5b9c04726d28e6fec93e49715ac45df7f4
This is needed for a follow up change that makes sure that the
prebuilt modules have the same visibility as the source modules.
Bug: 143678475
Test: m conscrypt-module-sdk
Change-Id: I9461c8c094ab19ee9ececb5e5fd50565789f2fa2
Move the ImageMutator to be registered just after the archMutator
in preparation for moving it between osMutator and archMutator.
Requries updating variants in a few tests that now run the
ImageMutator.
Bug: 142286466
Test: no change to build.ninja
Test: all soong tests
Change-Id: Ia9d2a7bc0e225bedec3c9a83ea04f471a931bf47
Add a new java_header_libs property that exports header jars (as
java_libs currently does) and switch java_libs to export implementation
jars instead.
Refactors implementation of the existing library sdk member type so
both properties can be supported from common code as they differ only
on the jar being exported.
Bug: 143678475
Test: m nothing
Change-Id: I04642122f72d083bbdfd3290624f957b71ee8875
Jooyung Han