When a source and a prebuilt module are present in the same build a
dependency is added from the source module to the prebuilt module.
Previously, the code for generating the APEX did not recognize that
tag and in some cases (e.g. for cc_(prebuilt_)library_shared) will
fail the build.
This change:
1) Adds a test to reproduce the problem.
2) Improves the debug message by pretty printing the tag.
3) Adds a new ExcludeFromApexContents interface that can be implemented
by a tag to declare that it should be excluded from the APEX
contents.
4) Ignores tags that implement that interface when generating APEX
contents.
5) Implements that interface on prebuiltDependencyTag to fix the
test.
Bug: 153326844
Bug: 153306490
Test: m nothing
Merged-In: I9dd4312c4f995c816c0a31d8d733eb5d7f56e1ea
Change-Id: I9dd4312c4f995c816c0a31d8d733eb5d7f56e1ea
Previously, adding java_library to an sdk required that the names of
any APEXes that transitively compiled against it were added to its
apex_available property. This change removes that requirement.
Also corrects the dependency path in the TestApexAvailable_IndirectDep
error which previously passed through "shared from static" static
dependency tags even though those are explicitly NOT followed when
checking apex_available settings.
Bug: 152878661
Bug: 153306490
Test: m droid
Merged-In: I995ed38956c1bc210b09494812de012fed9f9232
Change-Id: I995ed38956c1bc210b09494812de012fed9f9232
Having dependency tags in the dependency path that shows why a specific
module is considered part of an apex makes it easier to understand why
that is the case and detect possible issues.
Bug: 152762638
Bug: 153306490
Test: m nothing
Merged-In: Iba2a8a5a6abe03dadee456e760aa4373cd00c07b
Change-Id: Iba2a8a5a6abe03dadee456e760aa4373cd00c07b
The apex available check can traverse quite a long path (5+ steps) to
get from the apex to a module that is missing the apex from its
apex_available property. Understanding where that dependency came from
can often require examining the dependency path which can be difficult.
This change adds the path to the error to simplify that process.
Bug: 153306490
Test: m nothing
Bug: 152762638
Merged-In: Ic4eb169dc2026cd8339d49e23b25d6d1c3879750
Change-Id: Ic4eb169dc2026cd8339d49e23b25d6d1c3879750
Having multiple tests within one method makes debugging specific
failures more difficult so this change split the TestApexAvailable
test into multiple separate tests.
Bug: 153306490
Test: m nothing
Bug: 152762638
Merged-In: I2b2408ef515fd79c078686ef29a6ee8fb0407e7e
Change-Id: I2b2408ef515fd79c078686ef29a6ee8fb0407e7e
This is to guard against the potential situation when someone adds
updatable modules to the list of boot jars by mistake.
Test: aosp_walleye-userdebug builds.
Test: Manually break the checks and observe the errors:
- move updatable module 'conscrypt' from
PRODUCT_UPDATABLE_BOOT_JARS to ART_APEX_JARS:
internal error: module 'conscrypt' from updatable apex 'com.android.conscrypt' is not allowed in the ART boot image
- add updatable module 'conscrypt' to ART_APEX_JARS
(but do not remove it from PRODUCT_UPDATABLE_BOOT_JARS):
error: A jar in PRODUCT_UPDATABLE_BOOT_JARS must not be in PRODUCT_BOOT_JARS, but conscrypt is.
- move updatable module 'framework-tethering' from
PRODUCT_UPDATABLE_BOOT_JARS to PRODUCT_BOOT_JARS:
internal error: module 'framework-tethering' from updatable apex 'com.android.tethering' is not allowed in the framework boot image
- add non-updatable (in AOSP) module 'android.net.ipsec.ike'
to PRODUCT_BOOT_JARS:
internal error: failed to find a dex jar path for module 'com.android.ipsec.ike', note that some jars may be filtered out by module constraints
Bug: 147579140
Exempt-From-Owner-Approval: cherry-pick, approved in AOSP.
Change-Id: I25ca2f52530fcfa1f9823b2cfa3485db9c0d0db1
Merged-In: I25ca2f52530fcfa1f9823b2cfa3485db9c0d0db1
(cherry picked from commit b28cc3758c)
Apex can use codenames like "Q", "R" for its min_sdk_version property.
Also, cc_library can use codenames for its stubs.versions.
Bug: 152655956
Test: vendor/google/build/build_mainline_modules.sh
Change-Id: I077ad7b2ac5d90b4c8708921e43846206f05ba70
Previously, when Q-targeting apexes are bundled-built, they are built
against the latest stubs.
It was because unwinder is linked dynamically in R and APIs are provided
by libc while Q apexes should run on Q where libc doesn't provide those
APIs. To make Q apexes run on Q device, libc++ should be linked with
static unwinder. But, because libc++ with static unwinder may cause problem
on HWASAN build, Q apexes were built against the latest stubs for bundled
build.
However, Q apexes should be built against Q stubs.
Now, only for HWASAN builds, Q apexes are built against the latest stubs
(and native modules are not linked with static unwinder).
Bug: 151912436
Test: TARGET_SANITIZE=hwaddress m
=> Q apexes(media, resolv, ..) are linked with the latest stubs
m
=> Q apexes are linked with Q stubs,
and Q apexes' libc++ is linked with static unwinder
Change-Id: If32f1b547e6d93e3955c7521eec8aef5851f908c
The macro is required only for apex variants regardless of useVndk.
Before the enforcement of LLNDK sdk version, the macro was not passed to
vendor variants.
Bug: 151689896
Test: TARGET_BUILD_APPS=com.android.media.swcodec m
libbase in swcodec apex is linked with liblog#29
(compiled with __ANDROID_SDK_VERSIO__=29)
Merged-In: I57fa4afe027eb39b98bd94d534be9ebe11713f19
Change-Id: I57fa4afe027eb39b98bd94d534be9ebe11713f19
(cherry picked from commit 24282778ee)
Exempt-From-Owner-Approval: cp from aosp
Even though use_vendor:true is prohibited, there is media.swcodec apex
which is still use_vendor: true and also needs to support Android10.
(min_sdk_version: 29)
Because LLNDK stubs were provided only for the current VNDK version,
media.swcodec couldn't be built against min_sdk_version: 29.
This change introduces additional versions for LLNDK stubs which are
enforced when an apex with use_vendor: true sets min_sdk_version.
To make things easier, the versions of LLNDK stubs are borrowed from its
implementation libraries.
Bug: 147450930
Bug: 149591522
Test: TARGET_BUILD_APPS=com.android.media.swcodec m
(with min_sdk_version: 29 set)
check if liblog/libc/libm/libdl stubs are 29
check if 29 stubs don't have new symbols.
Merged-In: I79946cbb4da6617138a96d2b254349d3a298e77b
Change-Id: I79946cbb4da6617138a96d2b254349d3a298e77b
(cherry picked from commit 380fc3615c)
This change fixes a bug that license info for statically linked
libraries are absent in the merged notice for APEX. The problem was that
we were iterating over the apexFiles list that represents actual files
(not Soong modules) that are included in the APEX. The problem is now
fixed by iterarting the all the modules that directly or indirectly
contribute to the APEX using walkPayloadDeps() function.
Bug: 149455933
Test: m
Merged-In: I38655da62b590b669ab4649815b61a5a8e314154
(cherry picked from commit 9918e1afd7)
Change-Id: I38655da62b590b669ab4649815b61a5a8e314154
sdk_version is passed for relevant variants.
If not specified or "current",
it maps to "10000" for platform variants, and
"min_sdk_version" of the apex for apex variants.
Bug: 150860940
Test: m (soong test)
manually check build.ninja
Merged-In: I5102ab0c5086b5ad29d16ac45af55d32062167b4
Change-Id: I5102ab0c5086b5ad29d16ac45af55d32062167b4
(cherry picked from commit ccce2f2c23)
Exempt-From-Owner-Approval: cp from aosp
This is rarely used feature but cost alot for the local build and build
inra.
Bug: 150506627
Test: m
Merged-In: Iec3ada4a97c7b228f2818563fa0e81b407f2715a
Change-Id: Iec3ada4a97c7b228f2818563fa0e81b407f2715a
(cherry picked from commit c87a059c88)
Exempt-From-Owner-Approval: cp from aosp
min_sdk_version = 29 implies that the module should support Android10.
Bug: 150431944
Test: m
Merged-In: Iad90a239898f59456900ae7816b90379b1b43406
Change-Id: Iad90a239898f59456900ae7816b90379b1b43406
(cherry picked from commit 5417f775e5)
Exempt-From-Owner-Approval: cp from aosp
ensureExactContents shouldn't return immediately when it finds a match
from expected list of files.
Bug: 151491839
Test: m nothing
Merged-In: Ie15c811f9cfcae7ede28dee0fcf203cee24659a0
Change-Id: Ie15c811f9cfcae7ede28dee0fcf203cee24659a0
(cherry picked from commit e6436d7bf0)
Native modules within APEX should be linked with proper stub version
according to its min_sdk_version.
For example, when min_sdk_version is set to "29", libfoo in the apex
would be linked to libbar of version 29 from platform, even if it has
a newer version like 30.
Bug: 145796956
Test: m nothing (soong tests)
Merged-In: I4a0b2002587bc24b7deeb5d59b6eeba5e1db5b1f
Change-Id: I4a0b2002587bc24b7deeb5d59b6eeba5e1db5b1f
(cherry picked from commit 03b5185b88)
Exempt-From-Owner-Approval: got ORV already.
When there is a runtime depedency (via runtime_libs property) to a
library providing stable C APIs, the dependency is considered as
crossing APEX boundary. Therefore, the requested lib doesn't need to be
made available to the APEX where the requesting lib is in.
Exempt-From-Owner-Approval: cherry-pick from aosp, approved there.
Bug: 147813447
Test: m
Merged-In: I9cf8a5877850fb85b92c851e15fac921b8b7641b
(cherry picked from commit 323a4c3ab3)
Change-Id: I9cf8a5877850fb85b92c851e15fac921b8b7641b
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
When the check for apex_available has failed, the build system now shows
the module that brought the unavailable module into the APEX.
Bug: 151051671
Test: m
Change-Id: Id1a3fda67fe56fdc2dc90ec800d10689415de4d6
apex { name: "foo" }
override_apex { name: "override_foo", base:"foo" }
PRODUCT_MANIFEST_PACKAGE_NAME_OVERRIDES := foo:com.android.foo
Previously, the override was done only for the overridden package "foo",
but not for "override_foo". Fixing this issue by using ctx.ModuleName()
when finding the package name to use.
Bug: 150645663
Test: m
Change-Id: I2947e5c75369216a4bbce8749503236be86771c3
If an APEX contains APKs and the manifest package name of the APKs are
overridden (either via override_android_app
orPRODUCT_MANIFEST_PACKAGE_NAME_OVERRIDES), that the path to the APK
(relative in the APEX) and the overridden manifest package name is
recorded in the bundle config file.
Exempt-From-Owner-Approval: cherry-pick from master
Bug: 148002117
Test: m
Merged-In: Ibb90bcefb77fa6b2dad77cb2facc6079de9ab154
(cherry picked from commit cfaa1643e8)
Change-Id: Ibb90bcefb77fa6b2dad77cb2facc6079de9ab154
bundle config file for apexes are auto-generated. It is included in the
<apex>-base.zip file, which is expected to be extracted and then fed
into the bundletool.
This change is in preparation for the upcoming change to include
information about embedded apks in the bundle confir file.
Exempt-From-Owner-Approval: cherry-pick from master
Bug: 148002117
Test: m
Merged-In: If25d75e0f62036dc777faf8593ed8eb9a74950b0
(cherry picked from commit bd15961043)
Change-Id: If25d75e0f62036dc777faf8593ed8eb9a74950b0
Because APK-in-APEX embeds its jni_libs in it. We don't have to follow
deps of jni_libs.
Bug: 146992436
Test: m com.android.tethering
deapexer extract com.android.tethering.apex apex
ls apex # there should be no /lib dir
Merged-In: Ifa1a6430a420ae7376b155cd59b8ece462cced7e
Change-Id: Ifa1a6430a420ae7376b155cd59b8ece462cced7e
(cherry picked from commit b7bebe2616)
The optimization is confusing syshealth because the modules will use
more memory when they are switched to the prebuilt (unbundled) or
updated via Play.
Let's have a per-module switch to control the behavior and turn it on
only for non-updatable modules like ART.
Bug: 149805758
Test: m
Change-Id: Ieb842c47f31f3b06e403b1e1f9e463c3e5524107
This change fixes a regression that was introduced with
I597bccbb177b6b6320c3a3edeff467243230d384. With the change, the content
of the permissions XML file for a java_sdk_library was determined before
the java_sdk_library is mutated for an APEX. As a result, the file path
to the implementation jar library was always set to
/system/framework/*.jar regardless of whether the java_sdk_library is
part of an APEX or not.
This change fixes the problem, by creating the permissions XML file via
a new module type. The content of the xml file is determined after the
xml file is mutated for APEXes.
Bug: 149600642
Test: m
Change-Id: Id21f8d8285df49b0b3be1daf0f101f2bc978eeb0
Bug: 149075752
Test: tapas com.android.conscrypt com.android.tethering arm64
Test: m out/target/product/generic_arm64/{,symbols/}apex/com.android.{tethering,conscrypt}/lib64/libc++.so
Test: Verified that unwinder was dynamically linked to tethering's
Test: libc++ and statically linked to conscrypt's.
Test: lunch flame-userdebug && m
Test: Verified that unwinder was dynamically linked to /system/lib64/libc++.so
Change-Id: I98eed7cb4316962b19b5c12e150c224c25d0e91d
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
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
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
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
This reverts commit 5df3b11f78.
Reason for revert: re-land with a fix
Fix a broken soong test
Add implicit dependency (libprofile-clang-extra) to make a test pass.
Bug: n/a
Test: m
Change-Id: I0b179199bc032501354f8e24782837453781bd8c
VNDK APEX is supposed to contain "vendor" variants of VNDK libraries.
This is different from normal APEXes which have "apex" variants.
Bug: 146758869
Test: build / flash / boot
Change-Id: I5e035678c337334092616b58d2e0e404788a6639
Exempt-From-Owner-Approval: Got ORV, but rebased with resolving merge conflicts.
