Give prebuilt_etc and sh_binary their own packages and split the
gigantic main Android.bp up to small, per-package ones.
(This is a cherry-pick change.)
Test: m nothing, TreeHugger
Bug: 156980228
Change-Id: I7b00cd344b9f16861f1ff39edf0029f016b853d0
Merged-In: I7b00cd344b9f16861f1ff39edf0029f016b853d0
apex now respects stem of java_library modules.
As a follow-up we need to suppor the same for other types of modules.
Exempt-From-Owner-Approval: cherry-pick from AOSP
Bug: 157638999
Test: m
Merged-In: Iaf5023020b5440f1ffd4f5414b5a7864655fc22a
(cherry picked from commit a62aa23990)
Change-Id: Iaf5023020b5440f1ffd4f5414b5a7864655fc22a
For a given variant of a module that implements ApexModule interface,
the "updatable" property tests if this variant comes from an updatable
apex. For platform variants it is always false.
Test: lunch aosp_walleye-userdebug && m nothing
Bug: 138994281
Merged-In: I2d4c54fb397e29dc9b3203be7fb17be4536529f7
Change-Id: I2d4c54fb397e29dc9b3203be7fb17be4536529f7
Exempt-From-Owner-Approval: cp from aosp
(cherry picked from commit 7c140d828a)
Access to the implementation JARs is restricted to avoid code from
depending on implementation details that could change from one release
to the next which could cause compatibility issues. That is not a
problem when referenced from within the APEX that contains the
java_sdk_library.
As references from within the same APEX often need to access
implementation specific details of the java_sdk_library and doing that
from within the same APEX is safe this change all references to a
java_sdk_library made within the same APEX to use the implementation
jars instead of stub jars.
Bug: 155164730
Test: m droid
Change-Id: If239059690de61683c2ad2d8a0ce2e47286a3637
(cherry picked from commit 9b879594ed)
apex_set takes an .apks file that contains a set of prebuilt apexes with
different configurations. It uses extract_apks to select and install the
best matching one for the current target.
Bug: 153456259
Test: apex_test.go
Test: com.android.media.apks
Change-Id: I1da8bbcf1611b7c580a0cb225856cbd7029cc0a7
Merged-In: I1da8bbcf1611b7c580a0cb225856cbd7029cc0a7
A follow up change will add a mechanism for a module to register a hook
that is called after any defaults have been applied. That is intended
for use by modules like java_sdk_library that create child modules that
are dependent upon properties that could be supplied by defaults.
Creating those child modules after prebuilts mutators are run will
cause problems if those child modules clash with prebuilts modules.
Moving the prebuilts mutators after the defaults mutators will fix
that.
Tests are currently being run with the mutators in different orders so
this change also cleans that up so they are consistent with the actual
code that is being run.
Bug: 155295806
Test: m checkbuild
Merged-In: I825c6df09058fb3a45db196661959eb332aca2f3
Change-Id: I825c6df09058fb3a45db196661959eb332aca2f3
(cherry picked from commit c988c8e202)
Compared to full list, flat list drops dependency edges and simply
lists all transitive dependencies for a top-level apex bundle.
Bug: 149622332
Test: m, manually build flatlist
Change-Id: Ibd521c96b7aeab90b95965c1b524e0a0152aaf5a
Merged-In: Ibd521c96b7aeab90b95965c1b524e0a0152aaf5a
Exempt-From-Owner-Approval: cp from aosp
(cherry picked from commit a8bd113a69)
Move depsInfo into android for easier sharing with APK code.
Bug: 149622332
Test: m, diff'ing outputs for conscrypt module.
Change-Id: If0ee967d37425540e69b4ce9304229d9f2cd86bd
Merged-In: If0ee967d37425540e69b4ce9304229d9f2cd86bd
Exempt-From-Owner-Approval: cp from aosp
(cherry picked from commit 872a144dca)
This change adds 'test_for' property to cc_test_* types. The property is
used to mark a module as a test for one or more APEXes, in which case
the module has accecss to the private part of the listed APEXes. For
example, the module is linked with the actrual shared library in the
APEX instead of the stub of the shared library.
Exempt-From-Owner-Approval: cherry-pick from AOSP
Bug: 129539670
Bug: 153046163
Test: m
Merged-In: I45ed0d7a15540b0d69b2a3b8d9c4cb202adff6f2
(cherry picked from commit 62304bbeec)
Change-Id: I45ed0d7a15540b0d69b2a3b8d9c4cb202adff6f2
A module is marked unavailable for platform when 1) it does not have
"//apex_available:platform" in its apex_available property, or 2)
it depends on another module that is unavailable for platform.
In that case, LOCAL_NOT_AVAILABLE_FOR_PLATFORM is set to true for the
module in the Make world. Later, that flag is used to ensure that there
is no module with the flag is installed to the device.
The reason why this isn't entirely done in Soong is because Soong
doesn't know if a module will be installed to the device or not. To
explain this, let's have an example.
cc_test { name: "mytest", static_libs: ["libfoo"]}
cc_library_static { name: "libfoo", static_libs: ["libbar"]}
cc_library { name: "libbar", apex_available: ["com.android.xxx"]}
Here, libbar is not available for platform, but is used by libfoo which
is available for platform (apex_available defaults to
"//apex_available:platform"). libfoo is again depended on by mytest
which again is available for platform. The use of libbar should be
allowed in the context of test; we don't want to make libbar available
to platform just for the dependency from test because it will allow
non-test uses of the library as well.
Soong by itself can't tell whether libfoo and libbar are used only in the
context of a test. There could be another module depending them, e.g.,
cc_library_shared { name: "mylib", static_libs: ["libfoo"] }
can exist and it might be installed to the device, in which case
we really should trigger an error.
Since Make has the knowledge of what's installed and what's not,
the check should be done there.
Exempt-From-Owner-Approval: cherry-pick from AOSP
Bug: 153073816
Test: m
Test: remove "//apex_available:platform" from libmdnssd (it is currently
installed to /system/lib), and check that `m system_image` fails
Merged-In: Ia304cc5f41f173229e8a154e90cea4dce46dcebe
(cherry picked from commit 89e850ab84)
Change-Id: Ia304cc5f41f173229e8a154e90cea4dce46dcebe
Compiling native modules against the NDK disables platform features
like ASAN. For anything shipped on the system image there is no
reason to compile against the NDK. Add a new mutator to Soong that
creates a platform and an SDK variant for modules that set
sdk_version, and ignore sdk_version for the platform variant. The
SDK variant will be used for embedding in APKs that may be installed
on older platforms. Apexes use their own variants that enforce
backwards compatibility.
Test: sdk_test.go
Test: TestJNIPackaging
Bug: 149591340
Change-Id: I7d72934aaee2e1326cc0ba5f29f51f14feec4521
Merged-In: I7d72934aaee2e1326cc0ba5f29f51f14feec4521
(cherry picked from commit 82e192c3ae)
Apps that expect to run on older platforms should use JNI libraries
that will also run on older platforms. Require that apps that set
sdk_version have jni_libs modules that also set sdk_version, or
set jni_uses_platform_apis: true to bypass the check.
Fixes: 149591057
Test: app_test.go
Change-Id: I76b9b45fb5773bc4dfc10520108f4f3578723909
Merged-In: I76b9b45fb5773bc4dfc10520108f4f3578723909
updatable APEXes should set min_sdk_version as well.
Bug: 152655956
Test: m
Merged-In: I8192086eb89fa958dd8ff1b731e43e24bf217ce2
Change-Id: I8192086eb89fa958dd8ff1b731e43e24bf217ce2
(cherry picked from commit 548640b55f)
apex_deps/apex/apex_flattened mutators don't have to run if module is
disabled.
For some branches which have no valid targets, apex modules are disabled
by the os mutator. e.g. aosp-build-tools
Some enforcement checks which run during those mutators may fail because
build-environment doesn't provide full context information.
For example, "Platform_version_all_codenames" config variable is not
set while apex.min_sdk_version uses one of those codenames.
Bug: 152655956
Test: m
Merged-In: I47e27d2d025ba4c36534708b113ce77c4cb2397b
Change-Id: I47e27d2d025ba4c36534708b113ce77c4cb2397b
(cherry picked from commit 49f6701e9a)
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)
