apex { name: ["myapex"], native_shared_libs: ["libX", "libY"] }
cc_library { name: "libX", shared_libs: ["libY"] }
cc_library { name: "libY", shared_libs: ["libZ"], stubs: {...} }
apexDepsMutator was a bottom up mutator and it uses WalkDeps to traverse
the dependency tree rooted at myapex in a depth-first order. While
traversing the tree, if calls BuildForApex for a module that will be
part of the APEX.
libY is visited twice. Once via libX and once via myapex. If the visit
from libX was before the visit from myapex (since this is a depth-first
traversing), BuildForApex is not called for libY and its dependency
libZ, because libY provides a stub. And then when libY is again visited
via myapex, BuildForApex is correctly called for the module, but not for
its dependencies libZ because the paths from libY to libZ was already
visited.
As a result, the apex variant of libY has a dependency to the non-apex
variant of libZ.
Fixing the problem by changing the mutator a top-down one.
Bug: 148645937
Test: m
Change-Id: Ib2cb28852087c63a568b3fd036504e9261cf0782
The apex dependency map wasn't updated for test or non-installable
APEXes to work around the problem that a module being in such APEX
prevented the module from being installed in the system partition.
Since that problem is not happening any more, removing the unnecessary
work-around.
Bug: 123892969
Test: m
Change-Id: I43e07a9611a3e08ff39b9a64454b1c67949d35bc
When a module is not available for platform (i.e.
//apex_available:platform is missing in the apex_available property), m
<module_name> previously just didn't work because there is no platform
variant of the module.
This change fixes the behavior; regardless of whether the platform
variant is available or not, m <module_name> builds all the apex
variants of the module along with the platform variant if it exists.
Bug: 147728094
Test: m conscrypt
Change-Id: Iedd3fa6fc0ed779c5f7c5d65f23d86f799ac0cbe
This library is empty, and its functionality has moved
into libbinder/libhwbinder.
Bug: 148692216
Test: N/A
Change-Id: I5874efda9ab43fc00cf90395a1aabde45cf49579
The APEX dependency is more correctly tracked. Previously, the
dependency was tracked while we gather modules that will be installed to
an APEX. This actually was incorrect because we skipped many dependency
types that we don't need to follow to gather the modules list, such as
the headers dependency.
Now, the dependency is tracked directly when a module is mutated for an
APEX. In other words, if a module is mutated for an apex X, then the
module will appear in the X-deps-into.txt file.
This change also changes the format of the txt file. It now clearly
shows why a module is included in the APEX by showing the list of
modules that depend on the module.
Bug: 146323213
Test: m
Change-Id: I0a70cf9cce56e36565f9d55683fdaace8748a081
The function visits dependencies of an APEX that contribute to the
payload. checkApexAvailability is rewritten using the generic function.
There is no change in behavior.
Bug: N/A
Test: m
Change-Id: I1a8b4eb0a60a432f667a61b4f6f457c3b8f1cd3d
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
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.
Change-Id: I4aaf674a5daeabab5ed6e7025c5389821ee9a013
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
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
This reverts commit a952495643.
Reason for revert: PermissionController may need to be built outside of APEX
Fixes: 148957736
Change-Id: I80a2cd666ea5028741250dd2cebf2bd7d7b331ad
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
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.
Bug: 147671264
Test: m
Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
