For now, apex_name is used only for flattened apex.
Even if apex_name is set, the activation point of unflattened is
determined by 'name' in apex_manifest.json.
This change make apex_name as priority.
If apex_name is set, then use this for apex name
- update name in apex_manifest.json to apex_name
- do not check if key filename matches (use apex_name as key name)
This can be useful if soong wants to rename apex module. Simply setting
apex_name has the same effect of renaming "activation point" of apex.
But: 139774701
Test: m (soong test)
Change-Id: I8ea3645e4aa8f317997bc1443ec308ed0595b1c2
The return value is true if TARGET_FLATTEN_APEX is true,
TARGET_BUILD_APPS is false and the module is flatten variant.
Only the module name of flattened variant is appended with
".flattened" as suffix.
Test: m -j
Bug: 139716748
Change-Id: I966a178b43c5d08bd69d19e97e59456aa66d9d28
This change introduces a new module type named 'sdk'. It is a logical
group of prebuilt modules that together provide a context (e.g. APIs)
in which Mainline modules (such as APEXes) are built.
A prebuilt module (e.g. java_import) can join an sdk by adding it to the
sdk module as shown below:
sdk {
name: "mysdk#20",
java_libs: ["myjavalib_mysdk_20"],
}
java_import {
name: "myjavalib_mysdk_20",
srcs: ["myjavalib-v20.jar"],
sdk_member_name: "myjavalib",
}
sdk {
name: "mysdk#21",
java_libs: ["myjavalib_mysdk_21"],
}
java_import {
name: "myjavalib_mysdk_21",
srcs: ["myjavalib-v21.jar"],
sdk_member_name: "myjavalib",
}
java_library {
name: "myjavalib",
srcs: ["**/*/*.java"],
}
An APEX can specify the SDK(s) that it wants to build with via the new
'uses_sdks' property.
apex {
name: "myapex",
java_libs: ["libX", "libY"],
uses_sdks: ["mysdk#20"],
}
With this, libX, libY, and their transitive dependencies are all built
with the version 20 of myjavalib (the first java_import module) instead
of the other one (which is for version 21) and java_library having the
same name (which is for ToT).
Bug: 138182343
Test: m (sdk_test.go added)
Change-Id: I7e14c524a7d6a0d9f575fb20822080f39818c01e
Remove the mention to the (APEX) manifest (`apex_manifest.json`) from
this field's documentation, as `Apex_name` is neither read from nor
written to that file.
Test: n/a
Change-Id: Ia0dfac4f35f1ea697f379bcb19dd11af8705a0a0
This reverts commit fe6330c7d2.
Reason for revert: this was accidentally propping up NDK builds
Bug: 141242600
Change-Id: Ie9f8e31479a74e8e9e14d720a5936da6b1d5d113
Translated second architectures now go in NativeBridgeArch instead
of DeviceSecondaryArch.
Bug: 141242600
Test: m checkbuild
Change-Id: I568046330abc002d4eed582cb999b62a5eaba790
Vendor variant is now divided into several vendor.{version} variants,
depending on their intended usages:
vendor.{BOARD_VNDK_VERSION}: vendor and vendor_available modules
vendor.{PLATFORM_VNDK_VERSION}: VNDK modules in the source tree
vendor.{snapshot_ver}: VNDK snapshot modules
This also affects exported module names from Soong to Make. But to
maintain backward compatibility, ".{BOARD_VNDK_VERSION}" suffix will not
be emitted for modules having version BOARD_VNDK_VERSION, so that vendor
modules still can be referred as-is.
Bug: 65377115
Bug: 68123344
Test: clean build and boot blueline
Change-Id: Ib9016a0f1fe06b97e9423fd95142653a89a343fa
If payload type of APEX is zip, flattened variant and non-flattened
variant create the same MK rules (it's build error). So only
non-flattened variant case, MK rule is created.
And if a.flattenedConfigValue is true, soong don't mutate variants. So
when a.flattenedConfigValue is true, MK rule should be created.
This CL is a partial revert of 4c04713871
Bug: 139716748
Test: m -j com.android.art.host
Change-Id: I37b2fa17e203fb668a0255cda37f10fcfadb3f85
The NOTICE files are missing from prebuilt apexes, and it turns out they
were excluded when building bundles.
Bug: 140317706
Test: Ran build_mainline_modules.sh and checked bundle base modules.
Change-Id: I92c4231f2007e1d8cd9c2bd044201458803c0fd7
Merged-In: I92c4231f2007e1d8cd9c2bd044201458803c0fd7
This reverts commit 8029d6a305.
Reason for revert: The bundletool change has been merged to master.
Change-Id: I87d87827f634a46153ab8ec812f11bc8aaa65c69
Ensure that it ends up in the bionic/ subdir in the Runtime APEX and is
symlinked from /system/lib(64). That makes it available in the default
(platform) linker namespace and no longer requires it to be accessible
through the runtime namespace. All this makes it consistent with how the
other Bionic libs are handled, and avoids the need for various special
cases in ld.config.txt files (to be cleaned up later).
With this there might no longer be a need for a linker namespace for the
Runtime APEX, and we could consider removing the kludge with the
/apex/com.android.runtime/${LIB}/bionic subdirectories and the special case
in getCopyManifestForNativeLibrary in apex.go. However, keeping it calls out
the special treatment of those libraries, and allows a namespace to be added
again if necessary.
Test: Build and boot on taimen_hwasan-userdebug
Test: adb shell /apex/com.android.art/bin/dexdump on taimen_hwasan-userdebug
Test: atest CtsCompilationTestCases on taimen_hwasan-userdebug
Bug: 140734238
Bug: 140790209
Change-Id: Ieb506bfa5d5c159db391273c7eba41d7909de286
The apexBundle module is mutated flattened variant and unflattened
variant. So we can install flattened apex and unflattened apex at the
same time with adding {Apex module name}.flattened to PRODUCT_PACKAGES.
Bug: 139716748
Test: m -j && Add com.android.art.debug.flattened to PRODUCT PACAGES and
check system/apex/com.android.art.debug directory
Change-Id: I0d8c9a155e47c5d0ff13e2f55d4080d91ef5093d
This commit switches the build rule for APEX nativeTests from
`$(BUILD_PREBUILT)` to `soong_cc_prebuilt.mk`. Since these are not real
prebuilts, `soong_cc_prebuilt.mk` should be sufficient.
Using `soong_cc_prebuilt.mk` also fixes a problem reported by prebuilt
ELF checker because `LOCAL_SHARED_LIBRARIES` are not generated for
nativeTests.
Bug: 139525855
Test: lunch aosp_walleye-userdebug && make check-elf-files
Change-Id: I7bfc29f9c2708896dad4e7cfc214480e1205a51e
"apex_vndk" is a variant of "apex" module.
apex_vndk {
name: "com.android.vndk",
..
}
This rule is used to produce a VNDK APEX per vndk version.
It supports automatic inclusion of vndk libs.
If "vndk_version" property is set, the prebuilt vndk libs of
the version will be included in the apex bundle.
apex_vndk {
name: "com.android.vndk.v29"
vndk_version: "29",
...
}
Otherwise, platform's vndk version is used.
This will replace /system/{lib}/vndk-{ver} and vndk-sp-{ver}.
Bug: 134357236
Bug: 139772411
Test: m com.android.vndk
Change-Id: Ib5c86e625839389670d13c683a7427198ef6852f
Jooyung Han