tequilaOS/platform_build_soong
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
platform_build_soong/apex/apex.go

2505 lines
74 KiB
Go
Raw Normal View History

Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
// Copyright (C) 2018 The Android Open Source Project
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
package apex
import (
"fmt"
Make 'file_contexts' prop as `android:"path"` For platform APEXes, file_contexts should point a file under /system/sepolicy. Bug: 144732805 Test: m Change-Id: Ib2d5db715bbebc80a6178d1c42e387b268cc4a0d
2019-11-19 18:26:02 +01:00
"path"
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
"path/filepath"
Make APEX build rules consistent Don't directly iterate over the copyManifest map to generate the copy commands. Iterating over a map in golang isn't guaranteed to give consistent order. This causes the apex build rules to be executed even when there is no source file change. Fix the issue by creating a sorted list of the key and then iterate over the list. Bug: 117453592 Test: m apex.test; m.apex.test nothing is built during the second build Change-Id: I329a91ec0b6a34cbe745bf9a9ceb0843b63c200c
2018-10-10 07:05:29 +02:00
"sort"
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
"strings"
Add "apex_vndk" module type "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
2019-08-23 04:17:39 +02:00
"sync"
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
"android/soong/android"
"android/soong/cc"
"android/soong/java"
Add support for including py_binary and *_go_binary in apexs These additional binary types are useful for some apexs. Add the ability to include them. Due to the nature of the resulting artifacts only py binaries with embedded launchers and host go binaries are supported. Test: m com.android.support.apexer Bug: 119332365 Bug: 119332362 Change-Id: I27c253d3647cf7bbe15896610d7a74a5f93e8bec
2019-02-27 23:19:50 +01:00
"android/soong/python"
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
"github.com/google/blueprint"
Add support for including py_binary and *_go_binary in apexs These additional binary types are useful for some apexs. Add the ability to include them. Due to the nature of the resulting artifacts only py binaries with embedded launchers and host go binaries are supported. Test: m com.android.support.apexer Bug: 119332365 Bug: 119332362 Change-Id: I27c253d3647cf7bbe15896610d7a74a5f93e8bec
2019-02-27 23:19:50 +01:00
"github.com/google/blueprint/bootstrap"
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
"github.com/google/blueprint/proptools"
)
add symlink for compatibility (vndk apex) With VNDK APEX, the location of VNDK lib is changed. But vndk libs of older VNDK versions still depend on old location. For current VNDK version, those hard-coded references will be fixed. TODO(b/142911355): [VNDK APEX] Fix hard-coded references to /system/lib/vndk Bug: 143192278 Bug: 142912195 Test: m com.android.vndk.current and check if /system/lib/vndk OVERRIDE_TARGET_FLATTEN_APEX m com.android.vndk.current Change-Id: I2ebacde7fcd1c7621e4509e08a76765e1dfeb059
2019-10-23 09:46:38 +02:00
const (
imageApexSuffix = ".apex"
zipApexSuffix = ".zipapex"
Create variants for each image type Create variant of image, zip or flattened according to TARGET_FLATTEN_APEX and payload type. If payload type is zip, only zip variant is created because flattened apex is not supported. And if payload type is image, image and flattened variants are created. Bug: 139053989 Test: m -j Change-Id: Ibde18490d23ec602c4cca97cf97db90a562e014e
2019-10-22 06:58:29 +02:00
flattenedSuffix = ".flattened"
add symlink for compatibility (vndk apex) With VNDK APEX, the location of VNDK lib is changed. But vndk libs of older VNDK versions still depend on old location. For current VNDK version, those hard-coded references will be fixed. TODO(b/142911355): [VNDK APEX] Fix hard-coded references to /system/lib/vndk Bug: 143192278 Bug: 142912195 Test: m com.android.vndk.current and check if /system/lib/vndk OVERRIDE_TARGET_FLATTEN_APEX m com.android.vndk.current Change-Id: I2ebacde7fcd1c7621e4509e08a76765e1dfeb059
2019-10-23 09:46:38 +02:00
Create variants for each image type Create variant of image, zip or flattened according to TARGET_FLATTEN_APEX and payload type. If payload type is zip, only zip variant is created because flattened apex is not supported. And if payload type is image, image and flattened variants are created. Bug: 139053989 Test: m -j Change-Id: Ibde18490d23ec602c4cca97cf97db90a562e014e
2019-10-22 06:58:29 +02:00
imageApexType = "image"
zipApexType = "zip"
flattenedApexType = "flattened"
add symlink for compatibility (vndk apex) With VNDK APEX, the location of VNDK lib is changed. But vndk libs of older VNDK versions still depend on old location. For current VNDK version, those hard-coded references will be fixed. TODO(b/142911355): [VNDK APEX] Fix hard-coded references to /system/lib/vndk Bug: 143192278 Bug: 142912195 Test: m com.android.vndk.current and check if /system/lib/vndk OVERRIDE_TARGET_FLATTEN_APEX m com.android.vndk.current Change-Id: I2ebacde7fcd1c7621e4509e08a76765e1dfeb059
2019-10-23 09:46:38 +02:00
)
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
type dependencyTag struct {
blueprint.BaseDependencyTag
name string
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
// determines if the dependent will be part of the APEX payload
payload bool
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
}
var (
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
sharedLibTag = dependencyTag{name: "sharedLib", payload: true}
executableTag = dependencyTag{name: "executable", payload: true}
javaLibTag = dependencyTag{name: "javaLib", payload: true}
prebuiltTag = dependencyTag{name: "prebuilt", payload: true}
testTag = dependencyTag{name: "test", payload: true}
APEXs are signed with apk signer The entire APEX (which is a zip file) is signed with the apk signer. Certificate can be specified via the 'certificate' property just like ordinary apps. Note: multiple additional certificates are not supported. Bug: 115721587 Test: m apex.test Test: jarsigner -verify -verbose -certs .../apex.test.apex shows the certificate info Change-Id: Ia4c898d3427779a3809fdc683b85d7661ca65137
2018-10-30 13:20:05 +01:00
keyTag = dependencyTag{name: "key"}
certificateTag = dependencyTag{name: "certificate"}
Add "provide_cpp_shared_libs/uses" props to "apex" For APEXes to share C++ native libraries, we need a new kind of depedency between APEXes: "providing" APEXes and "using" APEXes. To reflect this dependency two new properties are added. provide_cpp_shared_libs: bool this indicates that the current APEX module provides the native C++ shared libs to other APEXes. uses: []string this indicates that the current APEX module uses the native C++ shared libraries from APEXes listed. With these two, "using" APEXes can omit shared libraries in its APEX bundle and use them from the "providing" APEXes. Note that without corresponding changes in ld.config.txt, this won't work.(The linker namespaces should be configured so that user APEX can access provided libs.) Bug: 136975105 Test: m nothing (this will trigger soong's test) Change-Id: Iec6f9f67bcbde01145acc383f862ba21c8197536
2019-06-27 04:30:33 +02:00
usesTag = dependencyTag{name: "uses"}
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
androidAppTag = dependencyTag{name: "androidApp", payload: true}
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
apexAvailWl = makeApexAvailableWhitelist()
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
)
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
// This is a map from apex to modules, which overrides the
// apex_available setting for that particular module to make
// it available for the apex regardless of its setting.
// TODO(b/147364041): remove this
func makeApexAvailableWhitelist() map[string][]string {
// The "Module separator"s below are employed to minimize merge conflicts.
m := make(map[string][]string)
//
// Module separator
//
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
m["com.android.adbd"] = []string{
"adbd",
"bcm_object",
"fmtlib",
"libadbconnection_server",
"libadbd",
"libadbd_auth",
"libadbd_core",
"libadbd_services",
"libasyncio",
"libbacktrace_headers",
"libbase",
"libbase_headers",
"libbuildversion",
"libc++",
"libcap",
"libcrypto",
"libcrypto_utils",
"libcutils",
"libcutils_headers",
"libdiagnose_usb",
"liblog_headers",
"libmdnssd",
"libminijail",
"libminijail_gen_constants",
"libminijail_gen_constants_obj",
"libminijail_gen_syscall",
"libminijail_gen_syscall_obj",
"libminijail_generated",
"libpackagelistparser",
"libpcre2",
"libprocessgroup_headers",
"libqemu_pipe",
"libsystem_headers",
"libutils_headers",
}
//
// Module separator
//
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
m["com.android.art"] = []string{
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"art_cmdlineparser_headers",
"art_disassembler_headers",
"art_libartbase_headers",
"bcm_object",
"bionic_libc_platform_headers",
"core-repackaged-icu4j",
"cpp-define-generator-asm-support",
"cpp-define-generator-definitions",
"crtbegin_dynamic",
"crtbegin_dynamic1",
"crtbegin_so1",
"crtbrand",
"conscrypt.module.intra.core.api.stubs",
"dex2oat_headers",
"dt_fd_forward_export",
"fmtlib",
"icu4c_extra_headers",
Whitelist jacocoagent for com.android.art Used in coverage builds. Test: NATIVE_COVERAGE=true \ EMMA_INSTRUMENT_FRAMEWORK=true \ EMMA_INSTRUMENT=true \ m nothing Change-Id: I6309d8149fce016eb9689326eeae221914e4c3bb
2020-01-16 10:11:57 +01:00
"jacocoagent",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"javavm_headers",
"jni_platform_headers",
"libPlatformProperties",
"libadbconnection_client",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libadbconnection_server",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libandroidicuinit",
"libart_runtime_headers_ndk",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libartd-disassembler",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libasync_safe",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libbacktrace",
"libbase",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libbase_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libc++",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libc++_static",
"libc++abi",
"libc++demangle",
"libc_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libcrypto",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libdexfile_all_headers",
"libdexfile_external_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libdexfile_support",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libdmabufinfo",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libexpat",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libfdlibm",
"libgtest_prod",
"libicui18n_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libicuuc",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libicuuc_headers",
"libicuuc_stubdata",
"libjdwp_headers",
"liblog_headers",
"liblz4",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"liblzma",
"libmeminfo",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libnativebridge-headers",
"libnativehelper_header_only",
"libnativeloader-headers",
"libnpt_headers",
"libopenjdkjvmti_headers",
"libperfetto_client_experimental",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libprocinfo",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libprotobuf-cpp-lite",
"libunwind_llvm",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libunwindstack",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libv8",
"libv8base",
"libv8gen",
"libv8platform",
"libv8sampler",
"libv8src",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libvixl",
"libvixld",
"libz",
"libziparchive",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"perfetto_trace_protos",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
}
//
// Module separator
//
m["com.android.bluetooth.updatable"] = []string{
"android.hardware.audio.common@5.0",
"android.hardware.bluetooth.a2dp@1.0",
"android.hardware.bluetooth.audio@2.0",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"android.hardware.bluetooth@1.0",
"android.hardware.bluetooth@1.1",
"android.hardware.graphics.bufferqueue@1.0",
"android.hardware.graphics.bufferqueue@2.0",
"android.hardware.graphics.common@1.0",
"android.hardware.graphics.common@1.1",
"android.hardware.graphics.common@1.2",
"android.hardware.media@1.0",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"android.hidl.safe_union@1.0",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"android.hidl.token@1.0",
"android.hidl.token@1.0-utils",
"avrcp-target-service",
"avrcp_headers",
"bcm_object",
"bluetooth-protos-lite",
"bluetooth.mapsapi",
"com.android.vcard",
Fix apex_available 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 5e9013be2202effb500a0aa14d95f5fef70cc75e) Change-Id: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
2020-03-09 22:23:13 +01:00
"dnsresolver_aidl_interface-V2-java",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"fmtlib",
"guava",
Fix apex_available 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 5e9013be2202effb500a0aa14d95f5fef70cc75e) Change-Id: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
2020-03-09 22:23:13 +01:00
"ipmemorystore-aidl-interfaces-V5-java",
"ipmemorystore-aidl-interfaces-java",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"internal_include_headers",
"lib-bt-packets",
"lib-bt-packets-avrcp",
"lib-bt-packets-base",
"libFraunhoferAAC",
"libaudio-a2dp-hw-utils",
"libaudio-hearing-aid-hw-utils",
"libbacktrace_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libbase",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libbase_headers",
"libbinder_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libbluetooth",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libbluetooth-types",
"libbluetooth-types-header",
"libbluetooth_gd",
"libbluetooth_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libbluetooth_jni",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libbt-audio-hal-interface",
"libbt-bta",
"libbt-common",
"libbt-hci",
"libbt-platform-protos-lite",
"libbt-protos-lite",
"libbt-sbc-decoder",
"libbt-sbc-encoder",
"libbt-stack",
"libbt-utils",
"libbtcore",
"libbtdevice",
"libbte",
"libbtif",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libc++",
"libchrome",
"libcrypto",
"libcutils",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libcutils_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libevent",
"libfmq",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libg722codec",
"libgtest_prod",
"libgui_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libhidlbase",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libhidlbase-impl-internal",
"libhidltransport-impl-internal",
"libhwbinder-impl-internal",
"libjsoncpp",
"liblog_headers",
"libmedia_headers",
"libmodpb64",
"libosi",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libprocessgroup",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libprocessgroup_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libprotobuf-cpp-lite",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libprotobuf-java-lite",
"libprotobuf-java-micro",
"libstagefright_foundation_headers",
"libstagefright_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libstatslog",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libstatssocket",
"libsystem_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libtinyxml2",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libudrv-uipc",
"libutils_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libz",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"media_plugin_headers",
Fix apex_available 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 5e9013be2202effb500a0aa14d95f5fef70cc75e) Change-Id: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
2020-03-09 22:23:13 +01:00
"net-utils-services-common",
"netd_aidl_interface-unstable-java",
"netd_event_listener_interface-java",
"netlink-client",
"networkstack-aidl-interfaces-unstable-java",
"networkstack-client",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"sap-api-java-static",
"services.net",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
}
//
// Module separator
//
m["com.android.cellbroadcast"] = []string{"CellBroadcastApp", "CellBroadcastServiceModule"}
//
// Module separator
//
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
m["com.android.conscrypt"] = []string{
"bcm_object",
"boringssl_self_test",
"libc++",
"libcrypto",
"libnativehelper_header_only",
"libssl",
Fix apex_available 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 5e9013be2202effb500a0aa14d95f5fef70cc75e) Change-Id: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
2020-03-09 22:23:13 +01:00
"unsupportedappusage",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
}
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
//
// Module separator
//
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
m["com.android.extservices"] = []string{
"flatbuffer_headers",
"liblua",
"libtextclassifier",
"libtextclassifier_hash_static",
"libtflite_static",
"libutf",
"libz_current",
"tensorflow_headers",
}
//
// Module separator
//
m["com.android.cronet"] = []string{
"cronet_impl_common_java",
"cronet_impl_native_java",
"cronet_impl_platform_java",
"libcronet.80.0.3986.0",
"org.chromium.net.cronet",
Fix apex_available 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 5e9013be2202effb500a0aa14d95f5fef70cc75e) Change-Id: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
2020-03-09 22:23:13 +01:00
"org.chromium.net.cronet.xml",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"prebuilt_libcronet.80.0.3986.0",
}
//
// Module separator
//
m["com.android.neuralnetworks"] = []string{
"android.hardware.neuralnetworks@1.0",
"android.hardware.neuralnetworks@1.1",
"android.hardware.neuralnetworks@1.2",
"android.hardware.neuralnetworks@1.3",
"android.hidl.allocator@1.0",
"android.hidl.memory.token@1.0",
"android.hidl.memory@1.0",
"android.hidl.safe_union@1.0",
"bcm_object",
"fmtlib",
"gemmlowp_headers",
"libarect",
"libbacktrace_headers",
"libbase",
"libbase_headers",
"libbuildversion",
"libc++",
"libcrypto",
"libcrypto_static",
"libcutils",
"libcutils_headers",
"libeigen",
"libfmq",
"libhidlbase",
"libhidlbase-impl-internal",
"libhidlmemory",
"libhidltransport-impl-internal",
"libhwbinder-impl-internal",
"libjsoncpp",
"liblog_headers",
"libmath",
"libneuralnetworks_common",
"libneuralnetworks_headers",
"libprocessgroup",
"libprocessgroup_headers",
"libprocpartition",
"libsync",
"libsystem_headers",
"libtextclassifier_hash",
"libtextclassifier_hash_headers",
"libtextclassifier_hash_static",
"libtflite_kernel_utils",
"libutils_headers",
"philox_random",
"philox_random_headers",
"tensorflow_headers",
}
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
//
// Module separator
//
m["com.android.media"] = []string{
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"android.frameworks.bufferhub@1.0",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"android.hardware.cas.native@1.0",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"android.hardware.cas@1.0",
"android.hardware.configstore-utils",
"android.hardware.configstore@1.0",
"android.hardware.configstore@1.1",
"android.hardware.graphics.allocator@2.0",
"android.hardware.graphics.allocator@3.0",
"android.hardware.graphics.bufferqueue@1.0",
"android.hardware.graphics.bufferqueue@2.0",
"android.hardware.graphics.common@1.0",
"android.hardware.graphics.common@1.1",
"android.hardware.graphics.common@1.2",
"android.hardware.graphics.mapper@2.0",
"android.hardware.graphics.mapper@2.1",
"android.hardware.graphics.mapper@3.0",
"android.hardware.media.omx@1.0",
"android.hardware.media@1.0",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"android.hidl.allocator@1.0",
"android.hidl.memory.token@1.0",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"android.hidl.memory@1.0",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"android.hidl.token@1.0",
"android.hidl.token@1.0-utils",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"bcm_object",
"bionic_libc_platform_headers",
"fmtlib",
"gl_headers",
"libEGL",
"libEGL_blobCache",
"libEGL_getProcAddress",
"libFLAC",
"libFLAC-config",
"libFLAC-headers",
"libGLESv2",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libaacextractor",
"libamrextractor",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libarect",
"libasync_safe",
"libaudio_system_headers",
"libaudioclient",
"libaudioclient_headers",
"libaudiofoundation",
"libaudiofoundation_headers",
"libaudiomanager",
"libaudiopolicy",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libaudioutils",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libaudioutils_fixedfft",
"libbacktrace",
"libbacktrace_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libbase",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libbase_headers",
"libbinder_headers",
"libbluetooth-types-header",
"libbufferhub",
"libbufferhub_headers",
"libbufferhubqueue",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libc++",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libc_headers",
"libc_malloc_debug_backtrace",
"libcamera_client",
"libcamera_metadata",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libcrypto",
"libcutils",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libcutils_headers",
"libdexfile_external_headers",
"libdexfile_support",
"libdvr_headers",
"libexpat",
"libfifo",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libflacextractor",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libgrallocusage",
"libgraphicsenv",
"libgui",
"libgui_headers",
"libhardware_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libhidlbase",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libhidlbase-impl-internal",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libhidlmemory",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libhidltransport-impl-internal",
"libhwbinder-impl-internal",
"libinput",
"libjsoncpp",
"liblog_headers",
"liblzma",
"libmath",
"libmedia",
"libmedia_codeclist",
"libmedia_headers",
"libmedia_helper",
"libmedia_helper_headers",
"libmedia_midiiowrapper",
"libmedia_omx",
"libmediautils",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libmidiextractor",
"libmkvextractor",
"libmp3extractor",
"libmp4extractor",
"libmpeg2extractor",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libnativebase_headers",
"libnativebridge-headers",
"libnativebridge_lazy",
"libnativeloader-headers",
"libnativeloader_lazy",
"libnativewindow_headers",
"libnblog",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"liboggextractor",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libpackagelistparser",
"libpcre2",
"libpdx",
"libpdx_default_transport",
"libpdx_headers",
"libpdx_uds",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libprocessgroup",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libprocessgroup_headers",
"libprocinfo",
"libsonivox",
"libspeexresampler",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libspeexresampler",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libstagefright_esds",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libstagefright_flacdec",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libstagefright_flacdec",
"libstagefright_foundation",
"libstagefright_foundation_headers",
"libstagefright_foundation_without_imemory",
"libstagefright_headers",
"libstagefright_id3",
"libstagefright_metadatautils",
"libstagefright_mpeg2extractor",
"libstagefright_mpeg2support",
"libsync",
"libsystem_headers",
"libui",
"libui_headers",
"libunwindstack",
"libutils_headers",
"libvibrator",
"libvorbisidec",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libwavextractor",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libwebm",
"media_ndk_headers",
"media_plugin_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"updatable-media",
}
//
// Module separator
//
m["com.android.media.swcodec"] = []string{
"android.frameworks.bufferhub@1.0",
"android.hardware.common-ndk_platform",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"android.hardware.configstore-utils",
"android.hardware.configstore@1.0",
"android.hardware.configstore@1.1",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"android.hardware.graphics.allocator@2.0",
"android.hardware.graphics.allocator@3.0",
"android.hardware.graphics.allocator@4.0",
"android.hardware.graphics.bufferqueue@1.0",
"android.hardware.graphics.bufferqueue@2.0",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"android.hardware.graphics.common-ndk_platform",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"android.hardware.graphics.common@1.0",
"android.hardware.graphics.common@1.1",
"android.hardware.graphics.common@1.2",
"android.hardware.graphics.mapper@2.0",
"android.hardware.graphics.mapper@2.1",
"android.hardware.graphics.mapper@3.0",
"android.hardware.graphics.mapper@4.0",
"android.hardware.media.bufferpool@2.0",
"android.hardware.media.c2@1.0",
"android.hardware.media.c2@1.1",
"android.hardware.media.omx@1.0",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"android.hardware.media@1.0",
"android.hardware.media@1.0",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"android.hidl.memory.token@1.0",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"android.hidl.memory@1.0",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"android.hidl.safe_union@1.0",
"android.hidl.token@1.0",
"android.hidl.token@1.0-utils",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"fmtlib",
"libEGL",
"libFLAC",
"libFLAC-config",
"libFLAC-headers",
"libFraunhoferAAC",
Fix apex_available 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 5e9013be2202effb500a0aa14d95f5fef70cc75e) Change-Id: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
2020-03-09 22:23:13 +01:00
"libLibGuiProperties",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libarect",
"libasync_safe",
"libaudio_system_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libaudioutils",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libaudioutils",
"libaudioutils_fixedfft",
"libavcdec",
"libavcenc",
"libavservices_minijail",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libavservices_minijail",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libbacktrace",
"libbacktrace_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libbase",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libbase_headers",
"libbinder_headers",
Fix apex_available 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 5e9013be2202effb500a0aa14d95f5fef70cc75e) Change-Id: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
2020-03-09 22:23:13 +01:00
"libbinderthreadstateutils",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libbluetooth-types-header",
"libbufferhub_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libc++",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libc_scudo",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libcap",
"libcodec2",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libcodec2_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libcodec2_hidl@1.0",
"libcodec2_hidl@1.1",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libcodec2_internal",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libcodec2_soft_aacdec",
"libcodec2_soft_aacenc",
"libcodec2_soft_amrnbdec",
"libcodec2_soft_amrnbenc",
"libcodec2_soft_amrwbdec",
"libcodec2_soft_amrwbenc",
"libcodec2_soft_av1dec_gav1",
"libcodec2_soft_avcdec",
"libcodec2_soft_avcenc",
"libcodec2_soft_common",
"libcodec2_soft_flacdec",
"libcodec2_soft_flacenc",
"libcodec2_soft_g711alawdec",
"libcodec2_soft_g711mlawdec",
"libcodec2_soft_gsmdec",
"libcodec2_soft_h263dec",
"libcodec2_soft_h263enc",
"libcodec2_soft_hevcdec",
"libcodec2_soft_hevcenc",
"libcodec2_soft_mp3dec",
"libcodec2_soft_mpeg2dec",
"libcodec2_soft_mpeg4dec",
"libcodec2_soft_mpeg4enc",
"libcodec2_soft_opusdec",
"libcodec2_soft_opusenc",
"libcodec2_soft_rawdec",
"libcodec2_soft_vorbisdec",
"libcodec2_soft_vp8dec",
"libcodec2_soft_vp8enc",
"libcodec2_soft_vp9dec",
"libcodec2_soft_vp9enc",
"libcodec2_vndk",
"libcutils",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libcutils_headers",
"libdexfile_support",
"libdvr_headers",
"libfmq",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libfmq",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libgav1",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libgralloctypes",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libgrallocusage",
"libgraphicsenv",
"libgsm",
"libgui_bufferqueue_static",
"libgui_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libhardware",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libhardware_headers",
"libhevcdec",
"libhevcenc",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libhidlbase",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libhidlbase-impl-internal",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libhidlmemory",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libhidltransport-impl-internal",
"libhwbinder-impl-internal",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libion",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libjpeg",
"libjsoncpp",
"liblog_headers",
"liblzma",
"libmath",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libmedia_codecserviceregistrant",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libmedia_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libminijail",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libminijail_gen_constants",
"libminijail_gen_constants_obj",
"libminijail_gen_syscall",
"libminijail_gen_syscall_obj",
"libminijail_generated",
"libmpeg2dec",
"libnativebase_headers",
"libnativebridge_lazy",
"libnativeloader_lazy",
"libnativewindow_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libopus",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libpdx_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libprocessgroup",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libprocessgroup_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libscudo_wrapper",
"libsfplugin_ccodec_utils",
"libspeexresampler",
"libstagefright_amrnb_common",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libstagefright_amrnbdec",
"libstagefright_amrnbenc",
"libstagefright_amrwbdec",
"libstagefright_amrwbenc",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libstagefright_bufferpool@2.0.1",
"libstagefright_bufferqueue_helper",
"libstagefright_enc_common",
"libstagefright_flacdec",
"libstagefright_foundation",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libstagefright_foundation_headers",
"libstagefright_headers",
"libstagefright_m4vh263dec",
"libstagefright_m4vh263enc",
"libstagefright_mp3dec",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libsync",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libsystem_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libui",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libui_headers",
"libunwindstack",
"libutils_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libvorbisidec",
"libvpx",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libyuv",
"libyuv_static",
"media_ndk_headers",
"media_plugin_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"mediaswcodec",
}
//
// Module separator
//
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
m["com.android.mediaprovider"] = []string{
"MediaProvider",
"MediaProviderGoogle",
"fmtlib_ndk",
"guava",
"libbase_ndk",
"libfuse",
"libfuse_jni",
"libnativehelper_header_only",
}
//
// Module separator
//
m["com.android.permission"] = []string{
"androidx.annotation_annotation",
"androidx.annotation_annotation-nodeps",
"androidx.lifecycle_lifecycle-common",
"androidx.lifecycle_lifecycle-common-java8",
"androidx.lifecycle_lifecycle-common-java8-nodeps",
"androidx.lifecycle_lifecycle-common-nodeps",
"kotlin-annotations",
"kotlin-stdlib",
"kotlin-stdlib-jdk7",
"kotlin-stdlib-jdk8",
"kotlinx-coroutines-android",
"kotlinx-coroutines-android-nodeps",
"kotlinx-coroutines-core",
"kotlinx-coroutines-core-nodeps",
"libprotobuf-java-lite",
"permissioncontroller-statsd",
Fix the incorrect merge conflict resolution This change fixes the incorrect merge conflict resolution of 3b178969506ca9bb35e7c80dbab3b2ad39fc180b Bug: N/A Test: m Change-Id: If00db9ab9758384a2def5442fbeecb36615d2ec1
2020-02-06 08:47:54 +01:00
"GooglePermissionController",
"PermissionController",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
}
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
//
// Module separator
//
m["com.android.runtime"] = []string{
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"bionic_libc_platform_headers",
"fmtlib",
"libarm-optimized-routines-math",
"libasync_safe",
"libasync_safe_headers",
"libbacktrace_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libbase",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libbase_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libc++",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libc_aeabi",
"libc_bionic",
"libc_bionic_ndk",
"libc_bootstrap",
"libc_common",
"libc_common_shared",
"libc_common_static",
"libc_dns",
"libc_dynamic_dispatch",
"libc_fortify",
"libc_freebsd",
"libc_freebsd_large_stack",
"libc_gdtoa",
"libc_headers",
"libc_init_dynamic",
"libc_init_static",
"libc_jemalloc_wrapper",
"libc_netbsd",
"libc_nomalloc",
"libc_nopthread",
"libc_openbsd",
"libc_openbsd_large_stack",
"libc_openbsd_ndk",
"libc_pthread",
"libc_static_dispatch",
"libc_syscalls",
"libc_tzcode",
"libc_unwind_static",
"libcutils",
"libcutils_headers",
"libdebuggerd",
"libdebuggerd_common_headers",
"libdebuggerd_handler_core",
"libdebuggerd_handler_fallback",
"libdexfile_external_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libdexfile_support",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libdexfile_support_static",
Fix apex_available 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 5e9013be2202effb500a0aa14d95f5fef70cc75e) Change-Id: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
2020-03-09 22:23:13 +01:00
"libdl_static",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libgtest_prod",
"libjemalloc5",
"liblinker_main",
"liblinker_malloc",
"liblog_headers",
"liblz4",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"liblzma",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libprocessgroup_headers",
"libprocinfo",
"libpropertyinfoparser",
"libscudo",
"libstdc++",
"libsystem_headers",
"libsystemproperties",
"libtombstoned_client_static",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libunwindstack",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libutils_headers",
"libz",
"libziparchive",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
}
//
// Module separator
//
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
m["com.android.resolv"] = []string{
"bcm_object",
"dnsresolver_aidl_interface-unstable-ndk_platform",
"fmtlib",
"libbacktrace_headers",
"libbase",
"libbase_headers",
"libc++",
"libcrypto",
"libcutils",
"libcutils_headers",
"libgtest_prod",
"libjsoncpp",
"liblog_headers",
"libnativehelper_header_only",
"libnetd_client_headers",
"libnetd_resolv",
"libnetdutils",
"libprocessgroup",
"libprocessgroup_headers",
"libprotobuf-cpp-lite",
"libssl",
"libstatslog_resolv",
"libstatspush_compat",
"libstatssocket",
"libstatssocket_headers",
"libsystem_headers",
"libsysutils",
"libutils_headers",
"netd_event_listener_interface-ndk_platform",
"server_configurable_flags",
"stats_proto",
}
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
//
// Module separator
//
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
m["com.android.tethering"] = []string{
"libbase",
"libc++",
"libnativehelper_compat_libc++",
"android.hardware.tetheroffload.config@1.0",
"fmtlib",
"libbacktrace_headers",
"libbase_headers",
"libcgrouprc",
"libcgrouprc_format",
"libcutils",
"libcutils_headers",
"libhidlbase",
"libhidlbase-impl-internal",
"libhidltransport-impl-internal",
"libhwbinder-impl-internal",
"libjsoncpp",
"liblog_headers",
"libprocessgroup",
"libprocessgroup_headers",
"libsystem_headers",
"libtetherutilsjni",
"libutils_headers",
"libvndksupport",
"tethering-aidl-interfaces-java",
}
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
//
// Module separator
//
m["com.android.wifi"] = []string{
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"PlatformProperties",
"android.hardware.wifi-V1.0-java",
Fix apex_available 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 5e9013be2202effb500a0aa14d95f5fef70cc75e) Change-Id: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
2020-03-09 22:23:13 +01:00
"android.hardware.wifi-V1.0-java-constants",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"android.hardware.wifi-V1.1-java",
"android.hardware.wifi-V1.2-java",
"android.hardware.wifi-V1.3-java",
"android.hardware.wifi-V1.4-java",
"android.hardware.wifi.hostapd-V1.0-java",
"android.hardware.wifi.hostapd-V1.1-java",
"android.hardware.wifi.hostapd-V1.2-java",
"android.hardware.wifi.supplicant-V1.0-java",
"android.hardware.wifi.supplicant-V1.1-java",
"android.hardware.wifi.supplicant-V1.2-java",
"android.hardware.wifi.supplicant-V1.3-java",
"android.hidl.base-V1.0-java",
"android.hidl.manager-V1.0-java",
"android.hidl.manager-V1.1-java",
"android.hidl.manager-V1.2-java",
"androidx.annotation_annotation",
"androidx.annotation_annotation-nodeps",
"bouncycastle-unbundled",
"dnsresolver_aidl_interface-V2-java",
"error_prone_annotations",
Fix apex_available 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 5e9013be2202effb500a0aa14d95f5fef70cc75e) Change-Id: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
2020-03-09 22:23:13 +01:00
"framework-wifi-pre-jarjar",
"framework-wifi-util-lib",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"ipmemorystore-aidl-interfaces-V3-java",
"ipmemorystore-aidl-interfaces-java",
"ksoap2",
"libbacktrace_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libbase",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libbase_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libc++",
"libcutils",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libcutils_headers",
"liblog_headers",
"libnanohttpd",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libprocessgroup",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"libprocessgroup_headers",
"libprotobuf-java-lite",
"libprotobuf-java-nano",
"libsystem_headers",
"libutils_headers",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"libwifi-jni",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"net-utils-services-common",
"netd_aidl_interface-V2-java",
"netd_aidl_interface-unstable-java",
"netd_event_listener_interface-java",
"netlink-client",
"networkstack-aidl-interfaces-unstable-java",
"networkstack-client",
"services.net",
"wifi-lite-protos",
"wifi-nano-protos",
"wifi-service-pre-jarjar",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
"wifi-service-resources",
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
"prebuilt_androidx.annotation_annotation-nodeps",
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
}
//
// Module separator
//
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
m["com.android.sdkext"] = []string{
"fmtlib_ndk",
"libbase_ndk",
"libprotobuf-cpp-lite-ndk",
}
//
// Module separator
//
m["com.android.os.statsd"] = []string{
"libbacktrace_headers",
"libbase_headers",
"libc++",
"libcutils",
"libcutils_headers",
"liblog_headers",
"libprocessgroup_headers",
"libstatssocket",
"libsystem_headers",
"libutils_headers",
}
//
// Module separator
//
m["//any"] = []string{
"crtbegin_dynamic",
"crtbegin_dynamic1",
"crtbegin_so",
"crtbegin_so1",
"crtbegin_static",
"crtbrand",
"crtend_android",
"crtend_so",
"libatomic",
"libc++_static",
"libc++abi",
"libc++demangle",
"libc_headers",
"libclang_rt",
"libgcc_stripped",
"libprofile-clang-extras",
"libprofile-clang-extras_ndk",
"libprofile-extras",
"libprofile-extras_ndk",
"libunwind_llvm",
"ndk_crtbegin_dynamic.27",
"ndk_crtbegin_so.16",
"ndk_crtbegin_so.19",
"ndk_crtbegin_so.21",
"ndk_crtbegin_so.24",
"ndk_crtbegin_so.27",
"ndk_crtend_android.27",
"ndk_crtend_so.16",
"ndk_crtend_so.19",
"ndk_crtend_so.21",
"ndk_crtend_so.24",
"ndk_crtend_so.27",
"ndk_libandroid_support",
"ndk_libc++_static",
"ndk_libc++abi",
"ndk_libunwind",
}
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
return m
}
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
func init() {
Apex: add NeverAllowRule for updatable to enforce that apexes that set updatable: true also set min_sdk_version Bug: 152655956 Test: m Change-Id: I0d2e9f9b3234873de073ab82d91211faedd16498
2020-04-08 07:13:04 +02:00
android.AddNeverAllowRules(android.NeverAllow().
ModuleType("apex").
With("updatable", "true").
With("min_sdk_version", "").
Because("All updatable apexes should set min_sdk_version."))
Introduce module type 'sdk' 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
2019-07-17 13:08:41 +02:00
android.RegisterModuleType("apex", BundleFactory)
Add support for test_apex Some test and other miscallaneous use-cases need apexs that are installable but will not affect the installation of other artifacts onto the device. For this purpose we added a test_apex type. These test_apex targets create apex files and have all the normal attributes but are not considered the source of any of their contents for the device by the rest of the build-system. Test: build and boot Test: ALLOW_MISSING_DEPENDENCIES=true \ DIST_DIR=$ANDROID_BUILD_TOP/out/dist \ ./art/tools/dist_linux_bionic.sh -j72 showcommands com.android.runtime.host Bug: 123591866 Bug: 123892969 Change-Id: I7f50be0ac0425cd87868145e18bcee6962d472ef
2019-02-07 22:20:53 +01:00
android.RegisterModuleType("apex_test", testApexBundleFactory)
Add "apex_vndk" module type "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
2019-08-23 04:17:39 +02:00
android.RegisterModuleType("apex_vndk", vndkApexBundleFactory)
add apex_defaults apex_defaults is the default module for apex. Bug: 124026431 Test: m (apex_test updated) Change-Id: I09f63046e909e8eeb52ecec6bb07eb51e5490561
2019-02-07 08:27:23 +01:00
android.RegisterModuleType("apex_defaults", defaultsFactory)
Add prebuilt_apex. Bug: 127789981 Test: apex_test.go + com.android.tzdata.apex Change-Id: I09bb0a4b2acf310c55c789569da3c9d755638232
2019-03-26 23:07:36 +01:00
android.RegisterModuleType("prebuilt_apex", PrebuiltFactory)
Add override_apex module type override_apex module type is used to override existing apex module with certain properties overridden. Currently, only the 'apps' property is overridable. Bug: 144338929 Test: m Change-Id: Ic050b062093cda29ce78126cc92dd6097647f7db
2019-11-15 10:40:32 +01:00
android.RegisterModuleType("override_apex", overrideApexFactory)
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
Revert "Revert "Supports VNDK APEX with different versions"" This reverts commit 48dd4b5ea480319da29359a668191d52e9d8c9c2. Bug: 141451661 Bug: 139772411 Test: m (soong tests) Test: boot with aosp_arm64 system image on Q vendor device
2019-10-18 09:26:59 +02:00
android.PreDepsMutators(RegisterPreDepsMutators)
Introduce module type 'sdk' 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
2019-07-17 13:08:41 +02:00
android.PostDepsMutators(RegisterPostDepsMutators)
Fix flattened apex install dir This fixes the bug: flattened apex is installed under /system/apex/<soong module name> not /system/apex/<apex name>. Flattened apexes can be seen as pre-activated under /system/apex, which is bind-mount to /apex. Therefore, install dir for flattend apex should be the same with the activation point(or mountpoint) of non-flattened apex. When apex_name: is set, it should be used as its name instead of name:. This change also emits makevar APEX_FILE_CONTEXTS_INFOS which is list of pairs(<apex_name>:<file_contexts>) and is used by sepolicy to modify file_contexts files for flattened apexes properly. Bug: 123314817 Bug: 142300241 Test: add a test apex module(foo) with apex_name(foobar) Test: OVERRIDE_TARGET_FLATTEN_APEX=true m foo Test: see if the apex is installed correctly(/system/apex/foobar) Test: see if the file_contexts for foo is correctly modified Change-Id: I97a07de5cc772cd1d91e95ae059d282038028916
2019-10-08 14:59:58 +02:00
android.RegisterMakeVarsProvider(pctx, func(ctx android.MakeVarsContext) {
apexFileContextsInfos := apexFileContextsInfos(ctx.Config())
sort.Strings(*apexFileContextsInfos)
ctx.Strict("APEX_FILE_CONTEXTS_INFOS", strings.Join(*apexFileContextsInfos, " "))
})
Introduce module type 'sdk' 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
2019-07-17 13:08:41 +02:00
}
Revert "Revert "Supports VNDK APEX with different versions"" This reverts commit 48dd4b5ea480319da29359a668191d52e9d8c9c2. Bug: 141451661 Bug: 139772411 Test: m (soong tests) Test: boot with aosp_arm64 system image on Q vendor device
2019-10-18 09:26:59 +02:00
func RegisterPreDepsMutators(ctx android.RegisterMutatorsContext) {
ctx.TopDown("apex_vndk", apexVndkMutator).Parallel()
ctx.BottomUp("apex_vndk_deps", apexVndkDepsMutator).Parallel()
}
Introduce module type 'sdk' 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
2019-07-17 13:08:41 +02:00
func RegisterPostDepsMutators(ctx android.RegisterMutatorsContext) {
apexDepsMutator is a top-down mutator 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
2020-02-11 23:53:12 +01:00
ctx.TopDown("apex_deps", apexDepsMutator)
Introduce module type 'sdk' 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
2019-07-17 13:08:41 +02:00
ctx.BottomUp("apex", apexMutator).Parallel()
ctx.BottomUp("apex_flattened", apexFlattenedMutator).Parallel()
ctx.BottomUp("apex_uses", apexUsesMutator).Parallel()
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
}
// Mark the direct and transitive dependencies of apex bundles so that they
// can be built for the apex bundles.
apexDepsMutator is a top-down mutator 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
2020-02-11 23:53:12 +01:00
func apexDepsMutator(mctx android.TopDownMutatorContext) {
Statically link the unwinder into binaries packaged into an unbundled APEX with legacy_android10_support: true. 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
2020-02-13 02:13:25 +01:00
var apexBundles []android.ApexInfo
apexDepsMutator is a top-down mutator 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
2020-02-11 23:53:12 +01:00
var directDep bool
Revert "Revert "apex_vndk uses vendor variants only"" This reverts commit 5df3b11f7865ea81eab765d30c82489bfd7e5fd5. 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
2020-01-23 06:36:59 +01:00
if a, ok := mctx.Module().(*apexBundle); ok && !a.vndkApex {
Fix apex_available 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 5e9013be2202effb500a0aa14d95f5fef70cc75e) Change-Id: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
2020-03-09 22:23:13 +01:00
apexBundles = []android.ApexInfo{android.ApexInfo{
apex: Deprecate legacy_android10_support prop 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 5417f775e5823cb93fd0547c019fd78e6e3cfe70) Exempt-From-Owner-Approval: cp from aosp
2020-03-12 10:37:20 +01:00
ApexName: mctx.ModuleName(),
MinSdkVersion: a.minSdkVersion(mctx),
Fix apex_available 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 5e9013be2202effb500a0aa14d95f5fef70cc75e) Change-Id: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
2020-03-09 22:23:13 +01:00
}}
apexDepsMutator is a top-down mutator 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
2020-02-11 23:53:12 +01:00
directDep = true
} else if am, ok := mctx.Module().(android.ApexModule); ok {
Statically link the unwinder into binaries packaged into an unbundled APEX with legacy_android10_support: true. 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
2020-02-13 02:13:25 +01:00
apexBundles = am.ApexVariations()
apexDepsMutator is a top-down mutator 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
2020-02-11 23:53:12 +01:00
directDep = false
}
Don't create unnecessary APEX variations This change fixes a problem that APEX variations are created for the modules that actually shouldn't built for any APEX. For example, consider this case. apex { name: "myapex", native_shared_libs: ["mylib"],} cc_library { name: "mylib", shared_libs: ["libfoo#10"],} cc_library { name: "libfoo", shared_libs: ["libbar"], stubs: { versions: ["10"], }, } cc_library { name: "libbar", ...} Before this change, both the stubs and non-stubs variations of libfoo were mutated with apexMuator, which is incorrect for the non-stubs varia; there is no dependency chain from the apex "myapex" to the non-stubs variation, but to the stubs variation due to the #10 syntax. This was happening becauses we used the name of the module to determine whether it should be built for APEX or not. Both stubs and non-stubs variations have the same module name "libfoo". Fixing this issue by recording the list of APEX variations required directly on the module. So, the stubs variation of libfoo has myapex in its apex variations list, but the non-stubs variation doesn't, and thus apexMutator does not pick up the non-stubs variation. Test: m (apex_test updated and passing) Test: cherry-pick ag/5747464 and m Change-Id: I31e618626809a828a55fff513ef5f81f79637afa
2018-12-10 17:35:25 +01:00
Statically link the unwinder into binaries packaged into an unbundled APEX with legacy_android10_support: true. 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
2020-02-13 02:13:25 +01:00
if len(apexBundles) == 0 {
apexDepsMutator is a top-down mutator 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
2020-02-11 23:53:12 +01:00
return
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
}
apexDepsMutator is a top-down mutator 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
2020-02-11 23:53:12 +01:00
Fix apex_available 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 5e9013be2202effb500a0aa14d95f5fef70cc75e) Change-Id: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
2020-03-09 22:23:13 +01:00
cur := mctx.Module().(interface {
DepIsInSameApex(android.BaseModuleContext, android.Module) bool
})
apexDepsMutator is a top-down mutator 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
2020-02-11 23:53:12 +01:00
mctx.VisitDirectDeps(func(child android.Module) {
depName := mctx.OtherModuleName(child)
if am, ok := child.(android.ApexModule); ok && am.CanHaveApexVariants() &&
Fix apex_available 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 5e9013be2202effb500a0aa14d95f5fef70cc75e) Change-Id: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
2020-03-09 22:23:13 +01:00
cur.DepIsInSameApex(mctx, child) {
Statically link the unwinder into binaries packaged into an unbundled APEX with legacy_android10_support: true. 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
2020-02-13 02:13:25 +01:00
android.UpdateApexDependency(apexBundles, depName, directDep)
am.BuildForApexes(apexBundles)
apexDepsMutator is a top-down mutator 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
2020-02-11 23:53:12 +01:00
}
})
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
}
// Create apex variations if a module is included in APEX(s).
func apexMutator(mctx android.BottomUpMutatorContext) {
if am, ok := mctx.Module().(android.ApexModule); ok && am.CanHaveApexVariants() {
Don't create unnecessary APEX variations This change fixes a problem that APEX variations are created for the modules that actually shouldn't built for any APEX. For example, consider this case. apex { name: "myapex", native_shared_libs: ["mylib"],} cc_library { name: "mylib", shared_libs: ["libfoo#10"],} cc_library { name: "libfoo", shared_libs: ["libbar"], stubs: { versions: ["10"], }, } cc_library { name: "libbar", ...} Before this change, both the stubs and non-stubs variations of libfoo were mutated with apexMuator, which is incorrect for the non-stubs varia; there is no dependency chain from the apex "myapex" to the non-stubs variation, but to the stubs variation due to the #10 syntax. This was happening becauses we used the name of the module to determine whether it should be built for APEX or not. Both stubs and non-stubs variations have the same module name "libfoo". Fixing this issue by recording the list of APEX variations required directly on the module. So, the stubs variation of libfoo has myapex in its apex variations list, but the non-stubs variation doesn't, and thus apexMutator does not pick up the non-stubs variation. Test: m (apex_test updated and passing) Test: cherry-pick ag/5747464 and m Change-Id: I31e618626809a828a55fff513ef5f81f79637afa
2018-12-10 17:35:25 +01:00
am.CreateApexVariations(mctx)
Revert "Revert "apex_vndk uses vendor variants only"" This reverts commit 5df3b11f7865ea81eab765d30c82489bfd7e5fd5. 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
2020-01-23 06:36:59 +01:00
} else if a, ok := mctx.Module().(*apexBundle); ok && !a.vndkApex {
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
// apex bundle itself is mutated so that it and its modules have same
// apex variant.
apexBundleName := mctx.ModuleName()
mctx.CreateVariations(apexBundleName)
Add override_apex module type override_apex module type is used to override existing apex module with certain properties overridden. Currently, only the 'apps' property is overridable. Bug: 144338929 Test: m Change-Id: Ic050b062093cda29ce78126cc92dd6097647f7db
2019-11-15 10:40:32 +01:00
} else if o, ok := mctx.Module().(*OverrideApex); ok {
apexBundleName := o.GetOverriddenModuleName()
if apexBundleName == "" {
mctx.ModuleErrorf("base property is not set")
return
}
mctx.CreateVariations(apexBundleName)
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
}
Add override_apex module type override_apex module type is used to override existing apex module with certain properties overridden. Currently, only the 'apps' property is overridable. Bug: 144338929 Test: m Change-Id: Ic050b062093cda29ce78126cc92dd6097647f7db
2019-11-15 10:40:32 +01:00
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
}
Create flattened variants for soong apex module 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
2019-09-06 10:37:42 +02:00
Fix flattened apex install dir This fixes the bug: flattened apex is installed under /system/apex/<soong module name> not /system/apex/<apex name>. Flattened apexes can be seen as pre-activated under /system/apex, which is bind-mount to /apex. Therefore, install dir for flattend apex should be the same with the activation point(or mountpoint) of non-flattened apex. When apex_name: is set, it should be used as its name instead of name:. This change also emits makevar APEX_FILE_CONTEXTS_INFOS which is list of pairs(<apex_name>:<file_contexts>) and is used by sepolicy to modify file_contexts files for flattened apexes properly. Bug: 123314817 Bug: 142300241 Test: add a test apex module(foo) with apex_name(foobar) Test: OVERRIDE_TARGET_FLATTEN_APEX=true m foo Test: see if the apex is installed correctly(/system/apex/foobar) Test: see if the file_contexts for foo is correctly modified Change-Id: I97a07de5cc772cd1d91e95ae059d282038028916
2019-10-08 14:59:58 +02:00
var (
apexFileContextsInfosKey = android.NewOnceKey("apexFileContextsInfosKey")
apexFileContextsInfosMutex sync.Mutex
)
func apexFileContextsInfos(config android.Config) *[]string {
return config.Once(apexFileContextsInfosKey, func() interface{} {
return &[]string{}
}).(*[]string)
}
Make 'file_contexts' prop as `android:"path"` For platform APEXes, file_contexts should point a file under /system/sepolicy. Bug: 144732805 Test: m Change-Id: Ib2d5db715bbebc80a6178d1c42e387b268cc4a0d
2019-11-19 18:26:02 +01:00
func addFlattenedFileContextsInfos(ctx android.BaseModuleContext, fileContextsInfo string) {
Fix flattened apex install dir This fixes the bug: flattened apex is installed under /system/apex/<soong module name> not /system/apex/<apex name>. Flattened apexes can be seen as pre-activated under /system/apex, which is bind-mount to /apex. Therefore, install dir for flattend apex should be the same with the activation point(or mountpoint) of non-flattened apex. When apex_name: is set, it should be used as its name instead of name:. This change also emits makevar APEX_FILE_CONTEXTS_INFOS which is list of pairs(<apex_name>:<file_contexts>) and is used by sepolicy to modify file_contexts files for flattened apexes properly. Bug: 123314817 Bug: 142300241 Test: add a test apex module(foo) with apex_name(foobar) Test: OVERRIDE_TARGET_FLATTEN_APEX=true m foo Test: see if the apex is installed correctly(/system/apex/foobar) Test: see if the file_contexts for foo is correctly modified Change-Id: I97a07de5cc772cd1d91e95ae059d282038028916
2019-10-08 14:59:58 +02:00
apexFileContextsInfosMutex.Lock()
defer apexFileContextsInfosMutex.Unlock()
apexFileContextsInfos := apexFileContextsInfos(ctx.Config())
Make 'file_contexts' prop as `android:"path"` For platform APEXes, file_contexts should point a file under /system/sepolicy. Bug: 144732805 Test: m Change-Id: Ib2d5db715bbebc80a6178d1c42e387b268cc4a0d
2019-11-19 18:26:02 +01:00
*apexFileContextsInfos = append(*apexFileContextsInfos, fileContextsInfo)
Fix flattened apex install dir This fixes the bug: flattened apex is installed under /system/apex/<soong module name> not /system/apex/<apex name>. Flattened apexes can be seen as pre-activated under /system/apex, which is bind-mount to /apex. Therefore, install dir for flattend apex should be the same with the activation point(or mountpoint) of non-flattened apex. When apex_name: is set, it should be used as its name instead of name:. This change also emits makevar APEX_FILE_CONTEXTS_INFOS which is list of pairs(<apex_name>:<file_contexts>) and is used by sepolicy to modify file_contexts files for flattened apexes properly. Bug: 123314817 Bug: 142300241 Test: add a test apex module(foo) with apex_name(foobar) Test: OVERRIDE_TARGET_FLATTEN_APEX=true m foo Test: see if the apex is installed correctly(/system/apex/foobar) Test: see if the file_contexts for foo is correctly modified Change-Id: I97a07de5cc772cd1d91e95ae059d282038028916
2019-10-08 14:59:58 +02:00
}
Create flattened variants for soong apex module 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
2019-09-06 10:37:42 +02:00
func apexFlattenedMutator(mctx android.BottomUpMutatorContext) {
Add isFlattenedVariant function 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
2019-09-17 06:50:45 +02:00
if ab, ok := mctx.Module().(*apexBundle); ok {
Create variants for each image type Create variant of image, zip or flattened according to TARGET_FLATTEN_APEX and payload type. If payload type is zip, only zip variant is created because flattened apex is not supported. And if payload type is image, image and flattened variants are created. Bug: 139053989 Test: m -j Change-Id: Ibde18490d23ec602c4cca97cf97db90a562e014e
2019-10-22 06:58:29 +02:00
var variants []string
switch proptools.StringDefault(ab.properties.Payload_type, "image") {
case "image":
variants = append(variants, imageApexType, flattenedApexType)
case "zip":
variants = append(variants, zipApexType)
case "both":
variants = append(variants, imageApexType, zipApexType, flattenedApexType)
default:
Change the partition of outputfile If some apex module can be installed for both flattened and unflattened, flattened apex should be installed to system_ext partition. So add MakeAsSystemExt func to change the partition from system to system_ext. Bug: 139053989 Test: m -j Change-Id: I3e3430413a9045d96130af99e249567b1a26ed7e
2019-10-08 12:34:03 +02:00
mctx.PropertyErrorf("type", "%q is not one of \"image\", \"zip\", or \"both\".", *ab.properties.Payload_type)
Create variants for each image type Create variant of image, zip or flattened according to TARGET_FLATTEN_APEX and payload type. If payload type is zip, only zip variant is created because flattened apex is not supported. And if payload type is image, image and flattened variants are created. Bug: 139053989 Test: m -j Change-Id: Ibde18490d23ec602c4cca97cf97db90a562e014e
2019-10-22 06:58:29 +02:00
return
}
modules := mctx.CreateLocalVariations(variants...)
for i, v := range variants {
switch v {
case imageApexType:
modules[i].(*apexBundle).properties.ApexType = imageApex
case zipApexType:
modules[i].(*apexBundle).properties.ApexType = zipApex
case flattenedApexType:
modules[i].(*apexBundle).properties.ApexType = flattenedApex
Fix: install flattened apex on system_ext This build rule is specific to platform APEXes. For non-platform APEXes, MakeAsSystemExt() is not applied. This fixes the cases of "soc_specific: true" apexes which fails to build. Bug: 139053989 Test: m nothing (soong tests) Change-Id: I98d0257499647ab41cdaa62a3671d89addbdf833 Exempt-From-Owner-Approval: got +1 before rebasing
2019-11-19 17:49:42 +01:00
if !mctx.Config().FlattenApex() && ab.Platform() {
Change the partition of outputfile If some apex module can be installed for both flattened and unflattened, flattened apex should be installed to system_ext partition. So add MakeAsSystemExt func to change the partition from system to system_ext. Bug: 139053989 Test: m -j Change-Id: I3e3430413a9045d96130af99e249567b1a26ed7e
2019-10-08 12:34:03 +02:00
modules[i].(*apexBundle).MakeAsSystemExt()
}
Create variants for each image type Create variant of image, zip or flattened according to TARGET_FLATTEN_APEX and payload type. If payload type is zip, only zip variant is created because flattened apex is not supported. And if payload type is image, image and flattened variants are created. Bug: 139053989 Test: m -j Change-Id: Ibde18490d23ec602c4cca97cf97db90a562e014e
2019-10-22 06:58:29 +02:00
}
Create flattened variants for soong apex module 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
2019-09-06 10:37:42 +02:00
}
Add override_apex module type override_apex module type is used to override existing apex module with certain properties overridden. Currently, only the 'apps' property is overridable. Bug: 144338929 Test: m Change-Id: Ic050b062093cda29ce78126cc92dd6097647f7db
2019-11-15 10:40:32 +01:00
} else if _, ok := mctx.Module().(*OverrideApex); ok {
mctx.CreateVariations(imageApexType, flattenedApexType)
Create flattened variants for soong apex module 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
2019-09-06 10:37:42 +02:00
}
}
Add "provide_cpp_shared_libs/uses" props to "apex" For APEXes to share C++ native libraries, we need a new kind of depedency between APEXes: "providing" APEXes and "using" APEXes. To reflect this dependency two new properties are added. provide_cpp_shared_libs: bool this indicates that the current APEX module provides the native C++ shared libs to other APEXes. uses: []string this indicates that the current APEX module uses the native C++ shared libraries from APEXes listed. With these two, "using" APEXes can omit shared libraries in its APEX bundle and use them from the "providing" APEXes. Note that without corresponding changes in ld.config.txt, this won't work.(The linker namespaces should be configured so that user APEX can access provided libs.) Bug: 136975105 Test: m nothing (this will trigger soong's test) Change-Id: Iec6f9f67bcbde01145acc383f862ba21c8197536
2019-06-27 04:30:33 +02:00
func apexUsesMutator(mctx android.BottomUpMutatorContext) {
if ab, ok := mctx.Module().(*apexBundle); ok {
mctx.AddFarVariationDependencies(nil, usesTag, ab.properties.Uses...)
}
}
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
apex: Restrict usage of "use_vendor" When use_vendor is used, native modules are built with __ANDROID_VNDK__ and __ANDROID_APEX__, which may cause compatibility issues. (e.g. libbinder) Even though libbinder restricts its availability via 'apex_available' property and relies on yet another macro __ANDROID_APEX_<NAME>__, we restrict usage of "use_vendor:" from other APEX modules to avoid similar problems. Bug: 142684427 Test: m -j Change-Id: Ibc781de2efcd20cb6688a183b08e908a8a6e2593
2019-10-31 19:14:38 +01:00
var (
useVendorWhitelistKey = android.NewOnceKey("useVendorWhitelist")
)
// useVendorWhitelist returns the list of APEXes which are allowed to use_vendor.
// When use_vendor is used, native modules are built with __ANDROID_VNDK__ and __ANDROID_APEX__,
// which may cause compatibility issues. (e.g. libbinder)
// Even though libbinder restricts its availability via 'apex_available' property and relies on
// yet another macro __ANDROID_APEX_<NAME>__, we restrict usage of "use_vendor:" from other APEX modules
// to avoid similar problems.
func useVendorWhitelist(config android.Config) []string {
return config.Once(useVendorWhitelistKey, func() interface{} {
return []string{
// swcodec uses "vendor" variants for smaller size
"com.android.media.swcodec",
"test_com.android.media.swcodec",
}
}).([]string)
}
// setUseVendorWhitelistForTest overrides useVendorWhitelist and must be
// called before the first call to useVendorWhitelist()
func setUseVendorWhitelistForTest(config android.Config, whitelist []string) {
config.Once(useVendorWhitelistKey, func() interface{} {
return whitelist
})
}
Add limited target-specific configuration to apex. Some apex targets need to be able to change their contents based on if they are host or target or what libc they are using. This adds support for doing this using the standard 'target: {...}' idiom. Test: m com.android.runtime.host Test: ./art/tools/build_linux_bionic.sh com.android.runtime.host Bug: 123591866 Change-Id: If73bee650cdeb277c0e603763aa0b0108656bfdd
2019-01-30 03:07:33 +01:00
type apexNativeDependencies struct {
// List of native libraries
Native_shared_libs []string
Add "apex_vndk" module type "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
2019-08-23 04:17:39 +02:00
Add limited target-specific configuration to apex. Some apex targets need to be able to change their contents based on if they are host or target or what libc they are using. This adds support for doing this using the standard 'target: {...}' idiom. Test: m com.android.runtime.host Test: ./art/tools/build_linux_bionic.sh com.android.runtime.host Bug: 123591866 Change-Id: If73bee650cdeb277c0e603763aa0b0108656bfdd
2019-01-30 03:07:33 +01:00
// List of native executables
Binaries []string
Add "apex_vndk" module type "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
2019-08-23 04:17:39 +02:00
Add support for tests in APEX test modules. Allow `tests` property in `apex_test` Soong modules. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: Ieeff7cf0980a7c394409632b6448102f59bceb3d
2019-06-26 13:48:34 +02:00
// List of native tests
Tests []string
Add limited target-specific configuration to apex. Some apex targets need to be able to change their contents based on if they are host or target or what libc they are using. This adds support for doing this using the standard 'target: {...}' idiom. Test: m com.android.runtime.host Test: ./art/tools/build_linux_bionic.sh com.android.runtime.host Bug: 123591866 Change-Id: If73bee650cdeb277c0e603763aa0b0108656bfdd
2019-01-30 03:07:33 +01:00
}
Add "apex_vndk" module type "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
2019-08-23 04:17:39 +02:00
Add limited target-specific configuration to apex. Some apex targets need to be able to change their contents based on if they are host or target or what libc they are using. This adds support for doing this using the standard 'target: {...}' idiom. Test: m com.android.runtime.host Test: ./art/tools/build_linux_bionic.sh com.android.runtime.host Bug: 123591866 Change-Id: If73bee650cdeb277c0e603763aa0b0108656bfdd
2019-01-30 03:07:33 +01:00
type apexMultilibProperties struct {
// Native dependencies whose compile_multilib is "first"
First apexNativeDependencies
// Native dependencies whose compile_multilib is "both"
Both apexNativeDependencies
// Native dependencies whose compile_multilib is "prefer32"
Prefer32 apexNativeDependencies
// Native dependencies whose compile_multilib is "32"
Lib32 apexNativeDependencies
// Native dependencies whose compile_multilib is "64"
Lib64 apexNativeDependencies
}
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
type apexBundleProperties struct {
// Json manifest file describing meta info of this APEX bundle. Default:
Rename manifest and image files. manifest.json -> apex_manifest.json image.img -> apex_payload.img Bug: 119672727 Test: m, installed on device, boots. Change-Id: Id79c6a1ac8f5d306f534477d94b76f8ed0e7d7a7
2018-11-20 19:04:58 +01:00
// "apex_manifest.json"
Annotate paths and deprecate ExtractSource(s)Deps Add `android:"path"` to all properties that take paths to source files, and remove the calls to ExtractSource(s)Deps, the pathsDepsMutator will add the necessary SourceDepTag dependency. Test: All soong tests Change-Id: I488ba1a5d680aaa50b04fc38acf693e23c6d4d6d
2019-03-05 07:35:41 +01:00
Manifest *string `android:"path"`
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
Allow each APEX to provide its own AndroidManifest AndroidManifest.xml file can be specified via the 'androidManifest' property in the apex module type. It can be used to have a custom AndroidManifest.xml that have additional tags (such as <uses-sdk> or <uses-feature>) for precise targeting. The property is optional; if unspecified, then one is auto-generated as before. Bug: 123857186 Test: m apex_test_build_features Change-Id: Id7ee0471661887cfa11124cbaa3beea8cffcdda4
2019-02-07 18:53:06 +01:00
// AndroidManifest.xml file used for the zip container of this APEX bundle.
// If unspecified, a default one is automatically generated.
Annotate paths and deprecate ExtractSource(s)Deps Add `android:"path"` to all properties that take paths to source files, and remove the calls to ExtractSource(s)Deps, the pathsDepsMutator will add the necessary SourceDepTag dependency. Test: All soong tests Change-Id: I488ba1a5d680aaa50b04fc38acf693e23c6d4d6d
2019-03-05 07:35:41 +01:00
AndroidManifest *string `android:"path"`
Allow each APEX to provide its own AndroidManifest AndroidManifest.xml file can be specified via the 'androidManifest' property in the apex module type. It can be used to have a custom AndroidManifest.xml that have additional tags (such as <uses-sdk> or <uses-feature>) for precise targeting. The property is optional; if unspecified, then one is auto-generated as before. Bug: 123857186 Test: m apex_test_build_features Change-Id: Id7ee0471661887cfa11124cbaa3beea8cffcdda4
2019-02-07 18:53:06 +01:00
Fix documentation of field `soong.apex.apexBundleProperties.Apex_name`. 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
2019-09-19 17:37:20 +02:00
// Canonical name of the APEX bundle. Used to determine the path to the activated APEX on
// device (/apex/<apex_name>).
// If unspecified, defaults to the value of name.
Fix the symbol file paths for files in APEXes This change fixes the problem that symbol files for APEXes are installed to incorrect path when TARGET_FLATTEN_APEX is set to true or the canonical name of an APEX is different fro the module name of the APEX. For the case when TARGET_FLATTEN_APEX is true, LOCAL_SOONG_SYMBOL_PATH is set to point to the runtime path of a file (e.g. /apex/<name>/*). For the case of the different canonical and module names, apex_name property is added to explicitly specify the canonical name Bug: 120846816 Test: m and inspect that symbol files exist under $(PRODUCT_OUT)/symbols/apex/com.android.runtime/ Change-Id: Idfec88d6a30a18c225b0d87b868b9f1e0a617e38
2019-03-18 06:26:32 +01:00
Apex_name *string
Move file_contexts file for APEXes to under /system/sepolicy For centralized development of sepolices, file_contexts files for APEXes are all moved to under /system/seplicy. The meaning of the existing file_contexts has been changed; when it is set to <value>, then /system/sepolicy/apex/<value>_file_contexts is used. When unset, it defaults to the name of the module. The property is not removed in order to support creating multiple versions of the same apex (for testing purpose) built with same file_contexts file. Bug: 119034475 Test: m apex.test com.android.tzdata com.android.runtime Change-Id: I7d14a9e37baea9ab78d9e15e1164cce54d256f56
2018-11-09 22:37:15 +01:00
// Determines the file contexts file for setting security context to each file in this APEX bundle.
Make 'file_contexts' prop as `android:"path"` For platform APEXes, file_contexts should point a file under /system/sepolicy. Bug: 144732805 Test: m Change-Id: Ib2d5db715bbebc80a6178d1c42e387b268cc4a0d
2019-11-19 18:26:02 +01:00
// For platform APEXes, this should points to a file under /system/sepolicy
// Default: /system/sepolicy/apex/<module_name>_file_contexts.
File_contexts *string `android:"path"`
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
// List of native shared libs that are embedded inside this APEX bundle
Native_shared_libs []string
Add support for tests in APEX test modules. Allow `tests` property in `apex_test` Soong modules. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: Ieeff7cf0980a7c394409632b6448102f59bceb3d
2019-06-26 13:48:34 +02:00
// List of executables that are embedded inside this APEX bundle
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
Binaries []string
// List of java libraries that are embedded inside this APEX bundle
Java_libs []string
// List of prebuilt files that are embedded inside this APEX bundle
Prebuilts []string
APEX can be signed with different keys A new module type 'apex_key' is defined to specify public and private key pair for APEXs. An APEX can refer to the module via the property 'key'. When building the APEX, the private key from the key module is used to sign it. In addition, the public key from the key module is automatically installed to /system/etc/security/apex. Bug: 115721587 Test: m apex.test; m /apex/com.android.example.apex@1 exists Change-Id: I82666db095bd7a09f6c1b9cbea2db57ebc076cbf
2018-10-12 14:49:38 +02:00
Add support for tests in APEX test modules. Allow `tests` property in `apex_test` Soong modules. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: Ieeff7cf0980a7c394409632b6448102f59bceb3d
2019-06-26 13:48:34 +02:00
// List of tests that are embedded inside this APEX bundle
Tests []string
APEX can be signed with different keys A new module type 'apex_key' is defined to specify public and private key pair for APEXs. An APEX can refer to the module via the property 'key'. When building the APEX, the private key from the key module is used to sign it. In addition, the public key from the key module is automatically installed to /system/etc/security/apex. Bug: 115721587 Test: m apex.test; m /apex/com.android.example.apex@1 exists Change-Id: I82666db095bd7a09f6c1b9cbea2db57ebc076cbf
2018-10-12 14:49:38 +02:00
// Name of the apex_key module that provides the private key to sign APEX
Key *string
binaries and native_shared_libraires are multilib-aware props The properties 'binaries' and 'native_shared_libraries' can be multilib-aware, i.e, can be under multilib.type where type can be either first, both, lib32, lib64, or prefer32. Native modules listed in multilib.first are installed only for the first ABI of the device. Similarily, multilib.both are for both of the ABIs, while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only, respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is available. Another change is that the binaries property, when not within multilib, targets only the first ABI. Test: m apex.test on ... 1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true 2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true 3) aosp_arm in all cases, vold, surfaceflinger and drmserver are all intalled under ./bin directory of the APEX. And native libraries are installed under both ./lib and ./lib64 directories in the case of 1) and 2). Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
Add zip-apex This adds support for an apex-like file where the payload is a zip file instead of a FS image. This makes it easier to examine and use without root. These can also be built for the host. This can be controlled using the 'type' modifier in the apex build rule. 'type' may be "image" to build an apex file called {name}.apex with an FS image payload, "zip" to build an apex with called {name}.zipapex with a zip-file payload or "both" to build both. By default we will use "image". This also adds support for setting apex rules to "host_supported: true". Test: cd art/build/apex; mma; examine the com.android.runtime.host.zipapex artifact. Test: go test android/soong/apex -v Bug: 120436895 Change-Id: I534d330672211ac5ccc3bd5a0c89b9fc507bf51e
2018-11-30 02:12:15 +01:00
// The type of APEX to build. Controls what the APEX payload is. Either
// 'image', 'zip' or 'both'. Default: 'image'.
Payload_type *string
APEXs are signed with apk signer The entire APEX (which is a zip file) is signed with the apk signer. Certificate can be specified via the 'certificate' property just like ordinary apps. Note: multiple additional certificates are not supported. Bug: 115721587 Test: m apex.test Test: jarsigner -verify -verbose -certs .../apex.test.apex shows the certificate info Change-Id: Ia4c898d3427779a3809fdc683b85d7661ca65137
2018-10-30 13:20:05 +01:00
// The name of a certificate in the default certificate directory, blank to use the default product certificate,
// or an android_app_certificate module name in the form ":module".
Certificate *string
Add installable property to apex module type When set to false, the apex is built but not installed. Useful for not polluting the system image with test APEXes when doing mma. Bug: 120960303 Test: add 'installable: false' to apex.test under system/apex/tests/Android.bp m; check that out/..../system/apex/apex.test.apex does not exist. Change-Id: I383d5cdcc8aec705b6a5778dbd07233471d289d0
2018-12-13 15:14:57 +01:00
// Whether this APEX is installable to one of the partitions. Default: true.
Installable *bool
Add use_vendor to APEX module use_vendor, when set to true, brings vendor variant of the native libraries and binaries to the APEX. Bug: 115707625 Test: m (apex_test updated) Change-Id: Ib4e996f8652f4ce4645a9c22f6914e2ab35edda6
2018-12-19 09:12:36 +01:00
// For native libraries and binaries, use the vendor variant instead of the core (platform) variant.
// Default is false.
Use_vendor *bool
Give a knob to have apex ignore system-lib special cases apex will normally place libc and some other system libraries into a separate directory. This is to ensure that early startup works correctly. Some apex targets want to have these libraries at the normal places however. Test: ./art/tools/build_linux_bionic.sh com.android.runtime.host Bug: 123591866 Bug: 120266448 Change-Id: Ib5a67a43fe3eea6188b4df9215e743f1634045f3
2019-01-30 03:31:59 +01:00
// For telling the apex to ignore special handling for system libraries such as bionic. Default is false.
Ignore_system_library_special_case *bool
Add limited target-specific configuration to apex. Some apex targets need to be able to change their contents based on if they are host or target or what libc they are using. This adds support for doing this using the standard 'target: {...}' idiom. Test: m com.android.runtime.host Test: ./art/tools/build_linux_bionic.sh com.android.runtime.host Bug: 123591866 Change-Id: If73bee650cdeb277c0e603763aa0b0108656bfdd
2019-01-30 03:07:33 +01:00
Multilib apexMultilibProperties
Add prefer_sanitize.* properties to apex It is used to configure an apex to prefere specific sanitizer variants if available. For example, if a lib is with sanitize: {cfi: true} then an APEX with prefer_sanitize: {cfi: true} will use the sanitized variant of the lib. Bug: 124128094 Test: m on marlin extractor libraries are found under /system/apex/com.android.media Change-Id: I858778eef78c5791cdeb497c7c11688cb128b5fe
2019-02-09 03:50:56 +01:00
Remove prefer_sanitize.* properties The properties are no longer required as an APEX module is mutated with required sanitizers which are gathered by scanning the sanitizers that are enabled for its direct dependencies. Bug: 124128094 Test: m on marlin The extractor libs are found under /system/apex/com.android.media Merged-In: I55961d400dcbac067a5c0dcecb90e399d4991a70 Change-Id: I55961d400dcbac067a5c0dcecb90e399d4991a70 (cherry picked from commit abda0eb76b8aa9aac3220e4f60391210fbcb5b53)
2019-02-13 12:28:58 +01:00
// List of sanitizer names that this APEX is enabled for
SanitizerNames []string `blueprint:"mutated"`
Add "provide_cpp_shared_libs/uses" props to "apex" For APEXes to share C++ native libraries, we need a new kind of depedency between APEXes: "providing" APEXes and "using" APEXes. To reflect this dependency two new properties are added. provide_cpp_shared_libs: bool this indicates that the current APEX module provides the native C++ shared libs to other APEXes. uses: []string this indicates that the current APEX module uses the native C++ shared libraries from APEXes listed. With these two, "using" APEXes can omit shared libraries in its APEX bundle and use them from the "providing" APEXes. Note that without corresponding changes in ld.config.txt, this won't work.(The linker namespaces should be configured so that user APEX can access provided libs.) Bug: 136975105 Test: m nothing (this will trigger soong's test) Change-Id: Iec6f9f67bcbde01145acc383f862ba21c8197536
2019-06-27 04:30:33 +02:00
Build native coverage variant of APEXes when needed When the native coverage is enabled, APEXes (and files there) are built for native coverage as well. Bug: 138952487 Test: make -j NATIVE_COVERAGE=true COVERAGE_PATHS='*' com.android.resolv find out -name "*.gcno" | grep DnsResolver shows files Test: libnetd_resolv.zip is found under $(TARGET_OUT)/apex/com.android.resolv/lib directory Change-Id: I97bcee9bf8ffc0dc71453abbdb613ed56ea2cdb4
2019-08-09 07:44:36 +02:00
PreventInstall bool `blueprint:"mutated"`
HideFromMake bool `blueprint:"mutated"`
Add "provide_cpp_shared_libs/uses" props to "apex" For APEXes to share C++ native libraries, we need a new kind of depedency between APEXes: "providing" APEXes and "using" APEXes. To reflect this dependency two new properties are added. provide_cpp_shared_libs: bool this indicates that the current APEX module provides the native C++ shared libs to other APEXes. uses: []string this indicates that the current APEX module uses the native C++ shared libraries from APEXes listed. With these two, "using" APEXes can omit shared libraries in its APEX bundle and use them from the "providing" APEXes. Note that without corresponding changes in ld.config.txt, this won't work.(The linker namespaces should be configured so that user APEX can access provided libs.) Bug: 136975105 Test: m nothing (this will trigger soong's test) Change-Id: Iec6f9f67bcbde01145acc383f862ba21c8197536
2019-06-27 04:30:33 +02:00
// Indicates this APEX provides C++ shared libaries to other APEXes. Default: false.
Provide_cpp_shared_libs *bool
// List of providing APEXes' names so that this APEX can depend on provided shared libraries.
Uses []string
apex.go: Add support for diffing content of APEX with whitelist file So far a very basic version. In case there is a diff, soong will emit an error message with a command to resolve the diff. Example: New unexpected files were added to com.android.apex.cts.shim.v3. To fix the build run following command: system/apex/tools/update_whitelist.sh system/apex/shim/build/default_shim_whitelist.txt out/soong/.intermediates/system/apex/shim/build/com.android.apex.cts.shim.v3/android_common_com.android.apex.cts.shim.v3/com.android.apex.cts.shim.v3-content.txt Test: m checkbuild Bug: 139125405 Change-Id: I57e694f394c56105dc7363a684983605c7bf5e7d
2019-08-31 15:38:05 +02:00
// A txt file containing list of files that are whitelisted to be included in this APEX.
Whitelisted_files *string
Support including apk inside an apex New property "apps" is added to APEX soong module. This property configure a list of APKs to package inside APEX payload. For each android_app module package it's APK into /app/$(android_app module Name) directory. Bug: 139906763 Test: m -j Change-Id: Ic6655f211951af08097c76e157a07ebc52425718
2019-08-27 06:55:42 +02:00
Create variants for each image type Create variant of image, zip or flattened according to TARGET_FLATTEN_APEX and payload type. If payload type is zip, only zip variant is created because flattened apex is not supported. And if payload type is image, image and flattened variants are created. Bug: 139053989 Test: m -j Change-Id: Ibde18490d23ec602c4cca97cf97db90a562e014e
2019-10-22 06:58:29 +02:00
// package format of this apex variant; could be non-flattened, flattened, or zip.
// imageApex, zipApex or flattened
ApexType apexPackaging `blueprint:"mutated"`
Add isFlattenedVariant function 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
2019-09-17 06:50:45 +02:00
Introduce module type 'sdk' 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
2019-07-17 13:08:41 +02:00
// List of SDKs that are used to build this APEX. A reference to an SDK should be either
// `name#version` or `name` which is an alias for `name#current`. If left empty, `platform#current`
// is implied. This value affects all modules included in this APEX. In other words, they are
// also built with the SDKs specified here.
Uses_sdks []string
Add override_apex module type override_apex module type is used to override existing apex module with certain properties overridden. Currently, only the 'apps' property is overridable. Bug: 144338929 Test: m Change-Id: Ic050b062093cda29ce78126cc92dd6097647f7db
2019-11-15 10:40:32 +01:00
Add property to apex soong modules to generate an APEX without hashtree This will help testing on-device hashtree generation. Test: see other CL in topic Bug: 145670581 Change-Id: I96b1b2392302aed8a6e80ed52de2d057a532a288
2019-12-07 18:30:22 +01:00
// Whenever apex_payload.img of the APEX should include dm-verity hashtree.
// Should be only used in tests#.
Test_only_no_hashtree *bool
Add "legacy_android10_support" to "apex" APEXes with "legacy_android10_support" will have apex_manifest.json for compatibility as well as apex_manifest.pb. Bug: 143951586 Test: m (soong tests) Change-Id: I019252aee5a9423f4b180ba1026e6e99c9961437
2019-11-12 05:03:50 +01:00
Reland "m <apex_name>-deps-info prints the internal/external deps of the APEX"" This reverts commit 4513f703f9902193fc5c29607ddb4a8f71bfd702. Bug: 1190898 Test: m Test: EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true NATIVE_COVERAGE=true m dist Change-Id: I50fdccabb43e4751694db83ee451d388657257e0
2020-01-09 04:32:06 +01:00
IsCoverageVariant bool `blueprint:"mutated"`
have a per-module switch to turn the symlinking optimizaiton off 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
2020-02-19 08:29:35 +01:00
// Whether this APEX is considered updatable or not. When set to true, this will enforce additional
// rules for making sure that the APEX is truely updatable. This will also disable the size optimizations
// like symlinking to the system libs. Default is false.
Updatable *bool
Add min_sdk_version property to apexes Add a min_sdk_version property apexes. Currently a noop, but will be used to enforce that dependencies are compatible with the specified version. Test: m checkbuild Bug: 149591522 Merged-In: I923773c90fe15becbffae3986791aa9edde8f8f6 Change-Id: I923773c90fe15becbffae3986791aa9edde8f8f6 (cherry picked from commit 50317874ffbe4722dd75583672a32fc48e478a18)
2020-02-20 05:41:10 +01:00
// The minimum SDK version that this apex must be compatible with.
Min_sdk_version *string
Add limited target-specific configuration to apex. Some apex targets need to be able to change their contents based on if they are host or target or what libc they are using. This adds support for doing this using the standard 'target: {...}' idiom. Test: m com.android.runtime.host Test: ./art/tools/build_linux_bionic.sh com.android.runtime.host Bug: 123591866 Change-Id: If73bee650cdeb277c0e603763aa0b0108656bfdd
2019-01-30 03:07:33 +01:00
}
type apexTargetBundleProperties struct {
Target struct {
// Multilib properties only for android.
Android struct {
Multilib apexMultilibProperties
binaries and native_shared_libraires are multilib-aware props The properties 'binaries' and 'native_shared_libraries' can be multilib-aware, i.e, can be under multilib.type where type can be either first, both, lib32, lib64, or prefer32. Native modules listed in multilib.first are installed only for the first ABI of the device. Similarily, multilib.both are for both of the ABIs, while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only, respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is available. Another change is that the binaries property, when not within multilib, targets only the first ABI. Test: m apex.test on ... 1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true 2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true 3) aosp_arm in all cases, vold, surfaceflinger and drmserver are all intalled under ./bin directory of the APEX. And native libraries are installed under both ./lib and ./lib64 directories in the case of 1) and 2). Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
}
Add "apex_vndk" module type "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
2019-08-23 04:17:39 +02:00
Add limited target-specific configuration to apex. Some apex targets need to be able to change their contents based on if they are host or target or what libc they are using. This adds support for doing this using the standard 'target: {...}' idiom. Test: m com.android.runtime.host Test: ./art/tools/build_linux_bionic.sh com.android.runtime.host Bug: 123591866 Change-Id: If73bee650cdeb277c0e603763aa0b0108656bfdd
2019-01-30 03:07:33 +01:00
// Multilib properties only for host.
Host struct {
Multilib apexMultilibProperties
binaries and native_shared_libraires are multilib-aware props The properties 'binaries' and 'native_shared_libraries' can be multilib-aware, i.e, can be under multilib.type where type can be either first, both, lib32, lib64, or prefer32. Native modules listed in multilib.first are installed only for the first ABI of the device. Similarily, multilib.both are for both of the ABIs, while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only, respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is available. Another change is that the binaries property, when not within multilib, targets only the first ABI. Test: m apex.test on ... 1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true 2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true 3) aosp_arm in all cases, vold, surfaceflinger and drmserver are all intalled under ./bin directory of the APEX. And native libraries are installed under both ./lib and ./lib64 directories in the case of 1) and 2). Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
}
Add "apex_vndk" module type "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
2019-08-23 04:17:39 +02:00
Add limited target-specific configuration to apex. Some apex targets need to be able to change their contents based on if they are host or target or what libc they are using. This adds support for doing this using the standard 'target: {...}' idiom. Test: m com.android.runtime.host Test: ./art/tools/build_linux_bionic.sh com.android.runtime.host Bug: 123591866 Change-Id: If73bee650cdeb277c0e603763aa0b0108656bfdd
2019-01-30 03:07:33 +01:00
// Multilib properties only for host linux_bionic.
Linux_bionic struct {
Multilib apexMultilibProperties
binaries and native_shared_libraires are multilib-aware props The properties 'binaries' and 'native_shared_libraries' can be multilib-aware, i.e, can be under multilib.type where type can be either first, both, lib32, lib64, or prefer32. Native modules listed in multilib.first are installed only for the first ABI of the device. Similarily, multilib.both are for both of the ABIs, while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only, respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is available. Another change is that the binaries property, when not within multilib, targets only the first ABI. Test: m apex.test on ... 1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true 2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true 3) aosp_arm in all cases, vold, surfaceflinger and drmserver are all intalled under ./bin directory of the APEX. And native libraries are installed under both ./lib and ./lib64 directories in the case of 1) and 2). Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
}
Add "apex_vndk" module type "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
2019-08-23 04:17:39 +02:00
Add limited target-specific configuration to apex. Some apex targets need to be able to change their contents based on if they are host or target or what libc they are using. This adds support for doing this using the standard 'target: {...}' idiom. Test: m com.android.runtime.host Test: ./art/tools/build_linux_bionic.sh com.android.runtime.host Bug: 123591866 Change-Id: If73bee650cdeb277c0e603763aa0b0108656bfdd
2019-01-30 03:07:33 +01:00
// Multilib properties only for host linux_glibc.
Linux_glibc struct {
Multilib apexMultilibProperties
binaries and native_shared_libraires are multilib-aware props The properties 'binaries' and 'native_shared_libraries' can be multilib-aware, i.e, can be under multilib.type where type can be either first, both, lib32, lib64, or prefer32. Native modules listed in multilib.first are installed only for the first ABI of the device. Similarily, multilib.both are for both of the ABIs, while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only, respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is available. Another change is that the binaries property, when not within multilib, targets only the first ABI. Test: m apex.test on ... 1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true 2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true 3) aosp_arm in all cases, vold, surfaceflinger and drmserver are all intalled under ./bin directory of the APEX. And native libraries are installed under both ./lib and ./lib64 directories in the case of 1) and 2). Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
}
}
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
}
Add override_apex module type override_apex module type is used to override existing apex module with certain properties overridden. Currently, only the 'apps' property is overridable. Bug: 144338929 Test: m Change-Id: Ic050b062093cda29ce78126cc92dd6097647f7db
2019-11-15 10:40:32 +01:00
type overridableProperties struct {
// List of APKs to package inside APEX
Apps []string
Make apex.overrides overridable by override_apex. Test: apex_test.go Change-Id: Id47e5e5bec45ec1ada68f9d2d806585c5141a2f9
2019-12-20 02:32:06 +01:00
// Names of modules to be overridden. Listed modules can only be other binaries
// (in Make or Soong).
// This does not completely prevent installation of the overridden binaries, but if both
// binaries would be installed by default (in PRODUCT_PACKAGES) the other binary will be removed
// from PRODUCT_PACKAGES.
Overrides []string
Allow for setting a logging_parent for an Apex. Test: go test ./... -test.v -run TestOverrideApex BUG: 148198056 Change-Id: Ib3749e59f5e31903f2dbe75f86534738147a55ec
2020-02-20 06:29:28 +01:00
// Logging Parent value
Logging_parent string
Allow for overriding container packagename for an Apex. Test: go test ./... -test.v -run TestOverrideApex BUG: 148198056 Merged-In: If49042a7acbf9f0dcb505664863d97805902e459 Change-Id: If49042a7acbf9f0dcb505664863d97805902e459
2020-03-15 21:01:05 +01:00
// Apex Container Package Name.
// Override value for attribute package:name in AndroidManifest.xml
Package_name string
Add override_apex module type override_apex module type is used to override existing apex module with certain properties overridden. Currently, only the 'apps' property is overridable. Bug: 144338929 Test: m Change-Id: Ic050b062093cda29ce78126cc92dd6097647f7db
2019-11-15 10:40:32 +01:00
}
Add zip-apex This adds support for an apex-like file where the payload is a zip file instead of a FS image. This makes it easier to examine and use without root. These can also be built for the host. This can be controlled using the 'type' modifier in the apex build rule. 'type' may be "image" to build an apex file called {name}.apex with an FS image payload, "zip" to build an apex with called {name}.zipapex with a zip-file payload or "both" to build both. By default we will use "image". This also adds support for setting apex rules to "host_supported: true". Test: cd art/build/apex; mma; examine the com.android.runtime.host.zipapex artifact. Test: go test android/soong/apex -v Bug: 120436895 Change-Id: I534d330672211ac5ccc3bd5a0c89b9fc507bf51e
2018-11-30 02:12:15 +01:00
type apexPackaging int
const (
imageApex apexPackaging = iota
zipApex
Create variants for each image type Create variant of image, zip or flattened according to TARGET_FLATTEN_APEX and payload type. If payload type is zip, only zip variant is created because flattened apex is not supported. And if payload type is image, image and flattened variants are created. Bug: 139053989 Test: m -j Change-Id: Ibde18490d23ec602c4cca97cf97db90a562e014e
2019-10-22 06:58:29 +02:00
flattenedApex
Add zip-apex This adds support for an apex-like file where the payload is a zip file instead of a FS image. This makes it easier to examine and use without root. These can also be built for the host. This can be controlled using the 'type' modifier in the apex build rule. 'type' may be "image" to build an apex file called {name}.apex with an FS image payload, "zip" to build an apex with called {name}.zipapex with a zip-file payload or "both" to build both. By default we will use "image". This also adds support for setting apex rules to "host_supported: true". Test: cd art/build/apex; mma; examine the com.android.runtime.host.zipapex artifact. Test: go test android/soong/apex -v Bug: 120436895 Change-Id: I534d330672211ac5ccc3bd5a0c89b9fc507bf51e
2018-11-30 02:12:15 +01:00
)
Create variants for each image type Create variant of image, zip or flattened according to TARGET_FLATTEN_APEX and payload type. If payload type is zip, only zip variant is created because flattened apex is not supported. And if payload type is image, image and flattened variants are created. Bug: 139053989 Test: m -j Change-Id: Ibde18490d23ec602c4cca97cf97db90a562e014e
2019-10-22 06:58:29 +02:00
// The suffix for the output "file", not the module
Add zip-apex This adds support for an apex-like file where the payload is a zip file instead of a FS image. This makes it easier to examine and use without root. These can also be built for the host. This can be controlled using the 'type' modifier in the apex build rule. 'type' may be "image" to build an apex file called {name}.apex with an FS image payload, "zip" to build an apex with called {name}.zipapex with a zip-file payload or "both" to build both. By default we will use "image". This also adds support for setting apex rules to "host_supported: true". Test: cd art/build/apex; mma; examine the com.android.runtime.host.zipapex artifact. Test: go test android/soong/apex -v Bug: 120436895 Change-Id: I534d330672211ac5ccc3bd5a0c89b9fc507bf51e
2018-11-30 02:12:15 +01:00
func (a apexPackaging) suffix() string {
switch a {
case imageApex:
return imageApexSuffix
case zipApex:
return zipApexSuffix
default:
Fix some typos in error messages in apex/apex.go. Test: m Change-Id: Iee54bd0e2e0d6651d82b7fbae246f20643e49ceb
2019-07-31 15:09:17 +02:00
panic(fmt.Errorf("unknown APEX type %d", a))
Add zip-apex This adds support for an apex-like file where the payload is a zip file instead of a FS image. This makes it easier to examine and use without root. These can also be built for the host. This can be controlled using the 'type' modifier in the apex build rule. 'type' may be "image" to build an apex file called {name}.apex with an FS image payload, "zip" to build an apex with called {name}.zipapex with a zip-file payload or "both" to build both. By default we will use "image". This also adds support for setting apex rules to "host_supported: true". Test: cd art/build/apex; mma; examine the com.android.runtime.host.zipapex artifact. Test: go test android/soong/apex -v Bug: 120436895 Change-Id: I534d330672211ac5ccc3bd5a0c89b9fc507bf51e
2018-11-30 02:12:15 +01:00
}
}
func (a apexPackaging) name() string {
switch a {
case imageApex:
return imageApexType
case zipApex:
return zipApexType
default:
Fix some typos in error messages in apex/apex.go. Test: m Change-Id: Iee54bd0e2e0d6651d82b7fbae246f20643e49ceb
2019-07-31 15:09:17 +02:00
panic(fmt.Errorf("unknown APEX type %d", a))
Add zip-apex This adds support for an apex-like file where the payload is a zip file instead of a FS image. This makes it easier to examine and use without root. These can also be built for the host. This can be controlled using the 'type' modifier in the apex build rule. 'type' may be "image" to build an apex file called {name}.apex with an FS image payload, "zip" to build an apex with called {name}.zipapex with a zip-file payload or "both" to build both. By default we will use "image". This also adds support for setting apex rules to "host_supported: true". Test: cd art/build/apex; mma; examine the com.android.runtime.host.zipapex artifact. Test: go test android/soong/apex -v Bug: 120436895 Change-Id: I534d330672211ac5ccc3bd5a0c89b9fc507bf51e
2018-11-30 02:12:15 +01:00
}
}
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
type apexFileClass int
const (
etc apexFileClass = iota
nativeSharedLib
nativeExecutable
shBinary
pyBinary
goBinary
javaSharedLib
nativeTest
app
)
APEX can be flattened When TARGET_FLATTEN_APEX is set to true, APEXes are flattened, which means files in an APEX is not packaged into the mini file system image, but instead directly copied to the system partition. This option is for devices where kernel does not support loopback devices or the maximum number of loopback devices is too small (though the threshold is TBD as of now). This CL also fixes a bug that jars having bytecode are installed instead of those having dex. Bug: 118485880 Test: TARGET_FLATTEN_APEX=true m apex.test; tree out/target/product/.../system/apex/apex.test shows list of files in it. Test; m apex.test, then a file out/target/product/.../system/apex/apex .test.apex exists. Change-Id: I5a3d62d392d05f2779c4925388afe4f6e460059b
2018-11-07 18:50:25 +01:00
func (class apexFileClass) NameInMake() string {
switch class {
case etc:
return "ETC"
case nativeSharedLib:
return "SHARED_LIBRARIES"
Add support for including py_binary and *_go_binary in apexs These additional binary types are useful for some apexs. Add the ability to include them. Due to the nature of the resulting artifacts only py binaries with embedded launchers and host go binaries are supported. Test: m com.android.support.apexer Bug: 119332365 Bug: 119332362 Change-Id: I27c253d3647cf7bbe15896610d7a74a5f93e8bec
2019-02-27 23:19:50 +01:00
case nativeExecutable, shBinary, pyBinary, goBinary:
APEX can be flattened When TARGET_FLATTEN_APEX is set to true, APEXes are flattened, which means files in an APEX is not packaged into the mini file system image, but instead directly copied to the system partition. This option is for devices where kernel does not support loopback devices or the maximum number of loopback devices is too small (though the threshold is TBD as of now). This CL also fixes a bug that jars having bytecode are installed instead of those having dex. Bug: 118485880 Test: TARGET_FLATTEN_APEX=true m apex.test; tree out/target/product/.../system/apex/apex.test shows list of files in it. Test; m apex.test, then a file out/target/product/.../system/apex/apex .test.apex exists. Change-Id: I5a3d62d392d05f2779c4925388afe4f6e460059b
2018-11-07 18:50:25 +01:00
return "EXECUTABLES"
case javaSharedLib:
return "JAVA_LIBRARIES"
Add support for tests in APEX test modules. Allow `tests` property in `apex_test` Soong modules. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: Ieeff7cf0980a7c394409632b6448102f59bceb3d
2019-06-26 13:48:34 +02:00
case nativeTest:
return "NATIVE_TESTS"
Support including apk inside an apex New property "apps" is added to APEX soong module. This property configure a list of APKs to package inside APEX payload. For each android_app module package it's APK into /app/$(android_app module Name) directory. Bug: 139906763 Test: m -j Change-Id: Ic6655f211951af08097c76e157a07ebc52425718
2019-08-27 06:55:42 +02:00
case app:
Correctly install APK-in-APEX APK in a flattened APEX is installed as 'ETC' class module, instead of the 'APP' class. This is to prevent Make from doing app-specific amendments (e.g. such as adding module name after my_module_path) to the paths and filenames which are all correctly set in the Soong side. Test: add `installable:true` to development/samples/Snake/Android.mk and add 'Snake' to the `apps` property of an APEX. The build is successful. Test: build the APEX on a device with TARGET_FLATTEN_APEX=true The APK is at system/apex/<apexname>/app/Snake/Snake.apk Bug: 142537672 Change-Id: I314bf1ab7abd4d4a4e9fa210442c004f54d8ccca
2019-10-11 13:46:25 +02:00
// b/142537672 Why isn't this APP? We want to have full control over
// the paths and file names of the apk file under the flattend APEX.
// If this is set to APP, then the paths and file names are modified
// by the Make build system. For example, it is installed to
// /system/apex/<apexname>/app/<Appname>/<apexname>.<Appname>/ instead of
// /system/apex/<apexname>/app/<Appname> because the build system automatically
// appends module name (which is <apexname>.<Appname> to the path.
return "ETC"
APEX can be flattened When TARGET_FLATTEN_APEX is set to true, APEXes are flattened, which means files in an APEX is not packaged into the mini file system image, but instead directly copied to the system partition. This option is for devices where kernel does not support loopback devices or the maximum number of loopback devices is too small (though the threshold is TBD as of now). This CL also fixes a bug that jars having bytecode are installed instead of those having dex. Bug: 118485880 Test: TARGET_FLATTEN_APEX=true m apex.test; tree out/target/product/.../system/apex/apex.test shows list of files in it. Test; m apex.test, then a file out/target/product/.../system/apex/apex .test.apex exists. Change-Id: I5a3d62d392d05f2779c4925388afe4f6e460059b
2018-11-07 18:50:25 +01:00
default:
Fix some typos in error messages in apex/apex.go. Test: m Change-Id: Iee54bd0e2e0d6651d82b7fbae246f20643e49ceb
2019-07-31 15:09:17 +02:00
panic(fmt.Errorf("unknown class %d", class))
APEX can be flattened When TARGET_FLATTEN_APEX is set to true, APEXes are flattened, which means files in an APEX is not packaged into the mini file system image, but instead directly copied to the system partition. This option is for devices where kernel does not support loopback devices or the maximum number of loopback devices is too small (though the threshold is TBD as of now). This CL also fixes a bug that jars having bytecode are installed instead of those having dex. Bug: 118485880 Test: TARGET_FLATTEN_APEX=true m apex.test; tree out/target/product/.../system/apex/apex.test shows list of files in it. Test; m apex.test, then a file out/target/product/.../system/apex/apex .test.apex exists. Change-Id: I5a3d62d392d05f2779c4925388afe4f6e460059b
2018-11-07 18:50:25 +01:00
}
}
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
// apexFile represents a file in an APEX bundle
APEX can be flattened When TARGET_FLATTEN_APEX is set to true, APEXes are flattened, which means files in an APEX is not packaged into the mini file system image, but instead directly copied to the system partition. This option is for devices where kernel does not support loopback devices or the maximum number of loopback devices is too small (though the threshold is TBD as of now). This CL also fixes a bug that jars having bytecode are installed instead of those having dex. Bug: 118485880 Test: TARGET_FLATTEN_APEX=true m apex.test; tree out/target/product/.../system/apex/apex.test shows list of files in it. Test; m apex.test, then a file out/target/product/.../system/apex/apex .test.apex exists. Change-Id: I5a3d62d392d05f2779c4925388afe4f6e460059b
2018-11-07 18:50:25 +01:00
type apexFile struct {
builtFile android.Path
moduleName string
installDir string
class apexFileClass
Fix: Flattend APEX is breaking build When TARGET_FLATTEN_APEX=true, individual files in an APEX are exported to make. However, because they lack LOCAL_SOONG_CLASSES_JAR, soong_java_prebuilt.mk get confused and the build breaks. Fixing the bug by correctly emitting LOCAL_SOONG_CLASSES_JAR and LOCAL_SOONG_HEADER_JAR. Test: TARGET_FLATTEN_APEX=true m out/target/common/obj/JAVA_LIBRARIES/com.android.conscrypt.conscrypt_intermediates/classes.jar Change-Id: I65ce86ec825f978a43715146bbd5c1d5af513de0
2018-12-19 09:36:39 +01:00
module android.Module
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
// list of symlinks that will be created in installDir that point to this apexFile
symlinks []string
transitiveDep bool
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
moduleDir string
APEX carries required properties of its dependencies When a module is included in an APEX and the module is not directly installed to the system partition, the 'required' property of the module is lost. The APEX containing the module now carries the property from its dependencies. Bug: 146549048 Test: m Change-Id: Ie21cc7b8420c6126c855e66c2363644de4a7ef42
2019-12-30 08:56:33 +01:00
requiredModuleNames []string
targetRequiredModuleNames []string
hostRequiredModuleNames []string
jacoco correctly gathers info from APK-in-APEX This change fixes a bug that jacoco-report-classes-all.jar does not include info for APK-in-APEX such as the MediaProvider apk in com.android.mediaprovider APEX. Firstly, LOCAL_SOONG_JACOCO_REPORT_CLASSES_JAR is correctly set also for the APKs included in APEXes. Secondly, the Make modules for the embedded APKs are now built with soong_app_prebuilt.mk to correctly import the jacoco file into the Make world. Bug: 147296855 Test: execute the following command in internal master. $ choosecombo cf_x86_phone userdebug $ NINJA_ARGS="-t path out/target/product/vsoc_x86/jacoco-report-classes-all.jar out/target/common/obj/ETC/MediaProvider.com.android.mediaprovider_intermediates/jacoco-report-classes.jar" EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true m The result shows that there is a path as follows: out/target/product/vsoc_x86/jacoco-report-classes-all.jar out/target/product/vsoc_x86/apex/com.android.mediaprovider/priv-app/MediaProvider/MediaProvider.apk out/target/product/vsoc_x86/obj/ETC/MediaProvider.com.android.mediaprovider_intermediates/package.apk out/target/common/obj/ETC/MediaProvider.com.android.mediaprovider_intermediates/jacoco-report-classes.jar Change-Id: I52d11534a34eb35219bfafca4453e75a1b701c0e
2020-01-08 05:35:43 +01:00
Set LOCAL_CERTIFICATE for flattened apex APKs Leaving out LOCAL_CERTIFICATE for flattened apex APKs causes the apkcerts.txt to have empty keys for those APKs, which confuses the signing tools. Set LOCAL_CERTIFICATE for them. Also refactor the Certificate support to avoid introducing duplicated handling for presigned certificates. Bug: 147765187 Test: m apkcerts-list Change-Id: Ife07661761cd5a89c9f009b8ce041db4dff9ec54
2020-01-28 23:00:53 +01:00
jacocoReportClassesFile android.Path // only for javalibs and apps
certificate java.Certificate // only for apps
bundle config contains (path,manifest) pairs of embedded APKs 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 cfaa1643e8aea1a045655274757a62f936ca235b) Change-Id: Ibb90bcefb77fa6b2dad77cb2facc6079de9ab154
2020-02-28 08:51:07 +01:00
overriddenPackageName string // only for apps
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
}
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
func newApexFile(ctx android.BaseModuleContext, builtFile android.Path, moduleName string, installDir string, class apexFileClass, module android.Module) apexFile {
ret := apexFile{
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
builtFile: builtFile,
moduleName: moduleName,
installDir: installDir,
class: class,
module: module,
}
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
if module != nil {
ret.moduleDir = ctx.OtherModuleDir(module)
APEX carries required properties of its dependencies When a module is included in an APEX and the module is not directly installed to the system partition, the 'required' property of the module is lost. The APEX containing the module now carries the property from its dependencies. Bug: 146549048 Test: m Change-Id: Ie21cc7b8420c6126c855e66c2363644de4a7ef42
2019-12-30 08:56:33 +01:00
ret.requiredModuleNames = module.RequiredModuleNames()
ret.targetRequiredModuleNames = module.TargetRequiredModuleNames()
ret.hostRequiredModuleNames = module.HostRequiredModuleNames()
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
}
return ret
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
}
func (af *apexFile) Ok() bool {
java libs that isn't installable is gracefully rejected ... rather than causing soong panic. Bug: 146197571 Test: m (apex_test amended) Change-Id: I3679a4e3041527533c1c05d54f3aa514abd6095b
2019-12-16 03:47:12 +01:00
return af.builtFile != nil && af.builtFile.String() != ""
APEX can be flattened When TARGET_FLATTEN_APEX is set to true, APEXes are flattened, which means files in an APEX is not packaged into the mini file system image, but instead directly copied to the system partition. This option is for devices where kernel does not support loopback devices or the maximum number of loopback devices is too small (though the threshold is TBD as of now). This CL also fixes a bug that jars having bytecode are installed instead of those having dex. Bug: 118485880 Test: TARGET_FLATTEN_APEX=true m apex.test; tree out/target/product/.../system/apex/apex.test shows list of files in it. Test; m apex.test, then a file out/target/product/.../system/apex/apex .test.apex exists. Change-Id: I5a3d62d392d05f2779c4925388afe4f6e460059b
2018-11-07 18:50:25 +01:00
}
Reland "use symlink for bundled APEX" This reverts commit 31c65d4fe474d26b6144c9b76365a207077a61c4. Bug: 144533348 Test: checkout master-art-host and run ALLOW_MISSING_DEPENDENCIES=true DIST_DIR=out/dist /art/tools/dist_linux_bionic.sh -j80 com.android.art.host the result is successful Change-Id: Ica11eec9b64867088b16720a41c6d83905976ec5
2020-01-14 01:22:18 +01:00
// Path() returns path of this apex file relative to the APEX root
func (af *apexFile) Path() string {
return filepath.Join(af.installDir, af.builtFile.Base())
}
// SymlinkPaths() returns paths of the symlinks (if any) relative to the APEX root
func (af *apexFile) SymlinkPaths() []string {
var ret []string
for _, symlink := range af.symlinks {
ret = append(ret, filepath.Join(af.installDir, symlink))
}
return ret
}
func (af *apexFile) AvailableToPlatform() bool {
if af.module == nil {
return false
}
if am, ok := af.module.(android.ApexModule); ok {
return am.AvailableFor(android.AvailableToPlatform)
}
return false
}
<apex_name>-deps-info correctly tracks dependencies 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
2020-02-07 09:25:49 +01:00
type depInfo struct {
to string
from []string
isExternal bool
}
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
type apexBundle struct {
android.ModuleBase
android.DefaultableModuleBase
Add override_apex module type override_apex module type is used to override existing apex module with certain properties overridden. Currently, only the 'apps' property is overridable. Bug: 144338929 Test: m Change-Id: Ic050b062093cda29ce78126cc92dd6097647f7db
2019-11-15 10:40:32 +01:00
android.OverridableModuleBase
Introduce module type 'sdk' 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
2019-07-17 13:08:41 +02:00
android.SdkBase
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
Add override_apex module type override_apex module type is used to override existing apex module with certain properties overridden. Currently, only the 'apps' property is overridable. Bug: 144338929 Test: m Change-Id: Ic050b062093cda29ce78126cc92dd6097647f7db
2019-11-15 10:40:32 +01:00
properties apexBundleProperties
targetProperties apexTargetBundleProperties
overridableProperties overridableProperties
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
Support apps attribute in apex_defaults Adding overridableProperties to apex_defaults as well. Bug: 146217017 Test: m Change-Id: I51182fec25ee589fea4006164c4dd69acc5ba67d
2019-12-16 14:32:06 +01:00
// specific to apex_vndk modules
vndkProperties apexVndkProperties
Convert apex modules to app bundle modules Convert .apex files to base.zip files suitable for bundletool. They will be copied to the dist directory when built with TARGET_BUILD_APPS and dist. Also fix up apex.go to use Build instead of the deprecated ModuleBuild, and ctx.ModuleName() instead of module.ModuleBase.Name(). Bug: 117295826 Test: tapas com.android.runtime && m dist Change-Id: I7919c8d3da280e87c624a6628a1715e8060852dc
2018-11-16 20:36:28 +01:00
bundleModuleFile android.WritablePath
Create variants for each image type Create variant of image, zip or flattened according to TARGET_FLATTEN_APEX and payload type. If payload type is zip, only zip variant is created because flattened apex is not supported. And if payload type is image, image and flattened variants are created. Bug: 139053989 Test: m -j Change-Id: Ibde18490d23ec602c4cca97cf97db90a562e014e
2019-10-22 06:58:29 +02:00
outputFile android.WritablePath
Separate InstallPath from OutputPath Create a new type InstallPath that is similar to OutputPath to differentiate intermediates output paths from installed output paths. RelPathString is a poorly defined, undocumented function that is primarily used to get an install path relative to out/soong to generate an equivalent install path for Make relative to $(OUT_DIR). Move it to InstallPath for now, and fix the one remaining user on OutputPath. Add a method to create an NDK install path so that ndk_sysroot.go doesn't have to do it manually with PathForOutput. Bug: 141877526 Test: m checkbuild Change-Id: I83c5a0bd1fd6c3dba8d3b6d20d039f64f353ddd5
2019-10-02 07:05:35 +02:00
installDir android.InstallPath
APEX can be flattened When TARGET_FLATTEN_APEX is set to true, APEXes are flattened, which means files in an APEX is not packaged into the mini file system image, but instead directly copied to the system partition. This option is for devices where kernel does not support loopback devices or the maximum number of loopback devices is too small (though the threshold is TBD as of now). This CL also fixes a bug that jars having bytecode are installed instead of those having dex. Bug: 118485880 Test: TARGET_FLATTEN_APEX=true m apex.test; tree out/target/product/.../system/apex/apex.test shows list of files in it. Test; m apex.test, then a file out/target/product/.../system/apex/apex .test.apex exists. Change-Id: I5a3d62d392d05f2779c4925388afe4f6e460059b
2018-11-07 18:50:25 +01:00
Delete prebuilt APEXes when installing source-built APEXes To build the platform for ASAN, we do `m && SANITIZE_TARGET='addresss' m` However, at the end of the second build, the system partition could have conflicting APEXes; prebuilt APEXes from the first build and source-built APEXes from the second build. Since the file names for the prebuilt and the source-built are different (e.g. com.google.android.media.apex v.s. com.android.media.apex), we end up having two files for the same APEX. This is confusing apexd at runtime and the device fails to boot. To fix this, when building a non-prebuilt APEX, the prebuilt APEX might have been installed by the previous build is deleted. Bug: 138146044 Test: lunch aosp_cf_x86_pasan; m && SANITIZE_TARGET='address' m check that out/target/product/vsoc_x86/system/apex has com.android.*.apex only. Change-Id: Ib5a021a297cf0173ea5a3b50e9398b1cf295c558
2019-07-26 16:20:40 +02:00
prebuiltFileToDelete string
Always bundle the public key for APEX The public key associated with an APEX is always included in the APEX. Obviously, the public keys are no longer installed to /system/etc/security/apex Bug: 128344735 Test: m Change-Id: I1e1aef1d32597a447b57d49ab80bbfb921fa8178
2019-04-01 04:15:50 +02:00
public_key_file android.Path
private_key_file android.Path
build apexkeys.txt apexkeys.txt is a text file having APEX-to-keys mappings. The file is included in the target-files package where it is used when re-sign the APEXes with release keys. Each line of the file consists of 5 fields: 1) name: file name of the APEX 2) public_key: the public key for the apex_payload.img of the APEX 3) private_key: the private key used to sign the apex_payload.img 4) container_certificate: the certificate used to sign the APEX zip container 5) container_private_key: the private key used to sign the APEX zip container Bug: 124406181 Test: m out/soong/apexkeys.txt and inspect the content Test: TARGET_BUILD_APPS=com.android.tzdata m dist and make sure out/dist/apexkeys.txt exists Change-Id: I1daa13ec50956323b97e15e8df7f1fbe5ea21d63
2019-02-18 07:25:04 +01:00
container_certificate_file android.Path
container_private_key_file android.Path
Make 'file_contexts' prop as `android:"path"` For platform APEXes, file_contexts should point a file under /system/sepolicy. Bug: 144732805 Test: m Change-Id: Ib2d5db715bbebc80a6178d1c42e387b268cc4a0d
2019-11-19 18:26:02 +01:00
fileContexts android.Path
APEX can be flattened When TARGET_FLATTEN_APEX is set to true, APEXes are flattened, which means files in an APEX is not packaged into the mini file system image, but instead directly copied to the system partition. This option is for devices where kernel does not support loopback devices or the maximum number of loopback devices is too small (though the threshold is TBD as of now). This CL also fixes a bug that jars having bytecode are installed instead of those having dex. Bug: 118485880 Test: TARGET_FLATTEN_APEX=true m apex.test; tree out/target/product/.../system/apex/apex.test shows list of files in it. Test; m apex.test, then a file out/target/product/.../system/apex/apex .test.apex exists. Change-Id: I5a3d62d392d05f2779c4925388afe4f6e460059b
2018-11-07 18:50:25 +01:00
// list of files to be included in this apex
filesInfo []apexFile
Reland "m <apex_name>-deps-info prints the internal/external deps of the APEX"" This reverts commit 4513f703f9902193fc5c29607ddb4a8f71bfd702. Bug: 1190898 Test: m Test: EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true NATIVE_COVERAGE=true m dist Change-Id: I50fdccabb43e4751694db83ee451d388657257e0
2020-01-09 04:32:06 +01:00
// list of module names that should be installed along with this APEX
requiredDeps []string
// list of module names that this APEX is including (to be shown via *-deps-info target)
<apex_name>-deps-info correctly tracks dependencies 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
2020-02-07 09:25:49 +01:00
depInfos map[string]depInfo
Install external deps of an APEX By default, if a lib is included in an APEX, all its direct and indirect dependencies are also included in the same APEX. However, when one of the dependencies have stable API (i.e. has stubs: {...}) then the lib having stable API and its dependencies are not included in the APEX. However, the problem here is that the lib having stable API might not be installed on the system, thus causing error at runtime. This can happen if there is no other module in the platform that depends on the lib. This change fixes the problem by adding such libraries as external dependencies so that they are also installed on the device along with the APEXes using them. Bug: 124831003 Test: m installclean; m com.android.resolv libbinder_ndk, libvndksupport are found under system/lib Change-Id: I457e03ff3fce37e0890c64d911e6e0ea6d0c6dd6
2019-02-20 13:49:26 +01:00
Create variants for each image type Create variant of image, zip or flattened according to TARGET_FLATTEN_APEX and payload type. If payload type is zip, only zip variant is created because flattened apex is not supported. And if payload type is image, image and flattened variants are created. Bug: 139053989 Test: m -j Change-Id: Ibde18490d23ec602c4cca97cf97db90a562e014e
2019-10-22 06:58:29 +02:00
testApex bool
vndkApex bool
Revert^4 "Package dexpreopt artifacts for libcore jars in the ART apex." This reverts commit bf0e47648ab6cba10e10d07693bf0c813905396c. Reason for revert: coverage build with EMMA_INSTRUMENT_FRAMEWORK=true is fixed by inspecting the environment variable and not generating boot image in case it is set. Dexpreopt artifacts for the libcore part of the boot class path are now packaged in the ART apex. The system image still contains dexpreopt artifacts for the full set of boot class path libraries (both libcore and framework); the libcore part will be removed and boot image extension will be used in a follow-up CL. Since this is specific to the ART apex and makes no sense for other apexes, the implementation adds a boolean flag "is ART apex" rather than a new apex module property. Build rules for the new set of dexpreopt artifacts are created using a new variant of the global boot image config. Previously we had two variants: "default" (for the system image) and "apex" (for the JIT-zygote experiment). This patch adds a third "art" variant. Test: m Test: m art/build/apex/runtests.sh Bug: 144091989 Change-Id: I113c0d39222d6d697cb62cd09d5010607872fc2b
2019-11-08 11:51:01 +01:00
artApex bool
Create variants for each image type Create variant of image, zip or flattened according to TARGET_FLATTEN_APEX and payload type. If payload type is zip, only zip variant is created because flattened apex is not supported. And if payload type is image, image and flattened variants are created. Bug: 139053989 Test: m -j Change-Id: Ibde18490d23ec602c4cca97cf97db90a562e014e
2019-10-22 06:58:29 +02:00
primaryApexType bool
Put dependency in apex_manifest.json To generate ld.config.txt dynamically(b/123722631), each APEX should provide some dependency information: a) list of libraries which other APEXes(or system) can use from this apex b) list of libraries which this apex uses from other APEXes(or system) This change puts dependency information in apex_manifest.json at build-time with two additional keys: a) provideNativeLibs b) requireNativeLibs Bug: 138695532 Test: m (runs soong tests) Test: find $OUT/apex -name apex_manifest.json -exec cat {} \; (shows contents of apex_manifest.json files) Change-Id: Iaad12c8c35454222ad177ce923cce76ef12a8a5a
2019-08-01 10:41:43 +02:00
Add "legacy_android10_support" to "apex" APEXes with "legacy_android10_support" will have apex_manifest.json for compatibility as well as apex_manifest.pb. Bug: 143951586 Test: m (soong tests) Change-Id: I019252aee5a9423f4b180ba1026e6e99c9961437
2019-11-12 05:03:50 +01:00
manifestJsonOut android.WritablePath
manifestPbOut android.WritablePath
add symlink for compatibility (vndk apex) With VNDK APEX, the location of VNDK lib is changed. But vndk libs of older VNDK versions still depend on old location. For current VNDK version, those hard-coded references will be fixed. TODO(b/142911355): [VNDK APEX] Fix hard-coded references to /system/lib/vndk Bug: 143192278 Bug: 142912195 Test: m com.android.vndk.current and check if /system/lib/vndk OVERRIDE_TARGET_FLATTEN_APEX m com.android.vndk.current Change-Id: I2ebacde7fcd1c7621e4509e08a76765e1dfeb059
2019-10-23 09:46:38 +02:00
Add compat symlinks for prebuilt_apex When prebuilt_apex overrides/replaces other apex, the same symlinks need to be created as well. Bug: 143192278 Test: 1. add prebuilt_apex with vndk apex with overrides set as ["com.android.vndk.current"] 2. m <prebuilt apex> 3. check if vndk symlinks are created Change-Id: I8ee9c981ea9c7202ccf5143b3f43e6848773cd63
2020-01-07 17:57:58 +01:00
// list of commands to create symlinks for backward compatibility.
add symlink for compatibility (vndk apex) With VNDK APEX, the location of VNDK lib is changed. But vndk libs of older VNDK versions still depend on old location. For current VNDK version, those hard-coded references will be fixed. TODO(b/142911355): [VNDK APEX] Fix hard-coded references to /system/lib/vndk Bug: 143192278 Bug: 142912195 Test: m com.android.vndk.current and check if /system/lib/vndk OVERRIDE_TARGET_FLATTEN_APEX m com.android.vndk.current Change-Id: I2ebacde7fcd1c7621e4509e08a76765e1dfeb059
2019-10-23 09:46:38 +02:00
// these commands will be attached as LOCAL_POST_INSTALL_CMD to
Add compat symlinks for prebuilt_apex When prebuilt_apex overrides/replaces other apex, the same symlinks need to be created as well. Bug: 143192278 Test: 1. add prebuilt_apex with vndk apex with overrides set as ["com.android.vndk.current"] 2. m <prebuilt apex> 3. check if vndk symlinks are created Change-Id: I8ee9c981ea9c7202ccf5143b3f43e6848773cd63
2020-01-07 17:57:58 +01:00
// apex package itself(for unflattened build) or apex_manifest(for flattened build)
add symlink for compatibility (vndk apex) With VNDK APEX, the location of VNDK lib is changed. But vndk libs of older VNDK versions still depend on old location. For current VNDK version, those hard-coded references will be fixed. TODO(b/142911355): [VNDK APEX] Fix hard-coded references to /system/lib/vndk Bug: 143192278 Bug: 142912195 Test: m com.android.vndk.current and check if /system/lib/vndk OVERRIDE_TARGET_FLATTEN_APEX m com.android.vndk.current Change-Id: I2ebacde7fcd1c7621e4509e08a76765e1dfeb059
2019-10-23 09:46:38 +02:00
// so that compat symlinks are always installed regardless of TARGET_FLATTEN_APEX setting.
compatSymlinks []string
Create variants for each image type Create variant of image, zip or flattened according to TARGET_FLATTEN_APEX and payload type. If payload type is zip, only zip variant is created because flattened apex is not supported. And if payload type is image, image and flattened variants are created. Bug: 139053989 Test: m -j Change-Id: Ibde18490d23ec602c4cca97cf97db90a562e014e
2019-10-22 06:58:29 +02:00
// Suffix of module name in Android.mk
// ".flattened", ".apex", ".zipapex", or ""
suffix string
List of installed files for each APEX is dist'ed For each APEX, <apexname>-installed-files.txt is dist'ed to show the list of files and their sizes that are included in the APEX. Bug: 147605944 Test: m dist and examine the txt files Change-Id: I565479523e51280fc88d5fbf8ea3f48ac0ae9fee
2020-01-14 06:39:19 +01:00
installedFilesFile android.WritablePath
Reland "use symlink for bundled APEX" This reverts commit 31c65d4fe474d26b6144c9b76365a207077a61c4. Bug: 144533348 Test: checkout master-art-host and run ALLOW_MISSING_DEPENDENCIES=true DIST_DIR=out/dist /art/tools/dist_linux_bionic.sh -j80 com.android.art.host the result is successful Change-Id: Ica11eec9b64867088b16720a41c6d83905976ec5
2020-01-14 01:22:18 +01:00
// Whether to create symlink to the system file instead of having a file
// inside the apex or not
linkToSystemLib bool
License info for APEXes are correctly gathered This change fixes a bug that license info for non-flattened APEXes are not captured in /system/etc/NOTICE.xml.gz file. For non-flatted APEXes, we have been creating NOTICE.html.gz file by concatenating all the license infos of the modules that contributes to the APEX and embedding the file into the asset directory of the APEX. Then at runtime, the info is shown through the "Google Play System Update Licenses" UI. However, this was problematic because the UI only shows license info for the Google-signed APEXes, leaving OEM-signed APEXes (a.k.a. optional modules). The problem is now fixed by associating a merged license file with each APEX and exporting them to Make, so that the merged license files are included in the partition level /system/etc/NOTICE.xml.gz file regardless of whether the APEX is a Google-signed one or not. This also fixes a bug that license info entries are created for the runtime paths /apex/<apex_name>/<path_to_a_file>, which is not necessary as they are already included in the license info of the containing APEX. Bug: N/A Test: Go to Settings->About Phone->Legal information and check that a) /system/apex/*.apex files are shown and b) /apex/<apex_name>/* files are not shown Change-Id: I2c25c803b6a4c39b24bb3f724502699382fab50c
2020-01-28 12:05:29 +01:00
// Struct holding the merged notice file paths in different formats
mergedNotices android.NoticeOutputs
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
}
binaries and native_shared_libraires are multilib-aware props The properties 'binaries' and 'native_shared_libraries' can be multilib-aware, i.e, can be under multilib.type where type can be either first, both, lib32, lib64, or prefer32. Native modules listed in multilib.first are installed only for the first ABI of the device. Similarily, multilib.both are for both of the ABIs, while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only, respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is available. Another change is that the binaries property, when not within multilib, targets only the first ABI. Test: m apex.test on ... 1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true 2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true 3) aosp_arm in all cases, vold, surfaceflinger and drmserver are all intalled under ./bin directory of the APEX. And native libraries are installed under both ./lib and ./lib64 directories in the case of 1) and 2). Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
func addDependenciesForNativeModules(ctx android.BottomUpMutatorContext,
Add support for tests in APEX test modules. Allow `tests` property in `apex_test` Soong modules. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: Ieeff7cf0980a7c394409632b6448102f59bceb3d
2019-06-26 13:48:34 +02:00
native_shared_libs []string, binaries []string, tests []string,
Add method to determine variations from a Target The arch variants are hardcoded in every module type. Refactor them out into a Target.Variations() method in preparation for splitting the arch mutator into two, which will require using different variations. Test: m checkbuild Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
2019-10-16 20:03:10 +02:00
target android.Target, imageVariation string) {
binaries and native_shared_libraires are multilib-aware props The properties 'binaries' and 'native_shared_libraries' can be multilib-aware, i.e, can be under multilib.type where type can be either first, both, lib32, lib64, or prefer32. Native modules listed in multilib.first are installed only for the first ABI of the device. Similarily, multilib.both are for both of the ABIs, while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only, respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is available. Another change is that the binaries property, when not within multilib, targets only the first ABI. Test: m apex.test on ... 1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true 2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true 3) aosp_arm in all cases, vold, surfaceflinger and drmserver are all intalled under ./bin directory of the APEX. And native libraries are installed under both ./lib and ./lib64 directories in the case of 1) and 2). Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
// Use *FarVariation* to be able to depend on modules having
// conflicting variations with this module. This is required since
// arch variant of an APEX bundle is 'common' but it is 'arm' or 'arm64'
// for native shared libs.
Add method to determine variations from a Target The arch variants are hardcoded in every module type. Refactor them out into a Target.Variations() method in preparation for splitting the arch mutator into two, which will require using different variations. Test: m checkbuild Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
2019-10-16 20:03:10 +02:00
ctx.AddFarVariationDependencies(append(target.Variations(), []blueprint.Variation{
Add use_vendor to APEX module use_vendor, when set to true, brings vendor variant of the native libraries and binaries to the APEX. Bug: 115707625 Test: m (apex_test updated) Change-Id: Ib4e996f8652f4ce4645a9c22f6914e2ab35edda6
2018-12-19 09:12:36 +01:00
{Mutator: "image", Variation: imageVariation},
binaries and native_shared_libraires are multilib-aware props The properties 'binaries' and 'native_shared_libraries' can be multilib-aware, i.e, can be under multilib.type where type can be either first, both, lib32, lib64, or prefer32. Native modules listed in multilib.first are installed only for the first ABI of the device. Similarily, multilib.both are for both of the ABIs, while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only, respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is available. Another change is that the binaries property, when not within multilib, targets only the first ABI. Test: m apex.test on ... 1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true 2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true 3) aosp_arm in all cases, vold, surfaceflinger and drmserver are all intalled under ./bin directory of the APEX. And native libraries are installed under both ./lib and ./lib64 directories in the case of 1) and 2). Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
{Mutator: "link", Variation: "shared"},
Fix: build error when a lib with stubs is included in an APEX apex { name: "foo", native_shared_libs: ["mylib"] } cc_library { name: "mylib", shared_libs: ["other_lib"], stubs: { versions: ["1"]}, } This is causing build error due to missing variant for other_lib. This is happening because the stubs variant of mylib is added to apex foo instead of the non-stubs variant. Because stubs variant does not have any further dependencies, other_lib is not included to the APEX and is not built for it. Fixing this issue by specifying the version variant when adding a lib to the dependency of an APEX, so that non-stub variant of the lib is depended on. Test: m (apex_test updated) Change-Id: I972b6dcbce11942f83a76212715ba915534ec3df
2018-12-07 14:42:47 +01:00
{Mutator: "version", Variation: ""}, // "" is the non-stub variant
Add method to determine variations from a Target The arch variants are hardcoded in every module type. Refactor them out into a Target.Variations() method in preparation for splitting the arch mutator into two, which will require using different variations. Test: m checkbuild Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
2019-10-16 20:03:10 +02:00
}...), sharedLibTag, native_shared_libs...)
binaries and native_shared_libraires are multilib-aware props The properties 'binaries' and 'native_shared_libraries' can be multilib-aware, i.e, can be under multilib.type where type can be either first, both, lib32, lib64, or prefer32. Native modules listed in multilib.first are installed only for the first ABI of the device. Similarily, multilib.both are for both of the ABIs, while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only, respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is available. Another change is that the binaries property, when not within multilib, targets only the first ABI. Test: m apex.test on ... 1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true 2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true 3) aosp_arm in all cases, vold, surfaceflinger and drmserver are all intalled under ./bin directory of the APEX. And native libraries are installed under both ./lib and ./lib64 directories in the case of 1) and 2). Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
Add method to determine variations from a Target The arch variants are hardcoded in every module type. Refactor them out into a Target.Variations() method in preparation for splitting the arch mutator into two, which will require using different variations. Test: m checkbuild Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
2019-10-16 20:03:10 +02:00
ctx.AddFarVariationDependencies(append(target.Variations(),
blueprint.Variation{Mutator: "image", Variation: imageVariation}),
executableTag, binaries...)
Add support for tests in APEX test modules. Allow `tests` property in `apex_test` Soong modules. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: Ieeff7cf0980a7c394409632b6448102f59bceb3d
2019-06-26 13:48:34 +02:00
Add method to determine variations from a Target The arch variants are hardcoded in every module type. Refactor them out into a Target.Variations() method in preparation for splitting the arch mutator into two, which will require using different variations. Test: m checkbuild Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
2019-10-16 20:03:10 +02:00
ctx.AddFarVariationDependencies(append(target.Variations(), []blueprint.Variation{
Add support for tests in APEX test modules. Allow `tests` property in `apex_test` Soong modules. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: Ieeff7cf0980a7c394409632b6448102f59bceb3d
2019-06-26 13:48:34 +02:00
{Mutator: "image", Variation: imageVariation},
Handle `test_per_src` test variations as dependencies of APEX modules. If a test module with a `test_per_src` property set to `true` is included in an APEX module, add all the variants for mutator `test_per_src` as dependencies of the APEX module (not just the first one). This is done by adding variation "" of mutator `test_per_src` when adding a test dependency to an APEX module, which creates an indirect dependency of the APEX module on all the `test_per_src` variants of the test module. When generating outputs for the APEX bundle, fetch and include the set of test outputs from the "" variant. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: I1c99855971a8a9b2fc5b964a420e882b6791d4e6
2019-06-28 16:41:19 +02:00
{Mutator: "test_per_src", Variation: ""}, // "" is the all-tests variant
Add method to determine variations from a Target The arch variants are hardcoded in every module type. Refactor them out into a Target.Variations() method in preparation for splitting the arch mutator into two, which will require using different variations. Test: m checkbuild Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
2019-10-16 20:03:10 +02:00
}...), testTag, tests...)
binaries and native_shared_libraires are multilib-aware props The properties 'binaries' and 'native_shared_libraries' can be multilib-aware, i.e, can be under multilib.type where type can be either first, both, lib32, lib64, or prefer32. Native modules listed in multilib.first are installed only for the first ABI of the device. Similarily, multilib.both are for both of the ABIs, while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only, respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is available. Another change is that the binaries property, when not within multilib, targets only the first ABI. Test: m apex.test on ... 1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true 2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true 3) aosp_arm in all cases, vold, surfaceflinger and drmserver are all intalled under ./bin directory of the APEX. And native libraries are installed under both ./lib and ./lib64 directories in the case of 1) and 2). Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
}
Add limited target-specific configuration to apex. Some apex targets need to be able to change their contents based on if they are host or target or what libc they are using. This adds support for doing this using the standard 'target: {...}' idiom. Test: m com.android.runtime.host Test: ./art/tools/build_linux_bionic.sh com.android.runtime.host Bug: 123591866 Change-Id: If73bee650cdeb277c0e603763aa0b0108656bfdd
2019-01-30 03:07:33 +01:00
func (a *apexBundle) combineProperties(ctx android.BottomUpMutatorContext) {
if ctx.Os().Class == android.Device {
proptools.AppendProperties(&a.properties.Multilib, &a.targetProperties.Target.Android.Multilib, nil)
} else {
proptools.AppendProperties(&a.properties.Multilib, &a.targetProperties.Target.Host.Multilib, nil)
if ctx.Os().Bionic() {
proptools.AppendProperties(&a.properties.Multilib, &a.targetProperties.Target.Linux_bionic.Multilib, nil)
} else {
proptools.AppendProperties(&a.properties.Multilib, &a.targetProperties.Target.Linux_glibc.Multilib, nil)
}
}
}
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
func (a *apexBundle) DepsMutator(ctx android.BottomUpMutatorContext) {
apex: Restrict usage of "use_vendor" When use_vendor is used, native modules are built with __ANDROID_VNDK__ and __ANDROID_APEX__, which may cause compatibility issues. (e.g. libbinder) Even though libbinder restricts its availability via 'apex_available' property and relies on yet another macro __ANDROID_APEX_<NAME>__, we restrict usage of "use_vendor:" from other APEX modules to avoid similar problems. Bug: 142684427 Test: m -j Change-Id: Ibc781de2efcd20cb6688a183b08e908a8a6e2593
2019-10-31 19:14:38 +01:00
if proptools.Bool(a.properties.Use_vendor) && !android.InList(a.Name(), useVendorWhitelist(ctx.Config())) {
ctx.PropertyErrorf("use_vendor", "not allowed to set use_vendor: true")
}
binaries and native_shared_libraires are multilib-aware props The properties 'binaries' and 'native_shared_libraries' can be multilib-aware, i.e, can be under multilib.type where type can be either first, both, lib32, lib64, or prefer32. Native modules listed in multilib.first are installed only for the first ABI of the device. Similarily, multilib.both are for both of the ABIs, while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only, respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is available. Another change is that the binaries property, when not within multilib, targets only the first ABI. Test: m apex.test on ... 1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true 2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true 3) aosp_arm in all cases, vold, surfaceflinger and drmserver are all intalled under ./bin directory of the APEX. And native libraries are installed under both ./lib and ./lib64 directories in the case of 1) and 2). Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
targets := ctx.MultiTargets()
Don't use vendor variant when BOARD_VNDK_VERSION is not set Vendor variants are not available when BOARD_VNDK_VERSION is not set. Test: m for aosp_marlin Change-Id: I5d89a401f5cf98db3f0a9aa553f00b2d6ee9ed1e
2019-01-05 03:15:24 +01:00
config := ctx.DeviceConfig()
Add limited target-specific configuration to apex. Some apex targets need to be able to change their contents based on if they are host or target or what libc they are using. This adds support for doing this using the standard 'target: {...}' idiom. Test: m com.android.runtime.host Test: ./art/tools/build_linux_bionic.sh com.android.runtime.host Bug: 123591866 Change-Id: If73bee650cdeb277c0e603763aa0b0108656bfdd
2019-01-30 03:07:33 +01:00
a.combineProperties(ctx)
binaries and native_shared_libraires are multilib-aware props The properties 'binaries' and 'native_shared_libraries' can be multilib-aware, i.e, can be under multilib.type where type can be either first, both, lib32, lib64, or prefer32. Native modules listed in multilib.first are installed only for the first ABI of the device. Similarily, multilib.both are for both of the ABIs, while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only, respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is available. Another change is that the binaries property, when not within multilib, targets only the first ABI. Test: m apex.test on ... 1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true 2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true 3) aosp_arm in all cases, vold, surfaceflinger and drmserver are all intalled under ./bin directory of the APEX. And native libraries are installed under both ./lib and ./lib64 directories in the case of 1) and 2). Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
has32BitTarget := false
for _, target := range targets {
if target.Arch.ArchType.Multilib == "lib32" {
has32BitTarget = true
}
}
for i, target := range targets {
// When multilib.* is omitted for native_shared_libs, it implies
// multilib.both.
Add method to determine variations from a Target The arch variants are hardcoded in every module type. Refactor them out into a Target.Variations() method in preparation for splitting the arch mutator into two, which will require using different variations. Test: m checkbuild Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
2019-10-16 20:03:10 +02:00
ctx.AddFarVariationDependencies(append(target.Variations(), []blueprint.Variation{
Don't use vendor variant when BOARD_VNDK_VERSION is not set Vendor variants are not available when BOARD_VNDK_VERSION is not set. Test: m for aosp_marlin Change-Id: I5d89a401f5cf98db3f0a9aa553f00b2d6ee9ed1e
2019-01-05 03:15:24 +01:00
{Mutator: "image", Variation: a.getImageVariation(config)},
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
{Mutator: "link", Variation: "shared"},
Add method to determine variations from a Target The arch variants are hardcoded in every module type. Refactor them out into a Target.Variations() method in preparation for splitting the arch mutator into two, which will require using different variations. Test: m checkbuild Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
2019-10-16 20:03:10 +02:00
}...), sharedLibTag, a.properties.Native_shared_libs...)
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
Add support for tests in APEX test modules. Allow `tests` property in `apex_test` Soong modules. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: Ieeff7cf0980a7c394409632b6448102f59bceb3d
2019-06-26 13:48:34 +02:00
// When multilib.* is omitted for tests, it implies
// multilib.both.
Add method to determine variations from a Target The arch variants are hardcoded in every module type. Refactor them out into a Target.Variations() method in preparation for splitting the arch mutator into two, which will require using different variations. Test: m checkbuild Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
2019-10-16 20:03:10 +02:00
ctx.AddFarVariationDependencies(append(target.Variations(), []blueprint.Variation{
Add support for tests in APEX test modules. Allow `tests` property in `apex_test` Soong modules. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: Ieeff7cf0980a7c394409632b6448102f59bceb3d
2019-06-26 13:48:34 +02:00
{Mutator: "image", Variation: a.getImageVariation(config)},
Handle `test_per_src` test variations as dependencies of APEX modules. If a test module with a `test_per_src` property set to `true` is included in an APEX module, add all the variants for mutator `test_per_src` as dependencies of the APEX module (not just the first one). This is done by adding variation "" of mutator `test_per_src` when adding a test dependency to an APEX module, which creates an indirect dependency of the APEX module on all the `test_per_src` variants of the test module. When generating outputs for the APEX bundle, fetch and include the set of test outputs from the "" variant. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: I1c99855971a8a9b2fc5b964a420e882b6791d4e6
2019-06-28 16:41:19 +02:00
{Mutator: "test_per_src", Variation: ""}, // "" is the all-tests variant
Add method to determine variations from a Target The arch variants are hardcoded in every module type. Refactor them out into a Target.Variations() method in preparation for splitting the arch mutator into two, which will require using different variations. Test: m checkbuild Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
2019-10-16 20:03:10 +02:00
}...), testTag, a.properties.Tests...)
Add support for tests in APEX test modules. Allow `tests` property in `apex_test` Soong modules. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: Ieeff7cf0980a7c394409632b6448102f59bceb3d
2019-06-26 13:48:34 +02:00
binaries and native_shared_libraires are multilib-aware props The properties 'binaries' and 'native_shared_libraries' can be multilib-aware, i.e, can be under multilib.type where type can be either first, both, lib32, lib64, or prefer32. Native modules listed in multilib.first are installed only for the first ABI of the device. Similarily, multilib.both are for both of the ABIs, while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only, respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is available. Another change is that the binaries property, when not within multilib, targets only the first ABI. Test: m apex.test on ... 1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true 2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true 3) aosp_arm in all cases, vold, surfaceflinger and drmserver are all intalled under ./bin directory of the APEX. And native libraries are installed under both ./lib and ./lib64 directories in the case of 1) and 2). Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
// Add native modules targetting both ABIs
addDependenciesForNativeModules(ctx,
a.properties.Multilib.Both.Native_shared_libs,
Add support for tests in APEX test modules. Allow `tests` property in `apex_test` Soong modules. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: Ieeff7cf0980a7c394409632b6448102f59bceb3d
2019-06-26 13:48:34 +02:00
a.properties.Multilib.Both.Binaries,
a.properties.Multilib.Both.Tests,
Add method to determine variations from a Target The arch variants are hardcoded in every module type. Refactor them out into a Target.Variations() method in preparation for splitting the arch mutator into two, which will require using different variations. Test: m checkbuild Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
2019-10-16 20:03:10 +02:00
target,
Don't use vendor variant when BOARD_VNDK_VERSION is not set Vendor variants are not available when BOARD_VNDK_VERSION is not set. Test: m for aosp_marlin Change-Id: I5d89a401f5cf98db3f0a9aa553f00b2d6ee9ed1e
2019-01-05 03:15:24 +01:00
a.getImageVariation(config))
binaries and native_shared_libraires are multilib-aware props The properties 'binaries' and 'native_shared_libraries' can be multilib-aware, i.e, can be under multilib.type where type can be either first, both, lib32, lib64, or prefer32. Native modules listed in multilib.first are installed only for the first ABI of the device. Similarily, multilib.both are for both of the ABIs, while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only, respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is available. Another change is that the binaries property, when not within multilib, targets only the first ABI. Test: m apex.test on ... 1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true 2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true 3) aosp_arm in all cases, vold, surfaceflinger and drmserver are all intalled under ./bin directory of the APEX. And native libraries are installed under both ./lib and ./lib64 directories in the case of 1) and 2). Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
Add support for symlink_preferred_arch in apex Some modules rely on symlink_preferred_arch to have expected files present. This change makes apexs include these symlinks. Test: m com.android.runtime.debug pushd $(mktemp -d) mkdir mnt unzip $OUT/apex/system/com.android.runtime.debug.apex sudo mount -o loop,ro apex_payload.img mnt Ensure that mnt/bin/dalvikvm and mnt/bin/dex2oatd both exist and are symlinks to mnt/bin/dalvikvm64 and mnt/bin/dex2oatd32 respectively. Bug: 119942078 Bug: 122373634 Bug: 123079311 Change-Id: I47868fbedc5bdd3141a836c488f79e91e0a6ddfe
2019-01-18 23:37:31 +01:00
isPrimaryAbi := i == 0
if isPrimaryAbi {
binaries and native_shared_libraires are multilib-aware props The properties 'binaries' and 'native_shared_libraries' can be multilib-aware, i.e, can be under multilib.type where type can be either first, both, lib32, lib64, or prefer32. Native modules listed in multilib.first are installed only for the first ABI of the device. Similarily, multilib.both are for both of the ABIs, while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only, respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is available. Another change is that the binaries property, when not within multilib, targets only the first ABI. Test: m apex.test on ... 1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true 2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true 3) aosp_arm in all cases, vold, surfaceflinger and drmserver are all intalled under ./bin directory of the APEX. And native libraries are installed under both ./lib and ./lib64 directories in the case of 1) and 2). Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
// When multilib.* is omitted for binaries, it implies
// multilib.first.
Add method to determine variations from a Target The arch variants are hardcoded in every module type. Refactor them out into a Target.Variations() method in preparation for splitting the arch mutator into two, which will require using different variations. Test: m checkbuild Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
2019-10-16 20:03:10 +02:00
ctx.AddFarVariationDependencies(append(target.Variations(),
blueprint.Variation{Mutator: "image", Variation: a.getImageVariation(config)}),
executableTag, a.properties.Binaries...)
binaries and native_shared_libraires are multilib-aware props The properties 'binaries' and 'native_shared_libraries' can be multilib-aware, i.e, can be under multilib.type where type can be either first, both, lib32, lib64, or prefer32. Native modules listed in multilib.first are installed only for the first ABI of the device. Similarily, multilib.both are for both of the ABIs, while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only, respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is available. Another change is that the binaries property, when not within multilib, targets only the first ABI. Test: m apex.test on ... 1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true 2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true 3) aosp_arm in all cases, vold, surfaceflinger and drmserver are all intalled under ./bin directory of the APEX. And native libraries are installed under both ./lib and ./lib64 directories in the case of 1) and 2). Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
// Add native modules targetting the first ABI
addDependenciesForNativeModules(ctx,
a.properties.Multilib.First.Native_shared_libs,
Add support for tests in APEX test modules. Allow `tests` property in `apex_test` Soong modules. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: Ieeff7cf0980a7c394409632b6448102f59bceb3d
2019-06-26 13:48:34 +02:00
a.properties.Multilib.First.Binaries,
a.properties.Multilib.First.Tests,
Add method to determine variations from a Target The arch variants are hardcoded in every module type. Refactor them out into a Target.Variations() method in preparation for splitting the arch mutator into two, which will require using different variations. Test: m checkbuild Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
2019-10-16 20:03:10 +02:00
target,
Don't use vendor variant when BOARD_VNDK_VERSION is not set Vendor variants are not available when BOARD_VNDK_VERSION is not set. Test: m for aosp_marlin Change-Id: I5d89a401f5cf98db3f0a9aa553f00b2d6ee9ed1e
2019-01-05 03:15:24 +01:00
a.getImageVariation(config))
binaries and native_shared_libraires are multilib-aware props The properties 'binaries' and 'native_shared_libraries' can be multilib-aware, i.e, can be under multilib.type where type can be either first, both, lib32, lib64, or prefer32. Native modules listed in multilib.first are installed only for the first ABI of the device. Similarily, multilib.both are for both of the ABIs, while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only, respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is available. Another change is that the binaries property, when not within multilib, targets only the first ABI. Test: m apex.test on ... 1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true 2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true 3) aosp_arm in all cases, vold, surfaceflinger and drmserver are all intalled under ./bin directory of the APEX. And native libraries are installed under both ./lib and ./lib64 directories in the case of 1) and 2). Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
}
switch target.Arch.ArchType.Multilib {
case "lib32":
// Add native modules targetting 32-bit ABI
addDependenciesForNativeModules(ctx,
a.properties.Multilib.Lib32.Native_shared_libs,
Add support for tests in APEX test modules. Allow `tests` property in `apex_test` Soong modules. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: Ieeff7cf0980a7c394409632b6448102f59bceb3d
2019-06-26 13:48:34 +02:00
a.properties.Multilib.Lib32.Binaries,
a.properties.Multilib.Lib32.Tests,
Add method to determine variations from a Target The arch variants are hardcoded in every module type. Refactor them out into a Target.Variations() method in preparation for splitting the arch mutator into two, which will require using different variations. Test: m checkbuild Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
2019-10-16 20:03:10 +02:00
target,
Don't use vendor variant when BOARD_VNDK_VERSION is not set Vendor variants are not available when BOARD_VNDK_VERSION is not set. Test: m for aosp_marlin Change-Id: I5d89a401f5cf98db3f0a9aa553f00b2d6ee9ed1e
2019-01-05 03:15:24 +01:00
a.getImageVariation(config))
binaries and native_shared_libraires are multilib-aware props The properties 'binaries' and 'native_shared_libraries' can be multilib-aware, i.e, can be under multilib.type where type can be either first, both, lib32, lib64, or prefer32. Native modules listed in multilib.first are installed only for the first ABI of the device. Similarily, multilib.both are for both of the ABIs, while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only, respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is available. Another change is that the binaries property, when not within multilib, targets only the first ABI. Test: m apex.test on ... 1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true 2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true 3) aosp_arm in all cases, vold, surfaceflinger and drmserver are all intalled under ./bin directory of the APEX. And native libraries are installed under both ./lib and ./lib64 directories in the case of 1) and 2). Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
addDependenciesForNativeModules(ctx,
a.properties.Multilib.Prefer32.Native_shared_libs,
Add support for tests in APEX test modules. Allow `tests` property in `apex_test` Soong modules. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: Ieeff7cf0980a7c394409632b6448102f59bceb3d
2019-06-26 13:48:34 +02:00
a.properties.Multilib.Prefer32.Binaries,
a.properties.Multilib.Prefer32.Tests,
Add method to determine variations from a Target The arch variants are hardcoded in every module type. Refactor them out into a Target.Variations() method in preparation for splitting the arch mutator into two, which will require using different variations. Test: m checkbuild Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
2019-10-16 20:03:10 +02:00
target,
Don't use vendor variant when BOARD_VNDK_VERSION is not set Vendor variants are not available when BOARD_VNDK_VERSION is not set. Test: m for aosp_marlin Change-Id: I5d89a401f5cf98db3f0a9aa553f00b2d6ee9ed1e
2019-01-05 03:15:24 +01:00
a.getImageVariation(config))
binaries and native_shared_libraires are multilib-aware props The properties 'binaries' and 'native_shared_libraries' can be multilib-aware, i.e, can be under multilib.type where type can be either first, both, lib32, lib64, or prefer32. Native modules listed in multilib.first are installed only for the first ABI of the device. Similarily, multilib.both are for both of the ABIs, while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only, respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is available. Another change is that the binaries property, when not within multilib, targets only the first ABI. Test: m apex.test on ... 1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true 2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true 3) aosp_arm in all cases, vold, surfaceflinger and drmserver are all intalled under ./bin directory of the APEX. And native libraries are installed under both ./lib and ./lib64 directories in the case of 1) and 2). Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
case "lib64":
// Add native modules targetting 64-bit ABI
addDependenciesForNativeModules(ctx,
a.properties.Multilib.Lib64.Native_shared_libs,
Add support for tests in APEX test modules. Allow `tests` property in `apex_test` Soong modules. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: Ieeff7cf0980a7c394409632b6448102f59bceb3d
2019-06-26 13:48:34 +02:00
a.properties.Multilib.Lib64.Binaries,
a.properties.Multilib.Lib64.Tests,
Add method to determine variations from a Target The arch variants are hardcoded in every module type. Refactor them out into a Target.Variations() method in preparation for splitting the arch mutator into two, which will require using different variations. Test: m checkbuild Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
2019-10-16 20:03:10 +02:00
target,
Don't use vendor variant when BOARD_VNDK_VERSION is not set Vendor variants are not available when BOARD_VNDK_VERSION is not set. Test: m for aosp_marlin Change-Id: I5d89a401f5cf98db3f0a9aa553f00b2d6ee9ed1e
2019-01-05 03:15:24 +01:00
a.getImageVariation(config))
binaries and native_shared_libraires are multilib-aware props The properties 'binaries' and 'native_shared_libraries' can be multilib-aware, i.e, can be under multilib.type where type can be either first, both, lib32, lib64, or prefer32. Native modules listed in multilib.first are installed only for the first ABI of the device. Similarily, multilib.both are for both of the ABIs, while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only, respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is available. Another change is that the binaries property, when not within multilib, targets only the first ABI. Test: m apex.test on ... 1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true 2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true 3) aosp_arm in all cases, vold, surfaceflinger and drmserver are all intalled under ./bin directory of the APEX. And native libraries are installed under both ./lib and ./lib64 directories in the case of 1) and 2). Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
if !has32BitTarget {
addDependenciesForNativeModules(ctx,
a.properties.Multilib.Prefer32.Native_shared_libs,
Add support for tests in APEX test modules. Allow `tests` property in `apex_test` Soong modules. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: Ieeff7cf0980a7c394409632b6448102f59bceb3d
2019-06-26 13:48:34 +02:00
a.properties.Multilib.Prefer32.Binaries,
a.properties.Multilib.Prefer32.Tests,
Add method to determine variations from a Target The arch variants are hardcoded in every module type. Refactor them out into a Target.Variations() method in preparation for splitting the arch mutator into two, which will require using different variations. Test: m checkbuild Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
2019-10-16 20:03:10 +02:00
target,
Don't use vendor variant when BOARD_VNDK_VERSION is not set Vendor variants are not available when BOARD_VNDK_VERSION is not set. Test: m for aosp_marlin Change-Id: I5d89a401f5cf98db3f0a9aa553f00b2d6ee9ed1e
2019-01-05 03:15:24 +01:00
a.getImageVariation(config))
binaries and native_shared_libraires are multilib-aware props The properties 'binaries' and 'native_shared_libraries' can be multilib-aware, i.e, can be under multilib.type where type can be either first, both, lib32, lib64, or prefer32. Native modules listed in multilib.first are installed only for the first ABI of the device. Similarily, multilib.both are for both of the ABIs, while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only, respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is available. Another change is that the binaries property, when not within multilib, targets only the first ABI. Test: m apex.test on ... 1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true 2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true 3) aosp_arm in all cases, vold, surfaceflinger and drmserver are all intalled under ./bin directory of the APEX. And native libraries are installed under both ./lib and ./lib64 directories in the case of 1) and 2). Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
}
Teach soong not to duplicate the HWASAN runtime into each APEX. When HWASAN is enabled, the runtime is conceptually part of Bionic (and mutually depends on it), so it needs to be treated in the same way as the Bionic libs. Now there are only two copies of the runtime: the one in /system/lib64/bootstrap (which won't be used by ordinary processes) and the one in the runtime APEX. This reduces the size of the HWASAN system image and fixes an issue where multiple copies of the HWASAN runtime were being loaded into 64-bit binaries in APEXes because the linker namespace for the binary is different from the one for its dependent libraries outside of APEXes. HWASAN only supports loading one copy of the runtime per process, so this was causing such binaries to crash on startup. Change-Id: I228896e193a035e6dfba9f6e28d0b2e12fc163ea
2019-04-24 23:41:12 +02:00
if strings.HasPrefix(ctx.ModuleName(), "com.android.runtime") && target.Os.Class == android.Device {
for _, sanitizer := range ctx.Config().SanitizeDevice() {
if sanitizer == "hwaddress" {
addDependenciesForNativeModules(ctx,
[]string{"libclang_rt.hwasan-aarch64-android"},
Add method to determine variations from a Target The arch variants are hardcoded in every module type. Refactor them out into a Target.Variations() method in preparation for splitting the arch mutator into two, which will require using different variations. Test: m checkbuild Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
2019-10-16 20:03:10 +02:00
nil, nil, target, a.getImageVariation(config))
Teach soong not to duplicate the HWASAN runtime into each APEX. When HWASAN is enabled, the runtime is conceptually part of Bionic (and mutually depends on it), so it needs to be treated in the same way as the Bionic libs. Now there are only two copies of the runtime: the one in /system/lib64/bootstrap (which won't be used by ordinary processes) and the one in the runtime APEX. This reduces the size of the HWASAN system image and fixes an issue where multiple copies of the HWASAN runtime were being loaded into 64-bit binaries in APEXes because the linker namespace for the binary is different from the one for its dependent libraries outside of APEXes. HWASAN only supports loading one copy of the runtime per process, so this was causing such binaries to crash on startup. Change-Id: I228896e193a035e6dfba9f6e28d0b2e12fc163ea
2019-04-24 23:41:12 +02:00
break
}
}
}
binaries and native_shared_libraires are multilib-aware props The properties 'binaries' and 'native_shared_libraries' can be multilib-aware, i.e, can be under multilib.type where type can be either first, both, lib32, lib64, or prefer32. Native modules listed in multilib.first are installed only for the first ABI of the device. Similarily, multilib.both are for both of the ABIs, while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only, respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is available. Another change is that the binaries property, when not within multilib, targets only the first ABI. Test: m apex.test on ... 1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true 2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true 3) aosp_arm in all cases, vold, surfaceflinger and drmserver are all intalled under ./bin directory of the APEX. And native libraries are installed under both ./lib and ./lib64 directories in the case of 1) and 2). Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
}
APEX can be signed with different keys A new module type 'apex_key' is defined to specify public and private key pair for APEXs. An APEX can refer to the module via the property 'key'. When building the APEX, the private key from the key module is used to sign it. In addition, the public key from the key module is automatically installed to /system/etc/security/apex. Bug: 115721587 Test: m apex.test; m /apex/com.android.example.apex@1 exists Change-Id: I82666db095bd7a09f6c1b9cbea2db57ebc076cbf
2018-10-12 14:49:38 +02:00
}
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
apex uses the first arch variant of prebuilt_etc modules prebult_etc module type does not respect prefer32, i.e. its primary arch is 64-bit on 64/32-bit device even when built with TARGET_PREFER_32_BIT is true. However, the apex module type respects prefer32 and therefore when TARGET_PREFER_32_BIT is true its primary arch becomes 32-bit. Then the problem is that the apex tries to depend on 32-bit variant of the prebuilt_etc modules which don't exist. Fixing the problem by force using the first arch of the device when adding dependencies to prebuilt_etc modules. Bug: 144532908 Test: choosecombo 1 aosp_arm64 userdebug; TARGET_PREFER_32_BIT=true m; Change-Id: I7642c57b05a837495587bbe4d3589d8549607862
2019-11-20 05:58:28 +01:00
// For prebuilt_etc, use the first variant (64 on 64/32bit device,
// 32 on 32bit device) regardless of the TARGET_PREFER_* setting.
// b/144532908
archForPrebuiltEtc := config.Arches()[0]
for _, arch := range config.Arches() {
// Prefer 64-bit arch if there is any
if arch.ArchType.Multilib == "lib64" {
archForPrebuiltEtc = arch
break
}
}
ctx.AddFarVariationDependencies([]blueprint.Variation{
{Mutator: "os", Variation: ctx.Os().String()},
{Mutator: "arch", Variation: archForPrebuiltEtc.String()},
}, prebuiltTag, a.properties.Prebuilts...)
Add method to determine variations from a Target The arch variants are hardcoded in every module type. Refactor them out into a Target.Variations() method in preparation for splitting the arch mutator into two, which will require using different variations. Test: m checkbuild Change-Id: I28ef7cd5168095ac888fe77f04e27f9ad81978c0
2019-10-16 20:03:10 +02:00
ctx.AddFarVariationDependencies(ctx.Config().AndroidCommonTarget.Variations(),
javaLibTag, a.properties.Java_libs...)
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
Include jacoco in the ART boot image if EMMA_INSTRUMENT_FRAMEWORK=true. Test: aosp_walleye-userdebug boots. Test: Coverage build boots: $ lunch aosp_walleye-userdebug $ cd $ANDROID_BUILD_TOP $ build/soong/soong_ui.bash --make-mode droid \ SKIP_ABI_CHECKS=true \ TARGET_PRODUCT=aosp_walleye \ TARGET_BUILD_VARIANT=userdebug \ EMMA_INSTRUMENT=true \ NATIVE_COVERAGE=true $ adb reboot bootloader && fastboot flashall -w Test: Coverage build with framework coverage boots: $ lunch aosp_walleye-userdebug $ cd $ANDROID_BUILD_TOP $ build/soong/soong_ui.bash --make-mode droid \ SKIP_ABI_CHECKS=true \ TARGET_PRODUCT=aosp_walleye \ TARGET_BUILD_VARIANT=userdebug \ EMMA_INSTRUMENT=true \ EMMA_INSTRUMENT_FRAMEWORK=true \ NATIVE_COVERAGE=true $ adb reboot bootloader && fastboot flashall -w Test: Static coverage build with framework coverage boots: $ lunch aosp_walleye-userdebug $ cd $ANDROID_BUILD_TOP $ build/soong/soong_ui.bash --make-mode droid \ SKIP_ABI_CHECKS=true \ TARGET_PRODUCT=aosp_walleye \ TARGET_BUILD_VARIANT=userdebug \ EMMA_INSTRUMENT=true \ EMMA_INSTRUMENT_FRAMEWORK=true \ EMMA_INSTRUMENT_STATIC=true \ NATIVE_COVERAGE=true $ adb reboot bootloader && fastboot flashall -w Change-Id: Iaa198b8505aaff36e6685559642ff721637ce55f
2020-01-03 14:25:54 +01:00
// With EMMA_INSTRUMENT_FRAMEWORK=true the ART boot image includes jacoco library.
if a.artApex && ctx.Config().IsEnvTrue("EMMA_INSTRUMENT_FRAMEWORK") {
ctx.AddFarVariationDependencies(ctx.Config().AndroidCommonTarget.Variations(),
javaLibTag, "jacocoagent")
}
:module syntax is supported for APEX even when TARGET_FLATTEN_APEX Build rules for both flattened and non-flattend APEXes are created regardless of TARGET_FLATTEN_APEX. The selection is made in AndroidMk. This allows other module to reference an APEX via :module syntax irrespective of TARGET_FLATTEN_APEX. Bug: 123780484 Test: TARGET_FLATTEN_APEX=true m out/soong/.intermediates/art/build/apex/art-check-debug-apex-gen/gen/art-check-debug-apex-gen.dummy with aosp/891696 applied Change-Id: Ia49415ec3d18cfc5081461be76900c73ea803dca
2019-02-02 05:13:47 +01:00
if String(a.properties.Key) == "" {
ctx.ModuleErrorf("key is missing")
return
}
ctx.AddDependency(ctx.Module(), keyTag, String(a.properties.Key))
APEXs are signed with apk signer The entire APEX (which is a zip file) is signed with the apk signer. Certificate can be specified via the 'certificate' property just like ordinary apps. Note: multiple additional certificates are not supported. Bug: 115721587 Test: m apex.test Test: jarsigner -verify -verbose -certs .../apex.test.apex shows the certificate info Change-Id: Ia4c898d3427779a3809fdc683b85d7661ca65137
2018-10-30 13:20:05 +01:00
APEX certificates can be overriden by PRODUCT_CERTIFICATE_OVERRIDES Test: m (apex_test amended) Change-Id: I9b66a250c9ca20ad754e12455de2b444cf19b1fa
2019-02-11 03:38:15 +01:00
cert := android.SrcIsModule(a.getCertString(ctx))
:module syntax is supported for APEX even when TARGET_FLATTEN_APEX Build rules for both flattened and non-flattend APEXes are created regardless of TARGET_FLATTEN_APEX. The selection is made in AndroidMk. This allows other module to reference an APEX via :module syntax irrespective of TARGET_FLATTEN_APEX. Bug: 123780484 Test: TARGET_FLATTEN_APEX=true m out/soong/.intermediates/art/build/apex/art-check-debug-apex-gen/gen/art-check-debug-apex-gen.dummy with aosp/891696 applied Change-Id: Ia49415ec3d18cfc5081461be76900c73ea803dca
2019-02-02 05:13:47 +01:00
if cert != "" {
ctx.AddDependency(ctx.Module(), certificateTag, cert)
APEXs are signed with apk signer The entire APEX (which is a zip file) is signed with the apk signer. Certificate can be specified via the 'certificate' property just like ordinary apps. Note: multiple additional certificates are not supported. Bug: 115721587 Test: m apex.test Test: jarsigner -verify -verbose -certs .../apex.test.apex shows the certificate info Change-Id: Ia4c898d3427779a3809fdc683b85d7661ca65137
2018-10-30 13:20:05 +01:00
}
Introduce module type 'sdk' 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
2019-07-17 13:08:41 +02:00
// TODO(jiyong): ensure that all apexes are with non-empty uses_sdks
if len(a.properties.Uses_sdks) > 0 {
sdkRefs := []android.SdkRef{}
for _, str := range a.properties.Uses_sdks {
parsed := android.ParseSdkRef(ctx, str, "uses_sdks")
sdkRefs = append(sdkRefs, parsed)
}
a.BuildWithSdks(sdkRefs)
}
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
}
Add override_apex module type override_apex module type is used to override existing apex module with certain properties overridden. Currently, only the 'apps' property is overridable. Bug: 144338929 Test: m Change-Id: Ic050b062093cda29ce78126cc92dd6097647f7db
2019-11-15 10:40:32 +01:00
func (a *apexBundle) OverridablePropertiesDepsMutator(ctx android.BottomUpMutatorContext) {
ctx.AddFarVariationDependencies(ctx.Config().AndroidCommonTarget.Variations(),
androidAppTag, a.overridableProperties.Apps...)
}
Prohibit dependencies outside of uses_sdks When an APEX is built with uses_sdks, any depedndency from the APEX to the outside of the APEX should be from the SDKs that the APEX is built against. Bug: 138182343 Test: m Change-Id: I1c2ffe8d28ccf648d928ea59652c2d0070bf10eb
2019-10-15 08:20:07 +02:00
func (a *apexBundle) DepIsInSameApex(ctx android.BaseModuleContext, dep android.Module) bool {
// direct deps of an APEX bundle are all part of the APEX bundle
return true
}
Consolidate baseContext, BaseContext, and BaseModuleContext blueprint.BaseModuleContext is the set of methods available to all module-specific calls (GenerateBuildActions or mutators). The android package split the same functionality across baseContext (nee androidBaseContext), BaseModuleContext, and BaseContext. Consolidate all of them into android.BaseModuleContext. Test: m checkbuild Change-Id: I2d7f5c56fd4424032cb93edff6dc730ff33e4f1e
2019-06-06 23:33:29 +02:00
func (a *apexBundle) getCertString(ctx android.BaseModuleContext) string {
Override package name for VNDK APEX com.android.vndk.v<VER> is overridden with com.google.android.vndk.v<VERE>. Test: m com.android.vndk.current && aapt2 dump badging ../system/apex/com.android.vndk.current.apex Change-Id: I623d7a144418d7198f0bbf09c5dc983ed1a631c6 Merged-In: I623d7a144418d7198f0bbf09c5dc983ed1a631c6 (cherry picked from commit 0ed1b1b1695b0f8ad75bd2493aef9f2801407f1c)
2019-12-16 09:45:32 +01:00
moduleName := ctx.ModuleName()
// VNDK APEXes share the same certificate. To avoid adding a new VNDK version to the OVERRIDE_* list,
// we check with the pseudo module name to see if its certificate is overridden.
if a.vndkApex {
moduleName = vndkApexName
}
certificate, overridden := ctx.DeviceConfig().OverrideCertificateFor(moduleName)
APEX certificates can be overriden by PRODUCT_CERTIFICATE_OVERRIDES Test: m (apex_test amended) Change-Id: I9b66a250c9ca20ad754e12455de2b444cf19b1fa
2019-02-11 03:38:15 +01:00
if overridden {
Revert "Add override_module." This reverts commit aa65e17016152d0d73cd10ab3987bc3bd5c2ef91. Reason for revert: Not compatible with PRODUCT_PACKAGES, and so has very limited use. Change-Id: Ib141d3984a6f12bb50989e66037494c466b066f1
2019-02-28 17:22:30 +01:00
return ":" + certificate
APEX certificates can be overriden by PRODUCT_CERTIFICATE_OVERRIDES Test: m (apex_test amended) Change-Id: I9b66a250c9ca20ad754e12455de2b444cf19b1fa
2019-02-11 03:38:15 +01:00
}
return String(a.properties.Certificate)
}
Support tagged module references There are cases where a module needs to refer to an intermediate output of another module instead of its final output. For example, a module may want to use the .jar containing .class files from another module whose final output is a .jar containing classes.dex files. Support a new ":module{.tag}" format in any property that is annotated with `android:"path"`, which will query the target module for its ".tag" output(s). Test: path_properties_test.go, paths_test.go Test: no unexpected changes in build.ninja Change-Id: Icd3c9b0d83ff125771767c04046fcffb9fc3f65a
2019-05-29 23:40:35 +02:00
func (a *apexBundle) OutputFiles(tag string) (android.Paths, error) {
switch tag {
case "":
Create variants for each image type Create variant of image, zip or flattened according to TARGET_FLATTEN_APEX and payload type. If payload type is zip, only zip variant is created because flattened apex is not supported. And if payload type is image, image and flattened variants are created. Bug: 139053989 Test: m -j Change-Id: Ibde18490d23ec602c4cca97cf97db90a562e014e
2019-10-22 06:58:29 +02:00
return android.Paths{a.outputFile}, nil
Support tagged module references There are cases where a module needs to refer to an intermediate output of another module instead of its final output. For example, a module may want to use the .jar containing .class files from another module whose final output is a .jar containing classes.dex files. Support a new ":module{.tag}" format in any property that is annotated with `android:"path"`, which will query the target module for its ".tag" output(s). Test: path_properties_test.go, paths_test.go Test: no unexpected changes in build.ninja Change-Id: Icd3c9b0d83ff125771767c04046fcffb9fc3f65a
2019-05-29 23:40:35 +02:00
default:
return nil, fmt.Errorf("unsupported module reference tag %q", tag)
Fix a nill pointer dereference when TARGET_FLATTEN_APEX When TARGET_FLATTEN_APEX is set to true, there is no single output file for an APEX that other modules can reference via ":module" syntax. Return nothing in that case. Bug: 121221006 Test: TARGET_FLATTEN_APEX=true m Change-Id: I556b55073720b16fd30fd133af58aac229e958c0
2018-12-20 01:54:35 +01:00
}
Output of an apex module type can be included in tests By implementing SourceFileProducer interface, output of an apex module can be included in tests (via ':modulename' syntax in 'data' property) Bug: 120055902 Test: replace apexd_testdata/* with :apex.test in system/apex/apexd/Android.bp. m apex_file_test. out/host/linux-x86/nativetest/apex_file_test/ has apex.test.apex in it. Change-Id: I8b721a68e0edc65a3e674febeed485e06b96bc24
2018-11-27 13:27:08 +01:00
}
Add installable property to apex module type When set to false, the apex is built but not installed. Useful for not polluting the system image with test APEXes when doing mma. Bug: 120960303 Test: add 'installable: false' to apex.test under system/apex/tests/Android.bp m; check that out/..../system/apex/apex.test.apex does not exist. Change-Id: I383d5cdcc8aec705b6a5778dbd07233471d289d0
2018-12-13 15:14:57 +01:00
func (a *apexBundle) installable() bool {
Build native coverage variant of APEXes when needed When the native coverage is enabled, APEXes (and files there) are built for native coverage as well. Bug: 138952487 Test: make -j NATIVE_COVERAGE=true COVERAGE_PATHS='*' com.android.resolv find out -name "*.gcno" | grep DnsResolver shows files Test: libnetd_resolv.zip is found under $(TARGET_OUT)/apex/com.android.resolv/lib directory Change-Id: I97bcee9bf8ffc0dc71453abbdb613ed56ea2cdb4
2019-08-09 07:44:36 +02:00
return !a.properties.PreventInstall && (a.properties.Installable == nil || proptools.Bool(a.properties.Installable))
Add installable property to apex module type When set to false, the apex is built but not installed. Useful for not polluting the system image with test APEXes when doing mma. Bug: 120960303 Test: add 'installable: false' to apex.test under system/apex/tests/Android.bp m; check that out/..../system/apex/apex.test.apex does not exist. Change-Id: I383d5cdcc8aec705b6a5778dbd07233471d289d0
2018-12-13 15:14:57 +01:00
}
Add property to apex soong modules to generate an APEX without hashtree This will help testing on-device hashtree generation. Test: see other CL in topic Bug: 145670581 Change-Id: I96b1b2392302aed8a6e80ed52de2d057a532a288
2019-12-07 18:30:22 +01:00
func (a *apexBundle) testOnlyShouldSkipHashtreeGeneration() bool {
return proptools.Bool(a.properties.Test_only_no_hashtree)
}
Don't use vendor variant when BOARD_VNDK_VERSION is not set Vendor variants are not available when BOARD_VNDK_VERSION is not set. Test: m for aosp_marlin Change-Id: I5d89a401f5cf98db3f0a9aa553f00b2d6ee9ed1e
2019-01-05 03:15:24 +01:00
func (a *apexBundle) getImageVariation(config android.DeviceConfig) string {
Revert "Revert "Supports VNDK APEX with different versions"" This reverts commit 48dd4b5ea480319da29359a668191d52e9d8c9c2. Bug: 141451661 Bug: 139772411 Test: m (soong tests) Test: boot with aosp_arm64 system image on Q vendor device
2019-10-18 09:26:59 +02:00
if a.vndkApex {
Move cc.imageMutator into the android package Prepare for making the image mutator available to all modules and moving it between the os and arch mutators by moving it into the android package and using an interface implemented by the module types to control it. Bug: 142286466 Test: No unexpected changes to out/soong/build.ninja Change-Id: I0dcc9c7b5ec80edffade340c367f6ae4da34151b
2019-11-19 01:00:16 +01:00
return cc.VendorVariationPrefix + a.vndkVersion(config)
Revert "Revert "Supports VNDK APEX with different versions"" This reverts commit 48dd4b5ea480319da29359a668191d52e9d8c9c2. Bug: 141451661 Bug: 139772411 Test: m (soong tests) Test: boot with aosp_arm64 system image on Q vendor device
2019-10-18 09:26:59 +02:00
}
Don't use vendor variant when BOARD_VNDK_VERSION is not set Vendor variants are not available when BOARD_VNDK_VERSION is not set. Test: m for aosp_marlin Change-Id: I5d89a401f5cf98db3f0a9aa553f00b2d6ee9ed1e
2019-01-05 03:15:24 +01:00
if config.VndkVersion() != "" && proptools.Bool(a.properties.Use_vendor) {
Move cc.imageMutator into the android package Prepare for making the image mutator available to all modules and moving it between the os and arch mutators by moving it into the android package and using an interface implemented by the module types to control it. Bug: 142286466 Test: No unexpected changes to out/soong/build.ninja Change-Id: I0dcc9c7b5ec80edffade340c367f6ae4da34151b
2019-11-19 01:00:16 +01:00
return cc.VendorVariationPrefix + config.PlatformVndkVersion()
Add use_vendor to APEX module use_vendor, when set to true, brings vendor variant of the native libraries and binaries to the APEX. Bug: 115707625 Test: m (apex_test updated) Change-Id: Ib4e996f8652f4ce4645a9c22f6914e2ab35edda6
2018-12-19 09:12:36 +01:00
} else {
Move cc.imageMutator into the android package Prepare for making the image mutator available to all modules and moving it between the os and arch mutators by moving it into the android package and using an interface implemented by the module types to control it. Bug: 142286466 Test: No unexpected changes to out/soong/build.ninja Change-Id: I0dcc9c7b5ec80edffade340c367f6ae4da34151b
2019-11-19 01:00:16 +01:00
return android.CoreVariation
Add use_vendor to APEX module use_vendor, when set to true, brings vendor variant of the native libraries and binaries to the APEX. Bug: 115707625 Test: m (apex_test updated) Change-Id: Ib4e996f8652f4ce4645a9c22f6914e2ab35edda6
2018-12-19 09:12:36 +01:00
}
}
Remove prefer_sanitize.* properties The properties are no longer required as an APEX module is mutated with required sanitizers which are gathered by scanning the sanitizers that are enabled for its direct dependencies. Bug: 124128094 Test: m on marlin The extractor libs are found under /system/apex/com.android.media Merged-In: I55961d400dcbac067a5c0dcecb90e399d4991a70 Change-Id: I55961d400dcbac067a5c0dcecb90e399d4991a70 (cherry picked from commit abda0eb76b8aa9aac3220e4f60391210fbcb5b53)
2019-02-13 12:28:58 +01:00
func (a *apexBundle) EnableSanitizer(sanitizerName string) {
if !android.InList(sanitizerName, a.properties.SanitizerNames) {
a.properties.SanitizerNames = append(a.properties.SanitizerNames, sanitizerName)
}
}
Create sanitizer variants of APEX only when SANITIZE_TARGET is set This fixes a problem that APEX is unconditionally mutated for all sanitizer types. This can make an APEX to include sanitized version of a lib even when SANITIZE_TARGET is not set. It can happen when lib X is directly depended on by an APEX (e.g. via native_shared_libs) and X has a sanitized variant due to the dependency from another library Y which is force sanitized (via 'sanitize' property). In that case, regardless of lib Y is in the APEX or not, the APEX chooses the sanitized variant of lib X since the dependency from APEX to the lib is created with AddFarVariationDependency. Fixing this problem by mutating the APEX for a sanitizer type only when the device is requested to be sanitized. Bug: 122717287 Test: add libnetd_client to com.android.runtime APEX. Inspect build.ninja to verify that libnetd_client.so in the runtime APEX is not a sanitized one. Change-Id: I918bc8407137d74c5456142b3a29de13df68c0b3
2019-01-28 11:47:32 +01:00
func (a *apexBundle) IsSanitizerEnabled(ctx android.BaseModuleContext, sanitizerName string) bool {
Remove prefer_sanitize.* properties The properties are no longer required as an APEX module is mutated with required sanitizers which are gathered by scanning the sanitizers that are enabled for its direct dependencies. Bug: 124128094 Test: m on marlin The extractor libs are found under /system/apex/com.android.media Merged-In: I55961d400dcbac067a5c0dcecb90e399d4991a70 Change-Id: I55961d400dcbac067a5c0dcecb90e399d4991a70 (cherry picked from commit abda0eb76b8aa9aac3220e4f60391210fbcb5b53)
2019-02-13 12:28:58 +01:00
if android.InList(sanitizerName, a.properties.SanitizerNames) {
return true
Add prefer_sanitize.* properties to apex It is used to configure an apex to prefere specific sanitizer variants if available. For example, if a lib is with sanitize: {cfi: true} then an APEX with prefer_sanitize: {cfi: true} will use the sanitized variant of the lib. Bug: 124128094 Test: m on marlin extractor libraries are found under /system/apex/com.android.media Change-Id: I858778eef78c5791cdeb497c7c11688cb128b5fe
2019-02-09 03:50:56 +01:00
}
// Then follow the global setting
Create sanitizer variants of APEX only when SANITIZE_TARGET is set This fixes a problem that APEX is unconditionally mutated for all sanitizer types. This can make an APEX to include sanitized version of a lib even when SANITIZE_TARGET is not set. It can happen when lib X is directly depended on by an APEX (e.g. via native_shared_libs) and X has a sanitized variant due to the dependency from another library Y which is force sanitized (via 'sanitize' property). In that case, regardless of lib Y is in the APEX or not, the APEX chooses the sanitized variant of lib X since the dependency from APEX to the lib is created with AddFarVariationDependency. Fixing this problem by mutating the APEX for a sanitizer type only when the device is requested to be sanitized. Bug: 122717287 Test: add libnetd_client to com.android.runtime APEX. Inspect build.ninja to verify that libnetd_client.so in the runtime APEX is not a sanitized one. Change-Id: I918bc8407137d74c5456142b3a29de13df68c0b3
2019-01-28 11:47:32 +01:00
globalSanitizerNames := []string{}
if a.Host() {
globalSanitizerNames = ctx.Config().SanitizeHost()
} else {
arches := ctx.Config().SanitizeDeviceArch()
if len(arches) == 0 || android.InList(a.Arch().ArchType.Name, arches) {
globalSanitizerNames = ctx.Config().SanitizeDevice()
}
}
return android.InList(sanitizerName, globalSanitizerNames)
APEXes can be sanitized This change first introduces the interface "Sanitizeable" that module types other than cc.Module can use to be handled by the sanitizer mutator. APEX module, by implementing the interface, gets sanitizer variants. In doing so, sanitizer.go is refactored so that modules have explicit dependencies to the runtime sanitizer libraries. This allows the runtime library to be packaged into the APEX when required. This also completes the dependency graph; updating the prebuilt sanitizer runtime will trigger rebuilding of modules using the runtime. Bug: 120894259 Bug: 121038155 Test: SANITIZE_TARGET=hwaddress m apex.test Test: TARGET_FLATTEN_APEX=true SANITIZE_TARGET=address m Change-Id: Ia91576ff48cda3c996350308b75bf83fcf7c23d7
2018-12-18 18:47:14 +01:00
}
Build native coverage variant of APEXes when needed When the native coverage is enabled, APEXes (and files there) are built for native coverage as well. Bug: 138952487 Test: make -j NATIVE_COVERAGE=true COVERAGE_PATHS='*' com.android.resolv find out -name "*.gcno" | grep DnsResolver shows files Test: libnetd_resolv.zip is found under $(TARGET_OUT)/apex/com.android.resolv/lib directory Change-Id: I97bcee9bf8ffc0dc71453abbdb613ed56ea2cdb4
2019-08-09 07:44:36 +02:00
func (a *apexBundle) IsNativeCoverageNeeded(ctx android.BaseModuleContext) bool {
Add coverage flags for Clang coverage builds. Bug: 143977934 Test: m CLANG_COVERAGE=true Test: m NATIVE_COVERAGE=true Change-Id: I5d07d336e241856961eb0bc9678fdc9d5a076802
2019-12-07 00:22:41 +01:00
return ctx.Device() && (ctx.DeviceConfig().NativeCoverageEnabled() || ctx.DeviceConfig().ClangCoverageEnabled())
Build native coverage variant of APEXes when needed When the native coverage is enabled, APEXes (and files there) are built for native coverage as well. Bug: 138952487 Test: make -j NATIVE_COVERAGE=true COVERAGE_PATHS='*' com.android.resolv find out -name "*.gcno" | grep DnsResolver shows files Test: libnetd_resolv.zip is found under $(TARGET_OUT)/apex/com.android.resolv/lib directory Change-Id: I97bcee9bf8ffc0dc71453abbdb613ed56ea2cdb4
2019-08-09 07:44:36 +02:00
}
func (a *apexBundle) PreventInstall() {
a.properties.PreventInstall = true
}
func (a *apexBundle) HideFromMake() {
a.properties.HideFromMake = true
}
Reland "m <apex_name>-deps-info prints the internal/external deps of the APEX"" This reverts commit 4513f703f9902193fc5c29607ddb4a8f71bfd702. Bug: 1190898 Test: m Test: EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true NATIVE_COVERAGE=true m dist Change-Id: I50fdccabb43e4751694db83ee451d388657257e0
2020-01-09 04:32:06 +01:00
func (a *apexBundle) MarkAsCoverageVariant(coverage bool) {
a.properties.IsCoverageVariant = coverage
}
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
// TODO(jiyong) move apexFileFor* close to the apexFile type definition
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
func apexFileForNativeLibrary(ctx android.BaseModuleContext, ccMod *cc.Module, handleSpecialLibs bool) apexFile {
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
// Decide the APEX-local directory by the multilib of the library
// In the future, we may query this to the module.
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
var dirInApex string
Treat libclang_rt.hwasan-* the same way as the other Bionic bootstrap libs. 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
2019-09-11 00:18:20 +02:00
switch ccMod.Arch().ArchType.Multilib {
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
case "lib32":
dirInApex = "lib"
case "lib64":
dirInApex = "lib64"
}
Treat libclang_rt.hwasan-* the same way as the other Bionic bootstrap libs. 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
2019-09-11 00:18:20 +02:00
dirInApex = filepath.Join(dirInApex, ccMod.RelativeInstallPath())
Remove old-style support for translated second architectures Translated second architectures now go in NativeBridgeArch instead of DeviceSecondaryArch. This reapplies I568046330abc002d4eed582cb999b62a5eaba790 with ctx.Config().HasMulitlibConflict() added to fix the NDK build, which has arm64, arm, x86_64, and x86 architectures enabled. Test: m checkbuild Test: OUT_DIR=out_ndk build/soong/scripts/build-ndk-prebuilts.sh Test: no change to build.ninja or Android-aosp_cf_x86_phone.mk Change-Id: Iadcafbd64bfb9579ae7c86914927c43a062b0c8e
2019-09-17 23:45:31 +02:00
if ccMod.Target().NativeBridge == android.NativeBridgeEnabled {
Treat libclang_rt.hwasan-* the same way as the other Bionic bootstrap libs. 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
2019-09-11 00:18:20 +02:00
dirInApex = filepath.Join(dirInApex, ccMod.Target().NativeBridgeRelativePath)
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
}
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
if handleSpecialLibs && cc.InstallToBootstrap(ccMod.BaseModuleName(), ctx.Config()) {
Treat libclang_rt.hwasan-* the same way as the other Bionic bootstrap libs. 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
2019-09-11 00:18:20 +02:00
// Special case for Bionic libs and other libs installed with them. This is
// to prevent those libs from being included in the search path
// /apex/com.android.runtime/${LIB}. This exclusion is required because
// those libs in the Runtime APEX are available via the legacy paths in
// /system/lib/. By the init process, the libs in the APEX are bind-mounted
// to the legacy paths and thus will be loaded into the default linker
// namespace (aka "platform" namespace). If the libs are directly in
// /apex/com.android.runtime/${LIB} then the same libs will be loaded again
// into the runtime linker namespace, which will result in double loading of
// them, which isn't supported.
dirInApex = filepath.Join(dirInApex, "bionic")
Rename non-stubs variant of a lib if it is included in APEX If a lib is directly included in an APEX (via native_shared_libs property) and the lib has stubs (via stubs.versions property), then the ordinary non-stubs variant of the library is renamed to <libname>.bootstrap in the makefile. At the same time, the stubs variant of the lib becomes visible and it's name is <libname>. This ensures that modules in Android.mk build against the stubs variant thus preventing them from using private APIs in the lib. The non-stubs variant, however, is used if the module explicitly has set the new 'bootstrap' property to true. This is useful for building some early binaries (such as init and vold) which need to run before APEXes are activated. Since they can't use the bionic libs from the runtime APEX, they should use the bionic libs left in the system partition which is called the boostrap bionic. Bug: 120266448 Test: m Test: m with https://android-review.googlesource.com/c/platform/bionic/+/849044 Change-Id: I882b8aeb5b29460f07b4424e4f8eb844d6c9a9b0
2018-12-20 14:10:17 +01:00
}
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
fileToCopy := ccMod.OutputFile().Path()
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
return newApexFile(ctx, fileToCopy, ccMod.Name(), dirInApex, nativeSharedLib, ccMod)
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
}
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
func apexFileForExecutable(ctx android.BaseModuleContext, cc *cc.Module) apexFile {
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
dirInApex := filepath.Join("bin", cc.RelativeInstallPath())
Remove old-style support for translated second architectures Translated second architectures now go in NativeBridgeArch instead of DeviceSecondaryArch. This reapplies I568046330abc002d4eed582cb999b62a5eaba790 with ctx.Config().HasMulitlibConflict() added to fix the NDK build, which has arm64, arm, x86_64, and x86 architectures enabled. Test: m checkbuild Test: OUT_DIR=out_ndk build/soong/scripts/build-ndk-prebuilts.sh Test: no change to build.ninja or Android-aosp_cf_x86_phone.mk Change-Id: Iadcafbd64bfb9579ae7c86914927c43a062b0c8e
2019-09-17 23:45:31 +02:00
if cc.Target().NativeBridge == android.NativeBridgeEnabled {
Make relative path for native_bridge binaries configurable This change introduces NativeBridgeRelativePath and NativeBridgeSecondaryRelativePath product variables to make relative path to native_bridge binaries configurable. It also removes moves information about native bridge host architecture to Target and sets it during decodeTargetProductVariables Test: make PRODUCT-cf_x86_phone-userdebug dist Change-Id: Ie736e81eae507e1775566ce9f29135011b12af27
2019-07-11 10:23:53 +02:00
dirInApex = filepath.Join(dirInApex, cc.Target().NativeBridgeRelativePath)
Use ctx.Target().NativeBridge to detect if the arch is translated or not Bug: 137015854 Test: m Test: build cf_x86_phone and ensure there is no dangling symlink /system/lib/arm/libm.so Change-Id: I0f5efdb9e1f5e4e213ca4ebaa28ace0a130b36a6
2019-07-09 09:19:16 +02:00
}
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
fileToCopy := cc.OutputFile().Path()
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
af := newApexFile(ctx, fileToCopy, cc.Name(), dirInApex, nativeExecutable, cc)
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
af.symlinks = cc.Symlinks()
return af
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
}
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
func apexFileForPyBinary(ctx android.BaseModuleContext, py *python.Module) apexFile {
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
dirInApex := "bin"
fileToCopy := py.HostToolPath().Path()
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
return newApexFile(ctx, fileToCopy, py.Name(), dirInApex, pyBinary, py)
Add support for including py_binary and *_go_binary in apexs These additional binary types are useful for some apexs. Add the ability to include them. Due to the nature of the resulting artifacts only py binaries with embedded launchers and host go binaries are supported. Test: m com.android.support.apexer Bug: 119332365 Bug: 119332362 Change-Id: I27c253d3647cf7bbe15896610d7a74a5f93e8bec
2019-02-27 23:19:50 +01:00
}
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
func apexFileForGoBinary(ctx android.BaseModuleContext, depName string, gb bootstrap.GoBinaryTool) apexFile {
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
dirInApex := "bin"
Add support for including py_binary and *_go_binary in apexs These additional binary types are useful for some apexs. Add the ability to include them. Due to the nature of the resulting artifacts only py binaries with embedded launchers and host go binaries are supported. Test: m com.android.support.apexer Bug: 119332365 Bug: 119332362 Change-Id: I27c253d3647cf7bbe15896610d7a74a5f93e8bec
2019-02-27 23:19:50 +01:00
s, err := filepath.Rel(android.PathForOutput(ctx).String(), gb.InstallPath())
if err != nil {
ctx.ModuleErrorf("Unable to use compiled binary at %s", gb.InstallPath())
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
return apexFile{}
Add support for including py_binary and *_go_binary in apexs These additional binary types are useful for some apexs. Add the ability to include them. Due to the nature of the resulting artifacts only py binaries with embedded launchers and host go binaries are supported. Test: m com.android.support.apexer Bug: 119332365 Bug: 119332362 Change-Id: I27c253d3647cf7bbe15896610d7a74a5f93e8bec
2019-02-27 23:19:50 +01:00
}
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
fileToCopy := android.PathForOutput(ctx, s)
// NB: Since go binaries are static we don't need the module for anything here, which is
// good since the go tool is a blueprint.Module not an android.Module like we would
// normally use.
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
return newApexFile(ctx, fileToCopy, depName, dirInApex, goBinary, nil)
Add support for including py_binary and *_go_binary in apexs These additional binary types are useful for some apexs. Add the ability to include them. Due to the nature of the resulting artifacts only py binaries with embedded launchers and host go binaries are supported. Test: m com.android.support.apexer Bug: 119332365 Bug: 119332362 Change-Id: I27c253d3647cf7bbe15896610d7a74a5f93e8bec
2019-02-27 23:19:50 +01:00
}
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
func apexFileForShBinary(ctx android.BaseModuleContext, sh *android.ShBinary) apexFile {
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
dirInApex := filepath.Join("bin", sh.SubDir())
fileToCopy := sh.OutputFile()
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
af := newApexFile(ctx, fileToCopy, sh.Name(), dirInApex, shBinary, sh)
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
af.symlinks = sh.Symlinks()
return af
sh_binary can be included in APEX Bug: 123891899 Test: m (apex_test amended) Change-Id: Idebe577b20019fe9cd0fb6617f3b8c52a5b87714
2019-02-05 16:16:29 +01:00
}
Support java_sdk_library as java_libs of apex When a java_sdk_library module is added, both impl jar and permission xml files are packaged together. For example, when a java_sdk_library "foo" is listed, following two entries will be in an APEX package. /javalibs/foo.jar /etc/permissions/foo.xml Bug: 145474221 Test: m com.android.cronet deapexer list com.android.cronet.apex Change-Id: If5883c02255e9309f20810b1532d3fbe73bf4e95
2019-12-18 07:34:32 +01:00
// TODO(b/146586360): replace javaLibrary(in apex/apex.go) with java.Dependency
type javaLibrary interface {
android.Module
java.Dependency
}
func apexFileForJavaLibrary(ctx android.BaseModuleContext, lib javaLibrary) apexFile {
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
dirInApex := "javalib"
Support java_sdk_library as java_libs of apex When a java_sdk_library module is added, both impl jar and permission xml files are packaged together. For example, when a java_sdk_library "foo" is listed, following two entries will be in an APEX package. /javalibs/foo.jar /etc/permissions/foo.xml Bug: 145474221 Test: m com.android.cronet deapexer list com.android.cronet.apex Change-Id: If5883c02255e9309f20810b1532d3fbe73bf4e95
2019-12-18 07:34:32 +01:00
fileToCopy := lib.DexJar()
jacoco correctly gathers info from APK-in-APEX This change fixes a bug that jacoco-report-classes-all.jar does not include info for APK-in-APEX such as the MediaProvider apk in com.android.mediaprovider APEX. Firstly, LOCAL_SOONG_JACOCO_REPORT_CLASSES_JAR is correctly set also for the APKs included in APEXes. Secondly, the Make modules for the embedded APKs are now built with soong_app_prebuilt.mk to correctly import the jacoco file into the Make world. Bug: 147296855 Test: execute the following command in internal master. $ choosecombo cf_x86_phone userdebug $ NINJA_ARGS="-t path out/target/product/vsoc_x86/jacoco-report-classes-all.jar out/target/common/obj/ETC/MediaProvider.com.android.mediaprovider_intermediates/jacoco-report-classes.jar" EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true m The result shows that there is a path as follows: out/target/product/vsoc_x86/jacoco-report-classes-all.jar out/target/product/vsoc_x86/apex/com.android.mediaprovider/priv-app/MediaProvider/MediaProvider.apk out/target/product/vsoc_x86/obj/ETC/MediaProvider.com.android.mediaprovider_intermediates/package.apk out/target/common/obj/ETC/MediaProvider.com.android.mediaprovider_intermediates/jacoco-report-classes.jar Change-Id: I52d11534a34eb35219bfafca4453e75a1b701c0e
2020-01-08 05:35:43 +01:00
af := newApexFile(ctx, fileToCopy, lib.Name(), dirInApex, javaSharedLib, lib)
af.jacocoReportClassesFile = lib.JacocoReportClassesFile()
return af
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
}
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
func apexFileForPrebuiltEtc(ctx android.BaseModuleContext, prebuilt android.PrebuiltEtcModule, depName string) apexFile {
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
dirInApex := filepath.Join("etc", prebuilt.SubDir())
fileToCopy := prebuilt.OutputFile()
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
return newApexFile(ctx, fileToCopy, depName, dirInApex, etc, prebuilt)
Support including apk inside an apex New property "apps" is added to APEX soong module. This property configure a list of APKs to package inside APEX payload. For each android_app module package it's APK into /app/$(android_app module Name) directory. Bug: 139906763 Test: m -j Change-Id: Ic6655f211951af08097c76e157a07ebc52425718
2019-08-27 06:55:42 +02:00
}
Add support for compat config in APEX. 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
2020-01-27 18:01:16 +01:00
func apexFileForCompatConfig(ctx android.BaseModuleContext, config java.PlatformCompatConfigIntf, depName string) apexFile {
dirInApex := filepath.Join("etc", config.SubDir())
fileToCopy := config.CompatConfig()
return newApexFile(ctx, fileToCopy, depName, dirInApex, etc, config)
}
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
func apexFileForAndroidApp(ctx android.BaseModuleContext, aapp interface {
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
android.Module
Privileged() bool
OutputFile() android.Path
jacoco correctly gathers info from APK-in-APEX This change fixes a bug that jacoco-report-classes-all.jar does not include info for APK-in-APEX such as the MediaProvider apk in com.android.mediaprovider APEX. Firstly, LOCAL_SOONG_JACOCO_REPORT_CLASSES_JAR is correctly set also for the APKs included in APEXes. Secondly, the Make modules for the embedded APKs are now built with soong_app_prebuilt.mk to correctly import the jacoco file into the Make world. Bug: 147296855 Test: execute the following command in internal master. $ choosecombo cf_x86_phone userdebug $ NINJA_ARGS="-t path out/target/product/vsoc_x86/jacoco-report-classes-all.jar out/target/common/obj/ETC/MediaProvider.com.android.mediaprovider_intermediates/jacoco-report-classes.jar" EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true m The result shows that there is a path as follows: out/target/product/vsoc_x86/jacoco-report-classes-all.jar out/target/product/vsoc_x86/apex/com.android.mediaprovider/priv-app/MediaProvider/MediaProvider.apk out/target/product/vsoc_x86/obj/ETC/MediaProvider.com.android.mediaprovider_intermediates/package.apk out/target/common/obj/ETC/MediaProvider.com.android.mediaprovider_intermediates/jacoco-report-classes.jar Change-Id: I52d11534a34eb35219bfafca4453e75a1b701c0e
2020-01-08 05:35:43 +01:00
JacocoReportClassesFile() android.Path
Set LOCAL_CERTIFICATE for flattened apex APKs Leaving out LOCAL_CERTIFICATE for flattened apex APKs causes the apkcerts.txt to have empty keys for those APKs, which confuses the signing tools. Set LOCAL_CERTIFICATE for them. Also refactor the Certificate support to avoid introducing duplicated handling for presigned certificates. Bug: 147765187 Test: m apkcerts-list Change-Id: Ife07661761cd5a89c9f009b8ce041db4dff9ec54
2020-01-28 23:00:53 +01:00
Certificate() java.Certificate
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
}, pkgName string) apexFile {
Add support for including app prebuilts in APEX. Bug: 138429615 Test: Created an APEX containing CtsShimPrebuilt and CtsShimPrivPrebuilt. Change-Id: I9d138ccfc03e4b96c9989d2681ad4e4ad5f20108
2019-10-27 01:29:22 +02:00
appDir := "app"
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
if aapp.Privileged() {
Add support for including app prebuilts in APEX. Bug: 138429615 Test: Created an APEX containing CtsShimPrebuilt and CtsShimPrivPrebuilt. Change-Id: I9d138ccfc03e4b96c9989d2681ad4e4ad5f20108
2019-10-27 01:29:22 +02:00
appDir = "priv-app"
}
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
dirInApex := filepath.Join(appDir, pkgName)
fileToCopy := aapp.OutputFile()
jacoco correctly gathers info from APK-in-APEX This change fixes a bug that jacoco-report-classes-all.jar does not include info for APK-in-APEX such as the MediaProvider apk in com.android.mediaprovider APEX. Firstly, LOCAL_SOONG_JACOCO_REPORT_CLASSES_JAR is correctly set also for the APKs included in APEXes. Secondly, the Make modules for the embedded APKs are now built with soong_app_prebuilt.mk to correctly import the jacoco file into the Make world. Bug: 147296855 Test: execute the following command in internal master. $ choosecombo cf_x86_phone userdebug $ NINJA_ARGS="-t path out/target/product/vsoc_x86/jacoco-report-classes-all.jar out/target/common/obj/ETC/MediaProvider.com.android.mediaprovider_intermediates/jacoco-report-classes.jar" EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true m The result shows that there is a path as follows: out/target/product/vsoc_x86/jacoco-report-classes-all.jar out/target/product/vsoc_x86/apex/com.android.mediaprovider/priv-app/MediaProvider/MediaProvider.apk out/target/product/vsoc_x86/obj/ETC/MediaProvider.com.android.mediaprovider_intermediates/package.apk out/target/common/obj/ETC/MediaProvider.com.android.mediaprovider_intermediates/jacoco-report-classes.jar Change-Id: I52d11534a34eb35219bfafca4453e75a1b701c0e
2020-01-08 05:35:43 +01:00
af := newApexFile(ctx, fileToCopy, aapp.Name(), dirInApex, app, aapp)
af.jacocoReportClassesFile = aapp.JacocoReportClassesFile()
Set LOCAL_CERTIFICATE for flattened apex APKs Leaving out LOCAL_CERTIFICATE for flattened apex APKs causes the apkcerts.txt to have empty keys for those APKs, which confuses the signing tools. Set LOCAL_CERTIFICATE for them. Also refactor the Certificate support to avoid introducing duplicated handling for presigned certificates. Bug: 147765187 Test: m apkcerts-list Change-Id: Ife07661761cd5a89c9f009b8ce041db4dff9ec54
2020-01-28 23:00:53 +01:00
af.certificate = aapp.Certificate()
bundle config contains (path,manifest) pairs of embedded APKs 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 cfaa1643e8aea1a045655274757a62f936ca235b) Change-Id: Ibb90bcefb77fa6b2dad77cb2facc6079de9ab154
2020-02-28 08:51:07 +01:00
if app, ok := aapp.(interface {
OverriddenManifestPackageName() string
}); ok {
af.overriddenPackageName = app.OverriddenManifestPackageName()
}
jacoco correctly gathers info from APK-in-APEX This change fixes a bug that jacoco-report-classes-all.jar does not include info for APK-in-APEX such as the MediaProvider apk in com.android.mediaprovider APEX. Firstly, LOCAL_SOONG_JACOCO_REPORT_CLASSES_JAR is correctly set also for the APKs included in APEXes. Secondly, the Make modules for the embedded APKs are now built with soong_app_prebuilt.mk to correctly import the jacoco file into the Make world. Bug: 147296855 Test: execute the following command in internal master. $ choosecombo cf_x86_phone userdebug $ NINJA_ARGS="-t path out/target/product/vsoc_x86/jacoco-report-classes-all.jar out/target/common/obj/ETC/MediaProvider.com.android.mediaprovider_intermediates/jacoco-report-classes.jar" EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true m The result shows that there is a path as follows: out/target/product/vsoc_x86/jacoco-report-classes-all.jar out/target/product/vsoc_x86/apex/com.android.mediaprovider/priv-app/MediaProvider/MediaProvider.apk out/target/product/vsoc_x86/obj/ETC/MediaProvider.com.android.mediaprovider_intermediates/package.apk out/target/common/obj/ETC/MediaProvider.com.android.mediaprovider_intermediates/jacoco-report-classes.jar Change-Id: I52d11534a34eb35219bfafca4453e75a1b701c0e
2020-01-08 05:35:43 +01:00
return af
Add support for including app prebuilts in APEX. Bug: 138429615 Test: Created an APEX containing CtsShimPrebuilt and CtsShimPrivPrebuilt. Change-Id: I9d138ccfc03e4b96c9989d2681ad4e4ad5f20108
2019-10-27 01:29:22 +02:00
}
Add an output file type for flattened APEXes. Allow modules to depend on the flattened flavor of an APEX package using `module.{flattened}` (returning the output install path of the flattened APEX). Also add this flattened output install path as an implicit output dependency of a flattened APEX phony module. Test: m checkbuild Bug: 139277987 Change-Id: I8c55d5ff2922a36fcc8ec0819fbe3e93a772ef8a Merged-In: I8c55d5ff2922a36fcc8ec0819fbe3e93a772ef8a
2019-08-13 15:55:28 +02:00
// Context "decorator", overriding the InstallBypassMake method to always reply `true`.
type flattenedApexContext struct {
android.ModuleContext
}
func (c *flattenedApexContext) InstallBypassMake() bool {
return true
}
add walkPayloadDeps 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
2020-02-07 09:25:49 +01:00
// Visit dependencies that contributes to the payload of this APEX
func (a *apexBundle) walkPayloadDeps(ctx android.ModuleContext,
do func(ctx android.ModuleContext, from blueprint.Module, to android.ApexModule, externalDep bool)) {
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
ctx.WalkDepsBlueprint(func(child, parent blueprint.Module) bool {
am, ok := child.(android.ApexModule)
if !ok || !am.CanHaveApexVariants() {
return false
}
// Check for the direct dependencies that contribute to the payload
if dt, ok := ctx.OtherModuleDependencyTag(child).(dependencyTag); ok {
if dt.payload {
add walkPayloadDeps 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
2020-02-07 09:25:49 +01:00
do(ctx, parent, am, false /* externalDep */)
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
return true
}
return false
}
// Check for the indirect dependencies if it is considered as part of the APEX
Fix apex_available 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 5e9013be2202effb500a0aa14d95f5fef70cc75e) Change-Id: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
2020-03-09 22:23:13 +01:00
if am.ApexName() != "" {
add walkPayloadDeps 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
2020-02-07 09:25:49 +01:00
do(ctx, parent, am, false /* externalDep */)
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
return true
}
add walkPayloadDeps 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
2020-02-07 09:25:49 +01:00
do(ctx, parent, am, true /* externalDep */)
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
// As soon as the dependency graph crosses the APEX boundary, don't go further.
return false
})
}
apex: choose stub according to min_sdk_version 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 03b5185b888f2d75b61916e37c8f366e10e7fd94) Exempt-From-Owner-Approval: got ORV already.
2020-02-26 14:45:42 +01:00
func (a *apexBundle) minSdkVersion(ctx android.BaseModuleContext) int {
ver := proptools.StringDefault(a.properties.Min_sdk_version, "current")
Apex: support codenames for min_sdk_version 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
2020-04-01 18:41:41 +02:00
intVer, err := android.ApiStrToNum(ctx, ver)
if err != nil {
ctx.PropertyErrorf("min_sdk_version", "%s", err.Error())
apex: choose stub according to min_sdk_version 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 03b5185b888f2d75b61916e37c8f366e10e7fd94) Exempt-From-Owner-Approval: got ORV already.
2020-02-26 14:45:42 +01:00
}
Apex: support codenames for min_sdk_version 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
2020-04-01 18:41:41 +02:00
return intVer
apex: choose stub according to min_sdk_version 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 03b5185b888f2d75b61916e37c8f366e10e7fd94) Exempt-From-Owner-Approval: got ORV already.
2020-02-26 14:45:42 +01:00
}
add walkPayloadDeps 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
2020-02-07 09:25:49 +01:00
// Ensures that the dependencies are marked as available for this APEX
func (a *apexBundle) checkApexAvailability(ctx android.ModuleContext) {
// Let's be practical. Availability for test, host, and the VNDK apex isn't important
if ctx.Host() || a.testApex || a.vndkApex {
return
}
a.walkPayloadDeps(ctx, func(ctx android.ModuleContext, from blueprint.Module, to android.ApexModule, externalDep bool) {
apexName := ctx.ModuleName()
Fix apex_available 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 5e9013be2202effb500a0aa14d95f5fef70cc75e) Change-Id: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
2020-03-09 22:23:13 +01:00
fromName := ctx.OtherModuleName(from)
toName := ctx.OtherModuleName(to)
if externalDep || to.AvailableFor(apexName) || whitelistedApexAvailable(apexName, toName) {
add walkPayloadDeps 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
2020-02-07 09:25:49 +01:00
return
}
Fix apex_available 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 5e9013be2202effb500a0aa14d95f5fef70cc75e) Change-Id: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
2020-03-09 22:23:13 +01:00
ctx.ModuleErrorf("%q requires %q that is not available for the APEX.", fromName, toName)
add walkPayloadDeps 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
2020-02-07 09:25:49 +01:00
})
}
<apex_name>-deps-info correctly tracks dependencies 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
2020-02-07 09:25:49 +01:00
// Collects the list of module names that directly or indirectly contributes to the payload of this APEX
func (a *apexBundle) collectDepsInfo(ctx android.ModuleContext) {
a.depInfos = make(map[string]depInfo)
a.walkPayloadDeps(ctx, func(ctx android.ModuleContext, from blueprint.Module, to android.ApexModule, externalDep bool) {
if from.Name() == to.Name() {
// This can happen for cc.reuseObjTag. We are not interested in tracking this.
return
}
if info, exists := a.depInfos[to.Name()]; exists {
if !android.InList(from.Name(), info.from) {
info.from = append(info.from, from.Name())
}
info.isExternal = info.isExternal && externalDep
a.depInfos[to.Name()] = info
} else {
a.depInfos[to.Name()] = depInfo{
to: to.Name(),
from: []string{from.Name()},
isExternal: externalDep,
}
}
})
}
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
func (a *apexBundle) GenerateAndroidBuildActions(ctx android.ModuleContext) {
Create variants for each image type Create variant of image, zip or flattened according to TARGET_FLATTEN_APEX and payload type. If payload type is zip, only zip variant is created because flattened apex is not supported. And if payload type is image, image and flattened variants are created. Bug: 139053989 Test: m -j Change-Id: Ibde18490d23ec602c4cca97cf97db90a562e014e
2019-10-22 06:58:29 +02:00
buildFlattenedAsDefault := ctx.Config().FlattenApex() && !ctx.Config().UnbundledBuild()
switch a.properties.ApexType {
case imageApex:
if buildFlattenedAsDefault {
a.suffix = imageApexSuffix
} else {
a.suffix = ""
a.primaryApexType = true
Install flattened/unflattend apexes for GSI GSI targets are supposed to have both 'flattened' and 'unflattened' APEXes. By adding 'flattened' APEX as REQUIRED moduled for 'unflattened' APEX, both will be installed togetther. This is done by a new variable PRODUCT_INSTALL_EXTRA_FLATTENED_APEXES, which is set only for GSI targets. Bug: 137802149 Test: lunch aosp_arm64-userdebug && m resulting apex images under /system/apex and flattened apexes under /system/system_ext/apex Change-Id: I336e2674e427b358542e0045b2a49dfa3d84095b
2019-12-05 08:27:44 +01:00
if ctx.Config().InstallExtraFlattenedApexes() {
Reland "m <apex_name>-deps-info prints the internal/external deps of the APEX"" This reverts commit 4513f703f9902193fc5c29607ddb4a8f71bfd702. Bug: 1190898 Test: m Test: EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true NATIVE_COVERAGE=true m dist Change-Id: I50fdccabb43e4751694db83ee451d388657257e0
2020-01-09 04:32:06 +01:00
a.requiredDeps = append(a.requiredDeps, a.Name()+flattenedSuffix)
Install flattened/unflattend apexes for GSI GSI targets are supposed to have both 'flattened' and 'unflattened' APEXes. By adding 'flattened' APEX as REQUIRED moduled for 'unflattened' APEX, both will be installed togetther. This is done by a new variable PRODUCT_INSTALL_EXTRA_FLATTENED_APEXES, which is set only for GSI targets. Bug: 137802149 Test: lunch aosp_arm64-userdebug && m resulting apex images under /system/apex and flattened apexes under /system/system_ext/apex Change-Id: I336e2674e427b358542e0045b2a49dfa3d84095b
2019-12-05 08:27:44 +01:00
}
Create variants for each image type Create variant of image, zip or flattened according to TARGET_FLATTEN_APEX and payload type. If payload type is zip, only zip variant is created because flattened apex is not supported. And if payload type is image, image and flattened variants are created. Bug: 139053989 Test: m -j Change-Id: Ibde18490d23ec602c4cca97cf97db90a562e014e
2019-10-22 06:58:29 +02:00
}
case zipApex:
if proptools.String(a.properties.Payload_type) == "zip" {
a.suffix = ""
a.primaryApexType = true
} else {
a.suffix = zipApexSuffix
}
case flattenedApex:
if buildFlattenedAsDefault {
a.suffix = ""
a.primaryApexType = true
} else {
a.suffix = flattenedSuffix
}
Add zip-apex This adds support for an apex-like file where the payload is a zip file instead of a FS image. This makes it easier to examine and use without root. These can also be built for the host. This can be controlled using the 'type' modifier in the apex build rule. 'type' may be "image" to build an apex file called {name}.apex with an FS image payload, "zip" to build an apex with called {name}.zipapex with a zip-file payload or "both" to build both. By default we will use "image". This also adds support for setting apex rules to "host_supported: true". Test: cd art/build/apex; mma; examine the com.android.runtime.host.zipapex artifact. Test: go test android/soong/apex -v Bug: 120436895 Change-Id: I534d330672211ac5ccc3bd5a0c89b9fc507bf51e
2018-11-30 02:12:15 +01:00
}
Add support for tests in APEX test modules. Allow `tests` property in `apex_test` Soong modules. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: Ieeff7cf0980a7c394409632b6448102f59bceb3d
2019-06-26 13:48:34 +02:00
if len(a.properties.Tests) > 0 && !a.testApex {
ctx.PropertyErrorf("tests", "property not allowed in apex module type")
return
}
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
a.checkApexAvailability(ctx)
<apex_name>-deps-info correctly tracks dependencies 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
2020-02-07 09:25:49 +01:00
a.collectDepsInfo(ctx)
Give a knob to have apex ignore system-lib special cases apex will normally place libc and some other system libraries into a separate directory. This is to ensure that early startup works correctly. Some apex targets want to have these libraries at the normal places however. Test: ./art/tools/build_linux_bionic.sh com.android.runtime.host Bug: 123591866 Bug: 120266448 Change-Id: Ib5a67a43fe3eea6188b4df9215e743f1634045f3
2019-01-30 03:31:59 +01:00
handleSpecialLibs := !android.Bool(a.properties.Ignore_system_library_special_case)
Put dependency in apex_manifest.json To generate ld.config.txt dynamically(b/123722631), each APEX should provide some dependency information: a) list of libraries which other APEXes(or system) can use from this apex b) list of libraries which this apex uses from other APEXes(or system) This change puts dependency information in apex_manifest.json at build-time with two additional keys: a) provideNativeLibs b) requireNativeLibs Bug: 138695532 Test: m (runs soong tests) Test: find $OUT/apex -name apex_manifest.json -exec cat {} \; (shows contents of apex_manifest.json files) Change-Id: Iaad12c8c35454222ad177ce923cce76ef12a8a5a
2019-08-01 10:41:43 +02:00
// native lib dependencies
var provideNativeLibs []string
var requireNativeLibs []string
Add "provide_cpp_shared_libs/uses" props to "apex" For APEXes to share C++ native libraries, we need a new kind of depedency between APEXes: "providing" APEXes and "using" APEXes. To reflect this dependency two new properties are added. provide_cpp_shared_libs: bool this indicates that the current APEX module provides the native C++ shared libs to other APEXes. uses: []string this indicates that the current APEX module uses the native C++ shared libraries from APEXes listed. With these two, "using" APEXes can omit shared libraries in its APEX bundle and use them from the "providing" APEXes. Note that without corresponding changes in ld.config.txt, this won't work.(The linker namespaces should be configured so that user APEX can access provided libs.) Bug: 136975105 Test: m nothing (this will trigger soong's test) Change-Id: Iec6f9f67bcbde01145acc383f862ba21c8197536
2019-06-27 04:30:33 +02:00
// Check if "uses" requirements are met with dependent apexBundles
var providedNativeSharedLibs []string
useVendor := proptools.Bool(a.properties.Use_vendor)
ctx.VisitDirectDepsBlueprint(func(m blueprint.Module) {
if ctx.OtherModuleDependencyTag(m) != usesTag {
return
}
otherName := ctx.OtherModuleName(m)
other, ok := m.(*apexBundle)
if !ok {
ctx.PropertyErrorf("uses", "%q is not a provider", otherName)
return
}
if proptools.Bool(other.properties.Use_vendor) != useVendor {
ctx.PropertyErrorf("use_vendor", "%q has different value of use_vendor", otherName)
return
}
if !proptools.Bool(other.properties.Provide_cpp_shared_libs) {
ctx.PropertyErrorf("uses", "%q does not provide native_shared_libs", otherName)
return
}
providedNativeSharedLibs = append(providedNativeSharedLibs, other.properties.Native_shared_libs...)
})
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
var filesInfo []apexFile
<apex_name>-deps-info correctly tracks dependencies 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
2020-02-07 09:25:49 +01:00
// TODO(jiyong) do this using walkPayloadDeps
Add support for including py_binary and *_go_binary in apexs These additional binary types are useful for some apexs. Add the ability to include them. Due to the nature of the resulting artifacts only py binaries with embedded launchers and host go binaries are supported. Test: m com.android.support.apexer Bug: 119332365 Bug: 119332362 Change-Id: I27c253d3647cf7bbe15896610d7a74a5f93e8bec
2019-02-27 23:19:50 +01:00
ctx.WalkDepsBlueprint(func(child, parent blueprint.Module) bool {
Handle `test_per_src` modules as indirect dependencies in APEXes. In `apex.apexBundle.GenerateAndroidBuildActions`, we used to pass the "all tests" ("") module as `module` for all `apexFile` objects created from a test module using `test_per_src: true`. An immediate issue of this situation was that the "" module is hidden from Make, which made all the generated `apexFile` objects hidden from Make too. This would break the construction of flattened APEXes, as they rely on Make logic to install their files. Instead of collecting `test_per_src` test variations' output files in `cc.Module.GenerateAndroidBuildActions` and using them in `apex.apexBundle.GenerateAndroidBuildActions` as part of handling the "" variation as a direct dependency of an `apexBundle`, process them as indirect dependencies (and do nothing for the "" variation direct dependency). Adjust the indirect dependency logic in `apex.apexBundle.GenerateAndroidBuildActions` to allow not only shared/runtime native libraries as indirect dependencies of an `apexBundle`, but also `test_per_src` tests. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: I845e0f0dd3a98d61d0b7118c5eaf61f3e5335724
2019-07-29 17:22:59 +02:00
depTag := ctx.OtherModuleDependencyTag(child)
depName := ctx.OtherModuleName(child)
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
if _, isDirectDep := parent.(*apexBundle); isDirectDep {
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
switch depTag {
case sharedLibTag:
Do not add bootstrap libs as providing from apex 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
2020-02-06 09:42:40 +01:00
if c, ok := child.(*cc.Module); ok {
// bootstrap bionic libs are treated as provided by system
if c.HasStubsVariants() && !cc.InstallToBootstrap(c.BaseModuleName(), ctx.Config()) {
provideNativeLibs = append(provideNativeLibs, c.OutputFile().Path().Base())
Put dependency in apex_manifest.json To generate ld.config.txt dynamically(b/123722631), each APEX should provide some dependency information: a) list of libraries which other APEXes(or system) can use from this apex b) list of libraries which this apex uses from other APEXes(or system) This change puts dependency information in apex_manifest.json at build-time with two additional keys: a) provideNativeLibs b) requireNativeLibs Bug: 138695532 Test: m (runs soong tests) Test: find $OUT/apex -name apex_manifest.json -exec cat {} \; (shows contents of apex_manifest.json files) Change-Id: Iaad12c8c35454222ad177ce923cce76ef12a8a5a
2019-08-01 10:41:43 +02:00
}
Do not add bootstrap libs as providing from apex 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
2020-02-06 09:42:40 +01:00
filesInfo = append(filesInfo, apexFileForNativeLibrary(ctx, c, handleSpecialLibs))
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
return true // track transitive dependencies
APEX can be signed with different keys A new module type 'apex_key' is defined to specify public and private key pair for APEXs. An APEX can refer to the module via the property 'key'. When building the APEX, the private key from the key module is used to sign it. In addition, the public key from the key module is automatically installed to /system/etc/security/apex. Bug: 115721587 Test: m apex.test; m /apex/com.android.example.apex@1 exists Change-Id: I82666db095bd7a09f6c1b9cbea2db57ebc076cbf
2018-10-12 14:49:38 +02:00
} else {
ctx.PropertyErrorf("native_shared_libs", "%q is not a cc_library or cc_library_shared module", depName)
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
}
case executableTag:
if cc, ok := child.(*cc.Module); ok {
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
filesInfo = append(filesInfo, apexFileForExecutable(ctx, cc))
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
return true // track transitive dependencies
sh_binary can be included in APEX Bug: 123891899 Test: m (apex_test amended) Change-Id: Idebe577b20019fe9cd0fb6617f3b8c52a5b87714
2019-02-05 16:16:29 +01:00
} else if sh, ok := child.(*android.ShBinary); ok {
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
filesInfo = append(filesInfo, apexFileForShBinary(ctx, sh))
Add support for including py_binary and *_go_binary in apexs These additional binary types are useful for some apexs. Add the ability to include them. Due to the nature of the resulting artifacts only py binaries with embedded launchers and host go binaries are supported. Test: m com.android.support.apexer Bug: 119332365 Bug: 119332362 Change-Id: I27c253d3647cf7bbe15896610d7a74a5f93e8bec
2019-02-27 23:19:50 +01:00
} else if py, ok := child.(*python.Module); ok && py.HostToolPath().Valid() {
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
filesInfo = append(filesInfo, apexFileForPyBinary(ctx, py))
Add support for including py_binary and *_go_binary in apexs These additional binary types are useful for some apexs. Add the ability to include them. Due to the nature of the resulting artifacts only py binaries with embedded launchers and host go binaries are supported. Test: m com.android.support.apexer Bug: 119332365 Bug: 119332362 Change-Id: I27c253d3647cf7bbe15896610d7a74a5f93e8bec
2019-02-27 23:19:50 +01:00
} else if gb, ok := child.(bootstrap.GoBinaryTool); ok && a.Host() {
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
filesInfo = append(filesInfo, apexFileForGoBinary(ctx, depName, gb))
APEX can be signed with different keys A new module type 'apex_key' is defined to specify public and private key pair for APEXs. An APEX can refer to the module via the property 'key'. When building the APEX, the private key from the key module is used to sign it. In addition, the public key from the key module is automatically installed to /system/etc/security/apex. Bug: 115721587 Test: m apex.test; m /apex/com.android.example.apex@1 exists Change-Id: I82666db095bd7a09f6c1b9cbea2db57ebc076cbf
2018-10-12 14:49:38 +02:00
} else {
Add support for including py_binary and *_go_binary in apexs These additional binary types are useful for some apexs. Add the ability to include them. Due to the nature of the resulting artifacts only py binaries with embedded launchers and host go binaries are supported. Test: m com.android.support.apexer Bug: 119332365 Bug: 119332362 Change-Id: I27c253d3647cf7bbe15896610d7a74a5f93e8bec
2019-02-27 23:19:50 +01:00
ctx.PropertyErrorf("binaries", "%q is neither cc_binary, (embedded) py_binary, (host) blueprint_go_binary, (host) bootstrap_go_binary, nor sh_binary", depName)
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
}
case javaLibTag:
java_import can be included in apex java_import can be included in apex via 'java_libs' property. Bug: 139175488 Test: m (apex_test.go updated) Change-Id: I3680a47cdac93b0cb2d41da8df3f8defa2bbe670
2019-08-09 13:39:45 +02:00
if javaLib, ok := child.(*java.Library); ok {
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
af := apexFileForJavaLibrary(ctx, javaLib)
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
if !af.Ok() {
APEX can be flattened When TARGET_FLATTEN_APEX is set to true, APEXes are flattened, which means files in an APEX is not packaged into the mini file system image, but instead directly copied to the system partition. This option is for devices where kernel does not support loopback devices or the maximum number of loopback devices is too small (though the threshold is TBD as of now). This CL also fixes a bug that jars having bytecode are installed instead of those having dex. Bug: 118485880 Test: TARGET_FLATTEN_APEX=true m apex.test; tree out/target/product/.../system/apex/apex.test shows list of files in it. Test; m apex.test, then a file out/target/product/.../system/apex/apex .test.apex exists. Change-Id: I5a3d62d392d05f2779c4925388afe4f6e460059b
2018-11-07 18:50:25 +01:00
ctx.PropertyErrorf("java_libs", "%q is not configured to be compiled into dex", depName)
} else {
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
filesInfo = append(filesInfo, af)
return true // track transitive dependencies
java_import can be included in apex java_import can be included in apex via 'java_libs' property. Bug: 139175488 Test: m (apex_test.go updated) Change-Id: I3680a47cdac93b0cb2d41da8df3f8defa2bbe670
2019-08-09 13:39:45 +02:00
}
Support java_sdk_library as java_libs of apex When a java_sdk_library module is added, both impl jar and permission xml files are packaged together. For example, when a java_sdk_library "foo" is listed, following two entries will be in an APEX package. /javalibs/foo.jar /etc/permissions/foo.xml Bug: 145474221 Test: m com.android.cronet deapexer list com.android.cronet.apex Change-Id: If5883c02255e9309f20810b1532d3fbe73bf4e95
2019-12-18 07:34:32 +01:00
} else if sdkLib, ok := child.(*java.SdkLibrary); ok {
af := apexFileForJavaLibrary(ctx, sdkLib)
if !af.Ok() {
ctx.PropertyErrorf("java_libs", "%q is not configured to be compiled into dex", depName)
return false
}
filesInfo = append(filesInfo, af)
return true // track transitive dependencies
APEX can be signed with different keys A new module type 'apex_key' is defined to specify public and private key pair for APEXs. An APEX can refer to the module via the property 'key'. When building the APEX, the private key from the key module is used to sign it. In addition, the public key from the key module is automatically installed to /system/etc/security/apex. Bug: 115721587 Test: m apex.test; m /apex/com.android.example.apex@1 exists Change-Id: I82666db095bd7a09f6c1b9cbea2db57ebc076cbf
2018-10-12 14:49:38 +02:00
} else {
java_import can be included in apex java_import can be included in apex via 'java_libs' property. Bug: 139175488 Test: m (apex_test.go updated) Change-Id: I3680a47cdac93b0cb2d41da8df3f8defa2bbe670
2019-08-09 13:39:45 +02:00
ctx.PropertyErrorf("java_libs", "%q of type %q is not supported", depName, ctx.OtherModuleType(child))
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
}
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
case androidAppTag:
pkgName := ctx.DeviceConfig().OverridePackageNameFor(depName)
if ap, ok := child.(*java.AndroidApp); ok {
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
filesInfo = append(filesInfo, apexFileForAndroidApp(ctx, ap, pkgName))
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
return true // track transitive dependencies
} else if ap, ok := child.(*java.AndroidAppImport); ok {
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
filesInfo = append(filesInfo, apexFileForAndroidApp(ctx, ap, pkgName))
Add support for java_test_helper_app. Bug: 142712057 Bug: 138429615 Test: apex_test passes, tried building an apex with a test app. Change-Id: Ib75bd48042d8b1fe102038bef08cd1be708e996d
2019-12-20 23:58:03 +01:00
} else if ap, ok := child.(*java.AndroidTestHelperApp); ok {
filesInfo = append(filesInfo, apexFileForAndroidApp(ctx, ap, pkgName))
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
} else {
ctx.PropertyErrorf("apps", "%q is not an android_app module", depName)
}
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
case prebuiltTag:
VNDK APEX contains related *.libraries.txt files These files were highly coupled with vndk version, so having them inside the corresponding VNDK APEX is reasonable. These files are used by linkerconfig and libnativeloader. In the future, they reference these files from and VNDK APEX. Bug: 141450808 Test: m com.android.vndk.current Change-Id: I055a979d2636ddd8844a0afff81f6ba441f7965e
2019-11-06 08:53:07 +01:00
if prebuilt, ok := child.(android.PrebuiltEtcModule); ok {
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
filesInfo = append(filesInfo, apexFileForPrebuiltEtc(ctx, prebuilt, depName))
Add support for compat config in APEX. 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
2020-01-27 18:01:16 +01:00
} else if prebuilt, ok := child.(java.PlatformCompatConfigIntf); ok {
filesInfo = append(filesInfo, apexFileForCompatConfig(ctx, prebuilt, depName))
APEX can be signed with different keys A new module type 'apex_key' is defined to specify public and private key pair for APEXs. An APEX can refer to the module via the property 'key'. When building the APEX, the private key from the key module is used to sign it. In addition, the public key from the key module is automatically installed to /system/etc/security/apex. Bug: 115721587 Test: m apex.test; m /apex/com.android.example.apex@1 exists Change-Id: I82666db095bd7a09f6c1b9cbea2db57ebc076cbf
2018-10-12 14:49:38 +02:00
} else {
Add support for compat config in APEX. 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
2020-01-27 18:01:16 +01:00
ctx.PropertyErrorf("prebuilts", "%q is not a prebuilt_etc and not a platform_compat_config module", depName)
APEX can be signed with different keys A new module type 'apex_key' is defined to specify public and private key pair for APEXs. An APEX can refer to the module via the property 'key'. When building the APEX, the private key from the key module is used to sign it. In addition, the public key from the key module is automatically installed to /system/etc/security/apex. Bug: 115721587 Test: m apex.test; m /apex/com.android.example.apex@1 exists Change-Id: I82666db095bd7a09f6c1b9cbea2db57ebc076cbf
2018-10-12 14:49:38 +02:00
}
Add support for tests in APEX test modules. Allow `tests` property in `apex_test` Soong modules. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: Ieeff7cf0980a7c394409632b6448102f59bceb3d
2019-06-26 13:48:34 +02:00
case testTag:
Handle `test_per_src` modules as indirect dependencies in APEXes. In `apex.apexBundle.GenerateAndroidBuildActions`, we used to pass the "all tests" ("") module as `module` for all `apexFile` objects created from a test module using `test_per_src: true`. An immediate issue of this situation was that the "" module is hidden from Make, which made all the generated `apexFile` objects hidden from Make too. This would break the construction of flattened APEXes, as they rely on Make logic to install their files. Instead of collecting `test_per_src` test variations' output files in `cc.Module.GenerateAndroidBuildActions` and using them in `apex.apexBundle.GenerateAndroidBuildActions` as part of handling the "" variation as a direct dependency of an `apexBundle`, process them as indirect dependencies (and do nothing for the "" variation direct dependency). Adjust the indirect dependency logic in `apex.apexBundle.GenerateAndroidBuildActions` to allow not only shared/runtime native libraries as indirect dependencies of an `apexBundle`, but also `test_per_src` tests. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: I845e0f0dd3a98d61d0b7118c5eaf61f3e5335724
2019-07-29 17:22:59 +02:00
if ccTest, ok := child.(*cc.Module); ok {
if ccTest.IsTestPerSrcAllTestsVariation() {
// Multiple-output test module (where `test_per_src: true`).
//
// `ccTest` is the "" ("all tests") variation of a `test_per_src` module.
// We do not add this variation to `filesInfo`, as it has no output;
// however, we do add the other variations of this module as indirect
// dependencies (see below).
return true
Handle `test_per_src` test variations as dependencies of APEX modules. If a test module with a `test_per_src` property set to `true` is included in an APEX module, add all the variants for mutator `test_per_src` as dependencies of the APEX module (not just the first one). This is done by adding variation "" of mutator `test_per_src` when adding a test dependency to an APEX module, which creates an indirect dependency of the APEX module on all the `test_per_src` variants of the test module. When generating outputs for the APEX bundle, fetch and include the set of test outputs from the "" variant. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: I1c99855971a8a9b2fc5b964a420e882b6791d4e6
2019-06-28 16:41:19 +02:00
} else {
Handle `test_per_src` modules as indirect dependencies in APEXes. In `apex.apexBundle.GenerateAndroidBuildActions`, we used to pass the "all tests" ("") module as `module` for all `apexFile` objects created from a test module using `test_per_src: true`. An immediate issue of this situation was that the "" module is hidden from Make, which made all the generated `apexFile` objects hidden from Make too. This would break the construction of flattened APEXes, as they rely on Make logic to install their files. Instead of collecting `test_per_src` test variations' output files in `cc.Module.GenerateAndroidBuildActions` and using them in `apex.apexBundle.GenerateAndroidBuildActions` as part of handling the "" variation as a direct dependency of an `apexBundle`, process them as indirect dependencies (and do nothing for the "" variation direct dependency). Adjust the indirect dependency logic in `apex.apexBundle.GenerateAndroidBuildActions` to allow not only shared/runtime native libraries as indirect dependencies of an `apexBundle`, but also `test_per_src` tests. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: I845e0f0dd3a98d61d0b7118c5eaf61f3e5335724
2019-07-29 17:22:59 +02:00
// Single-output test module (where `test_per_src: false`).
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
af := apexFileForExecutable(ctx, ccTest)
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
af.class = nativeTest
filesInfo = append(filesInfo, af)
Handle `test_per_src` test variations as dependencies of APEX modules. If a test module with a `test_per_src` property set to `true` is included in an APEX module, add all the variants for mutator `test_per_src` as dependencies of the APEX module (not just the first one). This is done by adding variation "" of mutator `test_per_src` when adding a test dependency to an APEX module, which creates an indirect dependency of the APEX module on all the `test_per_src` variants of the test module. When generating outputs for the APEX bundle, fetch and include the set of test outputs from the "" variant. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: I1c99855971a8a9b2fc5b964a420e882b6791d4e6
2019-06-28 16:41:19 +02:00
}
Add support for tests in APEX test modules. Allow `tests` property in `apex_test` Soong modules. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: Ieeff7cf0980a7c394409632b6448102f59bceb3d
2019-06-26 13:48:34 +02:00
} else {
ctx.PropertyErrorf("tests", "%q is not a cc module", depName)
}
APEX can be signed with different keys A new module type 'apex_key' is defined to specify public and private key pair for APEXs. An APEX can refer to the module via the property 'key'. When building the APEX, the private key from the key module is used to sign it. In addition, the public key from the key module is automatically installed to /system/etc/security/apex. Bug: 115721587 Test: m apex.test; m /apex/com.android.example.apex@1 exists Change-Id: I82666db095bd7a09f6c1b9cbea2db57ebc076cbf
2018-10-12 14:49:38 +02:00
case keyTag:
if key, ok := child.(*apexKey); ok {
build apexkeys.txt apexkeys.txt is a text file having APEX-to-keys mappings. The file is included in the target-files package where it is used when re-sign the APEXes with release keys. Each line of the file consists of 5 fields: 1) name: file name of the APEX 2) public_key: the public key for the apex_payload.img of the APEX 3) private_key: the private key used to sign the apex_payload.img 4) container_certificate: the certificate used to sign the APEX zip container 5) container_private_key: the private key used to sign the APEX zip container Bug: 124406181 Test: m out/soong/apexkeys.txt and inspect the content Test: TARGET_BUILD_APPS=com.android.tzdata m dist and make sure out/dist/apexkeys.txt exists Change-Id: I1daa13ec50956323b97e15e8df7f1fbe5ea21d63
2019-02-18 07:25:04 +01:00
a.private_key_file = key.private_key_file
a.public_key_file = key.public_key_file
APEX can be signed with different keys A new module type 'apex_key' is defined to specify public and private key pair for APEXs. An APEX can refer to the module via the property 'key'. When building the APEX, the private key from the key module is used to sign it. In addition, the public key from the key module is automatically installed to /system/etc/security/apex. Bug: 115721587 Test: m apex.test; m /apex/com.android.example.apex@1 exists Change-Id: I82666db095bd7a09f6c1b9cbea2db57ebc076cbf
2018-10-12 14:49:38 +02:00
} else {
ctx.PropertyErrorf("key", "%q is not an apex_key module", depName)
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
}
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
return false
APEXs are signed with apk signer The entire APEX (which is a zip file) is signed with the apk signer. Certificate can be specified via the 'certificate' property just like ordinary apps. Note: multiple additional certificates are not supported. Bug: 115721587 Test: m apex.test Test: jarsigner -verify -verbose -certs .../apex.test.apex shows the certificate info Change-Id: Ia4c898d3427779a3809fdc683b85d7661ca65137
2018-10-30 13:20:05 +01:00
case certificateTag:
if dep, ok := child.(*java.AndroidAppCertificate); ok {
build apexkeys.txt apexkeys.txt is a text file having APEX-to-keys mappings. The file is included in the target-files package where it is used when re-sign the APEXes with release keys. Each line of the file consists of 5 fields: 1) name: file name of the APEX 2) public_key: the public key for the apex_payload.img of the APEX 3) private_key: the private key used to sign the apex_payload.img 4) container_certificate: the certificate used to sign the APEX zip container 5) container_private_key: the private key used to sign the APEX zip container Bug: 124406181 Test: m out/soong/apexkeys.txt and inspect the content Test: TARGET_BUILD_APPS=com.android.tzdata m dist and make sure out/dist/apexkeys.txt exists Change-Id: I1daa13ec50956323b97e15e8df7f1fbe5ea21d63
2019-02-18 07:25:04 +01:00
a.container_certificate_file = dep.Certificate.Pem
a.container_private_key_file = dep.Certificate.Key
APEXs are signed with apk signer The entire APEX (which is a zip file) is signed with the apk signer. Certificate can be specified via the 'certificate' property just like ordinary apps. Note: multiple additional certificates are not supported. Bug: 115721587 Test: m apex.test Test: jarsigner -verify -verbose -certs .../apex.test.apex shows the certificate info Change-Id: Ia4c898d3427779a3809fdc683b85d7661ca65137
2018-10-30 13:20:05 +01:00
} else {
ctx.ModuleErrorf("certificate dependency %q must be an android_app_certificate module", depName)
}
Delete prebuilt APEXes when installing source-built APEXes To build the platform for ASAN, we do `m && SANITIZE_TARGET='addresss' m` However, at the end of the second build, the system partition could have conflicting APEXes; prebuilt APEXes from the first build and source-built APEXes from the second build. Since the file names for the prebuilt and the source-built are different (e.g. com.google.android.media.apex v.s. com.android.media.apex), we end up having two files for the same APEX. This is confusing apexd at runtime and the device fails to boot. To fix this, when building a non-prebuilt APEX, the prebuilt APEX might have been installed by the previous build is deleted. Bug: 138146044 Test: lunch aosp_cf_x86_pasan; m && SANITIZE_TARGET='address' m check that out/target/product/vsoc_x86/system/apex has com.android.*.apex only. Change-Id: Ib5a021a297cf0173ea5a3b50e9398b1cf295c558
2019-07-26 16:20:40 +02:00
case android.PrebuiltDepTag:
// If the prebuilt is force disabled, remember to delete the prebuilt file
// that might have been installed in the previous builds
if prebuilt, ok := child.(*Prebuilt); ok && prebuilt.isForceDisabled() {
a.prebuiltFileToDelete = prebuilt.InstallFilename()
}
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
}
Do not follow deps for apex_vndk Since apex_vndk deals with its own dependencies, it should not follow dependencies while packaging. Bug: 139772411 Test: TARGET_VNDK_USE_CORE_VARIANT=true m com.android.vndk.current see if there are unexpected libs in the apex for example, android.hardware.audio.common@2.0.so should not be included in the apex since it is not listed as "must use vendor variant". Change-Id: Ibada600b3099fb19630d1e327a2e09cd26b2deb0
2019-10-28 21:08:31 +01:00
} else if !a.vndkApex {
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
// indirect dependencies
apex: add llndk libs as requireNativeLibs "use_vendor: true" APEX modules may bundle vendor variants of cc modules, which can depend on llndk stubs. In that case, those llndk libraries should be also counted as required libraries. (stored in 'requireNativeLibs' key in apex_manifest.json) Bug: 138695532 Test: m nothing (runs soong tests) Change-Id: If7ad4dec0e723c8d0c73ca60453b555063e14694
2019-08-20 10:30:57 +02:00
if am, ok := child.(android.ApexModule); ok {
Handle `test_per_src` modules as indirect dependencies in APEXes. In `apex.apexBundle.GenerateAndroidBuildActions`, we used to pass the "all tests" ("") module as `module` for all `apexFile` objects created from a test module using `test_per_src: true`. An immediate issue of this situation was that the "" module is hidden from Make, which made all the generated `apexFile` objects hidden from Make too. This would break the construction of flattened APEXes, as they rely on Make logic to install their files. Instead of collecting `test_per_src` test variations' output files in `cc.Module.GenerateAndroidBuildActions` and using them in `apex.apexBundle.GenerateAndroidBuildActions` as part of handling the "" variation as a direct dependency of an `apexBundle`, process them as indirect dependencies (and do nothing for the "" variation direct dependency). Adjust the indirect dependency logic in `apex.apexBundle.GenerateAndroidBuildActions` to allow not only shared/runtime native libraries as indirect dependencies of an `apexBundle`, but also `test_per_src` tests. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: I845e0f0dd3a98d61d0b7118c5eaf61f3e5335724
2019-07-29 17:22:59 +02:00
// We cannot use a switch statement on `depTag` here as the checked
// tags used below are private (e.g. `cc.sharedDepTag`).
Reland: JNI lib is always embedded for APKs in APEX If a JNI lib is depended on by an APK that is included in an APEX, the lib is embedded inside the APK. This change also fixes a bug that APKs are not mutated for APEXes. Bug: 144135069 Test: m (apex_test.go amended) Change-Id: I21ac24412b30c05afc03385655c6b196130dffe3
2019-11-11 02:14:32 +01:00
if cc.IsSharedDepTag(depTag) || cc.IsRuntimeDepTag(depTag) {
Handle `test_per_src` modules as indirect dependencies in APEXes. In `apex.apexBundle.GenerateAndroidBuildActions`, we used to pass the "all tests" ("") module as `module` for all `apexFile` objects created from a test module using `test_per_src: true`. An immediate issue of this situation was that the "" module is hidden from Make, which made all the generated `apexFile` objects hidden from Make too. This would break the construction of flattened APEXes, as they rely on Make logic to install their files. Instead of collecting `test_per_src` test variations' output files in `cc.Module.GenerateAndroidBuildActions` and using them in `apex.apexBundle.GenerateAndroidBuildActions` as part of handling the "" variation as a direct dependency of an `apexBundle`, process them as indirect dependencies (and do nothing for the "" variation direct dependency). Adjust the indirect dependency logic in `apex.apexBundle.GenerateAndroidBuildActions` to allow not only shared/runtime native libraries as indirect dependencies of an `apexBundle`, but also `test_per_src` tests. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: I845e0f0dd3a98d61d0b7118c5eaf61f3e5335724
2019-07-29 17:22:59 +02:00
if cc, ok := child.(*cc.Module); ok {
if android.InList(cc.Name(), providedNativeSharedLibs) {
// If we're using a shared library which is provided from other APEX,
// don't include it in this APEX
return false
}
Fix apex to follow deps of modules with stubs. In case that an apex module depends on a module with stubs directly *and* indirectly, the build system should follow the deps graph further. Note that WalkDeps() visits deps in DFS and it won't visit again visited modules. Bug: n/a Test: m (apex_test.go amended) Change-Id: I1a6f135dbda6d1eb641575a3fbbc9bbee0622076
2019-12-17 04:47:13 +01:00
if !a.Host() && !android.DirectlyInApex(ctx.ModuleName(), ctx.OtherModuleName(cc)) && (cc.IsStubs() || cc.HasStubsVariants()) {
Handle `test_per_src` modules as indirect dependencies in APEXes. In `apex.apexBundle.GenerateAndroidBuildActions`, we used to pass the "all tests" ("") module as `module` for all `apexFile` objects created from a test module using `test_per_src: true`. An immediate issue of this situation was that the "" module is hidden from Make, which made all the generated `apexFile` objects hidden from Make too. This would break the construction of flattened APEXes, as they rely on Make logic to install their files. Instead of collecting `test_per_src` test variations' output files in `cc.Module.GenerateAndroidBuildActions` and using them in `apex.apexBundle.GenerateAndroidBuildActions` as part of handling the "" variation as a direct dependency of an `apexBundle`, process them as indirect dependencies (and do nothing for the "" variation direct dependency). Adjust the indirect dependency logic in `apex.apexBundle.GenerateAndroidBuildActions` to allow not only shared/runtime native libraries as indirect dependencies of an `apexBundle`, but also `test_per_src` tests. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: I845e0f0dd3a98d61d0b7118c5eaf61f3e5335724
2019-07-29 17:22:59 +02:00
// If the dependency is a stubs lib, don't include it in this APEX,
// but make sure that the lib is installed on the device.
// In case no APEX is having the lib, the lib is installed to the system
// partition.
//
// Always include if we are a host-apex however since those won't have any
// system libraries.
Reland "m <apex_name>-deps-info prints the internal/external deps of the APEX"" This reverts commit 4513f703f9902193fc5c29607ddb4a8f71bfd702. Bug: 1190898 Test: m Test: EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true NATIVE_COVERAGE=true m dist Change-Id: I50fdccabb43e4751694db83ee451d388657257e0
2020-01-09 04:32:06 +01:00
if !android.DirectlyInAnyApex(ctx, cc.Name()) && !android.InList(cc.Name(), a.requiredDeps) {
a.requiredDeps = append(a.requiredDeps, cc.Name())
Handle `test_per_src` modules as indirect dependencies in APEXes. In `apex.apexBundle.GenerateAndroidBuildActions`, we used to pass the "all tests" ("") module as `module` for all `apexFile` objects created from a test module using `test_per_src: true`. An immediate issue of this situation was that the "" module is hidden from Make, which made all the generated `apexFile` objects hidden from Make too. This would break the construction of flattened APEXes, as they rely on Make logic to install their files. Instead of collecting `test_per_src` test variations' output files in `cc.Module.GenerateAndroidBuildActions` and using them in `apex.apexBundle.GenerateAndroidBuildActions` as part of handling the "" variation as a direct dependency of an `apexBundle`, process them as indirect dependencies (and do nothing for the "" variation direct dependency). Adjust the indirect dependency logic in `apex.apexBundle.GenerateAndroidBuildActions` to allow not only shared/runtime native libraries as indirect dependencies of an `apexBundle`, but also `test_per_src` tests. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: I845e0f0dd3a98d61d0b7118c5eaf61f3e5335724
2019-07-29 17:22:59 +02:00
}
Put dependency in apex_manifest.json To generate ld.config.txt dynamically(b/123722631), each APEX should provide some dependency information: a) list of libraries which other APEXes(or system) can use from this apex b) list of libraries which this apex uses from other APEXes(or system) This change puts dependency information in apex_manifest.json at build-time with two additional keys: a) provideNativeLibs b) requireNativeLibs Bug: 138695532 Test: m (runs soong tests) Test: find $OUT/apex -name apex_manifest.json -exec cat {} \; (shows contents of apex_manifest.json files) Change-Id: Iaad12c8c35454222ad177ce923cce76ef12a8a5a
2019-08-01 10:41:43 +02:00
requireNativeLibs = append(requireNativeLibs, cc.OutputFile().Path().Base())
Handle `test_per_src` modules as indirect dependencies in APEXes. In `apex.apexBundle.GenerateAndroidBuildActions`, we used to pass the "all tests" ("") module as `module` for all `apexFile` objects created from a test module using `test_per_src: true`. An immediate issue of this situation was that the "" module is hidden from Make, which made all the generated `apexFile` objects hidden from Make too. This would break the construction of flattened APEXes, as they rely on Make logic to install their files. Instead of collecting `test_per_src` test variations' output files in `cc.Module.GenerateAndroidBuildActions` and using them in `apex.apexBundle.GenerateAndroidBuildActions` as part of handling the "" variation as a direct dependency of an `apexBundle`, process them as indirect dependencies (and do nothing for the "" variation direct dependency). Adjust the indirect dependency logic in `apex.apexBundle.GenerateAndroidBuildActions` to allow not only shared/runtime native libraries as indirect dependencies of an `apexBundle`, but also `test_per_src` tests. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: I845e0f0dd3a98d61d0b7118c5eaf61f3e5335724
2019-07-29 17:22:59 +02:00
// Don't track further
return false
Install external deps of an APEX By default, if a lib is included in an APEX, all its direct and indirect dependencies are also included in the same APEX. However, when one of the dependencies have stable API (i.e. has stubs: {...}) then the lib having stable API and its dependencies are not included in the APEX. However, the problem here is that the lib having stable API might not be installed on the system, thus causing error at runtime. This can happen if there is no other module in the platform that depends on the lib. This change fixes the problem by adding such libraries as external dependencies so that they are also installed on the device along with the APEXes using them. Bug: 124831003 Test: m installclean; m com.android.resolv libbinder_ndk, libvndksupport are found under system/lib Change-Id: I457e03ff3fce37e0890c64d911e6e0ea6d0c6dd6
2019-02-20 13:49:26 +01:00
}
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
af := apexFileForNativeLibrary(ctx, cc, handleSpecialLibs)
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
af.transitiveDep = true
filesInfo = append(filesInfo, af)
return true // track transitive dependencies
Stubs variant is used when building for APEX When a native module is built for an APEX and is depending on a native library having stubs (i.e. stubs.versions property is set), the stubs variant is used unless the dependent lib is directly included in the same APEX with the depending module. Example: apex { name: "myapex", native_shared_libs: ["libX", "libY"], } cc_library { name: "libX", shared_libs: ["libY", "libZ"], } cc_library { name: "libY", stubs: { versions: ["1", "2"], }, } cc_library { name: "libZ", stubs: { versions: ["1", "2"], }, } In this case, libX is linking to the impl variant of libY (that provides private APIs) while libY is linking to the version 2 stubs of libZ. This is because libY is directly included in the same apex via native_shared_libs property, but libZ isn't. Bug: 112672359 Test: apex_test added Change-Id: If9871b70dc74a06bd828dd4cd1aeebd2e68b837c
2018-11-18 10:02:45 +01:00
}
Handle `test_per_src` modules as indirect dependencies in APEXes. In `apex.apexBundle.GenerateAndroidBuildActions`, we used to pass the "all tests" ("") module as `module` for all `apexFile` objects created from a test module using `test_per_src: true`. An immediate issue of this situation was that the "" module is hidden from Make, which made all the generated `apexFile` objects hidden from Make too. This would break the construction of flattened APEXes, as they rely on Make logic to install their files. Instead of collecting `test_per_src` test variations' output files in `cc.Module.GenerateAndroidBuildActions` and using them in `apex.apexBundle.GenerateAndroidBuildActions` as part of handling the "" variation as a direct dependency of an `apexBundle`, process them as indirect dependencies (and do nothing for the "" variation direct dependency). Adjust the indirect dependency logic in `apex.apexBundle.GenerateAndroidBuildActions` to allow not only shared/runtime native libraries as indirect dependencies of an `apexBundle`, but also `test_per_src` tests. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: I845e0f0dd3a98d61d0b7118c5eaf61f3e5335724
2019-07-29 17:22:59 +02:00
} else if cc.IsTestPerSrcDepTag(depTag) {
if cc, ok := child.(*cc.Module); ok {
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
af := apexFileForExecutable(ctx, cc)
Handle `test_per_src` modules as indirect dependencies in APEXes. In `apex.apexBundle.GenerateAndroidBuildActions`, we used to pass the "all tests" ("") module as `module` for all `apexFile` objects created from a test module using `test_per_src: true`. An immediate issue of this situation was that the "" module is hidden from Make, which made all the generated `apexFile` objects hidden from Make too. This would break the construction of flattened APEXes, as they rely on Make logic to install their files. Instead of collecting `test_per_src` test variations' output files in `cc.Module.GenerateAndroidBuildActions` and using them in `apex.apexBundle.GenerateAndroidBuildActions` as part of handling the "" variation as a direct dependency of an `apexBundle`, process them as indirect dependencies (and do nothing for the "" variation direct dependency). Adjust the indirect dependency logic in `apex.apexBundle.GenerateAndroidBuildActions` to allow not only shared/runtime native libraries as indirect dependencies of an `apexBundle`, but also `test_per_src` tests. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: I845e0f0dd3a98d61d0b7118c5eaf61f3e5335724
2019-07-29 17:22:59 +02:00
// Handle modules created as `test_per_src` variations of a single test module:
// use the name of the generated test binary (`fileToCopy`) instead of the name
// of the original test module (`depName`, shared by all `test_per_src`
// variations of that module).
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
af.moduleName = filepath.Base(af.builtFile.String())
Reland "use symlink for bundled APEX" This reverts commit 31c65d4fe474d26b6144c9b76365a207077a61c4. Bug: 144533348 Test: checkout master-art-host and run ALLOW_MISSING_DEPENDENCIES=true DIST_DIR=out/dist /art/tools/dist_linux_bionic.sh -j80 com.android.art.host the result is successful Change-Id: Ica11eec9b64867088b16720a41c6d83905976ec5
2020-01-14 01:22:18 +01:00
// these are not considered transitive dep
af.transitiveDep = false
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
filesInfo = append(filesInfo, af)
return true // track transitive dependencies
Handle `test_per_src` modules as indirect dependencies in APEXes. In `apex.apexBundle.GenerateAndroidBuildActions`, we used to pass the "all tests" ("") module as `module` for all `apexFile` objects created from a test module using `test_per_src: true`. An immediate issue of this situation was that the "" module is hidden from Make, which made all the generated `apexFile` objects hidden from Make too. This would break the construction of flattened APEXes, as they rely on Make logic to install their files. Instead of collecting `test_per_src` test variations' output files in `cc.Module.GenerateAndroidBuildActions` and using them in `apex.apexBundle.GenerateAndroidBuildActions` as part of handling the "" variation as a direct dependency of an `apexBundle`, process them as indirect dependencies (and do nothing for the "" variation direct dependency). Adjust the indirect dependency logic in `apex.apexBundle.GenerateAndroidBuildActions` to allow not only shared/runtime native libraries as indirect dependencies of an `apexBundle`, but also `test_per_src` tests. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: I845e0f0dd3a98d61d0b7118c5eaf61f3e5335724
2019-07-29 17:22:59 +02:00
}
Reland: JNI lib is always embedded for APKs in APEX If a JNI lib is depended on by an APK that is included in an APEX, the lib is embedded inside the APK. This change also fixes a bug that APKs are not mutated for APEXes. Bug: 144135069 Test: m (apex_test.go amended) Change-Id: I21ac24412b30c05afc03385655c6b196130dffe3
2019-11-11 02:14:32 +01:00
} else if java.IsJniDepTag(depTag) {
apex: do not follow jni_libs from android_app 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 b7bebe2616184a02008d6ed3729845445a2310ca)
2020-02-25 08:59:29 +01:00
// Because APK-in-APEX embeds jni_libs transitively, we don't need to track transitive deps
return false
Permissions XML file for java_sdk_library is mutated for APEX 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
2020-02-17 09:28:10 +01:00
} else if java.IsXmlPermissionsFileDepTag(depTag) {
if prebuilt, ok := child.(android.PrebuiltEtcModule); ok {
filesInfo = append(filesInfo, apexFileForPrebuiltEtc(ctx, prebuilt, depName))
}
apex: add llndk libs as requireNativeLibs "use_vendor: true" APEX modules may bundle vendor variants of cc modules, which can depend on llndk stubs. In that case, those llndk libraries should be also counted as required libraries. (stored in 'requireNativeLibs' key in apex_manifest.json) Bug: 138695532 Test: m nothing (runs soong tests) Change-Id: If7ad4dec0e723c8d0c73ca60453b555063e14694
2019-08-20 10:30:57 +02:00
} else if am.CanHaveApexVariants() && am.IsInstallableToApex() {
Handle `test_per_src` modules as indirect dependencies in APEXes. In `apex.apexBundle.GenerateAndroidBuildActions`, we used to pass the "all tests" ("") module as `module` for all `apexFile` objects created from a test module using `test_per_src: true`. An immediate issue of this situation was that the "" module is hidden from Make, which made all the generated `apexFile` objects hidden from Make too. This would break the construction of flattened APEXes, as they rely on Make logic to install their files. Instead of collecting `test_per_src` test variations' output files in `cc.Module.GenerateAndroidBuildActions` and using them in `apex.apexBundle.GenerateAndroidBuildActions` as part of handling the "" variation as a direct dependency of an `apexBundle`, process them as indirect dependencies (and do nothing for the "" variation direct dependency). Adjust the indirect dependency logic in `apex.apexBundle.GenerateAndroidBuildActions` to allow not only shared/runtime native libraries as indirect dependencies of an `apexBundle`, but also `test_per_src` tests. Test: m (`apex/apex_test.go` amended) Bug: 129534335 Change-Id: I845e0f0dd3a98d61d0b7118c5eaf61f3e5335724
2019-07-29 17:22:59 +02:00
ctx.ModuleErrorf("unexpected tag %q for indirect dependency %q", depTag, depName)
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
}
}
}
return false
})
Revert^4 "Package dexpreopt artifacts for libcore jars in the ART apex." This reverts commit bf0e47648ab6cba10e10d07693bf0c813905396c. Reason for revert: coverage build with EMMA_INSTRUMENT_FRAMEWORK=true is fixed by inspecting the environment variable and not generating boot image in case it is set. Dexpreopt artifacts for the libcore part of the boot class path are now packaged in the ART apex. The system image still contains dexpreopt artifacts for the full set of boot class path libraries (both libcore and framework); the libcore part will be removed and boot image extension will be used in a follow-up CL. Since this is specific to the ART apex and makes no sense for other apexes, the implementation adds a boolean flag "is ART apex" rather than a new apex module property. Build rules for the new set of dexpreopt artifacts are created using a new variant of the global boot image config. Previously we had two variants: "default" (for the system image) and "apex" (for the JIT-zygote experiment). This patch adds a third "art" variant. Test: m Test: m art/build/apex/runtests.sh Bug: 144091989 Change-Id: I113c0d39222d6d697cb62cd09d5010607872fc2b
2019-11-08 11:51:01 +01:00
// Specific to the ART apex: dexpreopt artifacts for libcore Java libraries.
// Build rules are generated by the dexpreopt singleton, and here we access build artifacts
// via the global boot image config.
if a.artApex {
for arch, files := range java.DexpreoptedArtApexJars(ctx) {
dirInApex := filepath.Join("javalib", arch.String())
for _, f := range files {
localModule := "javalib_" + arch.String() + "_" + filepath.Base(f.String())
fix: LOCAL_PATH for modules included in APEX is wrong This change fixes a bug that LOCAL_PATH for modules included in an APEX is set to the path of the APEX bundle, not to the path of the embedded module. For example, LOCAL_PATH of libconscrypt included in com.android.adbd was set to /system/core/adb instead of /external/boringssl. This caused a problem that NOTICE file in /external/boringssl is not tagged to libconscrypt, but the NOTICE file for adbd is. Fixing the problem by recording the module directories of the included modules and emitting it in LOCAL_PATH. Bug: 145347092 Test: Settings -> About Phone -> Legal Information -> Third-party license. The license for /apex/com.android.adbd/lib64/libconscrypt.so is OpenSSL. Change-Id: I76f1830d5a10af63fa74dcc2a42730ffabb8c4ed
2019-12-13 05:28:36 +01:00
af := newApexFile(ctx, f, localModule, dirInApex, etc, nil)
Refactor the routine for creating apexFile This change is to make it easier to add new fields to the struct. transitiveDep field is added to distinguish apexFiles coming from transitive dependencies of the APEX. We will later use the info to reduce the size of bundled APEXes by replacing the transitive deps with symlinks to the corresponding files in the system partition outside of the APEX. Bug: 144533348 Test: m Change-Id: I283859f2f2f1b5cfb3025569f168ba8569b22bb9
2019-11-18 07:39:01 +01:00
filesInfo = append(filesInfo, af)
Revert^4 "Package dexpreopt artifacts for libcore jars in the ART apex." This reverts commit bf0e47648ab6cba10e10d07693bf0c813905396c. Reason for revert: coverage build with EMMA_INSTRUMENT_FRAMEWORK=true is fixed by inspecting the environment variable and not generating boot image in case it is set. Dexpreopt artifacts for the libcore part of the boot class path are now packaged in the ART apex. The system image still contains dexpreopt artifacts for the full set of boot class path libraries (both libcore and framework); the libcore part will be removed and boot image extension will be used in a follow-up CL. Since this is specific to the ART apex and makes no sense for other apexes, the implementation adds a boolean flag "is ART apex" rather than a new apex module property. Build rules for the new set of dexpreopt artifacts are created using a new variant of the global boot image config. Previously we had two variants: "default" (for the system image) and "apex" (for the JIT-zygote experiment). This patch adds a third "art" variant. Test: m Test: m art/build/apex/runtests.sh Bug: 144091989 Change-Id: I113c0d39222d6d697cb62cd09d5010607872fc2b
2019-11-08 11:51:01 +01:00
}
}
}
build apexkeys.txt apexkeys.txt is a text file having APEX-to-keys mappings. The file is included in the target-files package where it is used when re-sign the APEXes with release keys. Each line of the file consists of 5 fields: 1) name: file name of the APEX 2) public_key: the public key for the apex_payload.img of the APEX 3) private_key: the private key used to sign the apex_payload.img 4) container_certificate: the certificate used to sign the APEX zip container 5) container_private_key: the private key used to sign the APEX zip container Bug: 124406181 Test: m out/soong/apexkeys.txt and inspect the content Test: TARGET_BUILD_APPS=com.android.tzdata m dist and make sure out/dist/apexkeys.txt exists Change-Id: I1daa13ec50956323b97e15e8df7f1fbe5ea21d63
2019-02-18 07:25:04 +01:00
if a.private_key_file == nil {
Fail gracefully when apek_key is not found When the private key file can not be obtained, e.g., due to missing git project where the apex_key module is defined, fail gracefully with an error message instead of panicing. Bug: 119256776 Test: modify the key property in /systme/apex/Android.bp to apex.test.key2 and run `ALLOW_MISSING_DEPENDENCIES=true m apex.test` The build fails with error: system/apex/Android.bp:32:8: module "apex.test" variant "android_common_apex.test": key: private_key for "apex.test.key2" could not be found Change-Id: I2cd5fed0f046de1f0b380fbdac5f8b82816b0e24
2018-11-08 21:52:26 +01:00
ctx.PropertyErrorf("key", "private_key for %q could not be found", String(a.properties.Key))
return
}
APEX can be flattened When TARGET_FLATTEN_APEX is set to true, APEXes are flattened, which means files in an APEX is not packaged into the mini file system image, but instead directly copied to the system partition. This option is for devices where kernel does not support loopback devices or the maximum number of loopback devices is too small (though the threshold is TBD as of now). This CL also fixes a bug that jars having bytecode are installed instead of those having dex. Bug: 118485880 Test: TARGET_FLATTEN_APEX=true m apex.test; tree out/target/product/.../system/apex/apex.test shows list of files in it. Test; m apex.test, then a file out/target/product/.../system/apex/apex .test.apex exists. Change-Id: I5a3d62d392d05f2779c4925388afe4f6e460059b
2018-11-07 18:50:25 +01:00
// remove duplicates in filesInfo
removeDup := func(filesInfo []apexFile) []apexFile {
Reland "use symlink for bundled APEX" This reverts commit 31c65d4fe474d26b6144c9b76365a207077a61c4. Bug: 144533348 Test: checkout master-art-host and run ALLOW_MISSING_DEPENDENCIES=true DIST_DIR=out/dist /art/tools/dist_linux_bionic.sh -j80 com.android.art.host the result is successful Change-Id: Ica11eec9b64867088b16720a41c6d83905976ec5
2020-01-14 01:22:18 +01:00
encountered := make(map[string]apexFile)
APEX can be flattened When TARGET_FLATTEN_APEX is set to true, APEXes are flattened, which means files in an APEX is not packaged into the mini file system image, but instead directly copied to the system partition. This option is for devices where kernel does not support loopback devices or the maximum number of loopback devices is too small (though the threshold is TBD as of now). This CL also fixes a bug that jars having bytecode are installed instead of those having dex. Bug: 118485880 Test: TARGET_FLATTEN_APEX=true m apex.test; tree out/target/product/.../system/apex/apex.test shows list of files in it. Test; m apex.test, then a file out/target/product/.../system/apex/apex .test.apex exists. Change-Id: I5a3d62d392d05f2779c4925388afe4f6e460059b
2018-11-07 18:50:25 +01:00
for _, f := range filesInfo {
Add "apex_vndk" module type "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
2019-08-23 04:17:39 +02:00
dest := filepath.Join(f.installDir, f.builtFile.Base())
Reland "use symlink for bundled APEX" This reverts commit 31c65d4fe474d26b6144c9b76365a207077a61c4. Bug: 144533348 Test: checkout master-art-host and run ALLOW_MISSING_DEPENDENCIES=true DIST_DIR=out/dist /art/tools/dist_linux_bionic.sh -j80 com.android.art.host the result is successful Change-Id: Ica11eec9b64867088b16720a41c6d83905976ec5
2020-01-14 01:22:18 +01:00
if e, ok := encountered[dest]; !ok {
encountered[dest] = f
} else {
// If a module is directly included and also transitively depended on
// consider it as directly included.
e.transitiveDep = e.transitiveDep && f.transitiveDep
encountered[dest] = e
APEX can be flattened When TARGET_FLATTEN_APEX is set to true, APEXes are flattened, which means files in an APEX is not packaged into the mini file system image, but instead directly copied to the system partition. This option is for devices where kernel does not support loopback devices or the maximum number of loopback devices is too small (though the threshold is TBD as of now). This CL also fixes a bug that jars having bytecode are installed instead of those having dex. Bug: 118485880 Test: TARGET_FLATTEN_APEX=true m apex.test; tree out/target/product/.../system/apex/apex.test shows list of files in it. Test; m apex.test, then a file out/target/product/.../system/apex/apex .test.apex exists. Change-Id: I5a3d62d392d05f2779c4925388afe4f6e460059b
2018-11-07 18:50:25 +01:00
}
}
Reland "use symlink for bundled APEX" This reverts commit 31c65d4fe474d26b6144c9b76365a207077a61c4. Bug: 144533348 Test: checkout master-art-host and run ALLOW_MISSING_DEPENDENCIES=true DIST_DIR=out/dist /art/tools/dist_linux_bionic.sh -j80 com.android.art.host the result is successful Change-Id: Ica11eec9b64867088b16720a41c6d83905976ec5
2020-01-14 01:22:18 +01:00
var result []apexFile
for _, v := range encountered {
result = append(result, v)
}
APEX can be flattened When TARGET_FLATTEN_APEX is set to true, APEXes are flattened, which means files in an APEX is not packaged into the mini file system image, but instead directly copied to the system partition. This option is for devices where kernel does not support loopback devices or the maximum number of loopback devices is too small (though the threshold is TBD as of now). This CL also fixes a bug that jars having bytecode are installed instead of those having dex. Bug: 118485880 Test: TARGET_FLATTEN_APEX=true m apex.test; tree out/target/product/.../system/apex/apex.test shows list of files in it. Test; m apex.test, then a file out/target/product/.../system/apex/apex .test.apex exists. Change-Id: I5a3d62d392d05f2779c4925388afe4f6e460059b
2018-11-07 18:50:25 +01:00
return result
}
filesInfo = removeDup(filesInfo)
// to have consistent build rules
sort.Slice(filesInfo, func(i, j int) bool {
return filesInfo[i].builtFile.String() < filesInfo[j].builtFile.String()
})
a.installDir = android.PathForModuleInstall(ctx, "apex")
a.filesInfo = filesInfo
Add zip-apex This adds support for an apex-like file where the payload is a zip file instead of a FS image. This makes it easier to examine and use without root. These can also be built for the host. This can be controlled using the 'type' modifier in the apex build rule. 'type' may be "image" to build an apex file called {name}.apex with an FS image payload, "zip" to build an apex with called {name}.zipapex with a zip-file payload or "both" to build both. By default we will use "image". This also adds support for setting apex rules to "host_supported: true". Test: cd art/build/apex; mma; examine the com.android.runtime.host.zipapex artifact. Test: go test android/soong/apex -v Bug: 120436895 Change-Id: I534d330672211ac5ccc3bd5a0c89b9fc507bf51e
2018-11-30 02:12:15 +01:00
Make 'file_contexts' prop as `android:"path"` For platform APEXes, file_contexts should point a file under /system/sepolicy. Bug: 144732805 Test: m Change-Id: Ib2d5db715bbebc80a6178d1c42e387b268cc4a0d
2019-11-19 18:26:02 +01:00
if a.properties.ApexType != zipApex {
if a.properties.File_contexts == nil {
a.fileContexts = android.PathForSource(ctx, "system/sepolicy/apex", ctx.ModuleName()+"-file_contexts")
} else {
a.fileContexts = android.PathForModuleSrc(ctx, *a.properties.File_contexts)
if a.Platform() {
if matched, err := path.Match("system/sepolicy/**/*", a.fileContexts.String()); err != nil || !matched {
ctx.PropertyErrorf("file_contexts", "should be under system/sepolicy, but %q", a.fileContexts)
}
}
}
if !android.ExistentPathForSource(ctx, a.fileContexts.String()).Valid() {
ctx.PropertyErrorf("file_contexts", "cannot find file_contexts file: %q", a.fileContexts)
return
}
}
Reland "use symlink for bundled APEX" This reverts commit 31c65d4fe474d26b6144c9b76365a207077a61c4. Bug: 144533348 Test: checkout master-art-host and run ALLOW_MISSING_DEPENDENCIES=true DIST_DIR=out/dist /art/tools/dist_linux_bionic.sh -j80 com.android.art.host the result is successful Change-Id: Ica11eec9b64867088b16720a41c6d83905976ec5
2020-01-14 01:22:18 +01:00
// Optimization. If we are building bundled APEX, for the files that are gathered due to the
// transitive dependencies, don't place them inside the APEX, but place a symlink pointing
// the same library in the system partition, thus effectively sharing the same libraries
// across the APEX boundary. For unbundled APEX, all the gathered files are actually placed
// in the APEX.
a.linkToSystemLib = !ctx.Config().UnbundledBuild() &&
a.installable() &&
!proptools.Bool(a.properties.Use_vendor)
Make 'file_contexts' prop as `android:"path"` For platform APEXes, file_contexts should point a file under /system/sepolicy. Bug: 144732805 Test: m Change-Id: Ib2d5db715bbebc80a6178d1c42e387b268cc4a0d
2019-11-19 18:26:02 +01:00
have a per-module switch to turn the symlinking optimizaiton off 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
2020-02-19 08:29:35 +01:00
// We don't need the optimization for updatable APEXes, as it might give false signal
// to the system health when the APEXes are still bundled (b/149805758)
if proptools.Bool(a.properties.Updatable) && a.properties.ApexType == imageApex {
a.linkToSystemLib = false
}
No symlink for host APEXes Symlinking doesn't make sense for host APEXes. Bug: 150255435 Test: m com.android.art.host and inspect the built APEX; there is no symlink. Change-Id: I28492dfaaef471117a430be05255fbef76e557b0
2020-02-26 10:27:19 +01:00
// We also don't want the optimization for host APEXes, because it doesn't make sense.
if ctx.Host() {
a.linkToSystemLib = false
}
respect "apex_name:" for "apex" module 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
2019-09-26 17:38:03 +02:00
// prepare apex_manifest.json
apex_manifest in protobuf binary format For Q compatibility, .json files are also bundled. Three different apex_manifest files are built from input. - apex_manifest.json: Q-readable .json file - apex_manifest_full.json: input + dependency - apex_manifest.pb: apex: converted from apex_manifest_full.json apexer will handle these files. Bug: 143654022 Test: m Change-Id: I9697094057f0c0543282b1b46b7535cf21431176
2019-11-01 18:52:25 +01:00
a.buildManifest(ctx, provideNativeLibs, requireNativeLibs)
a.setCertificateAndPrivateKey(ctx)
if a.properties.ApexType == flattenedApex {
a.buildFlattenedApex(ctx)
} else {
a.buildUnflattenedApex(ctx)
}
Add compat symlinks for prebuilt_apex When prebuilt_apex overrides/replaces other apex, the same symlinks need to be created as well. Bug: 143192278 Test: 1. add prebuilt_apex with vndk apex with overrides set as ["com.android.vndk.current"] 2. m <prebuilt apex> 3. check if vndk symlinks are created Change-Id: I8ee9c981ea9c7202ccf5143b3f43e6848773cd63
2020-01-07 17:57:58 +01:00
a.compatSymlinks = makeCompatSymlinks(a.BaseModuleName(), ctx)
Reland "m <apex_name>-deps-info prints the internal/external deps of the APEX"" This reverts commit 4513f703f9902193fc5c29607ddb4a8f71bfd702. Bug: 1190898 Test: m Test: EMMA_INSTRUMENT=true EMMA_INSTRUMENT_FRAMEWORK=true NATIVE_COVERAGE=true m dist Change-Id: I50fdccabb43e4751694db83ee451d388657257e0
2020-01-09 04:32:06 +01:00
a.buildApexDependencyInfo(ctx)
apex_manifest in protobuf binary format For Q compatibility, .json files are also bundled. Three different apex_manifest files are built from input. - apex_manifest.json: Q-readable .json file - apex_manifest_full.json: input + dependency - apex_manifest.pb: apex: converted from apex_manifest_full.json apexer will handle these files. Bug: 143654022 Test: m Change-Id: I9697094057f0c0543282b1b46b7535cf21431176
2019-11-01 18:52:25 +01:00
}
Fix apex_available 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 5e9013be2202effb500a0aa14d95f5fef70cc75e) Change-Id: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
2020-03-09 22:23:13 +01:00
func whitelistedApexAvailable(apex, moduleName string) bool {
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
key := apex
key = strings.Replace(key, "test_", "", 1)
key = strings.Replace(key, "com.android.art.debug", "com.android.art", 1)
key = strings.Replace(key, "com.android.art.release", "com.android.art", 1)
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
// Prebuilt modules (e.g. java_import, etc.) have "prebuilt_" prefix added by the build
// system. Trim the prefix for the check since they are confusing
moduleName = strings.TrimPrefix(moduleName, "prebuilt_")
if strings.HasPrefix(moduleName, "libclang_rt.") {
// This module has many arch variants that depend on the product being built.
// We don't want to list them all
moduleName = "libclang_rt"
}
if val, ok := apexAvailWl[key]; ok && android.InList(moduleName, val) {
return true
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
}
apex_available tracks static dependencies 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
2020-01-30 18:49:53 +01:00
key = "//any"
Default apex_available to //apex_available:platform This means everything that goes into apexes need to be explicitly labeled to be available for apex. Whitelist the current offenders. This list should be trimmed down. Bug: 147364041 Test: m Test: multiproduct_kati -only-soong Exempt-From-Owner-Approval: Just added more whitelist entries Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8
2020-01-10 16:12:39 +01:00
if val, ok := apexAvailWl[key]; ok && android.InList(moduleName, val) {
return true
}
return false
}
Add "apex_vndk" module type "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
2019-08-23 04:17:39 +02:00
func newApexBundle() *apexBundle {
Create variants for each image type Create variant of image, zip or flattened according to TARGET_FLATTEN_APEX and payload type. If payload type is zip, only zip variant is created because flattened apex is not supported. And if payload type is image, image and flattened variants are created. Bug: 139053989 Test: m -j Change-Id: Ibde18490d23ec602c4cca97cf97db90a562e014e
2019-10-22 06:58:29 +02:00
module := &apexBundle{}
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
module.AddProperties(&module.properties)
Add limited target-specific configuration to apex. Some apex targets need to be able to change their contents based on if they are host or target or what libc they are using. This adds support for doing this using the standard 'target: {...}' idiom. Test: m com.android.runtime.host Test: ./art/tools/build_linux_bionic.sh com.android.runtime.host Bug: 123591866 Change-Id: If73bee650cdeb277c0e603763aa0b0108656bfdd
2019-01-30 03:07:33 +01:00
module.AddProperties(&module.targetProperties)
Add override_apex module type override_apex module type is used to override existing apex module with certain properties overridden. Currently, only the 'apps' property is overridable. Bug: 144338929 Test: m Change-Id: Ic050b062093cda29ce78126cc92dd6097647f7db
2019-11-15 10:40:32 +01:00
module.AddProperties(&module.overridableProperties)
Add zip-apex This adds support for an apex-like file where the payload is a zip file instead of a FS image. This makes it easier to examine and use without root. These can also be built for the host. This can be controlled using the 'type' modifier in the apex build rule. 'type' may be "image" to build an apex file called {name}.apex with an FS image payload, "zip" to build an apex with called {name}.zipapex with a zip-file payload or "both" to build both. By default we will use "image". This also adds support for setting apex rules to "host_supported: true". Test: cd art/build/apex; mma; examine the com.android.runtime.host.zipapex artifact. Test: go test android/soong/apex -v Bug: 120436895 Change-Id: I534d330672211ac5ccc3bd5a0c89b9fc507bf51e
2018-11-30 02:12:15 +01:00
module.Prefer32(func(ctx android.BaseModuleContext, base *android.ModuleBase, class android.OsClass) bool {
binaries and native_shared_libraires are multilib-aware props The properties 'binaries' and 'native_shared_libraries' can be multilib-aware, i.e, can be under multilib.type where type can be either first, both, lib32, lib64, or prefer32. Native modules listed in multilib.first are installed only for the first ABI of the device. Similarily, multilib.both are for both of the ABIs, while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only, respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is available. Another change is that the binaries property, when not within multilib, targets only the first ABI. Test: m apex.test on ... 1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true 2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true 3) aosp_arm in all cases, vold, surfaceflinger and drmserver are all intalled under ./bin directory of the APEX. And native libraries are installed under both ./lib and ./lib64 directories in the case of 1) and 2). Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
return class == android.Device && ctx.Config().DevicePrefer32BitExecutables()
})
Add zip-apex This adds support for an apex-like file where the payload is a zip file instead of a FS image. This makes it easier to examine and use without root. These can also be built for the host. This can be controlled using the 'type' modifier in the apex build rule. 'type' may be "image" to build an apex file called {name}.apex with an FS image payload, "zip" to build an apex with called {name}.zipapex with a zip-file payload or "both" to build both. By default we will use "image". This also adds support for setting apex rules to "host_supported: true". Test: cd art/build/apex; mma; examine the com.android.runtime.host.zipapex artifact. Test: go test android/soong/apex -v Bug: 120436895 Change-Id: I534d330672211ac5ccc3bd5a0c89b9fc507bf51e
2018-11-30 02:12:15 +01:00
android.InitAndroidMultiTargetsArchModule(module, android.HostAndDeviceSupported, android.MultilibCommon)
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
android.InitDefaultableModule(module)
Introduce module type 'sdk' 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
2019-07-17 13:08:41 +02:00
android.InitSdkAwareModule(module)
Make apex.overrides overridable by override_apex. Test: apex_test.go Change-Id: Id47e5e5bec45ec1ada68f9d2d806585c5141a2f9
2019-12-20 02:32:06 +01:00
android.InitOverridableModule(module, &module.overridableProperties.Overrides)
Add apex variants Now, APEX-aware modules (the ones implementing android.ApexModule interface) are created with multiple variants for each APEX that they are included. For example, if a module is included (either directly or indirectly - via static linking) to two APEXs, the module is built separately for the two APEXs (and of course separately for platform). This is a first step to limit the symbol visibility to the modules built for APEXs; platform private symbols and libs shouldn't be allowed for them. In addition, the build system now tracks transitive dependencies of the modules in APEXs. For example, if native_shared_lib_modules:["libFoo"] then libFoo and its dependencies are all automatically included to the APEX. Bug: 112672359 Test: m apex.test; the built apex has additional libs (such as liblog, libc++, ...) that are dependencies of the ones specified in Android.bp Change-Id: Id9e3fc486dd4e7e36f8b6799dfb041868c5198d5
2018-10-10 07:01:00 +02:00
return module
}
add apex_defaults apex_defaults is the default module for apex. Bug: 124026431 Test: m (apex_test updated) Change-Id: I09f63046e909e8eeb52ecec6bb07eb51e5490561
2019-02-07 08:27:23 +01:00
Revert^4 "Package dexpreopt artifacts for libcore jars in the ART apex." This reverts commit bf0e47648ab6cba10e10d07693bf0c813905396c. Reason for revert: coverage build with EMMA_INSTRUMENT_FRAMEWORK=true is fixed by inspecting the environment variable and not generating boot image in case it is set. Dexpreopt artifacts for the libcore part of the boot class path are now packaged in the ART apex. The system image still contains dexpreopt artifacts for the full set of boot class path libraries (both libcore and framework); the libcore part will be removed and boot image extension will be used in a follow-up CL. Since this is specific to the ART apex and makes no sense for other apexes, the implementation adds a boolean flag "is ART apex" rather than a new apex module property. Build rules for the new set of dexpreopt artifacts are created using a new variant of the global boot image config. Previously we had two variants: "default" (for the system image) and "apex" (for the JIT-zygote experiment). This patch adds a third "art" variant. Test: m Test: m art/build/apex/runtests.sh Bug: 144091989 Change-Id: I113c0d39222d6d697cb62cd09d5010607872fc2b
2019-11-08 11:51:01 +01:00
func ApexBundleFactory(testApex bool, artApex bool) android.Module {
Add "apex_vndk" module type "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
2019-08-23 04:17:39 +02:00
bundle := newApexBundle()
bundle.testApex = testApex
Revert^4 "Package dexpreopt artifacts for libcore jars in the ART apex." This reverts commit bf0e47648ab6cba10e10d07693bf0c813905396c. Reason for revert: coverage build with EMMA_INSTRUMENT_FRAMEWORK=true is fixed by inspecting the environment variable and not generating boot image in case it is set. Dexpreopt artifacts for the libcore part of the boot class path are now packaged in the ART apex. The system image still contains dexpreopt artifacts for the full set of boot class path libraries (both libcore and framework); the libcore part will be removed and boot image extension will be used in a follow-up CL. Since this is specific to the ART apex and makes no sense for other apexes, the implementation adds a boolean flag "is ART apex" rather than a new apex module property. Build rules for the new set of dexpreopt artifacts are created using a new variant of the global boot image config. Previously we had two variants: "default" (for the system image) and "apex" (for the JIT-zygote experiment). This patch adds a third "art" variant. Test: m Test: m art/build/apex/runtests.sh Bug: 144091989 Change-Id: I113c0d39222d6d697cb62cd09d5010607872fc2b
2019-11-08 11:51:01 +01:00
bundle.artApex = artApex
Add "apex_vndk" module type "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
2019-08-23 04:17:39 +02:00
return bundle
}
Document apex and apex_test Bug: 149082647 Test: m Change-Id: I39e72eecda1d0e2984a3dde4987c4928f58d2afc
2020-02-10 19:56:06 +01:00
// apex_test is an APEX for testing. The difference from the ordinary apex module type is that
// certain compatibility checks such as apex_available are not done for apex_test.
Add "apex_vndk" module type "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
2019-08-23 04:17:39 +02:00
func testApexBundleFactory() android.Module {
bundle := newApexBundle()
bundle.testApex = true
return bundle
}
Document apex and apex_test Bug: 149082647 Test: m Change-Id: I39e72eecda1d0e2984a3dde4987c4928f58d2afc
2020-02-10 19:56:06 +01:00
// apex packages other modules into an APEX file which is a packaging format for system-level
// components like binaries, shared libraries, etc.
Introduce module type 'sdk' 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
2019-07-17 13:08:41 +02:00
func BundleFactory() android.Module {
Add "apex_vndk" module type "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
2019-08-23 04:17:39 +02:00
return newApexBundle()
}
add apex_defaults apex_defaults is the default module for apex. Bug: 124026431 Test: m (apex_test updated) Change-Id: I09f63046e909e8eeb52ecec6bb07eb51e5490561
2019-02-07 08:27:23 +01:00
//
// Defaults
//
type Defaults struct {
android.ModuleBase
android.DefaultsModuleBase
}
func defaultsFactory() android.Module {
return DefaultsFactory()
}
func DefaultsFactory(props ...interface{}) android.Module {
module := &Defaults{}
module.AddProperties(props...)
module.AddProperties(
&apexBundleProperties{},
&apexTargetBundleProperties{},
Support apps attribute in apex_defaults Adding overridableProperties to apex_defaults as well. Bug: 146217017 Test: m Change-Id: I51182fec25ee589fea4006164c4dd69acc5ba67d
2019-12-16 14:32:06 +01:00
&overridableProperties{},
add apex_defaults apex_defaults is the default module for apex. Bug: 124026431 Test: m (apex_test updated) Change-Id: I09f63046e909e8eeb52ecec6bb07eb51e5490561
2019-02-07 08:27:23 +01:00
)
android.InitDefaultsModule(module)
return module
}
Add override_apex module type override_apex module type is used to override existing apex module with certain properties overridden. Currently, only the 'apps' property is overridable. Bug: 144338929 Test: m Change-Id: Ic050b062093cda29ce78126cc92dd6097647f7db
2019-11-15 10:40:32 +01:00
//
// OverrideApex
//
type OverrideApex struct {
android.ModuleBase
android.OverrideModuleBase
}
func (o *OverrideApex) GenerateAndroidBuildActions(ctx android.ModuleContext) {
// All the overrides happen in the base module.
}
// override_apex is used to create an apex module based on another apex module
// by overriding some of its properties.
func overrideApexFactory() android.Module {
m := &OverrideApex{}
m.AddProperties(&overridableProperties{})
android.InitAndroidMultiTargetsArchModule(m, android.DeviceSupported, android.MultilibCommon)
android.InitOverrideModule(m)
return m
}
Reference in a new issue Copy permalink