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

2463 lines
78 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"
"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
Soong package structure refactoring Give prebuilt_etc and sh_binary their own packages and split the gigantic main Android.bp up to small, per-package ones. Test: m nothing, TreeHugger Bug: 156980228 Change-Id: I7b00cd344b9f16861f1ff39edf0029f016b853d0
2020-06-01 19:45:49 +02:00
"github.com/google/blueprint"
"github.com/google/blueprint/bootstrap"
"github.com/google/blueprint/proptools"
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"
Soong package structure refactoring Give prebuilt_etc and sh_binary their own packages and split the gigantic main Android.bp up to small, per-package ones. Test: m nothing, TreeHugger Bug: 156980228 Change-Id: I7b00cd344b9f16861f1ff39edf0029f016b853d0
2020-06-01 19:45:49 +02:00
prebuilt_etc "android/soong/etc"
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/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"
Soong package structure refactoring Give prebuilt_etc and sh_binary their own packages and split the gigantic main Android.bp up to small, per-package ones. Test: m nothing, TreeHugger Bug: 156980228 Change-Id: I7b00cd344b9f16861f1ff39edf0029f016b853d0
2020-06-01 19:45:49 +02:00
"android/soong/sh"
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 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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) 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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
sharedLibTag = dependencyTag{name: "sharedLib", payload: true}
Add "jni_libs" property to apex module Which is the list of JNI libraries that are embeded inside the apex. jni_libs is handled just like native_shared_libs except that it is stored in apex_manifest. When linkerconfig finds an apex with JNI libs, it exposes the namespace for the apex as visible so that libnativeloader can link the namespace to the corresponding classloader-namespace. Bug: 149363889 Test: m nothing(runs soong test) Change-Id: I52ebe38b44545e6e8853e34a3404a235c858112a
2020-02-27 05:50:06 +01:00
jniLibTag = dependencyTag{name: "jniLib", payload: true}
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
androidAppTag = dependencyTag{name: "androidApp", payload: true}
runtime_resource_overlay can be included in APEXes runtime_resource_overlay is put to an APEX via 'apps' property. It is placed under ./overlay directory in it. Bug: 154822536 Test: m Change-Id: I8edf4a26c26368c52fb7b327b2ecc829f21ea148
2020-04-24 14:16:36 +02:00
rroTag = dependencyTag{name: "rro", payload: true}
Copy white listed apex available settings into snapshot Makes sure that the module snapshots do not rely on the white list of apex available settings so that when those lists are removed it is not necessary to update any snapshots. Bug: 142935992 Test: m nothing Change-Id: Iedcff7dfc2646a4da77258d16e06657dd2f411f9
2020-03-06 13:30:13 +01:00
Use inclusive language in build/soong Test: m checkbuild Change-Id: Id07890b7cbc2397291a658ca00e86b43c743aafc
2020-06-11 20:32:11 +02:00
apexAvailBaseline = makeApexAvailableBaseline()
inverseApexAvailBaseline = invertApexBaseline(apexAvailBaseline)
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
)
Copy white listed apex available settings into snapshot Makes sure that the module snapshots do not rely on the white list of apex available settings so that when those lists are removed it is not necessary to update any snapshots. Bug: 142935992 Test: m nothing Change-Id: Iedcff7dfc2646a4da77258d16e06657dd2f411f9
2020-03-06 13:30:13 +01:00
// Transform the map of apex -> modules to module -> apexes.
Use inclusive language in build/soong Test: m checkbuild Change-Id: Id07890b7cbc2397291a658ca00e86b43c743aafc
2020-06-11 20:32:11 +02:00
func invertApexBaseline(m map[string][]string) map[string][]string {
Copy white listed apex available settings into snapshot Makes sure that the module snapshots do not rely on the white list of apex available settings so that when those lists are removed it is not necessary to update any snapshots. Bug: 142935992 Test: m nothing Change-Id: Iedcff7dfc2646a4da77258d16e06657dd2f411f9
2020-03-06 13:30:13 +01:00
r := make(map[string][]string)
for apex, modules := range m {
for _, module := range modules {
r[module] = append(r[module], apex)
}
}
return r
}
Use inclusive language in build/soong Test: m checkbuild Change-Id: Id07890b7cbc2397291a658ca00e86b43c743aafc
2020-06-11 20:32:11 +02:00
// Retrieve the baseline of apexes to which the supplied module belongs.
func BaselineApexAvailable(moduleName string) []string {
return inverseApexAvailBaseline[normalizeModuleName(moduleName)]
Copy white listed apex available settings into snapshot Makes sure that the module snapshots do not rely on the white list of apex available settings so that when those lists are removed it is not necessary to update any snapshots. Bug: 142935992 Test: m nothing Change-Id: Iedcff7dfc2646a4da77258d16e06657dd2f411f9
2020-03-06 13:30:13 +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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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
Use inclusive language in build/soong Test: m checkbuild Change-Id: Id07890b7cbc2397291a658ca00e86b43c743aafc
2020-06-11 20:32:11 +02:00
func makeApexAvailableBaseline() map[string][]string {
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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
2020-01-10 16:12:39 +01:00
// The "Module separator"s below are employed to minimize merge conflicts.
m := make(map[string][]string)
//
// 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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) 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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) 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",
"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. Bug: 151071238 Test: build/boot Change-Id: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
2020-03-09 22:23:13 +01:00
"dnsresolver_aidl_interface-V2-java",
"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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) 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",
"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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) 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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) 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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
2020-01-10 16:12:39 +01:00
"libchrome",
"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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"libg722codec",
"libgui_headers",
"libmedia_headers",
"libmodpb64",
"libosi",
"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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"libstatssocket",
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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"libudrv-uipc",
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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) 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. Bug: 151071238 Test: build/boot 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-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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) 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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
m["com.android.cellbroadcast"] = []string{"CellBroadcastApp", "CellBroadcastServiceModule"}
//
// 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",
"libarect",
"libbuildversion",
"libmath",
"libprocpartition",
"libsync",
}
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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) 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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) 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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) 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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"bionic_libc_platform_headers",
apex: Make android_library support APEX variants The android_library module type can be used within an android_app that can itself be added to an apex but android_library does not call android.InitApexModule(module) and so it does not support apex variants and so is treated as if it cannot be part of an APEX even though it actually is. Now, android_library supports AEPX variants. Due to this change, the whilelist for apex_available got bigger. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 156978407 Test: m Merged-In: I3a21d653fe9c4159e3a89791fe1a8597865eeae6 Change-Id: I3a21d653fe9c4159e3a89791fe1a8597865eeae6 (cherry picked from commit bd133b1bdc1de378992491c3154a9ec0b347f7c3)
2020-05-20 02:06:00 +02:00
"exoplayer2-extractor",
"exoplayer2-extractor-annotation-stubs",
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"gl_headers",
apex: Make android_library support APEX variants The android_library module type can be used within an android_app that can itself be added to an apex but android_library does not call android.InitApexModule(module) and so it does not support apex variants and so is treated as if it cannot be part of an APEX even though it actually is. Now, android_library supports AEPX variants. Due to this change, the whilelist for apex_available got bigger. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 156978407 Test: m Merged-In: I3a21d653fe9c4159e3a89791fe1a8597865eeae6 Change-Id: I3a21d653fe9c4159e3a89791fe1a8597865eeae6 (cherry picked from commit bd133b1bdc1de378992491c3154a9ec0b347f7c3)
2020-05-20 02:06:00 +02:00
"jsr305",
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"libarect",
"libaudio_system_headers",
"libaudioclient",
"libaudioclient_headers",
"libaudiofoundation",
"libaudiofoundation_headers",
"libaudiomanager",
"libaudiopolicy",
"libaudioutils",
"libaudioutils_fixedfft",
"libbinder_headers",
"libbluetooth-types-header",
"libbufferhub",
"libbufferhub_headers",
"libbufferhubqueue",
"libc_malloc_debug_backtrace",
"libcamera_client",
"libcamera_metadata",
"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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"libgrallocusage",
"libgraphicsenv",
"libgui",
"libgui_headers",
"libhardware_headers",
"libinput",
"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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) 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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"libpackagelistparser",
"libpdx",
"libpdx_default_transport",
"libpdx_headers",
"libpdx_uds",
"libprocinfo",
"libsonivox",
"libspeexresampler",
"libspeexresampler",
"libstagefright_esds",
"libstagefright_flacdec",
"libstagefright_flacdec",
"libstagefright_foundation",
"libstagefright_foundation_headers",
"libstagefright_foundation_without_imemory",
"libstagefright_headers",
"libstagefright_id3",
"libstagefright_metadatautils",
"libstagefright_mpeg2extractor",
"libstagefright_mpeg2support",
"libsync",
"libui",
"libui_headers",
"libunwindstack",
"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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) 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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
2020-01-10 16:12:39 +01:00
"updatable-media",
}
//
// Module separator
//
m["com.android.media.swcodec"] = []string{
"android.frameworks.bufferhub@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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"android.hardware.common-ndk_platform",
"android.hardware.configstore-utils",
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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
2020-01-10 16:12:39 +01:00
"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",
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) 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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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",
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"android.hardware.graphics.mapper@4.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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
2020-01-10 16:12:39 +01:00
"android.hardware.media.bufferpool@2.0",
"android.hardware.media.c2@1.0",
"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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) 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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) 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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"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. Bug: 151071238 Test: build/boot 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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"libarect",
"libaudio_system_headers",
"libaudioutils",
"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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"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. Bug: 151071238 Test: build/boot 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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) 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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
2020-01-10 16:12:39 +01:00
"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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) 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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
2020-01-10 16:12:39 +01:00
"libcodec2_hidl@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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"libcodec2_hidl@1.1",
"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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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",
"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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"libdvr_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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"libfmq",
"libgav1",
"libgralloctypes",
"libgrallocusage",
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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
2020-01-10 16:12:39 +01:00
"libgraphicsenv",
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) 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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"libjpeg",
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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"libmedia_headers",
"libmpeg2dec",
"libnativebase_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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
2020-01-10 16:12:39 +01:00
"libnativebridge_lazy",
"libnativeloader_lazy",
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"libnativewindow_headers",
"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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
2020-01-10 16:12:39 +01:00
"libscudo_wrapper",
"libsfplugin_ccodec_utils",
"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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) 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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) 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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
2020-01-10 16:12:39 +01:00
"libsync",
"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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"libui_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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
2020-01-10 16:12:39 +01:00
"libunwindstack",
"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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) 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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
2020-01-10 16:12:39 +01:00
"mediaswcodec",
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
}
//
// Module separator
//
m["com.android.mediaprovider"] = []string{
"MediaProvider",
"MediaProviderGoogle",
"fmtlib_ndk",
"libbase_ndk",
"libfuse",
"libfuse_jni",
}
//
// Module separator
//
m["com.android.permission"] = []string{
"kotlin-annotations",
"kotlin-stdlib",
"kotlin-stdlib-jdk7",
"kotlin-stdlib-jdk8",
"kotlinx-coroutines-android",
"kotlinx-coroutines-android-nodeps",
"kotlinx-coroutines-core",
"kotlinx-coroutines-core-nodeps",
"permissioncontroller-statsd",
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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"bionic_libc_platform_headers",
"libarm-optimized-routines-math",
"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_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",
"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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) 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. Bug: 151071238 Test: build/boot 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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"libjemalloc5",
"liblinker_main",
"liblinker_malloc",
"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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"libprocinfo",
"libpropertyinfoparser",
"libscudo",
"libstdc++",
"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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
m["com.android.tethering"] = []string{
apex: Make android_library support APEX variants The android_library module type can be used within an android_app that can itself be added to an apex but android_library does not call android.InitApexModule(module) and so it does not support apex variants and so is treated as if it cannot be part of an APEX even though it actually is. Now, android_library supports AEPX variants. Due to this change, the whilelist for apex_available got bigger. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 156978407 Test: m Merged-In: I3a21d653fe9c4159e3a89791fe1a8597865eeae6 Change-Id: I3a21d653fe9c4159e3a89791fe1a8597865eeae6 (cherry picked from commit bd133b1bdc1de378992491c3154a9ec0b347f7c3)
2020-05-20 02:06:00 +02:00
"android.hardware.tetheroffload.config-V1.0-java",
"android.hardware.tetheroffload.control-V1.0-java",
"android.hidl.base-V1.0-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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"libcgrouprc",
"libcgrouprc_format",
"libtetherutilsjni",
"libvndksupport",
apex: Make android_library support APEX variants The android_library module type can be used within an android_app that can itself be added to an apex but android_library does not call android.InitApexModule(module) and so it does not support apex variants and so is treated as if it cannot be part of an APEX even though it actually is. Now, android_library supports AEPX variants. Due to this change, the whilelist for apex_available got bigger. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 156978407 Test: m Merged-In: I3a21d653fe9c4159e3a89791fe1a8597865eeae6 Change-Id: I3a21d653fe9c4159e3a89791fe1a8597865eeae6 (cherry picked from commit bd133b1bdc1de378992491c3154a9ec0b347f7c3)
2020-05-20 02:06:00 +02:00
"net-utils-framework-common",
"netd_aidl_interface-V3-java",
"netlink-client",
"networkstack-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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"tethering-aidl-interfaces-java",
apex: Make android_library support APEX variants The android_library module type can be used within an android_app that can itself be added to an apex but android_library does not call android.InitApexModule(module) and so it does not support apex variants and so is treated as if it cannot be part of an APEX even though it actually is. Now, android_library supports AEPX variants. Due to this change, the whilelist for apex_available got bigger. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 156978407 Test: m Merged-In: I3a21d653fe9c4159e3a89791fe1a8597865eeae6 Change-Id: I3a21d653fe9c4159e3a89791fe1a8597865eeae6 (cherry picked from commit bd133b1bdc1de378992491c3154a9ec0b347f7c3)
2020-05-20 02:06:00 +02:00
"TetheringApiCurrentLib",
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) 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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
m["com.android.wifi"] = []string{
"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. Bug: 151071238 Test: build/boot 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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) 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",
"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. Bug: 151071238 Test: build/boot 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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"ipmemorystore-aidl-interfaces-V3-java",
"ipmemorystore-aidl-interfaces-java",
"ksoap2",
"libnanohttpd",
"libwifi-jni",
"net-utils-services-common",
"netd_aidl_interface-V2-java",
"netd_aidl_interface-unstable-java",
"netd_event_listener_interface-java",
"netlink-client",
"networkstack-client",
"services.net",
"wifi-lite-protos",
"wifi-nano-protos",
"wifi-service-pre-jarjar",
"wifi-service-resources",
}
//
// Module separator
//
m["com.android.sdkext"] = []string{
"fmtlib_ndk",
"libbase_ndk",
"libprotobuf-cpp-lite-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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
m["com.android.os.statsd"] = []string{
"libstatssocket",
}
//
// Module separator
//
Copy white listed apex available settings into snapshot Makes sure that the module snapshots do not rely on the white list of apex available settings so that when those lists are removed it is not necessary to update any snapshots. Bug: 142935992 Test: m nothing Change-Id: Iedcff7dfc2646a4da77258d16e06657dd2f411f9
2020-03-06 13:30:13 +01:00
m[android.AvailableToAnyApex] = []string{
apex: Make android_library support APEX variants The android_library module type can be used within an android_app that can itself be added to an apex but android_library does not call android.InitApexModule(module) and so it does not support apex variants and so is treated as if it cannot be part of an APEX even though it actually is. Now, android_library supports AEPX variants. Due to this change, the whilelist for apex_available got bigger. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 156978407 Test: m Merged-In: I3a21d653fe9c4159e3a89791fe1a8597865eeae6 Change-Id: I3a21d653fe9c4159e3a89791fe1a8597865eeae6 (cherry picked from commit bd133b1bdc1de378992491c3154a9ec0b347f7c3)
2020-05-20 02:06:00 +02:00
// TODO(b/156996905) Set apex_available/min_sdk_version for androidx/extras support libraries
"androidx",
"androidx-constraintlayout_constraintlayout",
"androidx-constraintlayout_constraintlayout-nodeps",
"androidx-constraintlayout_constraintlayout-solver",
"androidx-constraintlayout_constraintlayout-solver-nodeps",
"com.google.android.material_material",
"com.google.android.material_material-nodeps",
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
"libatomic",
"libclang_rt",
"libgcc_stripped",
"libprofile-clang-extras",
"libprofile-clang-extras_ndk",
"libprofile-extras",
"libprofile-extras_ndk",
"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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
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() {
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_set module. apex_set takes an .apks file that contains a set of prebuilt apexes with different configurations. It uses extract_apks to select and install the best matching one for the current target. Bug: 153456259 Test: apex_test.go Test: com.android.media.apks Change-Id: I1da8bbcf1611b7c580a0cb225856cbd7029cc0a7
2020-05-14 23:15:24 +02:00
android.RegisterModuleType("apex_set", apexSetFactory)
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 uses WalkDeps apexDepsMutator marks all dependencies of apex modules. Previously, it was converted from WalkDeps() to Top-down mutator to avoid the pitfall of WalkDeps() bug. (It did't handle multiple visits via different paths.) Because WalkDeps() problem solved in aosp/1277516, apexDepsMutator can be reverted to use WalkDeps(). Even though there's no observable difference between them, I revert this for the up-coming change, which requires different pruning strategies per apexes. Bug: 159195575 Test: m Change-Id: Ib09cbc7a3dfd143dd37b660b1aea6c71392ce2e3
2020-07-22 08:17:19 +02:00
ctx.TopDown("apex_deps", apexDepsMutator).Parallel()
Reland: Deduplicate APEX variants that would build identically APEX variants that share the same SDK version and updatability almost always use identical command line arguments to build but with different intermediates directories. This causes unnecessary build time and disk space for duplicated work. Deduplicate APEX variants that would build identically. Create aliases from the per-APEX variations to the new shared variations so that the APEX modules can continue to depend on them via the APEX name as the variation. This has one significant change in behavior. Before this change, if an APEX had two libraries in its direct dependencies and one of those libraries depended on the other, and the second library had stubs, then the first library would depend on the implementation of the second library and not the stubs. After this change, if the first library is also present in a second APEX but the second library is not, then the common variant shared between the two APEXes would use the stubs, not the implementation. In a correctly configured set of build rules this change will be irrelevant, because if the compilation worked for the second APEX using stubs then it will work for the common variant using stubs. However, if an incorrect change to the build rules is made this could lead to confusing errors, as a previously-working common variant could suddenly stop building when a module is added to a new APEX without its dependencies that require implementation APIs to compile. This change reduces the number of modules in an AOSP arm64-userdebug build by 3% (52242 to 50586), reduces the number of variants of the libcutils module from 74 to 53, and reduces the number of variants of the massive libart[d] modules from 44 to 32. This relands I0529837476a253c32b3dfb98dcccf107427c742c with a fix to always mark permissions XML files of java_sdk_library modules as unique per apex since they contain the APEX filename, and a fix to UpdateUniqueApexVariationsForDeps to check ApexInfo.InApexes instead of DepIsInSameApex to check if two modules are in the same apex to account for a module that depends on another in a way that doesn't normally include the dependency in the APEX (e.g. a libs property), but the dependency is directly included in the APEX. Bug: 164216768 Test: go test ./build/soong/apex/... Change-Id: I2ae170601f764e5b88d0be2e0e6adc84e3a4d9cc
2020-08-11 21:17:01 +02:00
ctx.BottomUp("apex_unique", apexUniqueVariationsMutator).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
ctx.BottomUp("apex", apexMutator).Parallel()
ctx.BottomUp("apex_flattened", apexFlattenedMutator).Parallel()
ctx.BottomUp("apex_uses", apexUsesMutator).Parallel()
mark platform un-availability A module is marked unavailable for platform when 1) it does not have "//apex_available:platform" in its apex_available property, or 2) it depends on another module that is unavailable for platform. In that case, LOCAL_NOT_AVAILABLE_FOR_PLATFORM is set to true for the module in the Make world. Later, that flag is used to ensure that there is no module with the flag is installed to the device. The reason why this isn't entirely done in Soong is because Soong doesn't know if a module will be installed to the device or not. To explain this, let's have an example. cc_test { name: "mytest", static_libs: ["libfoo"]} cc_library_static { name: "libfoo", static_libs: ["libbar"]} cc_library { name: "libbar", apex_available: ["com.android.xxx"]} Here, libbar is not available for platform, but is used by libfoo which is available for platform (apex_available defaults to "//apex_available:platform"). libfoo is again depended on by mytest which again is available for platform. The use of libbar should be allowed in the context of test; we don't want to make libbar available to platform just for the dependency from test because it will allow non-test uses of the library as well. Soong by itself can't tell whether libfoo and libbar are used only in the context of a test. There could be another module depending them, e.g., cc_library_shared { name: "mylib", static_libs: ["libfoo"] } can exist and it might be installed to the device, in which case we really should trigger an error. Since Make has the knowledge of what's installed and what's not, the check should be done there. Bug: 153073816 Test: m Test: remove "//apex_available:platform" from libmdnssd (it is currently installed to /system/lib), and check that `m system_image` fails Change-Id: Ia304cc5f41f173229e8a154e90cea4dce46dcebe
2020-04-07 09:37:39 +02:00
ctx.BottomUp("mark_platform_availability", markPlatformAvailability).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) {
apex: Don't run apex mutators if disabled apex_deps/apex/apex_flattened mutators don't have to run if module is disabled. For some branches which have no valid targets, apex modules are disabled by the os mutator. e.g. aosp-build-tools Some enforcement checks which run during those mutators may fail because build-environment doesn't provide full context information. For example, "Platform_version_all_codenames" config variable is not set while apex.min_sdk_version uses one of those codenames. Bug: 152655956 Test: m Change-Id: I47e27d2d025ba4c36534708b113ce77c4cb2397b
2020-04-17 06:43:10 +02:00
if !mctx.Module().Enabled() {
return
}
apexDepsMutator uses WalkDeps apexDepsMutator marks all dependencies of apex modules. Previously, it was converted from WalkDeps() to Top-down mutator to avoid the pitfall of WalkDeps() bug. (It did't handle multiple visits via different paths.) Because WalkDeps() problem solved in aosp/1277516, apexDepsMutator can be reverted to use WalkDeps(). Even though there's no observable difference between them, I revert this for the up-coming change, which requires different pruning strategies per apexes. Bug: 159195575 Test: m Change-Id: Ib09cbc7a3dfd143dd37b660b1aea6c71392ce2e3
2020-07-22 08:17:19 +02:00
a, ok := mctx.Module().(*apexBundle)
if !ok || a.vndkApex {
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 uses WalkDeps apexDepsMutator marks all dependencies of apex modules. Previously, it was converted from WalkDeps() to Top-down mutator to avoid the pitfall of WalkDeps() bug. (It did't handle multiple visits via different paths.) Because WalkDeps() problem solved in aosp/1277516, apexDepsMutator can be reverted to use WalkDeps(). Even though there's no observable difference between them, I revert this for the up-coming change, which requires different pruning strategies per apexes. Bug: 159195575 Test: m Change-Id: Ib09cbc7a3dfd143dd37b660b1aea6c71392ce2e3
2020-07-22 08:17:19 +02:00
apexInfo := android.ApexInfo{
Rename ApexName to ApexVariationName In preparation for reusing the same variation for multiple apexes, rename ApexName to ApexVariationName. Bug: 164216768 Test: all soong tests Change-Id: I88f2c5b192ffa27acd38e01952d0cefd413222a0
2020-08-13 20:24:56 +02:00
ApexVariationName: mctx.ModuleName(),
MinSdkVersion: a.minSdkVersion(mctx),
Reland: Deduplicate APEX variants that would build identically APEX variants that share the same SDK version and updatability almost always use identical command line arguments to build but with different intermediates directories. This causes unnecessary build time and disk space for duplicated work. Deduplicate APEX variants that would build identically. Create aliases from the per-APEX variations to the new shared variations so that the APEX modules can continue to depend on them via the APEX name as the variation. This has one significant change in behavior. Before this change, if an APEX had two libraries in its direct dependencies and one of those libraries depended on the other, and the second library had stubs, then the first library would depend on the implementation of the second library and not the stubs. After this change, if the first library is also present in a second APEX but the second library is not, then the common variant shared between the two APEXes would use the stubs, not the implementation. In a correctly configured set of build rules this change will be irrelevant, because if the compilation worked for the second APEX using stubs then it will work for the common variant using stubs. However, if an incorrect change to the build rules is made this could lead to confusing errors, as a previously-working common variant could suddenly stop building when a module is added to a new APEX without its dependencies that require implementation APIs to compile. This change reduces the number of modules in an AOSP arm64-userdebug build by 3% (52242 to 50586), reduces the number of variants of the libcutils module from 74 to 53, and reduces the number of variants of the massive libart[d] modules from 44 to 32. This relands I0529837476a253c32b3dfb98dcccf107427c742c with a fix to always mark permissions XML files of java_sdk_library modules as unique per apex since they contain the APEX filename, and a fix to UpdateUniqueApexVariationsForDeps to check ApexInfo.InApexes instead of DepIsInSameApex to check if two modules are in the same apex to account for a module that depends on another in a way that doesn't normally include the dependency in the APEX (e.g. a libs property), but the dependency is directly included in the APEX. Bug: 164216768 Test: go test ./build/soong/apex/... Change-Id: I2ae170601f764e5b88d0be2e0e6adc84e3a4d9cc
2020-08-11 21:17:01 +02:00
RequiredSdks: a.RequiredSdks(),
Rename ApexName to ApexVariationName In preparation for reusing the same variation for multiple apexes, rename ApexName to ApexVariationName. Bug: 164216768 Test: all soong tests Change-Id: I88f2c5b192ffa27acd38e01952d0cefd413222a0
2020-08-13 20:24:56 +02:00
Updatable: a.Updatable(),
Reland: Deduplicate APEX variants that would build identically APEX variants that share the same SDK version and updatability almost always use identical command line arguments to build but with different intermediates directories. This causes unnecessary build time and disk space for duplicated work. Deduplicate APEX variants that would build identically. Create aliases from the per-APEX variations to the new shared variations so that the APEX modules can continue to depend on them via the APEX name as the variation. This has one significant change in behavior. Before this change, if an APEX had two libraries in its direct dependencies and one of those libraries depended on the other, and the second library had stubs, then the first library would depend on the implementation of the second library and not the stubs. After this change, if the first library is also present in a second APEX but the second library is not, then the common variant shared between the two APEXes would use the stubs, not the implementation. In a correctly configured set of build rules this change will be irrelevant, because if the compilation worked for the second APEX using stubs then it will work for the common variant using stubs. However, if an incorrect change to the build rules is made this could lead to confusing errors, as a previously-working common variant could suddenly stop building when a module is added to a new APEX without its dependencies that require implementation APIs to compile. This change reduces the number of modules in an AOSP arm64-userdebug build by 3% (52242 to 50586), reduces the number of variants of the libcutils module from 74 to 53, and reduces the number of variants of the massive libart[d] modules from 44 to 32. This relands I0529837476a253c32b3dfb98dcccf107427c742c with a fix to always mark permissions XML files of java_sdk_library modules as unique per apex since they contain the APEX filename, and a fix to UpdateUniqueApexVariationsForDeps to check ApexInfo.InApexes instead of DepIsInSameApex to check if two modules are in the same apex to account for a module that depends on another in a way that doesn't normally include the dependency in the APEX (e.g. a libs property), but the dependency is directly included in the APEX. Bug: 164216768 Test: go test ./build/soong/apex/... Change-Id: I2ae170601f764e5b88d0be2e0e6adc84e3a4d9cc
2020-08-11 21:17:01 +02:00
InApexes: []string{mctx.ModuleName()},
apexDepsMutator uses WalkDeps apexDepsMutator marks all dependencies of apex modules. Previously, it was converted from WalkDeps() to Top-down mutator to avoid the pitfall of WalkDeps() bug. (It did't handle multiple visits via different paths.) Because WalkDeps() problem solved in aosp/1277516, apexDepsMutator can be reverted to use WalkDeps(). Even though there's no observable difference between them, I revert this for the up-coming change, which requires different pruning strategies per apexes. Bug: 159195575 Test: m Change-Id: Ib09cbc7a3dfd143dd37b660b1aea6c71392ce2e3
2020-07-22 08:17:19 +02:00
}
Add apex.use_vndk_as_stable property Vendor APEXes(in general, APEXes for non-system partitions) which is supposed to be tied to a specific VNDK version can set this new property so that it excludes VNDK libs and use them from VNDK APEX (provided by system parition). For these APEXes to use VNDK libs from VNDK APEX, linkerconfig should link "vndk" linker namespace to the namespaces of these APEXes. Bug: 159195575 Test: m (soong test added) Change-Id: If90650973239ef7aab0ff084488bda57d9b0364e
2020-07-22 08:54:47 +02:00
useVndk := a.SocSpecific() || a.DeviceSpecific() || (a.ProductSpecific() && mctx.Config().EnforceProductPartitionInterface())
excludeVndkLibs := useVndk && proptools.Bool(a.properties.Use_vndk_as_stable)
if !useVndk && proptools.Bool(a.properties.Use_vndk_as_stable) {
mctx.PropertyErrorf("use_vndk_as_stable", "not supported for system/system_ext APEXes")
return
}
apexDepsMutator uses WalkDeps apexDepsMutator marks all dependencies of apex modules. Previously, it was converted from WalkDeps() to Top-down mutator to avoid the pitfall of WalkDeps() bug. (It did't handle multiple visits via different paths.) Because WalkDeps() problem solved in aosp/1277516, apexDepsMutator can be reverted to use WalkDeps(). Even though there's no observable difference between them, I revert this for the up-coming change, which requires different pruning strategies per apexes. Bug: 159195575 Test: m Change-Id: Ib09cbc7a3dfd143dd37b660b1aea6c71392ce2e3
2020-07-22 08:17:19 +02:00
mctx.WalkDeps(func(child, parent android.Module) bool {
am, ok := child.(android.ApexModule)
if !ok || !am.CanHaveApexVariants() {
return false
}
Avoid creating APEX variant for sdk member Previously, an APEX variant was created for a module that was a member of an SDK just in case it had to be replaced with an APEX requested snapshotted version of that member. That was necessary because that was the only way to have APEX specific replacements. Since then a new method called ReplaceDependenciesIf() has been added which provides fine grained control over which dependencies are replaced. This change uses that new method to handle the replacements which allows the APEX variants to be removed. Bug: 161928524 Test: m nothing Change-Id: If3869dd6753dc182b099af566b20fbc9c9c6eff7
2020-07-22 14:00:54 +02:00
if !parent.(android.DepIsInSameApex).DepIsInSameApex(mctx, child) {
apexDepsMutator uses WalkDeps apexDepsMutator marks all dependencies of apex modules. Previously, it was converted from WalkDeps() to Top-down mutator to avoid the pitfall of WalkDeps() bug. (It did't handle multiple visits via different paths.) Because WalkDeps() problem solved in aosp/1277516, apexDepsMutator can be reverted to use WalkDeps(). Even though there's no observable difference between them, I revert this for the up-coming change, which requires different pruning strategies per apexes. Bug: 159195575 Test: m Change-Id: Ib09cbc7a3dfd143dd37b660b1aea6c71392ce2e3
2020-07-22 08:17:19 +02:00
return false
}
Add apex.use_vndk_as_stable property Vendor APEXes(in general, APEXes for non-system partitions) which is supposed to be tied to a specific VNDK version can set this new property so that it excludes VNDK libs and use them from VNDK APEX (provided by system parition). For these APEXes to use VNDK libs from VNDK APEX, linkerconfig should link "vndk" linker namespace to the namespaces of these APEXes. Bug: 159195575 Test: m (soong test added) Change-Id: If90650973239ef7aab0ff084488bda57d9b0364e
2020-07-22 08:54:47 +02:00
if excludeVndkLibs {
if c, ok := child.(*cc.Module); ok && c.IsVndk() {
return false
}
}
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
depName := mctx.OtherModuleName(child)
apexDepsMutator uses WalkDeps apexDepsMutator marks all dependencies of apex modules. Previously, it was converted from WalkDeps() to Top-down mutator to avoid the pitfall of WalkDeps() bug. (It did't handle multiple visits via different paths.) Because WalkDeps() problem solved in aosp/1277516, apexDepsMutator can be reverted to use WalkDeps(). Even though there's no observable difference between them, I revert this for the up-coming change, which requires different pruning strategies per apexes. Bug: 159195575 Test: m Change-Id: Ib09cbc7a3dfd143dd37b660b1aea6c71392ce2e3
2020-07-22 08:17:19 +02:00
// If the parent is apexBundle, this child is directly depended.
_, directDep := parent.(*apexBundle)
android.UpdateApexDependency(apexInfo, depName, directDep)
am.BuildForApex(apexInfo)
return true
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
}
Reland: Deduplicate APEX variants that would build identically APEX variants that share the same SDK version and updatability almost always use identical command line arguments to build but with different intermediates directories. This causes unnecessary build time and disk space for duplicated work. Deduplicate APEX variants that would build identically. Create aliases from the per-APEX variations to the new shared variations so that the APEX modules can continue to depend on them via the APEX name as the variation. This has one significant change in behavior. Before this change, if an APEX had two libraries in its direct dependencies and one of those libraries depended on the other, and the second library had stubs, then the first library would depend on the implementation of the second library and not the stubs. After this change, if the first library is also present in a second APEX but the second library is not, then the common variant shared between the two APEXes would use the stubs, not the implementation. In a correctly configured set of build rules this change will be irrelevant, because if the compilation worked for the second APEX using stubs then it will work for the common variant using stubs. However, if an incorrect change to the build rules is made this could lead to confusing errors, as a previously-working common variant could suddenly stop building when a module is added to a new APEX without its dependencies that require implementation APIs to compile. This change reduces the number of modules in an AOSP arm64-userdebug build by 3% (52242 to 50586), reduces the number of variants of the libcutils module from 74 to 53, and reduces the number of variants of the massive libart[d] modules from 44 to 32. This relands I0529837476a253c32b3dfb98dcccf107427c742c with a fix to always mark permissions XML files of java_sdk_library modules as unique per apex since they contain the APEX filename, and a fix to UpdateUniqueApexVariationsForDeps to check ApexInfo.InApexes instead of DepIsInSameApex to check if two modules are in the same apex to account for a module that depends on another in a way that doesn't normally include the dependency in the APEX (e.g. a libs property), but the dependency is directly included in the APEX. Bug: 164216768 Test: go test ./build/soong/apex/... Change-Id: I2ae170601f764e5b88d0be2e0e6adc84e3a4d9cc
2020-08-11 21:17:01 +02:00
func apexUniqueVariationsMutator(mctx android.BottomUpMutatorContext) {
if !mctx.Module().Enabled() {
return
}
if am, ok := mctx.Module().(android.ApexModule); ok {
// Check if any dependencies use unique apex variations. If so, use unique apex variations
// for this module.
am.UpdateUniqueApexVariationsForDeps(mctx)
}
}
mark platform un-availability A module is marked unavailable for platform when 1) it does not have "//apex_available:platform" in its apex_available property, or 2) it depends on another module that is unavailable for platform. In that case, LOCAL_NOT_AVAILABLE_FOR_PLATFORM is set to true for the module in the Make world. Later, that flag is used to ensure that there is no module with the flag is installed to the device. The reason why this isn't entirely done in Soong is because Soong doesn't know if a module will be installed to the device or not. To explain this, let's have an example. cc_test { name: "mytest", static_libs: ["libfoo"]} cc_library_static { name: "libfoo", static_libs: ["libbar"]} cc_library { name: "libbar", apex_available: ["com.android.xxx"]} Here, libbar is not available for platform, but is used by libfoo which is available for platform (apex_available defaults to "//apex_available:platform"). libfoo is again depended on by mytest which again is available for platform. The use of libbar should be allowed in the context of test; we don't want to make libbar available to platform just for the dependency from test because it will allow non-test uses of the library as well. Soong by itself can't tell whether libfoo and libbar are used only in the context of a test. There could be another module depending them, e.g., cc_library_shared { name: "mylib", static_libs: ["libfoo"] } can exist and it might be installed to the device, in which case we really should trigger an error. Since Make has the knowledge of what's installed and what's not, the check should be done there. Bug: 153073816 Test: m Test: remove "//apex_available:platform" from libmdnssd (it is currently installed to /system/lib), and check that `m system_image` fails Change-Id: Ia304cc5f41f173229e8a154e90cea4dce46dcebe
2020-04-07 09:37:39 +02:00
// mark if a module cannot be available to platform. A module cannot be available
// to platform if 1) it is explicitly marked as not available (i.e. "//apex_available:platform"
// is absent) or 2) it depends on another module that isn't (or can't be) available to platform
func markPlatformAvailability(mctx android.BottomUpMutatorContext) {
// Host and recovery are not considered as platform
if mctx.Host() || mctx.Module().InstallInRecovery() {
return
}
if am, ok := mctx.Module().(android.ApexModule); ok {
availableToPlatform := am.AvailableFor(android.AvailableToPlatform)
// In a rare case when a lib is marked as available only to an apex
// but the apex doesn't exist. This can happen in a partial manifest branch
// like master-art. Currently, libstatssocket in the stats APEX is causing
// this problem.
// Include the lib in platform because the module SDK that ought to provide
// it doesn't exist, so it would otherwise be left out completely.
// TODO(b/154888298) remove this by adding those libraries in module SDKS and skipping
// this check for libraries provided by SDKs.
if !availableToPlatform && !android.InAnyApex(am.Name()) {
availableToPlatform = true
}
// If any of the dep is not available to platform, this module is also considered
// as being not available to platform even if it has "//apex_available:platform"
mctx.VisitDirectDeps(func(child android.Module) {
if !am.DepIsInSameApex(mctx, child) {
// if the dependency crosses apex boundary, don't consider it
return
}
if dep, ok := child.(android.ApexModule); ok && dep.NotAvailableForPlatform() {
availableToPlatform = false
// TODO(b/154889534) trigger an error when 'am' has "//apex_available:platform"
}
})
// Exception 1: stub libraries and native bridge libraries are always available to platform
if cc, ok := mctx.Module().(*cc.Module); ok &&
(cc.IsStubs() || cc.Target().NativeBridge == android.NativeBridgeEnabled) {
availableToPlatform = true
}
// Exception 2: bootstrap bionic libraries are also always available to platform
if cc.InstallToBootstrap(mctx.ModuleName(), mctx.Config()) {
availableToPlatform = true
}
if !availableToPlatform {
am.SetNotAvailableForPlatform()
}
}
}
Stop requiring apex_available on java_library members of sdks Previously, adding java_library to an sdk required that the names of any APEXes that transitively compiled against it were added to its apex_available property. This change removes that requirement. Also corrects the dependency path in the TestApexAvailable_IndirectDep error which previously passed through "shared from static" static dependency tags even though those are explicitly NOT followed when checking apex_available settings. Bug: 152878661 Test: m droid Change-Id: I995ed38956c1bc210b09494812de012fed9f9232
2020-03-31 16:23:40 +02:00
// If a module in an APEX depends on a module from an SDK then it needs an APEX
// specific variant created for it. Refer to sdk.sdkDepsReplaceMutator.
func inAnySdk(module android.Module) bool {
if sa, ok := module.(android.SdkAware); ok {
return sa.IsInAnySdk()
}
return false
}
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) {
apex: Don't run apex mutators if disabled apex_deps/apex/apex_flattened mutators don't have to run if module is disabled. For some branches which have no valid targets, apex modules are disabled by the os mutator. e.g. aosp-build-tools Some enforcement checks which run during those mutators may fail because build-environment doesn't provide full context information. For example, "Platform_version_all_codenames" config variable is not set while apex.min_sdk_version uses one of those codenames. Bug: 152655956 Test: m Change-Id: I47e27d2d025ba4c36534708b113ce77c4cb2397b
2020-04-17 06:43:10 +02:00
if !mctx.Module().Enabled() {
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
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) {
apex: Don't run apex mutators if disabled apex_deps/apex/apex_flattened mutators don't have to run if module is disabled. For some branches which have no valid targets, apex modules are disabled by the os mutator. e.g. aosp-build-tools Some enforcement checks which run during those mutators may fail because build-environment doesn't provide full context information. For example, "Platform_version_all_codenames" config variable is not set while apex.min_sdk_version uses one of those codenames. Bug: 152655956 Test: m Change-Id: I47e27d2d025ba4c36534708b113ce77c4cb2397b
2020-04-17 06:43:10 +02:00
if !mctx.Module().Enabled() {
return
}
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 (
Use inclusive language in build/soong Test: m checkbuild Change-Id: Id07890b7cbc2397291a658ca00e86b43c743aafc
2020-06-11 20:32:11 +02:00
useVendorAllowListKey = android.NewOnceKey("useVendorAllowList")
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
)
Use inclusive language in build/soong Test: m checkbuild Change-Id: Id07890b7cbc2397291a658ca00e86b43c743aafc
2020-06-11 20:32:11 +02:00
// useVendorAllowList returns the list of APEXes which are allowed to use_vendor.
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
// 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.
Use inclusive language in build/soong Test: m checkbuild Change-Id: Id07890b7cbc2397291a658ca00e86b43c743aafc
2020-06-11 20:32:11 +02:00
func useVendorAllowList(config android.Config) []string {
return config.Once(useVendorAllowListKey, func() interface{} {
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
return []string{
// swcodec uses "vendor" variants for smaller size
"com.android.media.swcodec",
"test_com.android.media.swcodec",
}
}).([]string)
}
Use inclusive language in build/soong Test: m checkbuild Change-Id: Id07890b7cbc2397291a658ca00e86b43c743aafc
2020-06-11 20:32:11 +02:00
// setUseVendorAllowListForTest overrides useVendorAllowList and must be
// called before the first call to useVendorAllowList()
func setUseVendorAllowListForTest(config android.Config, allowList []string) {
config.Once(useVendorAllowListKey, func() interface{} {
return allowList
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
})
}
apex: refactor apex properties Embed common properties (apexNativeDependencies) so that the logic for adding dependencies for native modules can be reused. Bug: N/A Test: m Change-Id: I789b526c09eea14213ab1544590ed2238ed8c625
2020-02-27 05:40:44 +01:00
type ApexNativeDependencies struct {
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 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 "jni_libs" property to apex module Which is the list of JNI libraries that are embeded inside the apex. jni_libs is handled just like native_shared_libs except that it is stored in apex_manifest. When linkerconfig finds an apex with JNI libs, it exposes the namespace for the apex as visible so that libnativeloader can link the namespace to the corresponding classloader-namespace. Bug: 149363889 Test: m nothing(runs soong test) Change-Id: I52ebe38b44545e6e8853e34a3404a235c858112a
2020-02-27 05:50:06 +01:00
// List of JNI libraries
Jni_libs []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
// 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"
apex: refactor apex properties Embed common properties (apexNativeDependencies) so that the logic for adding dependencies for native modules can be reused. Bug: N/A Test: m Change-Id: I789b526c09eea14213ab1544590ed2238ed8c625
2020-02-27 05:40:44 +01:00
First ApexNativeDependencies
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
// Native dependencies whose compile_multilib is "both"
apex: refactor apex properties Embed common properties (apexNativeDependencies) so that the logic for adding dependencies for native modules can be reused. Bug: N/A Test: m Change-Id: I789b526c09eea14213ab1544590ed2238ed8c625
2020-02-27 05:40:44 +01:00
Both ApexNativeDependencies
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
// Native dependencies whose compile_multilib is "prefer32"
apex: refactor apex properties Embed common properties (apexNativeDependencies) so that the logic for adding dependencies for native modules can be reused. Bug: N/A Test: m Change-Id: I789b526c09eea14213ab1544590ed2238ed8c625
2020-02-27 05:40:44 +01:00
Prefer32 ApexNativeDependencies
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
// Native dependencies whose compile_multilib is "32"
apex: refactor apex properties Embed common properties (apexNativeDependencies) so that the logic for adding dependencies for native modules can be reused. Bug: N/A Test: m Change-Id: I789b526c09eea14213ab1544590ed2238ed8c625
2020-02-27 05:40:44 +01:00
Lib32 ApexNativeDependencies
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
// Native dependencies whose compile_multilib is "64"
apex: refactor apex properties Embed common properties (apexNativeDependencies) so that the logic for adding dependencies for native modules can be reused. Bug: N/A Test: m Change-Id: I789b526c09eea14213ab1544590ed2238ed8c625
2020-02-27 05:40:44 +01:00
Lib64 ApexNativeDependencies
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 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
apex: refactor apex properties Embed common properties (apexNativeDependencies) so that the logic for adding dependencies for native modules can be reused. Bug: N/A Test: m Change-Id: I789b526c09eea14213ab1544590ed2238ed8c625
2020-02-27 05:40:44 +01:00
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
// 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
// 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
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
Allow building unsigned APEXs payload for testing. Bug: 148447155 Test: built a testing apex with unsigned payload. Merged-In: I95aa3f11ff1adc1421fcd7ed5a356ee531a0a818 Change-Id: I95aa3f11ff1adc1421fcd7ed5a356ee531a0a818 (cherry picked from commit 98410fd9d66a3717a1b0d52b68071821d11e6302)
2020-04-27 19:21:11 +02:00
// Whenever apex_payload.img of the APEX should not be dm-verity signed.
// Should be only used in tests#.
Test_only_unsigned_payload *bool
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
enforce updatable apexes to set min_sdk_version updatable APEXes should set min_sdk_version as well. Bug: 152655956 Test: m Change-Id: I8192086eb89fa958dd8ff1b731e43e24bf217ce2
2020-04-27 05:10:30 +02:00
// rules for making sure that the APEX is truly updatable.
// - To be updatable, min_sdk_version should be set as well
// This will also disable the size optimizations like symlinking to the system libs.
// Default is false.
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
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 Change-Id: I923773c90fe15becbffae3986791aa9edde8f8f6
2020-02-20 05:41:10 +01:00
// The minimum SDK version that this apex must be compatibile with.
Min_sdk_version *string
Add apex.use_vndk_as_stable property Vendor APEXes(in general, APEXes for non-system partitions) which is supposed to be tied to a specific VNDK version can set this new property so that it excludes VNDK libs and use them from VNDK APEX (provided by system parition). For these APEXes to use VNDK libs from VNDK APEX, linkerconfig should link "vndk" linker namespace to the namespaces of these APEXes. Bug: 159195575 Test: m (soong test added) Change-Id: If90650973239ef7aab0ff084488bda57d9b0364e
2020-07-22 08:54:47 +02:00
// If set true, VNDK libs are considered as stable libs and are not included in this apex.
// Should be only used in non-system apexes (e.g. vendor: true).
// Default is false.
Use_vndk_as_stable *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
}
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
runtime_resource_overlay can be included in APEXes runtime_resource_overlay is put to an APEX via 'apps' property. It is placed under ./overlay directory in it. Bug: 154822536 Test: m Change-Id: I8edf4a26c26368c52fb7b327b2ecc829f21ea148
2020-04-24 14:16:36 +02:00
// List of runtime resource overlays (RROs) inside APEX
Rros []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 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
apex: make allowed_files prop overridable Because override_apex can modify the contents of the base apex, allowed_files (which describes the contents) should be overridable. Bug: 159503079 Bug: 159392784 Bug: 158169437 Test: m (soong test added) Merged-In: I12744b0465dc3cfc90a66643867e65b4092cd0f7 Change-Id: I12744b0465dc3cfc90a66643867e65b4092cd0f7 (cherry picked from commit faa5399b3f304ab152c39c858d0ca4af8735a750)
2020-06-20 05:47:47 +02:00
// A txt file containing list of files that are allowed to be included in this APEX.
Allowed_files *string `android:"path"`
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
Allow apex module to have android_app_set as its constituent. Fixes: 157166068 Test: treehugger & manual Change-Id: I9f91f1b761286f489d175eb0772f78f702e8a2d6
2020-05-28 01:36:07 +02:00
appSet
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
)
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"
Allow apex module to have android_app_set as its constituent. Fixes: 157166068 Test: treehugger & manual Change-Id: I9f91f1b761286f489d175eb0772f78f702e8a2d6
2020-05-28 01:36:07 +02:00
case app, appSet:
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 {
Use BaseModuleName() + SubName as apexFile.moduleName This change fixes this error: ``` TARGET module com.android.adbd.flattened requires non-existent TARGET module: prebuilt_libclang_rt.ubsan_standalone-arm-android ``` apexFile.moduleName is used as Make dependency name, so it should use m.BaseModuleName() instead of m.Name(), because soong may prepend "prebuilt_" to or mutate the output of m.Name() in other ways. android/androidmk.go emits Android.mk modules with `LOCAL_MODULE := module.BaseModuleName() + <SubName>`, so replace apexFile.moduleName with BaseModuleName() + <SubName> as much as possible. Bug: 7456955 Test: Add unit test in apex/apex_test.go Test: lunch blueline_hwasan && SANITIZE_TARGET='hwaddress fuzzer' m nothing Test: Verify out/soong/Android-blueline_hwasan.mk Change-Id: If8537fc1bedbe6c3405de3662a5df210a073c43f
2020-07-23 14:09:18 +02:00
builtFile android.Path
stem string
// Module name of `module` in AndroidMk. Note the generated AndroidMk module for
// apexFile is named something like <AndroidMk module name>.<apex name>[<apex suffix>]
androidMkModuleName string
installDir string
class apexFileClass
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
Install data_libs using relative_install_path property Test: Added to data_libs tests Test: Manually verified with bionic-unit-tests Test: Treehugger Change-Id: I28a8e08e3409f1e7c7bb72f4351310b57f35f513
2020-07-09 23:12:52 +02:00
dataPaths []android.DataPath
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
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
Build transitive lint reports for apex modules Build and export transitive lint report zips for apex modules. Bug: 153485543 Test: m TARGET_BUILD_APPS=com.google.android.wifi lint-check dist Change-Id: I5a1805440452301a7e2c4ca91482b989638b54fb
2020-07-22 05:31:17 +02:00
lintDepSets java.LintDepSets // only for javalibs and apps
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 // 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. Bug: 148002117 Test: m Change-Id: Ibb90bcefb77fa6b2dad77cb2facc6079de9ab154
2020-02-28 08:51:07 +01:00
overriddenPackageName string // only for apps
Add "jni_libs" property to apex module Which is the list of JNI libraries that are embeded inside the apex. jni_libs is handled just like native_shared_libs except that it is stored in apex_manifest. When linkerconfig finds an apex with JNI libs, it exposes the namespace for the apex as visible so that libnativeloader can link the namespace to the corresponding classloader-namespace. Bug: 149363889 Test: m nothing(runs soong test) Change-Id: I52ebe38b44545e6e8853e34a3404a235c858112a
2020-02-27 05:50:06 +01:00
isJniLib bool
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
}
Use BaseModuleName() + SubName as apexFile.moduleName This change fixes this error: ``` TARGET module com.android.adbd.flattened requires non-existent TARGET module: prebuilt_libclang_rt.ubsan_standalone-arm-android ``` apexFile.moduleName is used as Make dependency name, so it should use m.BaseModuleName() instead of m.Name(), because soong may prepend "prebuilt_" to or mutate the output of m.Name() in other ways. android/androidmk.go emits Android.mk modules with `LOCAL_MODULE := module.BaseModuleName() + <SubName>`, so replace apexFile.moduleName with BaseModuleName() + <SubName> as much as possible. Bug: 7456955 Test: Add unit test in apex/apex_test.go Test: lunch blueline_hwasan && SANITIZE_TARGET='hwaddress fuzzer' m nothing Test: Verify out/soong/Android-blueline_hwasan.mk Change-Id: If8537fc1bedbe6c3405de3662a5df210a073c43f
2020-07-23 14:09:18 +02:00
func newApexFile(ctx android.BaseModuleContext, builtFile android.Path, androidMkModuleName string, installDir string, class apexFileClass, module android.Module) apexFile {
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
ret := apexFile{
Use BaseModuleName() + SubName as apexFile.moduleName This change fixes this error: ``` TARGET module com.android.adbd.flattened requires non-existent TARGET module: prebuilt_libclang_rt.ubsan_standalone-arm-android ``` apexFile.moduleName is used as Make dependency name, so it should use m.BaseModuleName() instead of m.Name(), because soong may prepend "prebuilt_" to or mutate the output of m.Name() in other ways. android/androidmk.go emits Android.mk modules with `LOCAL_MODULE := module.BaseModuleName() + <SubName>`, so replace apexFile.moduleName with BaseModuleName() + <SubName> as much as possible. Bug: 7456955 Test: Add unit test in apex/apex_test.go Test: lunch blueline_hwasan && SANITIZE_TARGET='hwaddress fuzzer' m nothing Test: Verify out/soong/Android-blueline_hwasan.mk Change-Id: If8537fc1bedbe6c3405de3662a5df210a073c43f
2020-07-23 14:09:18 +02:00
builtFile: builtFile,
androidMkModuleName: androidMkModuleName,
installDir: installDir,
class: class,
module: 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
}
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
}
Add test data dependencies to APEX. Test: soong go tests Bug: 155820504 Change-Id: If96d82c27f19953e34efb31f2111f1643c0c4008
2020-05-13 00:26:55 +02:00
func (af *apexFile) apexRelativePath(path string) string {
return filepath.Join(af.installDir, path)
}
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 {
Use Stem where output file name is expected in APEX Bug: 157638999 Test: m Change-Id: I4a4892bc2941cf1301d210fc3107c02f0e7b13b7
2020-05-29 14:29:20 +02:00
return af.apexRelativePath(af.Stem())
}
func (af *apexFile) Stem() string {
apex respects stem of java_library modules apex now respects stem of java_library modules. As a follow-up we need to suppor the same for other types of modules. Bug: 157638999 Test: m Change-Id: Iaf5023020b5440f1ffd4f5414b5a7864655fc22a
2020-05-28 16:46:55 +02:00
if af.stem != "" {
Use Stem where output file name is expected in APEX Bug: 157638999 Test: m Change-Id: I4a4892bc2941cf1301d210fc3107c02f0e7b13b7
2020-05-29 14:29:20 +02:00
return af.stem
apex respects stem of java_library modules apex now respects stem of java_library modules. As a follow-up we need to suppor the same for other types of modules. Bug: 157638999 Test: m Change-Id: Iaf5023020b5440f1ffd4f5414b5a7864655fc22a
2020-05-28 16:46:55 +02:00
}
Use Stem where output file name is expected in APEX Bug: 157638999 Test: m Change-Id: I4a4892bc2941cf1301d210fc3107c02f0e7b13b7
2020-05-29 14:29:20 +02:00
return af.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
}
// 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 {
Add test data dependencies to APEX. Test: soong go tests Bug: 155820504 Change-Id: If96d82c27f19953e34efb31f2111f1643c0c4008
2020-05-13 00:26:55 +02:00
ret = append(ret, af.apexRelativePath(symlink))
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
}
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
}
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
apex: add apex_manifest.pb in file_contexts apex_manifest.pb is added to payload.img by the build system and is supposed to be read by apexd during activation. So, it should be labeled as "system_file" so that apexd can read it regardless of how file_contexts is defined. Bug: 159767275 Test: add an apex with file_contexts with everything as vendor_file apexd should activate the apex. Change-Id: Ie34eb7ad905828976152d67a7dfabf0add0a5de4
2020-06-24 12:33:06 +02:00
fileContexts android.WritablePath
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
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)
Export depsInfo into android package. Move depsInfo into android for easier sharing with APK code. Bug: 149622332 Test: m, diff'ing outputs for conscrypt module. Change-Id: If0ee967d37425540e69b4ce9304229d9f2cd86bd
2020-04-27 18:08:37 +02:00
android.ApexBundleDepsInfo
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
Build transitive lint reports for apex modules Build and export transitive lint report zips for apex modules. Bug: 153485543 Test: m TARGET_BUILD_APPS=com.google.android.wifi lint-check dist Change-Id: I5a1805440452301a7e2c4ca91482b989638b54fb
2020-07-22 05:31:17 +02:00
// Optional list of lint report zip files for apexes that contain java or app modules
lintReports android.Paths
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,
apex: refactor apex properties Embed common properties (apexNativeDependencies) so that the logic for adding dependencies for native modules can be reused. Bug: N/A Test: m Change-Id: I789b526c09eea14213ab1544590ed2238ed8c625
2020-02-27 05:40:44 +01:00
nativeModules ApexNativeDependencies,
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
apex: refactor apex properties Embed common properties (apexNativeDependencies) so that the logic for adding dependencies for native modules can be reused. Bug: N/A Test: m Change-Id: I789b526c09eea14213ab1544590ed2238ed8c625
2020-02-27 05:40:44 +01:00
}...), sharedLibTag, nativeModules.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 "jni_libs" property to apex module Which is the list of JNI libraries that are embeded inside the apex. jni_libs is handled just like native_shared_libs except that it is stored in apex_manifest. When linkerconfig finds an apex with JNI libs, it exposes the namespace for the apex as visible so that libnativeloader can link the namespace to the corresponding classloader-namespace. Bug: 149363889 Test: m nothing(runs soong test) Change-Id: I52ebe38b44545e6e8853e34a3404a235c858112a
2020-02-27 05:50:06 +01:00
ctx.AddFarVariationDependencies(append(target.Variations(), []blueprint.Variation{
{Mutator: "image", Variation: imageVariation},
{Mutator: "link", Variation: "shared"},
{Mutator: "version", Variation: ""}, // "" is the non-stub variant
}...), jniLibTag, nativeModules.Jni_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{Mutator: "image", Variation: imageVariation}),
apex: refactor apex properties Embed common properties (apexNativeDependencies) so that the logic for adding dependencies for native modules can be reused. Bug: N/A Test: m Change-Id: I789b526c09eea14213ab1544590ed2238ed8c625
2020-02-27 05:40:44 +01:00
executableTag, nativeModules.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
apex: refactor apex properties Embed common properties (apexNativeDependencies) so that the logic for adding dependencies for native modules can be reused. Bug: N/A Test: m Change-Id: I789b526c09eea14213ab1544590ed2238ed8c625
2020-02-27 05:40:44 +01:00
}...), testTag, nativeModules.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) {
Use inclusive language in build/soong Test: m checkbuild Change-Id: Id07890b7cbc2397291a658ca00e86b43c743aafc
2020-06-11 20:32:11 +02:00
if proptools.Bool(a.properties.Use_vendor) && !android.InList(a.Name(), useVendorAllowList(ctx.Config())) {
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
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()
apex: support "vendor: true" When an apex sets "vendor: true", it becomes a vendor apex. Vendor apexes use vendor variants for native modules and are installed in /vendor/apex. Bug: 159211312 Test: m Change-Id: I2585dd990ba857a2ab3ec6ab24e09d4652e867f2
2020-06-24 16:50:26 +02:00
imageVariation := a.getImageVariation(ctx)
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 {
Add "jni_libs" property to apex module Which is the list of JNI libraries that are embeded inside the apex. jni_libs is handled just like native_shared_libs except that it is stored in apex_manifest. When linkerconfig finds an apex with JNI libs, it exposes the namespace for the apex as visible so that libnativeloader can link the namespace to the corresponding classloader-namespace. Bug: 149363889 Test: m nothing(runs soong test) Change-Id: I52ebe38b44545e6e8853e34a3404a235c858112a
2020-02-27 05:50:06 +01:00
// When multilib.* is omitted for native_shared_libs/jni_libs/tests, it implies
apex: refactor apex properties Embed common properties (apexNativeDependencies) so that the logic for adding dependencies for native modules can be reused. Bug: N/A Test: m Change-Id: I789b526c09eea14213ab1544590ed2238ed8c625
2020-02-27 05:40:44 +01:00
// multilib.both
addDependenciesForNativeModules(ctx,
ApexNativeDependencies{
Native_shared_libs: a.properties.Native_shared_libs,
Tests: a.properties.Tests,
Add "jni_libs" property to apex module Which is the list of JNI libraries that are embeded inside the apex. jni_libs is handled just like native_shared_libs except that it is stored in apex_manifest. When linkerconfig finds an apex with JNI libs, it exposes the namespace for the apex as visible so that libnativeloader can link the namespace to the corresponding classloader-namespace. Bug: 149363889 Test: m nothing(runs soong test) Change-Id: I52ebe38b44545e6e8853e34a3404a235c858112a
2020-02-27 05:50:06 +01:00
Jni_libs: a.properties.Jni_libs,
apex: refactor apex properties Embed common properties (apexNativeDependencies) so that the logic for adding dependencies for native modules can be reused. Bug: N/A Test: m Change-Id: I789b526c09eea14213ab1544590ed2238ed8c625
2020-02-27 05:40:44 +01:00
Binaries: nil,
},
apex: support "vendor: true" When an apex sets "vendor: true", it becomes a vendor apex. Vendor apexes use vendor variants for native modules and are installed in /vendor/apex. Bug: 159211312 Test: m Change-Id: I2585dd990ba857a2ab3ec6ab24e09d4652e867f2
2020-06-24 16:50:26 +02:00
target, imageVariation)
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,
apex: refactor apex properties Embed common properties (apexNativeDependencies) so that the logic for adding dependencies for native modules can be reused. Bug: N/A Test: m Change-Id: I789b526c09eea14213ab1544590ed2238ed8c625
2020-02-27 05:40:44 +01:00
a.properties.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
target,
apex: support "vendor: true" When an apex sets "vendor: true", it becomes a vendor apex. Vendor apexes use vendor variants for native modules and are installed in /vendor/apex. Bug: 159211312 Test: m Change-Id: I2585dd990ba857a2ab3ec6ab24e09d4652e867f2
2020-06-24 16:50:26 +02:00
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
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
apex: refactor apex properties Embed common properties (apexNativeDependencies) so that the logic for adding dependencies for native modules can be reused. Bug: N/A Test: m Change-Id: I789b526c09eea14213ab1544590ed2238ed8c625
2020-02-27 05:40:44 +01:00
// multilib.first
addDependenciesForNativeModules(ctx,
ApexNativeDependencies{
Native_shared_libs: nil,
Tests: nil,
Add "jni_libs" property to apex module Which is the list of JNI libraries that are embeded inside the apex. jni_libs is handled just like native_shared_libs except that it is stored in apex_manifest. When linkerconfig finds an apex with JNI libs, it exposes the namespace for the apex as visible so that libnativeloader can link the namespace to the corresponding classloader-namespace. Bug: 149363889 Test: m nothing(runs soong test) Change-Id: I52ebe38b44545e6e8853e34a3404a235c858112a
2020-02-27 05:50:06 +01:00
Jni_libs: nil,
apex: refactor apex properties Embed common properties (apexNativeDependencies) so that the logic for adding dependencies for native modules can be reused. Bug: N/A Test: m Change-Id: I789b526c09eea14213ab1544590ed2238ed8c625
2020-02-27 05:40:44 +01:00
Binaries: a.properties.Binaries,
},
apex: support "vendor: true" When an apex sets "vendor: true", it becomes a vendor apex. Vendor apexes use vendor variants for native modules and are installed in /vendor/apex. Bug: 159211312 Test: m Change-Id: I2585dd990ba857a2ab3ec6ab24e09d4652e867f2
2020-06-24 16:50:26 +02:00
target, 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
// Add native modules targetting the first ABI
addDependenciesForNativeModules(ctx,
apex: refactor apex properties Embed common properties (apexNativeDependencies) so that the logic for adding dependencies for native modules can be reused. Bug: N/A Test: m Change-Id: I789b526c09eea14213ab1544590ed2238ed8c625
2020-02-27 05:40:44 +01:00
a.properties.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
target,
apex: support "vendor: true" When an apex sets "vendor: true", it becomes a vendor apex. Vendor apexes use vendor variants for native modules and are installed in /vendor/apex. Bug: 159211312 Test: m Change-Id: I2585dd990ba857a2ab3ec6ab24e09d4652e867f2
2020-06-24 16:50:26 +02:00
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
}
switch target.Arch.ArchType.Multilib {
case "lib32":
// Add native modules targetting 32-bit ABI
addDependenciesForNativeModules(ctx,
apex: refactor apex properties Embed common properties (apexNativeDependencies) so that the logic for adding dependencies for native modules can be reused. Bug: N/A Test: m Change-Id: I789b526c09eea14213ab1544590ed2238ed8c625
2020-02-27 05:40:44 +01:00
a.properties.Multilib.Lib32,
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,
apex: support "vendor: true" When an apex sets "vendor: true", it becomes a vendor apex. Vendor apexes use vendor variants for native modules and are installed in /vendor/apex. Bug: 159211312 Test: m Change-Id: I2585dd990ba857a2ab3ec6ab24e09d4652e867f2
2020-06-24 16:50:26 +02:00
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
addDependenciesForNativeModules(ctx,
apex: refactor apex properties Embed common properties (apexNativeDependencies) so that the logic for adding dependencies for native modules can be reused. Bug: N/A Test: m Change-Id: I789b526c09eea14213ab1544590ed2238ed8c625
2020-02-27 05:40:44 +01:00
a.properties.Multilib.Prefer32,
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,
apex: support "vendor: true" When an apex sets "vendor: true", it becomes a vendor apex. Vendor apexes use vendor variants for native modules and are installed in /vendor/apex. Bug: 159211312 Test: m Change-Id: I2585dd990ba857a2ab3ec6ab24e09d4652e867f2
2020-06-24 16:50:26 +02:00
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
case "lib64":
// Add native modules targetting 64-bit ABI
addDependenciesForNativeModules(ctx,
apex: refactor apex properties Embed common properties (apexNativeDependencies) so that the logic for adding dependencies for native modules can be reused. Bug: N/A Test: m Change-Id: I789b526c09eea14213ab1544590ed2238ed8c625
2020-02-27 05:40:44 +01:00
a.properties.Multilib.Lib64,
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,
apex: support "vendor: true" When an apex sets "vendor: true", it becomes a vendor apex. Vendor apexes use vendor variants for native modules and are installed in /vendor/apex. Bug: 159211312 Test: m Change-Id: I2585dd990ba857a2ab3ec6ab24e09d4652e867f2
2020-06-24 16:50:26 +02:00
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
if !has32BitTarget {
addDependenciesForNativeModules(ctx,
apex: refactor apex properties Embed common properties (apexNativeDependencies) so that the logic for adding dependencies for native modules can be reused. Bug: N/A Test: m Change-Id: I789b526c09eea14213ab1544590ed2238ed8c625
2020-02-27 05:40:44 +01:00
a.properties.Multilib.Prefer32,
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,
apex: support "vendor: true" When an apex sets "vendor: true", it becomes a vendor apex. Vendor apexes use vendor variants for native modules and are installed in /vendor/apex. Bug: 159211312 Test: m Change-Id: I2585dd990ba857a2ab3ec6ab24e09d4652e867f2
2020-06-24 16:50:26 +02:00
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
}
}
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) {
apex: make allowed_files prop overridable Because override_apex can modify the contents of the base apex, allowed_files (which describes the contents) should be overridable. Bug: 159503079 Bug: 159392784 Bug: 158169437 Test: m (soong test added) Merged-In: I12744b0465dc3cfc90a66643867e65b4092cd0f7 Change-Id: I12744b0465dc3cfc90a66643867e65b4092cd0f7 (cherry picked from commit faa5399b3f304ab152c39c858d0ca4af8735a750)
2020-06-20 05:47:47 +02:00
if a.overridableProperties.Allowed_files != nil {
android.ExtractSourceDeps(ctx, a.overridableProperties.Allowed_files)
}
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
ctx.AddFarVariationDependencies(ctx.Config().AndroidCommonTarget.Variations(),
androidAppTag, a.overridableProperties.Apps...)
runtime_resource_overlay can be included in APEXes runtime_resource_overlay is put to an APEX via 'apps' property. It is placed under ./overlay directory in it. Bug: 154822536 Test: m Change-Id: I8edf4a26c26368c52fb7b327b2ecc829f21ea148
2020-04-24 14:16:36 +02:00
ctx.AddFarVariationDependencies(ctx.Config().AndroidCommonTarget.Variations(),
rroTag, a.overridableProperties.Rros...)
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
}
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)
}
Allow building unsigned APEXs payload for testing. Bug: 148447155 Test: built a testing apex with unsigned payload. Merged-In: I95aa3f11ff1adc1421fcd7ed5a356ee531a0a818 Change-Id: I95aa3f11ff1adc1421fcd7ed5a356ee531a0a818 (cherry picked from commit 98410fd9d66a3717a1b0d52b68071821d11e6302)
2020-04-27 19:21:11 +02:00
func (a *apexBundle) testOnlyShouldSkipPayloadSign() bool {
return proptools.Bool(a.properties.Test_only_unsigned_payload)
}
apex: support "vendor: true" When an apex sets "vendor: true", it becomes a vendor apex. Vendor apexes use vendor variants for native modules and are installed in /vendor/apex. Bug: 159211312 Test: m Change-Id: I2585dd990ba857a2ab3ec6ab24e09d4652e867f2
2020-06-24 16:50:26 +02:00
func (a *apexBundle) getImageVariation(ctx android.BottomUpMutatorContext) string {
deviceConfig := ctx.DeviceConfig()
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 {
apex: support "vendor: true" When an apex sets "vendor: true", it becomes a vendor apex. Vendor apexes use vendor variants for native modules and are installed in /vendor/apex. Bug: 159211312 Test: m Change-Id: I2585dd990ba857a2ab3ec6ab24e09d4652e867f2
2020-06-24 16:50:26 +02:00
return cc.VendorVariationPrefix + a.vndkVersion(deviceConfig)
}
var prefix string
var vndkVersion string
if deviceConfig.VndkVersion() != "" {
if proptools.Bool(a.properties.Use_vendor) {
prefix = cc.VendorVariationPrefix
vndkVersion = deviceConfig.PlatformVndkVersion()
} else if a.SocSpecific() || a.DeviceSpecific() {
prefix = cc.VendorVariationPrefix
vndkVersion = deviceConfig.VndkVersion()
} else if a.ProductSpecific() {
prefix = cc.ProductVariationPrefix
vndkVersion = deviceConfig.ProductVndkVersion()
}
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
}
apex: support "vendor: true" When an apex sets "vendor: true", it becomes a vendor apex. Vendor apexes use vendor variants for native modules and are installed in /vendor/apex. Bug: 159211312 Test: m Change-Id: I2585dd990ba857a2ab3ec6ab24e09d4652e867f2
2020-06-24 16:50:26 +02:00
if vndkVersion == "current" {
vndkVersion = deviceConfig.PlatformVndkVersion()
}
if vndkVersion != "" {
return prefix + vndkVersion
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
}
apex: support "vendor: true" When an apex sets "vendor: true", it becomes a vendor apex. Vendor apexes use vendor variants for native modules and are installed in /vendor/apex. Bug: 159211312 Test: m Change-Id: I2585dd990ba857a2ab3ec6ab24e09d4652e867f2
2020-06-24 16:50:26 +02: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
}
apex: install hwasan lib if depended on libc There're two ways to enable hwasan: - global setting: TARGET_SANITIZE=hwaddress - individual setting: sanitize: { hwaddress: true } This change covers both cases by looking up if com.android.runtime is hwaddress santized or not. Bug: 156678661 Test: m (soong test added) Change-Id: I67c382c3e76a06f4b27f221eebd153c698647227
2020-05-15 12:05:05 +02:00
func (a *apexBundle) AddSanitizerDependencies(ctx android.BottomUpMutatorContext, sanitizerName string) {
if ctx.Device() && sanitizerName == "hwaddress" && strings.HasPrefix(a.Name(), "com.android.runtime") {
for _, target := range ctx.MultiTargets() {
if target.Arch.ArchType.Multilib == "lib64" {
ctx.AddFarVariationDependencies(append(target.Variations(), []blueprint.Variation{
apex: support "vendor: true" When an apex sets "vendor: true", it becomes a vendor apex. Vendor apexes use vendor variants for native modules and are installed in /vendor/apex. Bug: 159211312 Test: m Change-Id: I2585dd990ba857a2ab3ec6ab24e09d4652e867f2
2020-06-24 16:50:26 +02:00
{Mutator: "image", Variation: a.getImageVariation(ctx)},
apex: install hwasan lib if depended on libc There're two ways to enable hwasan: - global setting: TARGET_SANITIZE=hwaddress - individual setting: sanitize: { hwaddress: true } This change covers both cases by looking up if com.android.runtime is hwaddress santized or not. Bug: 156678661 Test: m (soong test added) Change-Id: I67c382c3e76a06f4b27f221eebd153c698647227
2020-05-15 12:05:05 +02:00
{Mutator: "link", Variation: "shared"},
{Mutator: "version", Variation: ""}, // "" is the non-stub variant
}...), sharedLibTag, "libclang_rt.hwasan-aarch64-android")
break
}
}
}
}
Add gcov coverage support to Rust modules. This adds gcov coverage support for Rust device library and binary modules (including test modules). Support is provided to pass Rust static library gcno files to CC modules and visa versa. Additional changes: * Begin mutator added for Rust modules. * SuffixInList added to android package. * CoverageEnabled added to Coverage interface. * CoverageFiles added to LinkableLibrary interface. * Fix in coverage mutator for non-CC modules which marked the wrong variant as the coverage variant. * Added coverage libraries to the cc.GatherRequiredDepsForTest. Bug: 146448203 Test: NATIVE_COVERAGE=true COVERAGE_PATHS='*' m -j <rust_module> Change-Id: If20728bdde42a1dd544a35a40f0d981b80a5835f
2020-04-09 15:56:02 +02:00
var _ cc.Coverage = (*apexBundle)(nil)
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 {
Make native_coverage clause work with ClangCoverage Make uses NATIVE_COVERAGE to enable gcov coverage and CLANG_COVERAGE to enable clang coverage. NATIVE_COVERAGE is translated to the Soong Native_coverage product variable which triggers the native_coverage clause in Android.bp files. The clause also needs to be triggered for CLANG_COVERAGE. Rename the existing Native_coverage product variable to GcovCoverage, and regenerate Native_coverage when either GcovCoverage or ClangCoverage are set. Also remove NativeLineCoverage, it wasn't doing anything differently than Native_coverage. Bug: 159059537 Test: m checkbuild Change-Id: I215124a9b35a2ad50ad562079d392e3d33da11f4
2020-06-17 02:51:46 +02:00
return ctx.Device() && ctx.DeviceConfig().NativeCoverageEnabled()
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
}
Add gcov coverage support to Rust modules. This adds gcov coverage support for Rust device library and binary modules (including test modules). Support is provided to pass Rust static library gcno files to CC modules and visa versa. Additional changes: * Begin mutator added for Rust modules. * SuffixInList added to android package. * CoverageEnabled added to Coverage interface. * CoverageFiles added to LinkableLibrary interface. * Fix in coverage mutator for non-CC modules which marked the wrong variant as the coverage variant. * Added coverage libraries to the cc.GatherRequiredDepsForTest. Bug: 146448203 Test: NATIVE_COVERAGE=true COVERAGE_PATHS='*' m -j <rust_module> Change-Id: If20728bdde42a1dd544a35a40f0d981b80a5835f
2020-04-09 15:56:02 +02:00
func (a *apexBundle) EnableCoverageIfNeeded() {}
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"
}
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 path in apex when native_bridge_supported: true NativeBridgeRelativePath should be appended after /bin or /lib and before subdir. Bug: N/A Test: m (add a soong test) Change-Id: Id0c44c66b4900caa291e816cf3361fdec8ff9421
2020-02-06 09:33:20 +01:00
dirInApex = filepath.Join(dirInApex, ccMod.RelativeInstallPath())
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()
Use BaseModuleName() + SubName as apexFile.moduleName This change fixes this error: ``` TARGET module com.android.adbd.flattened requires non-existent TARGET module: prebuilt_libclang_rt.ubsan_standalone-arm-android ``` apexFile.moduleName is used as Make dependency name, so it should use m.BaseModuleName() instead of m.Name(), because soong may prepend "prebuilt_" to or mutate the output of m.Name() in other ways. android/androidmk.go emits Android.mk modules with `LOCAL_MODULE := module.BaseModuleName() + <SubName>`, so replace apexFile.moduleName with BaseModuleName() + <SubName> as much as possible. Bug: 7456955 Test: Add unit test in apex/apex_test.go Test: lunch blueline_hwasan && SANITIZE_TARGET='hwaddress fuzzer' m nothing Test: Verify out/soong/Android-blueline_hwasan.mk Change-Id: If8537fc1bedbe6c3405de3662a5df210a073c43f
2020-07-23 14:09:18 +02:00
androidMkModuleName := ccMod.BaseModuleName() + ccMod.Properties.SubName
return newApexFile(ctx, fileToCopy, androidMkModuleName, 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 {
Fix path in apex when native_bridge_supported: true NativeBridgeRelativePath should be appended after /bin or /lib and before subdir. Bug: N/A Test: m (add a soong test) Change-Id: Id0c44c66b4900caa291e816cf3361fdec8ff9421
2020-02-06 09:33:20 +01:00
dirInApex := "bin"
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
}
Fix path in apex when native_bridge_supported: true NativeBridgeRelativePath should be appended after /bin or /lib and before subdir. Bug: N/A Test: m (add a soong test) Change-Id: Id0c44c66b4900caa291e816cf3361fdec8ff9421
2020-02-06 09:33:20 +01:00
dirInApex = filepath.Join(dirInApex, cc.RelativeInstallPath())
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()
Use BaseModuleName() + SubName as apexFile.moduleName This change fixes this error: ``` TARGET module com.android.adbd.flattened requires non-existent TARGET module: prebuilt_libclang_rt.ubsan_standalone-arm-android ``` apexFile.moduleName is used as Make dependency name, so it should use m.BaseModuleName() instead of m.Name(), because soong may prepend "prebuilt_" to or mutate the output of m.Name() in other ways. android/androidmk.go emits Android.mk modules with `LOCAL_MODULE := module.BaseModuleName() + <SubName>`, so replace apexFile.moduleName with BaseModuleName() + <SubName> as much as possible. Bug: 7456955 Test: Add unit test in apex/apex_test.go Test: lunch blueline_hwasan && SANITIZE_TARGET='hwaddress fuzzer' m nothing Test: Verify out/soong/Android-blueline_hwasan.mk Change-Id: If8537fc1bedbe6c3405de3662a5df210a073c43f
2020-07-23 14:09:18 +02:00
androidMkModuleName := cc.BaseModuleName() + cc.Properties.SubName
af := newApexFile(ctx, fileToCopy, androidMkModuleName, 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()
Add test data dependencies to APEX. Test: soong go tests Bug: 155820504 Change-Id: If96d82c27f19953e34efb31f2111f1643c0c4008
2020-05-13 00:26:55 +02:00
af.dataPaths = cc.DataPaths()
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 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()
Use BaseModuleName() + SubName as apexFile.moduleName This change fixes this error: ``` TARGET module com.android.adbd.flattened requires non-existent TARGET module: prebuilt_libclang_rt.ubsan_standalone-arm-android ``` apexFile.moduleName is used as Make dependency name, so it should use m.BaseModuleName() instead of m.Name(), because soong may prepend "prebuilt_" to or mutate the output of m.Name() in other ways. android/androidmk.go emits Android.mk modules with `LOCAL_MODULE := module.BaseModuleName() + <SubName>`, so replace apexFile.moduleName with BaseModuleName() + <SubName> as much as possible. Bug: 7456955 Test: Add unit test in apex/apex_test.go Test: lunch blueline_hwasan && SANITIZE_TARGET='hwaddress fuzzer' m nothing Test: Verify out/soong/Android-blueline_hwasan.mk Change-Id: If8537fc1bedbe6c3405de3662a5df210a073c43f
2020-07-23 14:09:18 +02:00
return newApexFile(ctx, fileToCopy, py.BaseModuleName(), 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
}
Soong package structure refactoring Give prebuilt_etc and sh_binary their own packages and split the gigantic main Android.bp up to small, per-package ones. Test: m nothing, TreeHugger Bug: 156980228 Change-Id: I7b00cd344b9f16861f1ff39edf0029f016b853d0
2020-06-01 19:45:49 +02:00
func apexFileForShBinary(ctx android.BaseModuleContext, sh *sh.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()
Use BaseModuleName() + SubName as apexFile.moduleName This change fixes this error: ``` TARGET module com.android.adbd.flattened requires non-existent TARGET module: prebuilt_libclang_rt.ubsan_standalone-arm-android ``` apexFile.moduleName is used as Make dependency name, so it should use m.BaseModuleName() instead of m.Name(), because soong may prepend "prebuilt_" to or mutate the output of m.Name() in other ways. android/androidmk.go emits Android.mk modules with `LOCAL_MODULE := module.BaseModuleName() + <SubName>`, so replace apexFile.moduleName with BaseModuleName() + <SubName> as much as possible. Bug: 7456955 Test: Add unit test in apex/apex_test.go Test: lunch blueline_hwasan && SANITIZE_TARGET='hwaddress fuzzer' m nothing Test: Verify out/soong/Android-blueline_hwasan.mk Change-Id: If8537fc1bedbe6c3405de3662a5df210a073c43f
2020-07-23 14:09:18 +02:00
af := newApexFile(ctx, fileToCopy, sh.BaseModuleName(), 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
}
Use BaseModuleName() + SubName as apexFile.moduleName This change fixes this error: ``` TARGET module com.android.adbd.flattened requires non-existent TARGET module: prebuilt_libclang_rt.ubsan_standalone-arm-android ``` apexFile.moduleName is used as Make dependency name, so it should use m.BaseModuleName() instead of m.Name(), because soong may prepend "prebuilt_" to or mutate the output of m.Name() in other ways. android/androidmk.go emits Android.mk modules with `LOCAL_MODULE := module.BaseModuleName() + <SubName>`, so replace apexFile.moduleName with BaseModuleName() + <SubName> as much as possible. Bug: 7456955 Test: Add unit test in apex/apex_test.go Test: lunch blueline_hwasan && SANITIZE_TARGET='hwaddress fuzzer' m nothing Test: Verify out/soong/Android-blueline_hwasan.mk Change-Id: If8537fc1bedbe6c3405de3662a5df210a073c43f
2020-07-23 14:09:18 +02:00
type javaModule interface {
android.Module
BaseModuleName() string
Revert^2 "Rename DexJar interface method to DexJarBuildPath." This reverts commit b0dc851ff4eca650042b52ce4ff06cb7e0312b77. Reason for revert: relanding original change. Build failures were caused by a race with another CL: https://r.android.com/1320920 Test: lunch aosp_cf_x86_phone-userdebug && m Change-Id: Ic9016582dae7773b4d4f84a63425f1ef7a5d061f
2020-06-04 16:08:17 +02:00
DexJarBuildPath() android.Path
dex_import can be added to apex Bug:157886942 Test: m Change-Id: Ida6f7bb784efe74cc1fa0e8d370eaee803f08b0f
2020-06-01 14:39:15 +02:00
JacocoReportClassesFile() android.Path
Build transitive lint reports for apex modules Build and export transitive lint report zips for apex modules. Bug: 153485543 Test: m TARGET_BUILD_APPS=com.google.android.wifi lint-check dist Change-Id: I5a1805440452301a7e2c4ca91482b989638b54fb
2020-07-22 05:31:17 +02:00
LintDepSets() java.LintDepSets
apex respects stem of java_library modules apex now respects stem of java_library modules. As a follow-up we need to suppor the same for other types of modules. Bug: 157638999 Test: m Change-Id: Iaf5023020b5440f1ffd4f5414b5a7864655fc22a
2020-05-28 16:46:55 +02:00
Stem() string
}
Use BaseModuleName() + SubName as apexFile.moduleName This change fixes this error: ``` TARGET module com.android.adbd.flattened requires non-existent TARGET module: prebuilt_libclang_rt.ubsan_standalone-arm-android ``` apexFile.moduleName is used as Make dependency name, so it should use m.BaseModuleName() instead of m.Name(), because soong may prepend "prebuilt_" to or mutate the output of m.Name() in other ways. android/androidmk.go emits Android.mk modules with `LOCAL_MODULE := module.BaseModuleName() + <SubName>`, so replace apexFile.moduleName with BaseModuleName() + <SubName> as much as possible. Bug: 7456955 Test: Add unit test in apex/apex_test.go Test: lunch blueline_hwasan && SANITIZE_TARGET='hwaddress fuzzer' m nothing Test: Verify out/soong/Android-blueline_hwasan.mk Change-Id: If8537fc1bedbe6c3405de3662a5df210a073c43f
2020-07-23 14:09:18 +02:00
var _ javaModule = (*java.Library)(nil)
var _ javaModule = (*java.SdkLibrary)(nil)
var _ javaModule = (*java.DexImport)(nil)
var _ javaModule = (*java.SdkLibraryImport)(nil)
Build transitive lint reports for apex modules Build and export transitive lint report zips for apex modules. Bug: 153485543 Test: m TARGET_BUILD_APPS=com.google.android.wifi lint-check dist Change-Id: I5a1805440452301a7e2c4ca91482b989638b54fb
2020-07-22 05:31:17 +02:00
Use BaseModuleName() + SubName as apexFile.moduleName This change fixes this error: ``` TARGET module com.android.adbd.flattened requires non-existent TARGET module: prebuilt_libclang_rt.ubsan_standalone-arm-android ``` apexFile.moduleName is used as Make dependency name, so it should use m.BaseModuleName() instead of m.Name(), because soong may prepend "prebuilt_" to or mutate the output of m.Name() in other ways. android/androidmk.go emits Android.mk modules with `LOCAL_MODULE := module.BaseModuleName() + <SubName>`, so replace apexFile.moduleName with BaseModuleName() + <SubName> as much as possible. Bug: 7456955 Test: Add unit test in apex/apex_test.go Test: lunch blueline_hwasan && SANITIZE_TARGET='hwaddress fuzzer' m nothing Test: Verify out/soong/Android-blueline_hwasan.mk Change-Id: If8537fc1bedbe6c3405de3662a5df210a073c43f
2020-07-23 14:09:18 +02:00
func apexFileForJavaLibrary(ctx android.BaseModuleContext, module javaModule) 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"
Use BaseModuleName() + SubName as apexFile.moduleName This change fixes this error: ``` TARGET module com.android.adbd.flattened requires non-existent TARGET module: prebuilt_libclang_rt.ubsan_standalone-arm-android ``` apexFile.moduleName is used as Make dependency name, so it should use m.BaseModuleName() instead of m.Name(), because soong may prepend "prebuilt_" to or mutate the output of m.Name() in other ways. android/androidmk.go emits Android.mk modules with `LOCAL_MODULE := module.BaseModuleName() + <SubName>`, so replace apexFile.moduleName with BaseModuleName() + <SubName> as much as possible. Bug: 7456955 Test: Add unit test in apex/apex_test.go Test: lunch blueline_hwasan && SANITIZE_TARGET='hwaddress fuzzer' m nothing Test: Verify out/soong/Android-blueline_hwasan.mk Change-Id: If8537fc1bedbe6c3405de3662a5df210a073c43f
2020-07-23 14:09:18 +02:00
fileToCopy := module.DexJarBuildPath()
af := newApexFile(ctx, fileToCopy, module.BaseModuleName(), dirInApex, javaSharedLib, module)
af.jacocoReportClassesFile = module.JacocoReportClassesFile()
af.lintDepSets = module.LintDepSets()
af.stem = module.Stem() + ".jar"
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 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
}
Soong package structure refactoring Give prebuilt_etc and sh_binary their own packages and split the gigantic main Android.bp up to small, per-package ones. Test: m nothing, TreeHugger Bug: 156980228 Change-Id: I7b00cd344b9f16861f1ff39edf0029f016b853d0
2020-06-01 19:45:49 +02:00
func apexFileForPrebuiltEtc(ctx android.BaseModuleContext, prebuilt prebuilt_etc.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
apex: respect filename property for apk-in-apex android_app_import supports filename: property, which overrides .apk filename. Now, apex packaging rule respects it too. (Previously, apex packaging ignored it) Bug: 152163837 Test: m (soong tests amended) Change-Id: I72e2f1c923f4d01c42a87bf2232a025adca4c918
2020-03-23 12:21:11 +01:00
InstallApkName() string
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
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
Use BaseModuleName() + SubName as apexFile.moduleName This change fixes this error: ``` TARGET module com.android.adbd.flattened requires non-existent TARGET module: prebuilt_libclang_rt.ubsan_standalone-arm-android ``` apexFile.moduleName is used as Make dependency name, so it should use m.BaseModuleName() instead of m.Name(), because soong may prepend "prebuilt_" to or mutate the output of m.Name() in other ways. android/androidmk.go emits Android.mk modules with `LOCAL_MODULE := module.BaseModuleName() + <SubName>`, so replace apexFile.moduleName with BaseModuleName() + <SubName> as much as possible. Bug: 7456955 Test: Add unit test in apex/apex_test.go Test: lunch blueline_hwasan && SANITIZE_TARGET='hwaddress fuzzer' m nothing Test: Verify out/soong/Android-blueline_hwasan.mk Change-Id: If8537fc1bedbe6c3405de3662a5df210a073c43f
2020-07-23 14:09:18 +02:00
BaseModuleName() string
apex: respect filename property for apk-in-apex android_app_import supports filename: property, which overrides .apk filename. Now, apex packaging rule respects it too. (Previously, apex packaging ignored it) Bug: 152163837 Test: m (soong tests amended) Change-Id: I72e2f1c923f4d01c42a87bf2232a025adca4c918
2020-03-23 12:21:11 +01:00
}) 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"
}
apex: respect filename property for apk-in-apex android_app_import supports filename: property, which overrides .apk filename. Now, apex packaging rule respects it too. (Previously, apex packaging ignored it) Bug: 152163837 Test: m (soong tests amended) Change-Id: I72e2f1c923f4d01c42a87bf2232a025adca4c918
2020-03-23 12:21:11 +01:00
dirInApex := filepath.Join(appDir, aapp.InstallApkName())
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 := aapp.OutputFile()
Use BaseModuleName() + SubName as apexFile.moduleName This change fixes this error: ``` TARGET module com.android.adbd.flattened requires non-existent TARGET module: prebuilt_libclang_rt.ubsan_standalone-arm-android ``` apexFile.moduleName is used as Make dependency name, so it should use m.BaseModuleName() instead of m.Name(), because soong may prepend "prebuilt_" to or mutate the output of m.Name() in other ways. android/androidmk.go emits Android.mk modules with `LOCAL_MODULE := module.BaseModuleName() + <SubName>`, so replace apexFile.moduleName with BaseModuleName() + <SubName> as much as possible. Bug: 7456955 Test: Add unit test in apex/apex_test.go Test: lunch blueline_hwasan && SANITIZE_TARGET='hwaddress fuzzer' m nothing Test: Verify out/soong/Android-blueline_hwasan.mk Change-Id: If8537fc1bedbe6c3405de3662a5df210a073c43f
2020-07-23 14:09:18 +02:00
af := newApexFile(ctx, fileToCopy, aapp.BaseModuleName(), dirInApex, app, aapp)
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.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. Bug: 148002117 Test: m 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
}
runtime_resource_overlay can be included in APEXes runtime_resource_overlay is put to an APEX via 'apps' property. It is placed under ./overlay directory in it. Bug: 154822536 Test: m Change-Id: I8edf4a26c26368c52fb7b327b2ecc829f21ea148
2020-04-24 14:16:36 +02:00
func apexFileForRuntimeResourceOverlay(ctx android.BaseModuleContext, rro java.RuntimeResourceOverlayModule) apexFile {
rroDir := "overlay"
dirInApex := filepath.Join(rroDir, rro.Theme())
fileToCopy := rro.OutputFile()
af := newApexFile(ctx, fileToCopy, rro.Name(), dirInApex, app, rro)
af.certificate = rro.Certificate()
if a, ok := rro.(interface {
OverriddenManifestPackageName() string
}); ok {
af.overriddenPackageName = a.OverriddenManifestPackageName()
}
return af
}
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
apex/apk: enforce min_sdk_version of all deps Enforce min_sdk_version for every payload dependency of updatable APEX/APKs. android.CheckMinSdkVersion() calls ApexModule.ShouldSupportSdkVersion for every transitive dependency from APEX/APK modules to see if it meets the min_sdk_version requirements. The common implementation for apex/android_app is provided in android/apex.go. Bug: 145796956 Bug: 152655956 Bug: 153333044 Test: m nothing Change-Id: I4a947dc94026df7cebd552b6e8ccdb4cc1f67170
2020-04-15 04:03:39 +02:00
func (a *apexBundle) WalkPayloadDeps(ctx android.ModuleContext, do android.PayloadDepsCallback) {
Improve missing apex_available message The apex available check can traverse quite a long path (5+ steps) to get from the apex to a module that is missing the apex from its apex_available property. Understanding where that dependency came from can often require examining the dependency path which can be difficult. This change adds the path to the error to simplify that process. Test: m nothing Bug: 152762638 Change-Id: Ic4eb169dc2026cd8339d49e23b25d6d1c3879750
2020-03-30 18:58:21 +02:00
ctx.WalkDeps(func(child, parent android.Module) 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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
am, ok := child.(android.ApexModule)
if !ok || !am.CanHaveApexVariants() {
return false
}
Do not follow prebuiltDependencyTags in APEX payload walks. If prebuilts are active they will have the other direct dependencies from the source modules. Bug: 151303681 Test: m nothing Test: `m` with prebuilts/runtime in the manifest (along with other fixes) Change-Id: I1ffc7e7b528ed9db5ce6ca2ee96c9d23c6548c49
2020-07-06 23:56:01 +02:00
dt := ctx.OtherModuleDependencyTag(child)
if _, ok := dt.(android.ExcludeFromApexContentsTag); ok {
return false
}
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
// Check for the direct dependencies that contribute to the payload
Do not follow prebuiltDependencyTags in APEX payload walks. If prebuilts are active they will have the other direct dependencies from the source modules. Bug: 151303681 Test: m nothing Test: `m` with prebuilts/runtime in the manifest (along with other fixes) Change-Id: I1ffc7e7b528ed9db5ce6ca2ee96c9d23c6548c49
2020-07-06 23:56:01 +02:00
if adt, ok := dt.(dependencyTag); ok {
if adt.payload {
Allow walkPayloadDeps visitor to control walk flow Delegate the responsibility for determining whether the walkPayloadDeps() should visit a child dependency to its do function. This is needed to allow the visitor in checkApexAvailability() to avoid checking the apex_available setting after crossing the APEX boundary. Bug: 152878661 Test: m droid Change-Id: If46a2f74b6eca670befc3aeae430650e85542346
2020-03-30 16:54:08 +02:00
return 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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
}
Allow walkPayloadDeps visitor to control walk flow Delegate the responsibility for determining whether the walkPayloadDeps() should visit a child dependency to its do function. This is needed to allow the visitor in checkApexAvailability() to avoid checking the apex_available setting after crossing the APEX boundary. Bug: 152878661 Test: m droid Change-Id: If46a2f74b6eca670befc3aeae430650e85542346
2020-03-30 16:54:08 +02:00
// As soon as the dependency graph crosses the APEX boundary, don't go further.
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
return false
}
// Check for the indirect dependencies if it is considered as part of the APEX
Reland: Deduplicate APEX variants that would build identically APEX variants that share the same SDK version and updatability almost always use identical command line arguments to build but with different intermediates directories. This causes unnecessary build time and disk space for duplicated work. Deduplicate APEX variants that would build identically. Create aliases from the per-APEX variations to the new shared variations so that the APEX modules can continue to depend on them via the APEX name as the variation. This has one significant change in behavior. Before this change, if an APEX had two libraries in its direct dependencies and one of those libraries depended on the other, and the second library had stubs, then the first library would depend on the implementation of the second library and not the stubs. After this change, if the first library is also present in a second APEX but the second library is not, then the common variant shared between the two APEXes would use the stubs, not the implementation. In a correctly configured set of build rules this change will be irrelevant, because if the compilation worked for the second APEX using stubs then it will work for the common variant using stubs. However, if an incorrect change to the build rules is made this could lead to confusing errors, as a previously-working common variant could suddenly stop building when a module is added to a new APEX without its dependencies that require implementation APIs to compile. This change reduces the number of modules in an AOSP arm64-userdebug build by 3% (52242 to 50586), reduces the number of variants of the libcutils module from 74 to 53, and reduces the number of variants of the massive libart[d] modules from 44 to 32. This relands I0529837476a253c32b3dfb98dcccf107427c742c with a fix to always mark permissions XML files of java_sdk_library modules as unique per apex since they contain the APEX filename, and a fix to UpdateUniqueApexVariationsForDeps to check ApexInfo.InApexes instead of DepIsInSameApex to check if two modules are in the same apex to account for a module that depends on another in a way that doesn't normally include the dependency in the APEX (e.g. a libs property), but the dependency is directly included in the APEX. Bug: 164216768 Test: go test ./build/soong/apex/... Change-Id: I2ae170601f764e5b88d0be2e0e6adc84e3a4d9cc
2020-08-11 21:17:01 +02:00
if android.InList(ctx.ModuleName(), am.InApexes()) {
Allow walkPayloadDeps visitor to control walk flow Delegate the responsibility for determining whether the walkPayloadDeps() should visit a child dependency to its do function. This is needed to allow the visitor in checkApexAvailability() to avoid checking the apex_available setting after crossing the APEX boundary. Bug: 152878661 Test: m droid Change-Id: If46a2f74b6eca670befc3aeae430650e85542346
2020-03-30 16:54:08 +02:00
return 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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
}
Allow walkPayloadDeps visitor to control walk flow Delegate the responsibility for determining whether the walkPayloadDeps() should visit a child dependency to its do function. This is needed to allow the visitor in checkApexAvailability() to avoid checking the apex_available setting after crossing the APEX boundary. Bug: 152878661 Test: m droid Change-Id: If46a2f74b6eca670befc3aeae430650e85542346
2020-03-30 16:54:08 +02:00
return 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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
})
}
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) Change-Id: I4a0b2002587bc24b7deeb5d59b6eeba5e1db5b1f
2020-02-26 14:45:42 +01:00
func (a *apexBundle) minSdkVersion(ctx android.BaseModuleContext) int {
apex/apk: enforce min_sdk_version of all deps Enforce min_sdk_version for every payload dependency of updatable APEX/APKs. android.CheckMinSdkVersion() calls ApexModule.ShouldSupportSdkVersion for every transitive dependency from APEX/APK modules to see if it meets the min_sdk_version requirements. The common implementation for apex/android_app is provided in android/apex.go. Bug: 145796956 Bug: 152655956 Bug: 153333044 Test: m nothing Change-Id: I4a947dc94026df7cebd552b6e8ccdb4cc1f67170
2020-04-15 04:03:39 +02:00
ver := proptools.String(a.properties.Min_sdk_version)
if ver == "" {
return android.FutureApiLevel
}
// Treat the current codenames as "current", which means future API version (10000)
// Otherwise, ApiStrToNum converts codename(non-finalized) to a value from [9000...]
// and would fail to build against "current".
if android.InList(ver, ctx.Config().PlatformVersionActiveCodenames()) {
return android.FutureApiLevel
}
// In "REL" branch, "current" is mapped to finalized sdk version
if ctx.Config().PlatformSdkCodename() == "REL" && ver == "current" {
return ctx.Config().PlatformSdkVersionInt()
}
// Finalized codenames are OKAY and will be converted to int
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: m Merged-In: I077ad7b2ac5d90b4c8708921e43846206f05ba70 Change-Id: I077ad7b2ac5d90b4c8708921e43846206f05ba70 (cherry picked from commit 29e91d21219485f0bc675c4d6034b5726be4ca92)
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) Change-Id: I4a0b2002587bc24b7deeb5d59b6eeba5e1db5b1f
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: m Merged-In: I077ad7b2ac5d90b4c8708921e43846206f05ba70 Change-Id: I077ad7b2ac5d90b4c8708921e43846206f05ba70 (cherry picked from commit 29e91d21219485f0bc675c4d6034b5726be4ca92)
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) Change-Id: I4a0b2002587bc24b7deeb5d59b6eeba5e1db5b1f
2020-02-26 14:45:42 +01:00
}
Generate combined deps-info for all updatable modules. Introduce a singleton apex rule to merge contents of individual deps-info results into a single output file. Bug: 149622332 Test: m Change-Id: I4ab7e1a3527fead97a81a5a2cb0e1e93a429117c
2020-04-28 15:57:42 +02:00
func (a *apexBundle) Updatable() bool {
return proptools.Bool(a.properties.Updatable)
}
var _ android.ApexBundleDepsInfoIntf = (*apexBundle)(nil)
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
}
apex: support "vendor: true" When an apex sets "vendor: true", it becomes a vendor apex. Vendor apexes use vendor variants for native modules and are installed in /vendor/apex. Bug: 159211312 Test: m Change-Id: I2585dd990ba857a2ab3ec6ab24e09d4652e867f2
2020-06-24 16:50:26 +02:00
// Because APEXes targeting other than system/system_ext partitions
// can't set apex_available, we skip checks for these APEXes
Add apex.use_vndk_as_stable property Vendor APEXes(in general, APEXes for non-system partitions) which is supposed to be tied to a specific VNDK version can set this new property so that it excludes VNDK libs and use them from VNDK APEX (provided by system parition). For these APEXes to use VNDK libs from VNDK APEX, linkerconfig should link "vndk" linker namespace to the namespaces of these APEXes. Bug: 159195575 Test: m (soong test added) Change-Id: If90650973239ef7aab0ff084488bda57d9b0364e
2020-07-22 08:54:47 +02:00
if a.SocSpecific() || a.DeviceSpecific() ||
(a.ProductSpecific() && ctx.Config().EnforceProductPartitionInterface()) {
apex: support "vendor: true" When an apex sets "vendor: true", it becomes a vendor apex. Vendor apexes use vendor variants for native modules and are installed in /vendor/apex. Bug: 159211312 Test: m Change-Id: I2585dd990ba857a2ab3ec6ab24e09d4652e867f2
2020-06-24 16:50:26 +02:00
return
}
Don't run apex_available check for coverage builds Coverage build adds extra dependencies for the runtime libs. Marking them and their transitive dependenciese with apex_available doesn't make any value; it instead adds noise. Bug: 150999716 Test: m Change-Id: I08e51cec1de6ded624ef9d4c41c1e5b2e611ff38
2020-03-28 06:43:19 +01:00
// Coverage build adds additional dependencies for the coverage-only runtime libraries.
// Requiring them and their transitive depencies with apex_available is not right
// because they just add noise.
if ctx.Config().IsEnvTrue("EMMA_INSTRUMENT") || a.IsNativeCoverageNeeded(ctx) {
return
}
apex/apk: enforce min_sdk_version of all deps Enforce min_sdk_version for every payload dependency of updatable APEX/APKs. android.CheckMinSdkVersion() calls ApexModule.ShouldSupportSdkVersion for every transitive dependency from APEX/APK modules to see if it meets the min_sdk_version requirements. The common implementation for apex/android_app is provided in android/apex.go. Bug: 145796956 Bug: 152655956 Bug: 153333044 Test: m nothing Change-Id: I4a947dc94026df7cebd552b6e8ccdb4cc1f67170
2020-04-15 04:03:39 +02:00
a.WalkPayloadDeps(ctx, func(ctx android.ModuleContext, from blueprint.Module, to android.ApexModule, externalDep bool) bool {
Allow walkPayloadDeps visitor to control walk flow Delegate the responsibility for determining whether the walkPayloadDeps() should visit a child dependency to its do function. This is needed to allow the visitor in checkApexAvailability() to avoid checking the apex_available setting after crossing the APEX boundary. Bug: 152878661 Test: m droid Change-Id: If46a2f74b6eca670befc3aeae430650e85542346
2020-03-30 16:54:08 +02:00
if externalDep {
// As soon as the dependency graph crosses the APEX boundary, don't go further.
return false
}
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
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. Bug: 151071238 Test: build/boot Change-Id: I0569ef4bb8e79635e4d97a89f421a8d8b7d26456
2020-03-09 22:23:13 +01:00
fromName := ctx.OtherModuleName(from)
toName := ctx.OtherModuleName(to)
Stop requiring apex_available on java_library members of sdks Previously, adding java_library to an sdk required that the names of any APEXes that transitively compiled against it were added to its apex_available property. This change removes that requirement. Also corrects the dependency path in the TestApexAvailable_IndirectDep error which previously passed through "shared from static" static dependency tags even though those are explicitly NOT followed when checking apex_available settings. Bug: 152878661 Test: m droid Change-Id: I995ed38956c1bc210b09494812de012fed9f9232
2020-03-31 16:23:40 +02:00
// If `to` is not actually in the same APEX as `from` then it does not need apex_available and neither
// do any of its dependencies.
if am, ok := from.(android.DepIsInSameApex); ok && !am.DepIsInSameApex(ctx, to) {
// As soon as the dependency graph crosses the APEX boundary, don't go further.
return false
}
Use inclusive language in build/soong Test: m checkbuild Change-Id: Id07890b7cbc2397291a658ca00e86b43c743aafc
2020-06-11 20:32:11 +02:00
if to.AvailableFor(apexName) || baselineApexAvailable(apexName, toName) {
Allow walkPayloadDeps visitor to control walk flow Delegate the responsibility for determining whether the walkPayloadDeps() should visit a child dependency to its do function. This is needed to allow the visitor in checkApexAvailability() to avoid checking the apex_available setting after crossing the APEX boundary. Bug: 152878661 Test: m droid Change-Id: If46a2f74b6eca670befc3aeae430650e85542346
2020-03-30 16:54:08 +02: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
}
Add GetPathString The method is a thin wrapper around GetWalkPath and GetTagPath to make it easy to construct a string representation of the current path. It was originally inlined in the apex package. This change makes it a function and moves it to the android package so make it more useful. Bug: N/A Test: m Change-Id: I7e2bc2074baed759d67d9097151c9ac10e34ed31
2020-05-07 09:12:13 +02:00
ctx.ModuleErrorf("%q requires %q that is not available for the APEX. Dependency path:%s", fromName, toName, ctx.GetPathString(true))
Allow walkPayloadDeps visitor to control walk flow Delegate the responsibility for determining whether the walkPayloadDeps() should visit a child dependency to its do function. This is needed to allow the visitor in checkApexAvailability() to avoid checking the apex_available setting after crossing the APEX boundary. Bug: 152878661 Test: m droid Change-Id: If46a2f74b6eca670befc3aeae430650e85542346
2020-03-30 16:54:08 +02:00
// Visit this module's dependencies to check and report any issues with their availability.
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
})
}
enforce updatable apexes to set min_sdk_version updatable APEXes should set min_sdk_version as well. Bug: 152655956 Test: m Change-Id: I8192086eb89fa958dd8ff1b731e43e24bf217ce2
2020-04-27 05:10:30 +02:00
func (a *apexBundle) checkUpdatable(ctx android.ModuleContext) {
Generate combined deps-info for all updatable modules. Introduce a singleton apex rule to merge contents of individual deps-info results into a single output file. Bug: 149622332 Test: m Change-Id: I4ab7e1a3527fead97a81a5a2cb0e1e93a429117c
2020-04-28 15:57:42 +02:00
if a.Updatable() {
enforce updatable apexes to set min_sdk_version updatable APEXes should set min_sdk_version as well. Bug: 152655956 Test: m Change-Id: I8192086eb89fa958dd8ff1b731e43e24bf217ce2
2020-04-27 05:10:30 +02:00
if String(a.properties.Min_sdk_version) == "" {
ctx.PropertyErrorf("updatable", "updatable APEXes should set min_sdk_version as well")
}
Ensure APEX's Java deps use stable SDKs. Test: m Bug: 153333044 Change-Id: Ib1acf3073e96fe23c92d292ec0b1a91e2cd408db
2020-04-15 18:29:42 +02:00
a.checkJavaStableSdkVersion(ctx)
enforce updatable apexes to set min_sdk_version updatable APEXes should set min_sdk_version as well. Bug: 152655956 Test: m Change-Id: I8192086eb89fa958dd8ff1b731e43e24bf217ce2
2020-04-27 05:10:30 +02:00
}
}
apex/apk: enforce min_sdk_version of all deps Enforce min_sdk_version for every payload dependency of updatable APEX/APKs. android.CheckMinSdkVersion() calls ApexModule.ShouldSupportSdkVersion for every transitive dependency from APEX/APK modules to see if it meets the min_sdk_version requirements. The common implementation for apex/android_app is provided in android/apex.go. Bug: 145796956 Bug: 152655956 Bug: 153333044 Test: m nothing Change-Id: I4a947dc94026df7cebd552b6e8ccdb4cc1f67170
2020-04-15 04:03:39 +02:00
func (a *apexBundle) checkMinSdkVersion(ctx android.ModuleContext) {
if a.testApex || a.vndkApex {
return
}
// Meaningless to check min_sdk_version when building use_vendor modules against non-Trebleized targets
if proptools.Bool(a.properties.Use_vendor) && ctx.DeviceConfig().VndkVersion() == "" {
return
}
android.CheckMinSdkVersion(a, ctx, a.minSdkVersion(ctx))
}
Reland "Prevent statically linking to a lib providing stable C APIs" This reverts commit 5b75774004f0dc26a6dfe5d62976e1d2af4bcff3. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 151051671 Test: m Merged-In: I05f0465976098941d47ecc06c978cfa116364d78 (cherry picked from commit af7ed39b062c534263ea3091250fd64964896e55) Change-Id: I05f0465976098941d47ecc06c978cfa116364d78
2020-05-10 08:16:24 +02:00
// Ensures that a lib providing stub isn't statically linked
func (a *apexBundle) checkStaticLinkingToStubLibraries(ctx android.ModuleContext) {
// Practically, we only care about regular APEXes on the device.
if ctx.Host() || a.testApex || a.vndkApex {
return
}
apex/apk: enforce min_sdk_version of all deps Enforce min_sdk_version for every payload dependency of updatable APEX/APKs. android.CheckMinSdkVersion() calls ApexModule.ShouldSupportSdkVersion for every transitive dependency from APEX/APK modules to see if it meets the min_sdk_version requirements. The common implementation for apex/android_app is provided in android/apex.go. Bug: 145796956 Bug: 152655956 Bug: 153333044 Test: m nothing Change-Id: I4a947dc94026df7cebd552b6e8ccdb4cc1f67170
2020-04-15 04:03:39 +02:00
a.WalkPayloadDeps(ctx, func(ctx android.ModuleContext, from blueprint.Module, to android.ApexModule, externalDep bool) bool {
Reland "Prevent statically linking to a lib providing stable C APIs" This reverts commit 5b75774004f0dc26a6dfe5d62976e1d2af4bcff3. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 151051671 Test: m Merged-In: I05f0465976098941d47ecc06c978cfa116364d78 (cherry picked from commit af7ed39b062c534263ea3091250fd64964896e55) Change-Id: I05f0465976098941d47ecc06c978cfa116364d78
2020-05-10 08:16:24 +02:00
if ccm, ok := to.(*cc.Module); ok {
apexName := ctx.ModuleName()
fromName := ctx.OtherModuleName(from)
toName := ctx.OtherModuleName(to)
// If `to` is not actually in the same APEX as `from` then it does not need apex_available and neither
// do any of its dependencies.
if am, ok := from.(android.DepIsInSameApex); ok && !am.DepIsInSameApex(ctx, to) {
// As soon as the dependency graph crosses the APEX boundary, don't go further.
return false
}
// TODO(jiyong) remove this check when R is published to AOSP. Currently, libstatssocket
// is capable of providing a stub variant, but is being statically linked from the bluetooth
// APEX.
if toName == "libstatssocket" {
return false
}
// The dynamic linker and crash_dump tool in the runtime APEX is the only exception to this rule.
// It can't make the static dependencies dynamic because it can't
// do the dynamic linking for itself.
if apexName == "com.android.runtime" && (fromName == "linker" || fromName == "crash_dump") {
return false
}
isStubLibraryFromOtherApex := ccm.HasStubsVariants() && !android.DirectlyInApex(apexName, toName)
if isStubLibraryFromOtherApex && !externalDep {
ctx.ModuleErrorf("%q required by %q is a native library providing stub. "+
"It shouldn't be included in this APEX via static linking. Dependency path: %s", to.String(), fromName, ctx.GetPathString(false))
}
}
return true
})
}
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) {
Disable flattening only for unbundled apps. This allows the unbundled master-art branch to still use flattened APEXes in its test builds. Bug: 159109002 Test: art/build/apex/runtests.sh on master-art Test: m nothing Change-Id: I768c6b7f5afbc348cd7730e4ba96507678434778
2020-06-24 23:31:36 +02:00
buildFlattenedAsDefault := ctx.Config().FlattenApex() && !ctx.Config().UnbundledBuildApps()
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
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
a.checkApexAvailability(ctx)
enforce updatable apexes to set min_sdk_version updatable APEXes should set min_sdk_version as well. Bug: 152655956 Test: m Change-Id: I8192086eb89fa958dd8ff1b731e43e24bf217ce2
2020-04-27 05:10:30 +02:00
a.checkUpdatable(ctx)
apex/apk: enforce min_sdk_version of all deps Enforce min_sdk_version for every payload dependency of updatable APEX/APKs. android.CheckMinSdkVersion() calls ApexModule.ShouldSupportSdkVersion for every transitive dependency from APEX/APK modules to see if it meets the min_sdk_version requirements. The common implementation for apex/android_app is provided in android/apex.go. Bug: 145796956 Bug: 152655956 Bug: 153333044 Test: m nothing Change-Id: I4a947dc94026df7cebd552b6e8ccdb4cc1f67170
2020-04-15 04:03:39 +02:00
a.checkMinSdkVersion(ctx)
Reland "Prevent statically linking to a lib providing stable C APIs" This reverts commit 5b75774004f0dc26a6dfe5d62976e1d2af4bcff3. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 151051671 Test: m Merged-In: I05f0465976098941d47ecc06c978cfa116364d78 (cherry picked from commit af7ed39b062c534263ea3091250fd64964896e55) Change-Id: I05f0465976098941d47ecc06c978cfa116364d78
2020-05-10 08:16:24 +02:00
a.checkStaticLinkingToStubLibraries(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
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/apk: enforce min_sdk_version of all deps Enforce min_sdk_version for every payload dependency of updatable APEX/APKs. android.CheckMinSdkVersion() calls ApexModule.ShouldSupportSdkVersion for every transitive dependency from APEX/APK modules to see if it meets the min_sdk_version requirements. The common implementation for apex/android_app is provided in android/apex.go. Bug: 145796956 Bug: 152655956 Bug: 153333044 Test: m nothing Change-Id: I4a947dc94026df7cebd552b6e8ccdb4cc1f67170
2020-04-15 04:03:39 +02: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)
Ignore PrebuiltDepTag when processing APEX contents When a source and a prebuilt module are present in the same build a dependency is added from the source module to the prebuilt module. Previously, the code for generating the APEX did not recognize that tag and in some cases (e.g. for cc_(prebuilt_)library_shared) will fail the build. This change: 1) Adds a test to reproduce the problem. 2) Improves the debug message by pretty printing the tag. 3) Adds a new ExcludeFromApexContents interface that can be implemented by a tag to declare that it should be excluded from the APEX contents. 4) Ignores tags that implement that interface when generating APEX contents. 5) Implements that interface on prebuiltDependencyTag to fix the test. Bug: 153326844 Test: m nothing Change-Id: I9dd4312c4f995c816c0a31d8d733eb5d7f56e1ea
2020-04-07 16:25:44 +02:00
if _, ok := depTag.(android.ExcludeFromApexContentsTag); ok {
return false
}
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
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 {
Add "jni_libs" property to apex module Which is the list of JNI libraries that are embeded inside the apex. jni_libs is handled just like native_shared_libs except that it is stored in apex_manifest. When linkerconfig finds an apex with JNI libs, it exposes the namespace for the apex as visible so that libnativeloader can link the namespace to the corresponding classloader-namespace. Bug: 149363889 Test: m nothing(runs soong test) Change-Id: I52ebe38b44545e6e8853e34a3404a235c858112a
2020-02-27 05:50:06 +01:00
case sharedLibTag, jniLibTag:
isJniLib := depTag == jniLibTag
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 {
Add "jni_libs" property to apex module Which is the list of JNI libraries that are embeded inside the apex. jni_libs is handled just like native_shared_libs except that it is stored in apex_manifest. When linkerconfig finds an apex with JNI libs, it exposes the namespace for the apex as visible so that libnativeloader can link the namespace to the corresponding classloader-namespace. Bug: 149363889 Test: m nothing(runs soong test) Change-Id: I52ebe38b44545e6e8853e34a3404a235c858112a
2020-02-27 05:50:06 +01:00
fi := apexFileForNativeLibrary(ctx, c, handleSpecialLibs)
fi.isJniLib = isJniLib
filesInfo = append(filesInfo, fi)
VNDK APEX should not provide native libs While libz has stubs for other mainline modules, it doesn't provide stubs when it is used as a VNDK lib. In general, VNDK libs are only for vendor modules. So, we skip them even if they have stubs. Bug: 155456180 Test: m com.android.vndk.current provideNativeLibs of the APEX should be empty Change-Id: I22401a2b1732a8560802c5be850181682e183a8e
2020-06-15 07:59:42 +02:00
// Collect the list of stub-providing libs except:
// - VNDK libs are only for vendors
// - bootstrap bionic libs are treated as provided by system
if c.HasStubsVariants() && !a.vndkApex && !cc.InstallToBootstrap(c.BaseModuleName(), ctx.Config()) {
Use Stem where output file name is expected in APEX Bug: 157638999 Test: m Change-Id: I4a4892bc2941cf1301d210fc3107c02f0e7b13b7
2020-05-29 14:29:20 +02:00
provideNativeLibs = append(provideNativeLibs, fi.Stem())
}
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 {
Add "jni_libs" property to apex module Which is the list of JNI libraries that are embeded inside the apex. jni_libs is handled just like native_shared_libs except that it is stored in apex_manifest. When linkerconfig finds an apex with JNI libs, it exposes the namespace for the apex as visible so that libnativeloader can link the namespace to the corresponding classloader-namespace. Bug: 149363889 Test: m nothing(runs soong test) Change-Id: I52ebe38b44545e6e8853e34a3404a235c858112a
2020-02-27 05:50:06 +01:00
propertyName := "native_shared_libs"
if isJniLib {
propertyName = "jni_libs"
}
ctx.PropertyErrorf(propertyName, "%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
Soong package structure refactoring Give prebuilt_etc and sh_binary their own packages and split the gigantic main Android.bp up to small, per-package ones. Test: m nothing, TreeHugger Bug: 156980228 Change-Id: I7b00cd344b9f16861f1ff39edf0029f016b853d0
2020-06-01 19:45:49 +02:00
} else if sh, ok := child.(*sh.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:
dex_import can be added to apex Bug:157886942 Test: m Change-Id: Ida6f7bb784efe74cc1fa0e8d370eaee803f08b0f
2020-06-01 14:39:15 +02:00
switch child.(type) {
Let APEX build against preferred java_sdk_library_import If a java_sdk_library_import has a corresponding java_sdk_library then make the java_sdk_library_import export both the xml and impl modules created by the java_sdk_library. Makes java_sdk_library_import consistent with java_sdk_library by providing libraries within the same APEX access to the implementation library instead of the stubs. Bug: 158304459 Test: m nothing Test what happens when building com.android.tethering with and without a preferred "framework-tethering" java_sdk_library_import. Make sure that it does not change the generated APEX. Change-Id: I2f4edea937ac377431a5696c92cbd467bded62ef
2020-06-12 18:46:39 +02:00
case *java.Library, *java.SdkLibrary, *java.DexImport, *java.SdkLibraryImport:
Use BaseModuleName() + SubName as apexFile.moduleName This change fixes this error: ``` TARGET module com.android.adbd.flattened requires non-existent TARGET module: prebuilt_libclang_rt.ubsan_standalone-arm-android ``` apexFile.moduleName is used as Make dependency name, so it should use m.BaseModuleName() instead of m.Name(), because soong may prepend "prebuilt_" to or mutate the output of m.Name() in other ways. android/androidmk.go emits Android.mk modules with `LOCAL_MODULE := module.BaseModuleName() + <SubName>`, so replace apexFile.moduleName with BaseModuleName() + <SubName> as much as possible. Bug: 7456955 Test: Add unit test in apex/apex_test.go Test: lunch blueline_hwasan && SANITIZE_TARGET='hwaddress fuzzer' m nothing Test: Verify out/soong/Android-blueline_hwasan.mk Change-Id: If8537fc1bedbe6c3405de3662a5df210a073c43f
2020-07-23 14:09:18 +02:00
af := apexFileForJavaLibrary(ctx, child.(javaModule))
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
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
dex_import can be added to apex Bug:157886942 Test: m Change-Id: Ida6f7bb784efe74cc1fa0e8d370eaee803f08b0f
2020-06-01 14:39:15 +02:00
default:
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:
if ap, ok := child.(*java.AndroidApp); ok {
apex: respect filename property for apk-in-apex android_app_import supports filename: property, which overrides .apk filename. Now, apex packaging rule respects it too. (Previously, apex packaging ignored it) Bug: 152163837 Test: m (soong tests amended) Change-Id: I72e2f1c923f4d01c42a87bf2232a025adca4c918
2020-03-23 12:21:11 +01:00
filesInfo = append(filesInfo, apexFileForAndroidApp(ctx, ap))
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 {
apex: respect filename property for apk-in-apex android_app_import supports filename: property, which overrides .apk filename. Now, apex packaging rule respects it too. (Previously, apex packaging ignored it) Bug: 152163837 Test: m (soong tests amended) Change-Id: I72e2f1c923f4d01c42a87bf2232a025adca4c918
2020-03-23 12:21:11 +01:00
filesInfo = append(filesInfo, apexFileForAndroidApp(ctx, ap))
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 {
apex: respect filename property for apk-in-apex android_app_import supports filename: property, which overrides .apk filename. Now, apex packaging rule respects it too. (Previously, apex packaging ignored it) Bug: 152163837 Test: m (soong tests amended) Change-Id: I72e2f1c923f4d01c42a87bf2232a025adca4c918
2020-03-23 12:21:11 +01:00
filesInfo = append(filesInfo, apexFileForAndroidApp(ctx, ap))
Allow apex module to have android_app_set as its constituent. Fixes: 157166068 Test: treehugger & manual Change-Id: I9f91f1b761286f489d175eb0772f78f702e8a2d6
2020-05-28 01:36:07 +02:00
} else if ap, ok := child.(*java.AndroidAppSet); ok {
appDir := "app"
if ap.Privileged() {
appDir = "priv-app"
}
Use BaseModuleName() + SubName as apexFile.moduleName This change fixes this error: ``` TARGET module com.android.adbd.flattened requires non-existent TARGET module: prebuilt_libclang_rt.ubsan_standalone-arm-android ``` apexFile.moduleName is used as Make dependency name, so it should use m.BaseModuleName() instead of m.Name(), because soong may prepend "prebuilt_" to or mutate the output of m.Name() in other ways. android/androidmk.go emits Android.mk modules with `LOCAL_MODULE := module.BaseModuleName() + <SubName>`, so replace apexFile.moduleName with BaseModuleName() + <SubName> as much as possible. Bug: 7456955 Test: Add unit test in apex/apex_test.go Test: lunch blueline_hwasan && SANITIZE_TARGET='hwaddress fuzzer' m nothing Test: Verify out/soong/Android-blueline_hwasan.mk Change-Id: If8537fc1bedbe6c3405de3662a5df210a073c43f
2020-07-23 14:09:18 +02:00
af := newApexFile(ctx, ap.OutputFile(), ap.BaseModuleName(),
Allow apex module to have android_app_set as its constituent. Fixes: 157166068 Test: treehugger & manual Change-Id: I9f91f1b761286f489d175eb0772f78f702e8a2d6
2020-05-28 01:36:07 +02:00
filepath.Join(appDir, ap.BaseModuleName()), appSet, ap)
af.certificate = java.PresignedCertificate
filesInfo = append(filesInfo, af)
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)
}
runtime_resource_overlay can be included in APEXes runtime_resource_overlay is put to an APEX via 'apps' property. It is placed under ./overlay directory in it. Bug: 154822536 Test: m Change-Id: I8edf4a26c26368c52fb7b327b2ecc829f21ea148
2020-04-24 14:16:36 +02:00
case rroTag:
if rro, ok := child.(java.RuntimeResourceOverlayModule); ok {
filesInfo = append(filesInfo, apexFileForRuntimeResourceOverlay(ctx, rro))
} else {
ctx.PropertyErrorf("rros", "%q is not an runtime_resource_overlay 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:
Soong package structure refactoring Give prebuilt_etc and sh_binary their own packages and split the gigantic main Android.bp up to small, per-package ones. Test: m nothing, TreeHugger Bug: 156980228 Change-Id: I7b00cd344b9f16861f1ff39edf0029f016b853d0
2020-06-01 19:45:49 +02:00
if prebuilt, ok := child.(prebuilt_etc.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).
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
}
Dependencies of tests are also included in APEX Shared lib dependencies of a test is included in the APEX regardless of whether the test has test_per_srcs or not. Bug: N/A Test: m (apex_test.go amended) Change-Id: I6b16843cc7467c42e250aba88d79d5580ba47324
2020-05-04 03:31:32 +02:00
return true // track transitive dependencies
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
apex_set is force disabled when necessary prebuilt_apex has been disabled when the device is configured for flattened APEXes, sanitized, instrumented, or built unbundled. However, apex_set which is another type of APEX prebuilt wasn't disabled for the same conditions. This change fixes the discripency. apex_set modules are also force disabled when the prebuilts are not expected. Bug: 161316762 Bug: 160933444 Test: OVERRIDE_TARGET_FLATTEN_APEX=true m The built image has only the flattened APEXes and the device boots Change-Id: I6c90dfb28d565861a473a1bdce93269ec370601d
2020-07-16 14:38:56 +02:00
if prebuilt, ok := child.(prebuilt); ok && prebuilt.isForceDisabled() {
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
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
}
Add apex.use_vndk_as_stable property Vendor APEXes(in general, APEXes for non-system partitions) which is supposed to be tied to a specific VNDK version can set this new property so that it excludes VNDK libs and use them from VNDK APEX (provided by system parition). For these APEXes to use VNDK libs from VNDK APEX, linkerconfig should link "vndk" linker namespace to the namespaces of these APEXes. Bug: 159195575 Test: m (soong test added) Change-Id: If90650973239ef7aab0ff084488bda57d9b0364e
2020-07-22 08:54:47 +02:00
if cc.UseVndk() && proptools.Bool(a.properties.Use_vndk_as_stable) && cc.IsVndk() {
apex: set ":vndk" as required for vendor apexes When a vendor APEX sets use_vndk_as_stable: true, then the apex doesn't bundle VNDK libraries but instead it uses them from the "vndk" namespace at runtime. ":vndk" is a pseudo-name for VNDK libraries, which is processed by linkerconfig so that the generated linker configuration allows the namespace for the apex to access VNDK libs. Bug: 159576928 Test: test with a test-only vendor apex it runs okay with VNDK libs. (lsof shows that it opens libs from VNDK APEX) Change-Id: I924ce0fea696162575f59589b8f858deddf436b3
2020-07-29 09:00:54 +02:00
requireNativeLibs = append(requireNativeLibs, ":vndk")
Add apex.use_vndk_as_stable property Vendor APEXes(in general, APEXes for non-system partitions) which is supposed to be tied to a specific VNDK version can set this new property so that it excludes VNDK libs and use them from VNDK APEX (provided by system parition). For these APEXes to use VNDK libs from VNDK APEX, linkerconfig should link "vndk" linker namespace to the namespaces of these APEXes. Bug: 159195575 Test: m (soong test added) Change-Id: If90650973239ef7aab0ff084488bda57d9b0364e
2020-07-22 08:54:47 +02:00
return false
}
Use Stem where output file name is expected in APEX Bug: 157638999 Test: m Change-Id: I4a4892bc2941cf1301d210fc3107c02f0e7b13b7
2020-05-29 14:29:20 +02:00
af := apexFileForNativeLibrary(ctx, cc, handleSpecialLibs)
af.transitiveDep = true
apex: use SubName for requiredDeps apexBundle keeps the required dependencies for native modules which are external dependencies and then records it in .mk file as LOCAL_REQUIRED_MODULES key. LOCAL_REQUIRED_MODULES should list module name which are made of cc.BaseModuleName() + SubName. By the way, because a use_vendor:true apex is supposed to be installed in /system/apex, we don't append SubName(.vendor) suffix. Bug: 159211312 Bug: 155841765 Test: m Change-Id: Ifd2858dda0b373110a0cd18a0c55db41f0fc2a99
2020-06-25 10:14:25 +02:00
if !a.Host() && !android.DirectlyInApex(ctx.ModuleName(), depName) && (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.
apex: use SubName for requiredDeps apexBundle keeps the required dependencies for native modules which are external dependencies and then records it in .mk file as LOCAL_REQUIRED_MODULES key. LOCAL_REQUIRED_MODULES should list module name which are made of cc.BaseModuleName() + SubName. By the way, because a use_vendor:true apex is supposed to be installed in /system/apex, we don't append SubName(.vendor) suffix. Bug: 159211312 Bug: 155841765 Test: m Change-Id: Ifd2858dda0b373110a0cd18a0c55db41f0fc2a99
2020-06-25 10:14:25 +02:00
if !android.DirectlyInAnyApex(ctx, depName) {
// we need a module name for Make
name := cc.BaseModuleName() + cc.Properties.SubName
if proptools.Bool(a.properties.Use_vendor) {
// we don't use subName(.vendor) for a "use_vendor: true" apex
// which is supposed to be installed in /system
name = cc.BaseModuleName()
}
if !android.InList(name, a.requiredDeps) {
a.requiredDeps = append(a.requiredDeps, 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
}
Use Stem where output file name is expected in APEX Bug: 157638999 Test: m Change-Id: I4a4892bc2941cf1301d210fc3107c02f0e7b13b7
2020-05-29 14:29:20 +02:00
requireNativeLibs = append(requireNativeLibs, af.Stem())
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
}
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
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).
Use BaseModuleName() + SubName as apexFile.moduleName This change fixes this error: ``` TARGET module com.android.adbd.flattened requires non-existent TARGET module: prebuilt_libclang_rt.ubsan_standalone-arm-android ``` apexFile.moduleName is used as Make dependency name, so it should use m.BaseModuleName() instead of m.Name(), because soong may prepend "prebuilt_" to or mutate the output of m.Name() in other ways. android/androidmk.go emits Android.mk modules with `LOCAL_MODULE := module.BaseModuleName() + <SubName>`, so replace apexFile.moduleName with BaseModuleName() + <SubName> as much as possible. Bug: 7456955 Test: Add unit test in apex/apex_test.go Test: lunch blueline_hwasan && SANITIZE_TARGET='hwaddress fuzzer' m nothing Test: Verify out/soong/Android-blueline_hwasan.mk Change-Id: If8537fc1bedbe6c3405de3662a5df210a073c43f
2020-07-23 14:09:18 +02:00
af.androidMkModuleName = 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 Change-Id: Ifa1a6430a420ae7376b155cd59b8ece462cced7e
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) {
Soong package structure refactoring Give prebuilt_etc and sh_binary their own packages and split the gigantic main Android.bp up to small, per-package ones. Test: m nothing, TreeHugger Bug: 156980228 Change-Id: I7b00cd344b9f16861f1ff39edf0029f016b853d0
2020-06-01 19:45:49 +02:00
if prebuilt, ok := child.(prebuilt_etc.PrebuiltEtcModule); ok {
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
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() {
Add GetPathString The method is a thin wrapper around GetWalkPath and GetTagPath to make it easy to construct a string representation of the current path. It was originally inlined in the apex package. This change makes it a function and moves it to the android package so make it more useful. Bug: N/A Test: m Change-Id: I7e2bc2074baed759d67d9097151c9ac10e34ed31
2020-05-07 09:12:13 +02:00
ctx.ModuleErrorf("unexpected tag %s for indirect dependency %q", android.PrettyPrintTag(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 {
Revert "Share vdex files in the ART apex between architectures (..." Revert submission 1254009-vdex-symlinks Reason for revert: This causing some devices to fail to boot. See b/151836042 for details. Reverted Changes: Iced89071b:Expect vdex files in a target-independent director... Ifbceb8457:Share vdex files in the ART apex between architect... Change-Id: I5bd88f8e61d442eed921d840c90777a2750ddb16
2020-03-18 19:00:41 +01:00
for arch, files := range java.DexpreoptedArtApexJars(ctx) {
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
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
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
apex: support "vendor: true" When an apex sets "vendor: true", it becomes a vendor apex. Vendor apexes use vendor variants for native modules and are installed in /vendor/apex. Bug: 159211312 Test: m Change-Id: I2585dd990ba857a2ab3ec6ab24e09d4652e867f2
2020-06-24 16:50:26 +02:00
// APEXes targeting other than system/system_ext partitions use vendor/product variants.
// So we can't link them to /system/lib libs which are core variants.
Add apex.use_vndk_as_stable property Vendor APEXes(in general, APEXes for non-system partitions) which is supposed to be tied to a specific VNDK version can set this new property so that it excludes VNDK libs and use them from VNDK APEX (provided by system parition). For these APEXes to use VNDK libs from VNDK APEX, linkerconfig should link "vndk" linker namespace to the namespaces of these APEXes. Bug: 159195575 Test: m (soong test added) Change-Id: If90650973239ef7aab0ff084488bda57d9b0364e
2020-07-22 08:54:47 +02:00
if a.SocSpecific() || a.DeviceSpecific() ||
(a.ProductSpecific() && ctx.Config().EnforceProductPartitionInterface()) {
apex: support "vendor: true" When an apex sets "vendor: true", it becomes a vendor apex. Vendor apexes use vendor variants for native modules and are installed in /vendor/apex. Bug: 159211312 Test: m Change-Id: I2585dd990ba857a2ab3ec6ab24e09d4652e867f2
2020-06-24 16:50:26 +02:00
a.linkToSystemLib = false
}
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)
Generate combined deps-info for all updatable modules. Introduce a singleton apex rule to merge contents of individual deps-info results into a single output file. Bug: 149622332 Test: m Change-Id: I4ab7e1a3527fead97a81a5a2cb0e1e93a429117c
2020-04-28 15:57:42 +02:00
if a.Updatable() && a.properties.ApexType == imageApex {
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
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. Merged-In: I28492dfaaef471117a430be05255fbef76e557b0 (cherry picked from commit 9b96418dfefa251409f17495cc0f9b093f8b4897) 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)
apex: add apex_manifest.pb in file_contexts apex_manifest.pb is added to payload.img by the build system and is supposed to be read by apexd during activation. So, it should be labeled as "system_file" so that apexd can read it regardless of how file_contexts is defined. Bug: 159767275 Test: add an apex with file_contexts with everything as vendor_file apexd should activate the apex. Change-Id: Ie34eb7ad905828976152d67a7dfabf0add0a5de4
2020-06-24 12:33:06 +02:00
a.buildFileContexts(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
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)
Build transitive lint reports for apex modules Build and export transitive lint report zips for apex modules. Bug: 153485543 Test: m TARGET_BUILD_APPS=com.google.android.wifi lint-check dist Change-Id: I5a1805440452301a7e2c4ca91482b989638b54fb
2020-07-22 05:31:17 +02:00
a.buildLintReports(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
}
Ensure APEX's Java deps use stable SDKs. Test: m Bug: 153333044 Change-Id: Ib1acf3073e96fe23c92d292ec0b1a91e2cd408db
2020-04-15 18:29:42 +02:00
// Enforce that Java deps of the apex are using stable SDKs to compile
func (a *apexBundle) checkJavaStableSdkVersion(ctx android.ModuleContext) {
// Visit direct deps only. As long as we guarantee top-level deps are using
// stable SDKs, java's checkLinkType guarantees correct usage for transitive deps
ctx.VisitDirectDepsBlueprint(func(module blueprint.Module) {
tag := ctx.OtherModuleDependencyTag(module)
switch tag {
case javaLibTag, androidAppTag:
if m, ok := module.(interface{ CheckStableSdkVersion() error }); ok {
if err := m.CheckStableSdkVersion(); err != nil {
ctx.ModuleErrorf("cannot depend on \"%v\": %v", ctx.OtherModuleName(module), err)
}
}
}
})
}
Use inclusive language in build/soong Test: m checkbuild Change-Id: Id07890b7cbc2397291a658ca00e86b43c743aafc
2020-06-11 20:32:11 +02:00
func baselineApexAvailable(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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
2020-01-10 16:12:39 +01:00
key := apex
Copy white listed apex available settings into snapshot Makes sure that the module snapshots do not rely on the white list of apex available settings so that when those lists are removed it is not necessary to update any snapshots. Bug: 142935992 Test: m nothing Change-Id: Iedcff7dfc2646a4da77258d16e06657dd2f411f9
2020-03-06 13:30:13 +01:00
moduleName = normalizeModuleName(moduleName)
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
Use inclusive language in build/soong Test: m checkbuild Change-Id: Id07890b7cbc2397291a658ca00e86b43c743aafc
2020-06-11 20:32:11 +02:00
if val, ok := apexAvailBaseline[key]; ok && android.InList(moduleName, val) {
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. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 147671264 Test: m Merged-In: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e (cherry picked from commit fa89944c79f19552e906b41fd03a4981903eee7e) Change-Id: Iaedc05494085ff4e8af227a6392bdd0c338b8e6e
2020-01-30 18:49:53 +01:00
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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
2020-01-10 16:12:39 +01:00
}
Copy white listed apex available settings into snapshot Makes sure that the module snapshots do not rely on the white list of apex available settings so that when those lists are removed it is not necessary to update any snapshots. Bug: 142935992 Test: m nothing Change-Id: Iedcff7dfc2646a4da77258d16e06657dd2f411f9
2020-03-06 13:30:13 +01:00
key = android.AvailableToAnyApex
Use inclusive language in build/soong Test: m checkbuild Change-Id: Id07890b7cbc2397291a658ca00e86b43c743aafc
2020-06-11 20:32:11 +02:00
if val, ok := apexAvailBaseline[key]; ok && android.InList(moduleName, val) {
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: cherry-pick from internal Change-Id: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 Merged-In: I837299c6a15d46f8a5ba544b613776b1cc27d7b8 (cherry picked from commit 93488cbb10d4882845abb732f8e53714f0982031)
2020-01-10 16:12:39 +01:00
return true
}
return false
}
Copy white listed apex available settings into snapshot Makes sure that the module snapshots do not rely on the white list of apex available settings so that when those lists are removed it is not necessary to update any snapshots. Bug: 142935992 Test: m nothing Change-Id: Iedcff7dfc2646a4da77258d16e06657dd2f411f9
2020-03-06 13:30:13 +01:00
func normalizeModuleName(moduleName string) string {
// 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"
}
apex: Make android_library support APEX variants The android_library module type can be used within an android_app that can itself be added to an apex but android_library does not call android.InitApexModule(module) and so it does not support apex variants and so is treated as if it cannot be part of an APEX even though it actually is. Now, android_library supports AEPX variants. Due to this change, the whilelist for apex_available got bigger. Exempt-From-Owner-Approval: cherry-pick from internal Bug: 156978407 Test: m Merged-In: I3a21d653fe9c4159e3a89791fe1a8597865eeae6 Change-Id: I3a21d653fe9c4159e3a89791fe1a8597865eeae6 (cherry picked from commit bd133b1bdc1de378992491c3154a9ec0b347f7c3)
2020-05-20 02:06:00 +02:00
if strings.HasPrefix(moduleName, "androidx.") {
// TODO(b/156996905) Set apex_available/min_sdk_version for androidx support libraries
moduleName = "androidx"
}
Copy white listed apex available settings into snapshot Makes sure that the module snapshots do not rely on the white list of apex available settings so that when those lists are removed it is not necessary to update any snapshots. Bug: 142935992 Test: m nothing Change-Id: Iedcff7dfc2646a4da77258d16e06657dd2f411f9
2020-03-06 13:30:13 +01:00
return moduleName
}
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
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