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
With I63f8a1de463011c6e0b97f5f6eee83103e22bc30, a flattened APEX is
installed to /system/apex/<apexBundleName> not /system/apex/<apexName>.
The change was to be in sync with the non-flattened APEXes that are
installed to /system/apex/<apexBundleName>.apex.
apexName is from the 'name' property while apexBundleName is from the
'apex_name' property. The two names are mostly the same, but can be
different, notably for the ART and the VNDK APEXes. e,g apexName =
com.android.art, apexBundleName = com.android.art.release.
However, there was a bug in the fix; we haven't updated the path for the
flattened APEXes in other places: filecontexts and symlinks. As a
result, the files for the APEXes where apexName is different from
apexBundleName were incorrectly labeled and caused a boot loop.
Fixing the bug.
Bug: 140136207
Bug: 149013536
Test: m
Test: OVERRIDE_TARGET_FLATTEN_APEX=true m; then inspect the built
system.img to verify that
/system/apex/com.android.vndk.current/lib/libcrypto.so is correctly
labeled as system_lib_file.
Exempt-From-Owner-Approval: cherry-pick from internal
Merged-In: I4aaf674a5daeabab5ed6e7025c5389821ee9a013
(cherry picked from commit be95e6b245)
Change-Id: I4aaf674a5daeabab5ed6e7025c5389821ee9a013
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
If a library happens to contain the extension as a substring in its
name, libNameFromFilePath will return a truncated library name. Change
this calculation to remove the last instance of the extension substring
instead.
Bug: 147140513
Test: Modified rust tests pass.
Change-Id: I0ed91e5f571ed5c4040ee15956a1598846aee43a
Previously, a java_sdk_library called "SDKLIB" would create a
prebuilt_etc module called "SDKLIB.xml" which installs the generated
XML permission file to /etc/permissions/SDKLIB.xml. That module
depended on the java_sdk_library "SDKLIB" to generate the XML file
as one of its outputs by specifying srcs: [":SDKLIB{.xml}"].
If the java_sdk_library is replaced by a prebuilt then the SDKLIB.xml
module expects the prebuilt to provide the XML permissions file which
it doesn't because that is an implementation detail and so the build
breaks.
A couple of alternative approaches were looked at to fix this. One was
to have the logic that replaced the source module with the prebuilt to
inform the source module that it was being replaced so it could disable
its created module. That lead to a dependency cycle where
SDKLIB -> SDKLIB.xml -> SDKLIB{.xml}
Another solution was to mark dependency tags in such a way that the
prebuilt could automatically identify and disable the SDKLIB.xml
module. Similar to how the visibility code will ignore dependencies
that are tagged with ExcludeFromVisibilityEnforcementTag. That became
very convoluted.
Instead the java_sdk_library was changed so that it was not responsible
for creating the XML permissions file. Instead it created a genrule
called "gen-SDKLIB.xml" to create it and then "SDKLIB.xml" depended on
that. The java_sdk_library also depended on the genrule to make the XML
permissions file available for APEX and testing.
Some refactoring of the APEX code and tests was necessary because they
had knowledge of the internal implementation of java_sdk_library. The
refactoring insulates them a little better from those details.
Bug: 148080325
Test: m droid && TARGET_BUILD_APPS=Camera2 m
Change-Id: I597bccbb177b6b6320c3a3edeff467243230d384
Currently, com.android.runtime provides libc/libm/libdl to system. But
they are supposed to be used from symlinks under /system/lib not
directly from runtime apex.
This helps linkerconfig to generate ld.config.txt automatically for
apexes.
Bug: 144664390
Test: m com.android.runtime
deapexer info com.android.runtime.apex
Change-Id: I1620e88e489fba88a06cc3bd6eb5b86a9b581e4f
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
Previously, the java_sdk_library had special support for disabling the
stubs library when the build was configured to use prebuilts for sdks,
e.g. in an unbundled app build. That caused the prebuilt version of the
stubs library to be used instead. The disabling was done irrespective
of whether a prebuilt was available which prevents java_sdk_library
from being used in situations when prebuilts are not available, e.g.
when they have not been created yet.
This change moves the logic into tha java_sdk_library_import and
leverages the existing prebuilt/prefer mechanism to ensure that the
prebuilt version is used when required.
* Adds a ForcePrefer() method to Prebuilt to allow a module to forcibly
set the value of the prefer property.
* Sets prefer true on the java_sdk_library_import and the stubs modules
it creates when the prebuilt version should be used.
* Refactors PrebuiltJars for use by both java_sdk_library and
java_sdk_library_import as they both need to provide access to
prebuilts for previously released versions of the library.
* Removes disabling logic from java_sdk_library.
This will probably require some additional java_sdk_library_import
modules to be added to prebuilts/sdk/current/Android.bp.
Bug: 148080325
Test: m droid && TARGET_BUILD_APPS=Camera2 m
Change-Id: I0b5f751e82a2179a967ae64ca03dc9b9e7665c16
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
