Product variables structs are generated at runtime to contain only
the properties that apply to the current module. Defaults modules
always contained all product variable properties. Defaults modules
apply their properties to the target module using
proptools.PrependProperties, which prepends structs that have
matching types. Filtered property structs had a different type
and were dropped.
Even after adding filtering to the defaults product variable
properties, defaults modules may contain more property structs
than the target module they are applied to, so the product
variables struct for the defaults module could contain more
fields than the product variables struct for the target module.
Use proptools.PrependMatchingProperties when applying defaults
of product variables instead, which will apply matching properties
across types.
Test: defaults_test.go
Test: variable_test.go
Change-Id: I281bdefef92053457a3b7b65383493a4e7d999df
The zero value check was being done by using reflect.DeepEqual on a
field from the default product variables, but this results in
comparison against a random type when the product variables struct
for the module has been filtered down. Luckily this will always
fail false, which just removed and optimization but left the
behavior correct.
Use reflect.IsZero instead, which is both faster and correct.
Test: variable_test.go
Change-Id: Ieaaa590c2788ca39230e6695397e8ba8d1c6c103
Soong config variables come from Make where they might be capitalized,
but Blueprint didn't handle capitalized variables well. Add test
coverage for capitalized Soong config variables.
Bug: 148865218
Test: soong_config_module_test.go
Change-Id: I1e434e392d5ee660a221a0d3f959811c35e65865
Add a dependency on the Soong config module definition file in case
it wasn't called Android.bp.
Fixes: 148866376
Test: m checkbuild
Change-Id: Ib441881bcee52fd1dc3a8d1c5ae4f5f0b7efe3ce
cc_library_static {
name: "libfoo",
shared_libs: ["libbar"],
}
cc_library {
name: "libbar",
}
If libfoo is part of an APEX, then libbar is no longer considered as a
member of the APEX, because it isn't actually linked to libfoo.
To distinguish such a shared lib dependency from a static library from a
shared lib dependency from a shared library, a new dep type
SharedFromStaticDepTag is introduced. It is treated exactly the same as
SharedDepTag, except when we determine whether a dependency is crossing
the APEX boundary or not.
This allows us to check the apex_available property more correctly.
Previously, modules were incorrectly considered as being used for an
APEX due to the shared lib dependency from a static lib.
As a good side effect, this also reduces the number of APEX variants.
Specifically, on aosp_arm64, the number of the generated modules were
reduced from 44745 to 44180.
Exempt-From-Owner-Approval: cherry-pick from internal
Bug: 147671264
Test: m
Merged-In: I899ccb9eae1574effef77ca1bc3a0df145983861
(cherry picked from commit 931b676a69)
Change-Id: I899ccb9eae1574effef77ca1bc3a0df145983861
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
apex {
name: "myapex",
native_shared_libs: ["libfoo"],
apex_name: "apex_name",
}
override_apex {
name: "myapex.override",
base: "myapex"
}
Previsouly, above wasn't supported because both APEXes have the same
apex_name and that apex_name is used as the suffix of libfoo. i.e.,
there are two libfoo.apex_name modules defined.
Now, the two apex variants of libfoo are named as
libfoo.myapex and libfoo.myapex.override.
Bug: 140136207
Test: m
Change-Id: I63f8a1de463011c6e0b97f5f6eee83103e22bc30
apex module accepts PlatformCompatConfigIntf as prebuilt,
and places it in the etc folder of the apex.
Test: m
Test: flash device with dummy config in mediaprovider APEX -
the config is present
Change-Id: Ifc62cd262f6c6571c1bf6c2943879aa20877ecad
Some additional, possibly arch specific, properties need adding to
cc library (e.g. recovery_available). This dedups and cleans up the
code involved to simply the addition of those new properties.
Bug: 142918168
Test: m nothing
Change-Id: I0963aa02e9504af1ae9b427ff1016e7c481465f4
When SOONG_ALLOW_MISSING_DEPENDENCIES is set, it should be OK to miss
shared library variants.
Test: master-art manifest, use bionic stubs
Bug: 142935992
Change-Id: Ie0054acfef7c4406594a87378a7029380a9fda50
We add a compat config build rule to extract the merged config, and
then update the droiddoc build rule to consume that.
Test: m -j offline-sdk-docs
Bug: 144927670
Change-Id: Ib1e85f97895c89227882e665572bda9bfc2a8cba
Exempt-From-Owner-Approval: ag/10097965 approved internally, Colin requested to patch to aosp
Previously, when a library that used a numeric sdk version also
referenced a java_sdk_library it would use the current version of its
API. That was dangerous as there is an expectation that an app building
against a numbered version will also be targeted at that version and
so building against a later version of the API could hide runtime
incompatibilities.
This change will use prebuilt versions of the java_sdk_library's api
when being built for a numbered sdk version.
Bug: 148080325
Test: m droid
Change-Id: I3fd416553950785a443c1702e495a96debc33331
The legacy usages have all been updated so the legacy properties
can be safely removed. The Libs property is kept so it can be used to
specify properties common to all scopes.
Bug: 148080325
Test: m droid
TARGET_BUILD_APPS=Camera2 m
Change-Id: I252ebbedbb463db3c7346e86d86b5880eea76fe9
Previously, the java_sdk_library_import only exposed the public stubs.
This change adds support for exposing system and test stubs too by adding
separate structures for public, system and test scopes. The existing
properties are kept for legacy reasons (and because libs can be common
across the differents scopes).
It extracts some code that is common to both sdk library and sdk
library import.
The legacy support will be removed in a future change once all existing
usages have been switched over.
Bug: 148080325
Test: m droid
TARGET_BUILD_APPS=Camera2 m
Change-Id: I0b26cc8af9ee044437ff3b80c1eca611816b9386
This is the 1st part of the CL. It adds support to enable compilation
of line coverage instrumented binaries. For more details please refer
to the design doc: go/android-line-coverage-doc
Bug: b/147604881
Test: Code works successfully on Taimen devices
Change-Id: I07745c1438b611041ed032dd4b7788cb50130845
If CFI is enabled for a module, no-vendor-variant VNDK will fail
because CFI is not used for the vendor variant.
Bug: 148638729
Test: Remove libstagefright_bufferpool@2.0 from the whitelist. Build on
crosshatch is successful. Build on a ARM32 device with
TARGET_VNDK_USE_CORE_VARIANT set and check no-vendor-variant VNDK
is still enabled for libstagefright_bufferpool@2.0.
Change-Id: Ib0a411d7ea769097186afa802751b0796527ec76
module_bp_cc_deps.json was not written through
android.WriteFileToOuptutDir, so it didn't get the absolute path
prepended when sandboxing was turned on. Reuse the implementation
from module_bp_java_deps.json.
Bug: 147409906
Test: m SOONG_COLLECT_CC_DEPS=1 nothing
Change-Id: I3b255bdfd3b4c442db06fe185765414905531410
module_* is a new API surface for OS modules (e.g. APEXes). It has
slightly bigger API surface than the system_* SDK. Specifically, APIs
with @SystemApi(client=MODULE_LIBRARIES) are added there.
Bug: 146757305
Test: m
Change-Id: I8980e50c0e3a4cd843048e0de1f638e854384f46
When building a library against sdk_version: system_current it uses the
system stubs of any java_sdk_library that it references. Previously,
when building against sdk_version: test_current this used the public
stubs of any java_sdk_library. This change causes it to use the
test stubs instead to be consistent with the handling of system and
public.
Bug: 148080325
Test: updated the test
ran m nothing which failed as expected
fixed the code
ran m nothing again which succeeded
Change-Id: I58ec5bd243701c5a5c75664e2bb615ce7b2f2441
This flag indicates that the sample profile data matches the source
and can be fully trusted. The compiler will make aggressive
assumption that functions without any samples are cold functions,
and will optimize for size for them.
Test: binary size reduces to match instr PGO
Bug: 79161490
Change-Id: I53d6d05be70c39e5eb28b2f5b0549d9eb6b5cc62
