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"
|
2019-11-19 18:26:02 +01:00
|
|
|
"path"
|
2018-10-10 07:01:00 +02:00
|
|
|
"path/filepath"
|
2018-10-10 07:05:29 +02:00
|
|
|
"sort"
|
2018-10-10 07:01:00 +02:00
|
|
|
"strings"
|
2019-08-23 04:17:39 +02:00
|
|
|
"sync"
|
2018-10-10 07:01:00 +02:00
|
|
|
|
2020-06-01 19:45:49 +02:00
|
|
|
"github.com/google/blueprint"
|
|
|
|
|
"github.com/google/blueprint/bootstrap"
|
|
|
|
|
"github.com/google/blueprint/proptools"
|
|
|
|
|
|
2018-10-10 07:01:00 +02:00
|
|
|
"android/soong/android"
|
|
|
|
|
"android/soong/cc"
|
2020-06-01 19:45:49 +02:00
|
|
|
prebuilt_etc "android/soong/etc"
|
2018-10-10 07:01:00 +02:00
|
|
|
"android/soong/java"
|
2019-02-27 23:19:50 +01:00
|
|
|
"android/soong/python"
|
2020-06-01 19:45:49 +02:00
|
|
|
"android/soong/sh"
|
2018-10-10 07:01:00 +02:00
|
|
|
)
|
|
|
|
|
|
2019-10-23 09:46:38 +02:00
|
|
|
const (
|
|
|
|
|
imageApexSuffix = ".apex"
|
|
|
|
|
zipApexSuffix = ".zipapex"
|
2019-10-22 06:58:29 +02:00
|
|
|
flattenedSuffix = ".flattened"
|
2019-10-23 09:46:38 +02:00
|
|
|
|
2019-10-22 06:58:29 +02:00
|
|
|
imageApexType = "image"
|
|
|
|
|
zipApexType = "zip"
|
|
|
|
|
flattenedApexType = "flattened"
|
2019-10-23 09:46:38 +02:00
|
|
|
)
|
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
|
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}
|
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}
|
2018-10-30 13:20:05 +01:00
|
|
|
keyTag = dependencyTag{name: "key"}
|
|
|
|
|
certificateTag = dependencyTag{name: "certificate"}
|
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}
|
2020-04-24 14:16:36 +02:00
|
|
|
rroTag = dependencyTag{name: "rro", payload: true}
|
2020-03-06 13:30:13 +01:00
|
|
|
|
2020-06-11 20:32:11 +02:00
|
|
|
apexAvailBaseline = makeApexAvailableBaseline()
|
|
|
|
|
|
|
|
|
|
inverseApexAvailBaseline = invertApexBaseline(apexAvailBaseline)
|
2018-10-10 07:01:00 +02:00
|
|
|
)
|
|
|
|
|
|
2020-03-06 13:30:13 +01:00
|
|
|
// Transform the map of apex -> modules to module -> apexes.
|
2020-06-11 20:32:11 +02:00
|
|
|
func invertApexBaseline(m map[string][]string) map[string][]string {
|
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
|
|
|
|
|
}
|
|
|
|
|
|
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)]
|
2020-03-06 13:30:13 +01:00
|
|
|
}
|
|
|
|
|
|
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
|
2020-06-11 20:32:11 +02:00
|
|
|
func makeApexAvailableBaseline() map[string][]string {
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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.conscrypt"] = []string{
|
|
|
|
|
"libnativehelper_header_only",
|
|
|
|
|
}
|
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.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",
|
|
|
|
|
}
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
|
|
|
|
"libc_scudo",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
|
|
|
|
"libnativehelper_header_only",
|
|
|
|
|
}
|
|
|
|
|
//
|
|
|
|
|
// 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",
|
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",
|
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",
|
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",
|
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",
|
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",
|
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{
|
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",
|
|
|
|
|
"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
|
|
|
"libcgrouprc",
|
|
|
|
|
"libcgrouprc_format",
|
2020-05-20 02:06:00 +02:00
|
|
|
"libnativehelper_compat_libc++",
|
apex_available tracks static dependencies
This change fixes a bug that apex_available is not enforced for static
dependencies. For example, a module with 'apex_available:
["//apex_available:platform"]' was able to be statically linked to any
APEX. This was happening because the check was done on the modules that
are actually installed to an APEX. Static dependencies of the modules
were not counted as they are not installed to the APEX as files.
Fixing this bug by doing the check by traversing the tree in the method
checkApexAvailability.
This change includes a few number of related changes:
1) DepIsInSameApex implementation for cc.Module was changed as well.
Previuosly, it returned false only when the dependency is actually a
stub variant of a lib. Now, it returns false when the dependency has one
or more stub variants. To understand why, we need to recall that when
there is a dependency to a lib having stubs, we actually create two
dependencies: to the non-stub variant and to the stub variant during the
DepsMutator phase. And later in the build action generation phase, we
choose one of them depending on the context. Also recall that an APEX
variant is created only when DepIsInSameApex returns true. Given these,
with the previous implementatin of DepIsInSameApex, we did create apex
variants of the non-stub variant of the dependency, while not creating
the apex variant for the stub variant. This is not right; we needlessly
created the apex variant. The extra apex variant has caused no harm so
far, but since the apex_available check became more correct, it actually
breaks the build. To fix the issue, we stop creating the APEX variant
both for non-stub and stub variants.
2) platform variant is created regardless of the apex_available value.
This is required for the case when a library X that provides stub is in
an APEX A and is configured to be available only for A. In that case,
libs in other APEX can't use the stub library since the stub library is
mutated only for apex A. By creating the platform variant for the stub
library, it can be used from outside as the default dependency variation
is set to the platform variant when creating the APEX variations.
3) The ApexAvailableWhitelist is added with the dependencies that were
revealed with this change.
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
|
|
|
"libtetherutilsjni",
|
|
|
|
|
"libvndksupport",
|
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",
|
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
|
|
|
}
|
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",
|
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",
|
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",
|
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
|
|
|
|
|
//
|
2020-03-06 13:30:13 +01:00
|
|
|
m[android.AvailableToAnyApex] = []string{
|
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",
|
|
|
|
|
}
|
2020-01-10 16:12:39 +01:00
|
|
|
return m
|
|
|
|
|
}
|
|
|
|
|
|
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)
|
2019-02-07 22:20:53 +01:00
|
|
|
android.RegisterModuleType("apex_test", testApexBundleFactory)
|
2019-08-23 04:17:39 +02:00
|
|
|
android.RegisterModuleType("apex_vndk", vndkApexBundleFactory)
|
2019-02-07 08:27:23 +01:00
|
|
|
android.RegisterModuleType("apex_defaults", defaultsFactory)
|
2019-03-26 23:07:36 +01:00
|
|
|
android.RegisterModuleType("prebuilt_apex", PrebuiltFactory)
|
2019-11-15 10:40:32 +01:00
|
|
|
android.RegisterModuleType("override_apex", overrideApexFactory)
|
2020-05-14 23:15:24 +02:00
|
|
|
android.RegisterModuleType("apex_set", apexSetFactory)
|
2018-10-10 07:01:00 +02:00
|
|
|
|
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)
|
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
|
|
|
}
|
|
|
|
|
|
2019-10-18 09:26:59 +02:00
|
|
|
func RegisterPreDepsMutators(ctx android.RegisterMutatorsContext) {
|
|
|
|
|
ctx.TopDown("apex_vndk", apexVndkMutator).Parallel()
|
|
|
|
|
ctx.BottomUp("apex_vndk_deps", apexVndkDepsMutator).Parallel()
|
|
|
|
|
}
|
|
|
|
|
|
Introduce module type 'sdk'
This change introduces a new module type named 'sdk'. It is a logical
group of prebuilt modules that together provide a context (e.g. APIs)
in which Mainline modules (such as APEXes) are built.
A prebuilt module (e.g. java_import) can join an sdk by adding it to the
sdk module as shown below:
sdk {
name: "mysdk#20",
java_libs: ["myjavalib_mysdk_20"],
}
java_import {
name: "myjavalib_mysdk_20",
srcs: ["myjavalib-v20.jar"],
sdk_member_name: "myjavalib",
}
sdk {
name: "mysdk#21",
java_libs: ["myjavalib_mysdk_21"],
}
java_import {
name: "myjavalib_mysdk_21",
srcs: ["myjavalib-v21.jar"],
sdk_member_name: "myjavalib",
}
java_library {
name: "myjavalib",
srcs: ["**/*/*.java"],
}
An APEX can specify the SDK(s) that it wants to build with via the new
'uses_sdks' property.
apex {
name: "myapex",
java_libs: ["libX", "libY"],
uses_sdks: ["mysdk#20"],
}
With this, libX, libY, and their transitive dependencies are all built
with the version 20 of myjavalib (the first java_import module) instead
of the other one (which is for version 21) and java_library having the
same name (which is for ToT).
Bug: 138182343
Test: m (sdk_test.go added)
Change-Id: I7e14c524a7d6a0d9f575fb20822080f39818c01e
2019-07-17 13:08:41 +02:00
|
|
|
func RegisterPostDepsMutators(ctx android.RegisterMutatorsContext) {
|
apexDepsMutator is a top-down mutator
apex { name: ["myapex"], native_shared_libs: ["libX", "libY"] }
cc_library { name: "libX", shared_libs: ["libY"] }
cc_library { name: "libY", shared_libs: ["libZ"], stubs: {...} }
apexDepsMutator was a bottom up mutator and it uses WalkDeps to traverse
the dependency tree rooted at myapex in a depth-first order. While
traversing the tree, if calls BuildForApex for a module that will be
part of the APEX.
libY is visited twice. Once via libX and once via myapex. If the visit
from libX was before the visit from myapex (since this is a depth-first
traversing), BuildForApex is not called for libY and its dependency
libZ, because libY provides a stub. And then when libY is again visited
via myapex, BuildForApex is correctly called for the module, but not for
its dependencies libZ because the paths from libY to libZ was already
visited.
As a result, the apex variant of libY has a dependency to the non-apex
variant of libZ.
Fixing the problem by changing the mutator a top-down one.
Bug: 148645937
Test: m
Change-Id: Ib2cb28852087c63a568b3fd036504e9261cf0782
2020-02-11 23:53:12 +01:00
|
|
|
ctx.TopDown("apex_deps", apexDepsMutator)
|
Introduce module type 'sdk'
This change introduces a new module type named 'sdk'. It is a logical
group of prebuilt modules that together provide a context (e.g. APIs)
in which Mainline modules (such as APEXes) are built.
A prebuilt module (e.g. java_import) can join an sdk by adding it to the
sdk module as shown below:
sdk {
name: "mysdk#20",
java_libs: ["myjavalib_mysdk_20"],
}
java_import {
name: "myjavalib_mysdk_20",
srcs: ["myjavalib-v20.jar"],
sdk_member_name: "myjavalib",
}
sdk {
name: "mysdk#21",
java_libs: ["myjavalib_mysdk_21"],
}
java_import {
name: "myjavalib_mysdk_21",
srcs: ["myjavalib-v21.jar"],
sdk_member_name: "myjavalib",
}
java_library {
name: "myjavalib",
srcs: ["**/*/*.java"],
}
An APEX can specify the SDK(s) that it wants to build with via the new
'uses_sdks' property.
apex {
name: "myapex",
java_libs: ["libX", "libY"],
uses_sdks: ["mysdk#20"],
}
With this, libX, libY, and their transitive dependencies are all built
with the version 20 of myjavalib (the first java_import module) instead
of the other one (which is for version 21) and java_library having the
same name (which is for ToT).
Bug: 138182343
Test: m (sdk_test.go added)
Change-Id: I7e14c524a7d6a0d9f575fb20822080f39818c01e
2019-07-17 13:08:41 +02:00
|
|
|
ctx.BottomUp("apex", apexMutator).Parallel()
|
|
|
|
|
ctx.BottomUp("apex_flattened", apexFlattenedMutator).Parallel()
|
|
|
|
|
ctx.BottomUp("apex_uses", apexUsesMutator).Parallel()
|
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()
|
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) {
|
2020-04-17 06:43:10 +02:00
|
|
|
if !mctx.Module().Enabled() {
|
|
|
|
|
return
|
|
|
|
|
}
|
2020-02-13 02:13:25 +01:00
|
|
|
var apexBundles []android.ApexInfo
|
apexDepsMutator is a top-down mutator
apex { name: ["myapex"], native_shared_libs: ["libX", "libY"] }
cc_library { name: "libX", shared_libs: ["libY"] }
cc_library { name: "libY", shared_libs: ["libZ"], stubs: {...} }
apexDepsMutator was a bottom up mutator and it uses WalkDeps to traverse
the dependency tree rooted at myapex in a depth-first order. While
traversing the tree, if calls BuildForApex for a module that will be
part of the APEX.
libY is visited twice. Once via libX and once via myapex. If the visit
from libX was before the visit from myapex (since this is a depth-first
traversing), BuildForApex is not called for libY and its dependency
libZ, because libY provides a stub. And then when libY is again visited
via myapex, BuildForApex is correctly called for the module, but not for
its dependencies libZ because the paths from libY to libZ was already
visited.
As a result, the apex variant of libY has a dependency to the non-apex
variant of libZ.
Fixing the problem by changing the mutator a top-down one.
Bug: 148645937
Test: m
Change-Id: Ib2cb28852087c63a568b3fd036504e9261cf0782
2020-02-11 23:53:12 +01:00
|
|
|
var directDep bool
|
2020-01-23 06:36:59 +01:00
|
|
|
if a, ok := mctx.Module().(*apexBundle); ok && !a.vndkApex {
|
2020-04-17 06:43:10 +02:00
|
|
|
apexBundles = []android.ApexInfo{{
|
2020-03-12 10:37:20 +01:00
|
|
|
ApexName: mctx.ModuleName(),
|
|
|
|
|
MinSdkVersion: a.minSdkVersion(mctx),
|
2020-04-28 15:57:42 +02:00
|
|
|
Updatable: a.Updatable(),
|
2020-03-09 22:23:13 +01:00
|
|
|
}}
|
apexDepsMutator is a top-down mutator
apex { name: ["myapex"], native_shared_libs: ["libX", "libY"] }
cc_library { name: "libX", shared_libs: ["libY"] }
cc_library { name: "libY", shared_libs: ["libZ"], stubs: {...} }
apexDepsMutator was a bottom up mutator and it uses WalkDeps to traverse
the dependency tree rooted at myapex in a depth-first order. While
traversing the tree, if calls BuildForApex for a module that will be
part of the APEX.
libY is visited twice. Once via libX and once via myapex. If the visit
from libX was before the visit from myapex (since this is a depth-first
traversing), BuildForApex is not called for libY and its dependency
libZ, because libY provides a stub. And then when libY is again visited
via myapex, BuildForApex is correctly called for the module, but not for
its dependencies libZ because the paths from libY to libZ was already
visited.
As a result, the apex variant of libY has a dependency to the non-apex
variant of libZ.
Fixing the problem by changing the mutator a top-down one.
Bug: 148645937
Test: m
Change-Id: Ib2cb28852087c63a568b3fd036504e9261cf0782
2020-02-11 23:53:12 +01:00
|
|
|
directDep = true
|
|
|
|
|
} else if am, ok := mctx.Module().(android.ApexModule); ok {
|
2020-02-13 02:13:25 +01:00
|
|
|
apexBundles = am.ApexVariations()
|
apexDepsMutator is a top-down mutator
apex { name: ["myapex"], native_shared_libs: ["libX", "libY"] }
cc_library { name: "libX", shared_libs: ["libY"] }
cc_library { name: "libY", shared_libs: ["libZ"], stubs: {...} }
apexDepsMutator was a bottom up mutator and it uses WalkDeps to traverse
the dependency tree rooted at myapex in a depth-first order. While
traversing the tree, if calls BuildForApex for a module that will be
part of the APEX.
libY is visited twice. Once via libX and once via myapex. If the visit
from libX was before the visit from myapex (since this is a depth-first
traversing), BuildForApex is not called for libY and its dependency
libZ, because libY provides a stub. And then when libY is again visited
via myapex, BuildForApex is correctly called for the module, but not for
its dependencies libZ because the paths from libY to libZ was already
visited.
As a result, the apex variant of libY has a dependency to the non-apex
variant of libZ.
Fixing the problem by changing the mutator a top-down one.
Bug: 148645937
Test: m
Change-Id: Ib2cb28852087c63a568b3fd036504e9261cf0782
2020-02-11 23:53:12 +01:00
|
|
|
directDep = false
|
|
|
|
|
}
|
Don't create unnecessary APEX variations
This change fixes a problem that APEX variations are created for the
modules that actually shouldn't built for any APEX. For example,
consider this case.
apex { name: "myapex", native_shared_libs: ["mylib"],}
cc_library { name: "mylib", shared_libs: ["libfoo#10"],}
cc_library { name: "libfoo",
shared_libs: ["libbar"],
stubs: { versions: ["10"], }, }
cc_library { name: "libbar", ...}
Before this change, both the stubs and non-stubs variations of libfoo
were mutated with apexMuator, which is incorrect for the non-stubs
varia; there is no dependency chain from the apex "myapex" to the
non-stubs variation, but to the stubs variation due to the #10 syntax.
This was happening becauses we used the name of the module to determine
whether it should be built for APEX or not. Both stubs and non-stubs
variations have the same module name "libfoo".
Fixing this issue by recording the list of APEX variations required
directly on the module. So, the stubs variation of libfoo has myapex in
its apex variations list, but the non-stubs variation doesn't, and thus
apexMutator does not pick up the non-stubs variation.
Test: m (apex_test updated and passing)
Test: cherry-pick ag/5747464 and m
Change-Id: I31e618626809a828a55fff513ef5f81f79637afa
2018-12-10 17:35:25 +01:00
|
|
|
|
2020-02-13 02:13:25 +01:00
|
|
|
if len(apexBundles) == 0 {
|
apexDepsMutator is a top-down mutator
apex { name: ["myapex"], native_shared_libs: ["libX", "libY"] }
cc_library { name: "libX", shared_libs: ["libY"] }
cc_library { name: "libY", shared_libs: ["libZ"], stubs: {...} }
apexDepsMutator was a bottom up mutator and it uses WalkDeps to traverse
the dependency tree rooted at myapex in a depth-first order. While
traversing the tree, if calls BuildForApex for a module that will be
part of the APEX.
libY is visited twice. Once via libX and once via myapex. If the visit
from libX was before the visit from myapex (since this is a depth-first
traversing), BuildForApex is not called for libY and its dependency
libZ, because libY provides a stub. And then when libY is again visited
via myapex, BuildForApex is correctly called for the module, but not for
its dependencies libZ because the paths from libY to libZ was already
visited.
As a result, the apex variant of libY has a dependency to the non-apex
variant of libZ.
Fixing the problem by changing the mutator a top-down one.
Bug: 148645937
Test: m
Change-Id: Ib2cb28852087c63a568b3fd036504e9261cf0782
2020-02-11 23:53:12 +01:00
|
|
|
return
|
2018-10-10 07:01:00 +02:00
|
|
|
}
|
apexDepsMutator is a top-down mutator
apex { name: ["myapex"], native_shared_libs: ["libX", "libY"] }
cc_library { name: "libX", shared_libs: ["libY"] }
cc_library { name: "libY", shared_libs: ["libZ"], stubs: {...} }
apexDepsMutator was a bottom up mutator and it uses WalkDeps to traverse
the dependency tree rooted at myapex in a depth-first order. While
traversing the tree, if calls BuildForApex for a module that will be
part of the APEX.
libY is visited twice. Once via libX and once via myapex. If the visit
from libX was before the visit from myapex (since this is a depth-first
traversing), BuildForApex is not called for libY and its dependency
libZ, because libY provides a stub. And then when libY is again visited
via myapex, BuildForApex is correctly called for the module, but not for
its dependencies libZ because the paths from libY to libZ was already
visited.
As a result, the apex variant of libY has a dependency to the non-apex
variant of libZ.
Fixing the problem by changing the mutator a top-down one.
Bug: 148645937
Test: m
Change-Id: Ib2cb28852087c63a568b3fd036504e9261cf0782
2020-02-11 23:53:12 +01:00
|
|
|
|
2020-03-30 16:33:32 +02:00
|
|
|
cur := mctx.Module().(android.DepIsInSameApex)
|
2020-03-09 22:23:13 +01:00
|
|
|
|
apexDepsMutator is a top-down mutator
apex { name: ["myapex"], native_shared_libs: ["libX", "libY"] }
cc_library { name: "libX", shared_libs: ["libY"] }
cc_library { name: "libY", shared_libs: ["libZ"], stubs: {...} }
apexDepsMutator was a bottom up mutator and it uses WalkDeps to traverse
the dependency tree rooted at myapex in a depth-first order. While
traversing the tree, if calls BuildForApex for a module that will be
part of the APEX.
libY is visited twice. Once via libX and once via myapex. If the visit
from libX was before the visit from myapex (since this is a depth-first
traversing), BuildForApex is not called for libY and its dependency
libZ, because libY provides a stub. And then when libY is again visited
via myapex, BuildForApex is correctly called for the module, but not for
its dependencies libZ because the paths from libY to libZ was already
visited.
As a result, the apex variant of libY has a dependency to the non-apex
variant of libZ.
Fixing the problem by changing the mutator a top-down one.
Bug: 148645937
Test: m
Change-Id: Ib2cb28852087c63a568b3fd036504e9261cf0782
2020-02-11 23:53:12 +01:00
|
|
|
mctx.VisitDirectDeps(func(child android.Module) {
|
|
|
|
|
depName := mctx.OtherModuleName(child)
|
|
|
|
|
if am, ok := child.(android.ApexModule); ok && am.CanHaveApexVariants() &&
|
2020-03-31 16:23:40 +02:00
|
|
|
(cur.DepIsInSameApex(mctx, child) || inAnySdk(child)) {
|
2020-02-13 02:13:25 +01:00
|
|
|
android.UpdateApexDependency(apexBundles, depName, directDep)
|
|
|
|
|
am.BuildForApexes(apexBundles)
|
apexDepsMutator is a top-down mutator
apex { name: ["myapex"], native_shared_libs: ["libX", "libY"] }
cc_library { name: "libX", shared_libs: ["libY"] }
cc_library { name: "libY", shared_libs: ["libZ"], stubs: {...} }
apexDepsMutator was a bottom up mutator and it uses WalkDeps to traverse
the dependency tree rooted at myapex in a depth-first order. While
traversing the tree, if calls BuildForApex for a module that will be
part of the APEX.
libY is visited twice. Once via libX and once via myapex. If the visit
from libX was before the visit from myapex (since this is a depth-first
traversing), BuildForApex is not called for libY and its dependency
libZ, because libY provides a stub. And then when libY is again visited
via myapex, BuildForApex is correctly called for the module, but not for
its dependencies libZ because the paths from libY to libZ was already
visited.
As a result, the apex variant of libY has a dependency to the non-apex
variant of libZ.
Fixing the problem by changing the mutator a top-down one.
Bug: 148645937
Test: m
Change-Id: Ib2cb28852087c63a568b3fd036504e9261cf0782
2020-02-11 23:53:12 +01:00
|
|
|
}
|
|
|
|
|
})
|
2018-10-10 07:01:00 +02:00
|
|
|
}
|
|
|
|
|
|
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()
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-10 07:01:00 +02:00
|
|
|
// Create apex variations if a module is included in APEX(s).
|
|
|
|
|
func apexMutator(mctx android.BottomUpMutatorContext) {
|
2020-04-17 06:43:10 +02:00
|
|
|
if !mctx.Module().Enabled() {
|
|
|
|
|
return
|
|
|
|
|
}
|
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)
|
2020-01-23 06:36:59 +01:00
|
|
|
} else if a, ok := mctx.Module().(*apexBundle); ok && !a.vndkApex {
|
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)
|
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)
|
2018-10-10 07:01:00 +02:00
|
|
|
}
|
2019-11-15 10:40:32 +01:00
|
|
|
|
2018-10-10 07:01:00 +02:00
|
|
|
}
|
2019-09-06 10:37:42 +02:00
|
|
|
|
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)
|
|
|
|
|
}
|
|
|
|
|
|
2019-11-19 18:26:02 +01:00
|
|
|
func addFlattenedFileContextsInfos(ctx android.BaseModuleContext, fileContextsInfo string) {
|
2019-10-08 14:59:58 +02:00
|
|
|
apexFileContextsInfosMutex.Lock()
|
|
|
|
|
defer apexFileContextsInfosMutex.Unlock()
|
|
|
|
|
apexFileContextsInfos := apexFileContextsInfos(ctx.Config())
|
2019-11-19 18:26:02 +01:00
|
|
|
*apexFileContextsInfos = append(*apexFileContextsInfos, fileContextsInfo)
|
2019-10-08 14:59:58 +02:00
|
|
|
}
|
|
|
|
|
|
2019-09-06 10:37:42 +02:00
|
|
|
func apexFlattenedMutator(mctx android.BottomUpMutatorContext) {
|
2020-04-17 06:43:10 +02:00
|
|
|
if !mctx.Module().Enabled() {
|
|
|
|
|
return
|
|
|
|
|
}
|
2019-09-17 06:50:45 +02:00
|
|
|
if ab, ok := mctx.Module().(*apexBundle); ok {
|
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:
|
2019-10-08 12:34:03 +02:00
|
|
|
mctx.PropertyErrorf("type", "%q is not one of \"image\", \"zip\", or \"both\".", *ab.properties.Payload_type)
|
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
|
2019-11-19 17:49:42 +01:00
|
|
|
if !mctx.Config().FlattenApex() && ab.Platform() {
|
2019-10-08 12:34:03 +02:00
|
|
|
modules[i].(*apexBundle).MakeAsSystemExt()
|
|
|
|
|
}
|
2019-10-22 06:58:29 +02:00
|
|
|
}
|
2019-09-06 10:37:42 +02:00
|
|
|
}
|
2019-11-15 10:40:32 +01:00
|
|
|
} else if _, ok := mctx.Module().(*OverrideApex); ok {
|
|
|
|
|
mctx.CreateVariations(imageApexType, flattenedApexType)
|
2019-09-06 10:37:42 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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...)
|
|
|
|
|
}
|
|
|
|
|
}
|
2018-10-10 07:01:00 +02:00
|
|
|
|
2019-10-31 19:14:38 +01:00
|
|
|
var (
|
2020-06-11 20:32:11 +02:00
|
|
|
useVendorAllowListKey = android.NewOnceKey("useVendorAllowList")
|
2019-10-31 19:14:38 +01:00
|
|
|
)
|
|
|
|
|
|
2020-06-11 20:32:11 +02:00
|
|
|
// useVendorAllowList returns the list of APEXes which are allowed to use_vendor.
|
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.
|
2020-06-11 20:32:11 +02:00
|
|
|
func useVendorAllowList(config android.Config) []string {
|
|
|
|
|
return config.Once(useVendorAllowListKey, func() interface{} {
|
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)
|
|
|
|
|
}
|
|
|
|
|
|
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
|
2019-10-31 19:14:38 +01:00
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-27 05:40:44 +01:00
|
|
|
type ApexNativeDependencies struct {
|
2019-01-30 03:07:33 +01:00
|
|
|
// List of native libraries
|
|
|
|
|
Native_shared_libs []string
|
2019-08-23 04:17:39 +02:00
|
|
|
|
2020-02-27 05:50:06 +01:00
|
|
|
// List of JNI libraries
|
|
|
|
|
Jni_libs []string
|
|
|
|
|
|
2019-01-30 03:07:33 +01:00
|
|
|
// List of native executables
|
|
|
|
|
Binaries []string
|
2019-08-23 04:17:39 +02:00
|
|
|
|
2019-06-26 13:48:34 +02:00
|
|
|
// List of native tests
|
|
|
|
|
Tests []string
|
2019-01-30 03:07:33 +01:00
|
|
|
}
|
2019-08-23 04:17:39 +02:00
|
|
|
|
2019-01-30 03:07:33 +01:00
|
|
|
type apexMultilibProperties struct {
|
|
|
|
|
// Native dependencies whose compile_multilib is "first"
|
2020-02-27 05:40:44 +01:00
|
|
|
First ApexNativeDependencies
|
2019-01-30 03:07:33 +01:00
|
|
|
|
|
|
|
|
// Native dependencies whose compile_multilib is "both"
|
2020-02-27 05:40:44 +01:00
|
|
|
Both ApexNativeDependencies
|
2019-01-30 03:07:33 +01:00
|
|
|
|
|
|
|
|
// Native dependencies whose compile_multilib is "prefer32"
|
2020-02-27 05:40:44 +01:00
|
|
|
Prefer32 ApexNativeDependencies
|
2019-01-30 03:07:33 +01:00
|
|
|
|
|
|
|
|
// Native dependencies whose compile_multilib is "32"
|
2020-02-27 05:40:44 +01:00
|
|
|
Lib32 ApexNativeDependencies
|
2019-01-30 03:07:33 +01:00
|
|
|
|
|
|
|
|
// Native dependencies whose compile_multilib is "64"
|
2020-02-27 05:40:44 +01:00
|
|
|
Lib64 ApexNativeDependencies
|
2019-01-30 03:07:33 +01:00
|
|
|
}
|
|
|
|
|
|
2018-10-10 07:01:00 +02:00
|
|
|
type apexBundleProperties struct {
|
|
|
|
|
// Json manifest file describing meta info of this APEX bundle. Default:
|
2018-11-20 19:04:58 +01:00
|
|
|
// "apex_manifest.json"
|
2019-03-05 07:35:41 +01:00
|
|
|
Manifest *string `android:"path"`
|
2018-10-10 07:01:00 +02:00
|
|
|
|
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.
|
2019-03-05 07:35:41 +01:00
|
|
|
AndroidManifest *string `android:"path"`
|
2019-02-07 18:53:06 +01:00
|
|
|
|
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.
|
2019-03-18 06:26:32 +01:00
|
|
|
Apex_name *string
|
|
|
|
|
|
2018-11-09 22:37:15 +01:00
|
|
|
// Determines the file contexts file for setting security context to each file in this APEX bundle.
|
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"`
|
2018-10-10 07:01:00 +02:00
|
|
|
|
2020-02-27 05:40:44 +01:00
|
|
|
ApexNativeDependencies
|
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
|
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
|
|
|
|
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
|
|
|
|
|
|
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
|
|
|
|
|
|
2018-12-13 15:14:57 +01:00
|
|
|
// Whether this APEX is installable to one of the partitions. Default: true.
|
|
|
|
|
Installable *bool
|
|
|
|
|
|
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
|
|
|
|
|
|
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
|
|
|
|
|
|
2019-01-30 03:07:33 +01:00
|
|
|
Multilib apexMultilibProperties
|
2019-02-09 03:50:56 +01:00
|
|
|
|
2019-02-13 12:28:58 +01:00
|
|
|
// List of sanitizer names that this APEX is enabled for
|
|
|
|
|
SanitizerNames []string `blueprint:"mutated"`
|
2019-06-27 04:30:33 +02:00
|
|
|
|
2019-08-09 07:44:36 +02:00
|
|
|
PreventInstall bool `blueprint:"mutated"`
|
|
|
|
|
|
|
|
|
|
HideFromMake bool `blueprint:"mutated"`
|
|
|
|
|
|
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
|
2019-08-31 15:38:05 +02:00
|
|
|
|
2020-06-11 20:32:11 +02:00
|
|
|
// A txt file containing list of files that are allowed to be included in this APEX.
|
2019-08-31 15:38:05 +02:00
|
|
|
Whitelisted_files *string
|
2019-08-27 06:55:42 +02:00
|
|
|
|
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"`
|
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
|
2019-11-15 10:40:32 +01:00
|
|
|
|
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
|
2019-11-12 05:03:50 +01:00
|
|
|
|
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
|
|
|
|
|
|
2020-01-09 04:32:06 +01:00
|
|
|
IsCoverageVariant bool `blueprint:"mutated"`
|
2020-02-19 08:29:35 +01:00
|
|
|
|
|
|
|
|
// Whether this APEX is considered updatable or not. When set to true, this will enforce additional
|
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.
|
2020-02-19 08:29:35 +01:00
|
|
|
Updatable *bool
|
2020-02-20 05:41:10 +01:00
|
|
|
|
|
|
|
|
// The minimum SDK version that this apex must be compatibile with.
|
|
|
|
|
Min_sdk_version *string
|
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
|
|
|
}
|
2019-08-23 04:17:39 +02:00
|
|
|
|
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
|
|
|
}
|
2019-08-23 04:17:39 +02:00
|
|
|
|
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
|
|
|
}
|
2019-08-23 04:17:39 +02:00
|
|
|
|
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
|
|
|
}
|
|
|
|
|
}
|
2018-10-10 07:01:00 +02:00
|
|
|
}
|
|
|
|
|
|
2019-11-15 10:40:32 +01:00
|
|
|
type overridableProperties struct {
|
|
|
|
|
// List of APKs to package inside APEX
|
|
|
|
|
Apps []string
|
2019-12-20 02:32:06 +01:00
|
|
|
|
2020-04-24 14:16:36 +02:00
|
|
|
// List of runtime resource overlays (RROs) inside APEX
|
|
|
|
|
Rros []string
|
|
|
|
|
|
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
|
2020-02-20 06:29:28 +01:00
|
|
|
|
|
|
|
|
// Logging Parent value
|
|
|
|
|
Logging_parent string
|
2020-03-15 21:01:05 +01:00
|
|
|
|
|
|
|
|
// Apex Container Package Name.
|
|
|
|
|
// Override value for attribute package:name in AndroidManifest.xml
|
|
|
|
|
Package_name string
|
2019-11-15 10:40:32 +01:00
|
|
|
}
|
|
|
|
|
|
2018-11-30 02:12:15 +01:00
|
|
|
type apexPackaging int
|
|
|
|
|
|
|
|
|
|
const (
|
|
|
|
|
imageApex apexPackaging = iota
|
|
|
|
|
zipApex
|
2019-10-22 06:58:29 +02:00
|
|
|
flattenedApex
|
2018-11-30 02:12:15 +01:00
|
|
|
)
|
|
|
|
|
|
2019-10-22 06:58:29 +02:00
|
|
|
// The suffix for the output "file", not the module
|
2018-11-30 02:12:15 +01:00
|
|
|
func (a apexPackaging) suffix() string {
|
|
|
|
|
switch a {
|
|
|
|
|
case imageApex:
|
|
|
|
|
return imageApexSuffix
|
|
|
|
|
case zipApex:
|
|
|
|
|
return zipApexSuffix
|
|
|
|
|
default:
|
2019-07-31 15:09:17 +02:00
|
|
|
panic(fmt.Errorf("unknown APEX type %d", a))
|
2018-11-30 02:12:15 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (a apexPackaging) name() string {
|
|
|
|
|
switch a {
|
|
|
|
|
case imageApex:
|
|
|
|
|
return imageApexType
|
|
|
|
|
case zipApex:
|
|
|
|
|
return zipApexType
|
|
|
|
|
default:
|
2019-07-31 15:09:17 +02:00
|
|
|
panic(fmt.Errorf("unknown APEX type %d", a))
|
2018-11-30 02:12:15 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-11-18 07:39:01 +01:00
|
|
|
type apexFileClass int
|
|
|
|
|
|
|
|
|
|
const (
|
|
|
|
|
etc apexFileClass = iota
|
|
|
|
|
nativeSharedLib
|
|
|
|
|
nativeExecutable
|
|
|
|
|
shBinary
|
|
|
|
|
pyBinary
|
|
|
|
|
goBinary
|
|
|
|
|
javaSharedLib
|
|
|
|
|
nativeTest
|
|
|
|
|
app
|
2020-05-28 01:36:07 +02:00
|
|
|
appSet
|
2019-11-18 07:39:01 +01:00
|
|
|
)
|
|
|
|
|
|
2018-11-07 18:50:25 +01:00
|
|
|
func (class apexFileClass) NameInMake() string {
|
|
|
|
|
switch class {
|
|
|
|
|
case etc:
|
|
|
|
|
return "ETC"
|
|
|
|
|
case nativeSharedLib:
|
|
|
|
|
return "SHARED_LIBRARIES"
|
2019-02-27 23:19:50 +01:00
|
|
|
case nativeExecutable, shBinary, pyBinary, goBinary:
|
2018-11-07 18:50:25 +01:00
|
|
|
return "EXECUTABLES"
|
|
|
|
|
case javaSharedLib:
|
|
|
|
|
return "JAVA_LIBRARIES"
|
2019-06-26 13:48:34 +02:00
|
|
|
case nativeTest:
|
|
|
|
|
return "NATIVE_TESTS"
|
2020-05-28 01:36:07 +02:00
|
|
|
case app, appSet:
|
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"
|
2018-11-07 18:50:25 +01:00
|
|
|
default:
|
2019-07-31 15:09:17 +02:00
|
|
|
panic(fmt.Errorf("unknown class %d", class))
|
2018-11-07 18:50:25 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-11-18 07:39:01 +01:00
|
|
|
// apexFile represents a file in an APEX bundle
|
2018-11-07 18:50:25 +01:00
|
|
|
type apexFile struct {
|
|
|
|
|
builtFile android.Path
|
2020-05-28 16:46:55 +02:00
|
|
|
stem string
|
2018-11-07 18:50:25 +01:00
|
|
|
moduleName string
|
|
|
|
|
installDir string
|
|
|
|
|
class apexFileClass
|
2018-12-19 09:36:39 +01:00
|
|
|
module android.Module
|
2019-11-18 07:39:01 +01:00
|
|
|
// list of symlinks that will be created in installDir that point to this apexFile
|
|
|
|
|
symlinks []string
|
2020-05-13 00:26:55 +02:00
|
|
|
dataPaths android.Paths
|
2019-11-18 07:39:01 +01:00
|
|
|
transitiveDep bool
|
2019-12-13 05:28:36 +01:00
|
|
|
moduleDir string
|
2019-12-30 08:56:33 +01:00
|
|
|
|
|
|
|
|
requiredModuleNames []string
|
|
|
|
|
targetRequiredModuleNames []string
|
|
|
|
|
hostRequiredModuleNames []string
|
2020-01-08 05:35:43 +01:00
|
|
|
|
2020-01-28 23:00:53 +01:00
|
|
|
jacocoReportClassesFile android.Path // only for javalibs and apps
|
|
|
|
|
certificate java.Certificate // only for apps
|
2020-02-28 08:51:07 +01:00
|
|
|
overriddenPackageName string // only for apps
|
2020-02-27 05:50:06 +01:00
|
|
|
|
|
|
|
|
isJniLib bool
|
2019-11-18 07:39:01 +01:00
|
|
|
}
|
|
|
|
|
|
2019-12-13 05:28:36 +01:00
|
|
|
func newApexFile(ctx android.BaseModuleContext, builtFile android.Path, moduleName string, installDir string, class apexFileClass, module android.Module) apexFile {
|
|
|
|
|
ret := apexFile{
|
2019-11-18 07:39:01 +01:00
|
|
|
builtFile: builtFile,
|
|
|
|
|
moduleName: moduleName,
|
|
|
|
|
installDir: installDir,
|
|
|
|
|
class: class,
|
|
|
|
|
module: module,
|
|
|
|
|
}
|
2019-12-13 05:28:36 +01:00
|
|
|
if module != nil {
|
|
|
|
|
ret.moduleDir = ctx.OtherModuleDir(module)
|
2019-12-30 08:56:33 +01:00
|
|
|
ret.requiredModuleNames = module.RequiredModuleNames()
|
|
|
|
|
ret.targetRequiredModuleNames = module.TargetRequiredModuleNames()
|
|
|
|
|
ret.hostRequiredModuleNames = module.HostRequiredModuleNames()
|
2019-12-13 05:28:36 +01:00
|
|
|
}
|
|
|
|
|
return ret
|
2019-11-18 07:39:01 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (af *apexFile) Ok() bool {
|
2019-12-16 03:47:12 +01:00
|
|
|
return af.builtFile != nil && af.builtFile.String() != ""
|
2018-11-07 18:50:25 +01:00
|
|
|
}
|
|
|
|
|
|
2020-05-13 00:26:55 +02:00
|
|
|
func (af *apexFile) apexRelativePath(path string) string {
|
|
|
|
|
return filepath.Join(af.installDir, path)
|
|
|
|
|
}
|
|
|
|
|
|
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 {
|
2020-05-29 14:29:20 +02:00
|
|
|
return af.apexRelativePath(af.Stem())
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (af *apexFile) Stem() string {
|
2020-05-28 16:46:55 +02:00
|
|
|
if af.stem != "" {
|
2020-05-29 14:29:20 +02:00
|
|
|
return af.stem
|
2020-05-28 16:46:55 +02:00
|
|
|
}
|
2020-05-29 14:29:20 +02:00
|
|
|
return af.builtFile.Base()
|
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 {
|
2020-05-13 00:26:55 +02:00
|
|
|
ret = append(ret, af.apexRelativePath(symlink))
|
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
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-10 07:01:00 +02:00
|
|
|
type apexBundle struct {
|
|
|
|
|
android.ModuleBase
|
|
|
|
|
android.DefaultableModuleBase
|
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
|
2018-10-10 07:01:00 +02:00
|
|
|
|
2019-11-15 10:40:32 +01:00
|
|
|
properties apexBundleProperties
|
|
|
|
|
targetProperties apexTargetBundleProperties
|
|
|
|
|
overridableProperties overridableProperties
|
2018-10-10 07:01:00 +02:00
|
|
|
|
2019-12-16 14:32:06 +01:00
|
|
|
// specific to apex_vndk modules
|
|
|
|
|
vndkProperties apexVndkProperties
|
|
|
|
|
|
2018-11-16 20:36:28 +01:00
|
|
|
bundleModuleFile android.WritablePath
|
2019-10-22 06:58:29 +02:00
|
|
|
outputFile android.WritablePath
|
2019-10-02 07:05:35 +02:00
|
|
|
installDir android.InstallPath
|
2018-11-07 18:50:25 +01:00
|
|
|
|
2019-07-26 16:20:40 +02:00
|
|
|
prebuiltFileToDelete string
|
|
|
|
|
|
2019-04-01 04:15:50 +02:00
|
|
|
public_key_file android.Path
|
|
|
|
|
private_key_file android.Path
|
2019-02-18 07:25:04 +01:00
|
|
|
|
|
|
|
|
container_certificate_file android.Path
|
|
|
|
|
container_private_key_file android.Path
|
|
|
|
|
|
2019-11-19 18:26:02 +01:00
|
|
|
fileContexts android.Path
|
|
|
|
|
|
2018-11-07 18:50:25 +01:00
|
|
|
// list of files to be included in this apex
|
|
|
|
|
filesInfo []apexFile
|
|
|
|
|
|
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)
|
2020-04-27 18:08:37 +02:00
|
|
|
android.ApexBundleDepsInfo
|
2019-02-20 13:49:26 +01:00
|
|
|
|
2019-10-22 06:58:29 +02:00
|
|
|
testApex bool
|
|
|
|
|
vndkApex bool
|
2019-11-08 11:51:01 +01:00
|
|
|
artApex bool
|
2019-10-22 06:58:29 +02:00
|
|
|
primaryApexType bool
|
2019-08-01 10:41:43 +02:00
|
|
|
|
2019-11-12 05:03:50 +01:00
|
|
|
manifestJsonOut android.WritablePath
|
|
|
|
|
manifestPbOut android.WritablePath
|
2019-10-23 09:46:38 +02:00
|
|
|
|
2020-01-07 17:57:58 +01:00
|
|
|
// list of commands to create symlinks for backward compatibility.
|
2019-10-23 09:46:38 +02:00
|
|
|
// these commands will be attached as LOCAL_POST_INSTALL_CMD to
|
2020-01-07 17:57:58 +01:00
|
|
|
// apex package itself(for unflattened build) or apex_manifest(for flattened build)
|
2019-10-23 09:46:38 +02:00
|
|
|
// so that compat symlinks are always installed regardless of TARGET_FLATTEN_APEX setting.
|
|
|
|
|
compatSymlinks []string
|
2019-10-22 06:58:29 +02:00
|
|
|
|
|
|
|
|
// Suffix of module name in Android.mk
|
|
|
|
|
// ".flattened", ".apex", ".zipapex", or ""
|
|
|
|
|
suffix string
|
2020-01-14 06:39:19 +01:00
|
|
|
|
|
|
|
|
installedFilesFile android.WritablePath
|
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
|
2020-01-28 12:05:29 +01:00
|
|
|
|
|
|
|
|
// Struct holding the merged notice file paths in different formats
|
|
|
|
|
mergedNotices android.NoticeOutputs
|
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,
|
2020-02-27 05:40:44 +01:00
|
|
|
nativeModules ApexNativeDependencies,
|
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.
|
2019-10-16 20:03:10 +02:00
|
|
|
ctx.AddFarVariationDependencies(append(target.Variations(), []blueprint.Variation{
|
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"},
|
2018-12-07 14:42:47 +01:00
|
|
|
{Mutator: "version", Variation: ""}, // "" is the non-stub variant
|
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
|
|
|
|
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...)
|
|
|
|
|
|
2019-10-16 20:03:10 +02:00
|
|
|
ctx.AddFarVariationDependencies(append(target.Variations(),
|
|
|
|
|
blueprint.Variation{Mutator: "image", Variation: imageVariation}),
|
2020-02-27 05:40:44 +01:00
|
|
|
executableTag, nativeModules.Binaries...)
|
2019-06-26 13:48:34 +02:00
|
|
|
|
2019-10-16 20:03:10 +02:00
|
|
|
ctx.AddFarVariationDependencies(append(target.Variations(), []blueprint.Variation{
|
2019-06-26 13:48:34 +02:00
|
|
|
{Mutator: "image", Variation: imageVariation},
|
2019-06-28 16:41:19 +02:00
|
|
|
{Mutator: "test_per_src", Variation: ""}, // "" is the all-tests variant
|
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
|
|
|
}
|
|
|
|
|
|
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)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-10 07:01:00 +02:00
|
|
|
func (a *apexBundle) DepsMutator(ctx android.BottomUpMutatorContext) {
|
2020-06-11 20:32:11 +02:00
|
|
|
if proptools.Bool(a.properties.Use_vendor) && !android.InList(a.Name(), useVendorAllowList(ctx.Config())) {
|
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()
|
2019-01-05 03:15:24 +01:00
|
|
|
config := ctx.DeviceConfig()
|
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 {
|
2020-02-27 05:50:06 +01:00
|
|
|
// When multilib.* is omitted for native_shared_libs/jni_libs/tests, it implies
|
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,
|
2020-02-27 05:50:06 +01:00
|
|
|
Jni_libs: a.properties.Jni_libs,
|
2020-02-27 05:40:44 +01:00
|
|
|
Binaries: nil,
|
|
|
|
|
},
|
|
|
|
|
target, a.getImageVariation(config))
|
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,
|
2020-02-27 05:40:44 +01:00
|
|
|
a.properties.Multilib.Both,
|
2019-10-16 20:03:10 +02:00
|
|
|
target,
|
2019-01-05 03:15:24 +01:00
|
|
|
a.getImageVariation(config))
|
binaries and native_shared_libraires are multilib-aware props
The properties 'binaries' and 'native_shared_libraries' can be
multilib-aware, i.e, can be under multilib.type where type can be either
first, both, lib32, lib64, or prefer32.
Native modules listed in multilib.first are installed only for the first
ABI of the device. Similarily, multilib.both are for both of the ABIs,
while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only,
respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is
available.
Another change is that the binaries property, when not within multilib,
targets only the first ABI.
Test: m apex.test on ...
1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true
2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true
3) aosp_arm
in all cases, vold, surfaceflinger and drmserver are all intalled under
./bin directory of the APEX. And native libraries are installed under
both ./lib and ./lib64 directories in the case of 1) and 2).
Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
|
|
|
|
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
|
2020-02-27 05:40:44 +01:00
|
|
|
// multilib.first
|
|
|
|
|
addDependenciesForNativeModules(ctx,
|
|
|
|
|
ApexNativeDependencies{
|
|
|
|
|
Native_shared_libs: nil,
|
|
|
|
|
Tests: nil,
|
2020-02-27 05:50:06 +01:00
|
|
|
Jni_libs: nil,
|
2020-02-27 05:40:44 +01:00
|
|
|
Binaries: a.properties.Binaries,
|
|
|
|
|
},
|
|
|
|
|
target, a.getImageVariation(config))
|
binaries and native_shared_libraires are multilib-aware props
The properties 'binaries' and 'native_shared_libraries' can be
multilib-aware, i.e, can be under multilib.type where type can be either
first, both, lib32, lib64, or prefer32.
Native modules listed in multilib.first are installed only for the first
ABI of the device. Similarily, multilib.both are for both of the ABIs,
while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only,
respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is
available.
Another change is that the binaries property, when not within multilib,
targets only the first ABI.
Test: m apex.test on ...
1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true
2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true
3) aosp_arm
in all cases, vold, surfaceflinger and drmserver are all intalled under
./bin directory of the APEX. And native libraries are installed under
both ./lib and ./lib64 directories in the case of 1) and 2).
Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
|
|
|
|
|
|
|
|
// Add native modules targetting the first ABI
|
|
|
|
|
addDependenciesForNativeModules(ctx,
|
2020-02-27 05:40:44 +01:00
|
|
|
a.properties.Multilib.First,
|
2019-10-16 20:03:10 +02:00
|
|
|
target,
|
2019-01-05 03:15:24 +01:00
|
|
|
a.getImageVariation(config))
|
binaries and native_shared_libraires are multilib-aware props
The properties 'binaries' and 'native_shared_libraries' can be
multilib-aware, i.e, can be under multilib.type where type can be either
first, both, lib32, lib64, or prefer32.
Native modules listed in multilib.first are installed only for the first
ABI of the device. Similarily, multilib.both are for both of the ABIs,
while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only,
respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is
available.
Another change is that the binaries property, when not within multilib,
targets only the first ABI.
Test: m apex.test on ...
1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true
2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true
3) aosp_arm
in all cases, vold, surfaceflinger and drmserver are all intalled under
./bin directory of the APEX. And native libraries are installed under
both ./lib and ./lib64 directories in the case of 1) and 2).
Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
switch target.Arch.ArchType.Multilib {
|
|
|
|
|
case "lib32":
|
|
|
|
|
// Add native modules targetting 32-bit ABI
|
|
|
|
|
addDependenciesForNativeModules(ctx,
|
2020-02-27 05:40:44 +01:00
|
|
|
a.properties.Multilib.Lib32,
|
2019-10-16 20:03:10 +02:00
|
|
|
target,
|
2019-01-05 03:15:24 +01:00
|
|
|
a.getImageVariation(config))
|
binaries and native_shared_libraires are multilib-aware props
The properties 'binaries' and 'native_shared_libraries' can be
multilib-aware, i.e, can be under multilib.type where type can be either
first, both, lib32, lib64, or prefer32.
Native modules listed in multilib.first are installed only for the first
ABI of the device. Similarily, multilib.both are for both of the ABIs,
while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only,
respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is
available.
Another change is that the binaries property, when not within multilib,
targets only the first ABI.
Test: m apex.test on ...
1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true
2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true
3) aosp_arm
in all cases, vold, surfaceflinger and drmserver are all intalled under
./bin directory of the APEX. And native libraries are installed under
both ./lib and ./lib64 directories in the case of 1) and 2).
Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
|
|
|
|
|
|
|
|
addDependenciesForNativeModules(ctx,
|
2020-02-27 05:40:44 +01:00
|
|
|
a.properties.Multilib.Prefer32,
|
2019-10-16 20:03:10 +02:00
|
|
|
target,
|
2019-01-05 03:15:24 +01:00
|
|
|
a.getImageVariation(config))
|
binaries and native_shared_libraires are multilib-aware props
The properties 'binaries' and 'native_shared_libraries' can be
multilib-aware, i.e, can be under multilib.type where type can be either
first, both, lib32, lib64, or prefer32.
Native modules listed in multilib.first are installed only for the first
ABI of the device. Similarily, multilib.both are for both of the ABIs,
while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only,
respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is
available.
Another change is that the binaries property, when not within multilib,
targets only the first ABI.
Test: m apex.test on ...
1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true
2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true
3) aosp_arm
in all cases, vold, surfaceflinger and drmserver are all intalled under
./bin directory of the APEX. And native libraries are installed under
both ./lib and ./lib64 directories in the case of 1) and 2).
Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
|
|
|
case "lib64":
|
|
|
|
|
// Add native modules targetting 64-bit ABI
|
|
|
|
|
addDependenciesForNativeModules(ctx,
|
2020-02-27 05:40:44 +01:00
|
|
|
a.properties.Multilib.Lib64,
|
2019-10-16 20:03:10 +02:00
|
|
|
target,
|
2019-01-05 03:15:24 +01:00
|
|
|
a.getImageVariation(config))
|
binaries and native_shared_libraires are multilib-aware props
The properties 'binaries' and 'native_shared_libraries' can be
multilib-aware, i.e, can be under multilib.type where type can be either
first, both, lib32, lib64, or prefer32.
Native modules listed in multilib.first are installed only for the first
ABI of the device. Similarily, multilib.both are for both of the ABIs,
while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only,
respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is
available.
Another change is that the binaries property, when not within multilib,
targets only the first ABI.
Test: m apex.test on ...
1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true
2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true
3) aosp_arm
in all cases, vold, surfaceflinger and drmserver are all intalled under
./bin directory of the APEX. And native libraries are installed under
both ./lib and ./lib64 directories in the case of 1) and 2).
Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
|
|
|
|
|
|
|
|
if !has32BitTarget {
|
|
|
|
|
addDependenciesForNativeModules(ctx,
|
2020-02-27 05:40:44 +01:00
|
|
|
a.properties.Multilib.Prefer32,
|
2019-10-16 20:03:10 +02:00
|
|
|
target,
|
2019-01-05 03:15:24 +01:00
|
|
|
a.getImageVariation(config))
|
binaries and native_shared_libraires are multilib-aware props
The properties 'binaries' and 'native_shared_libraries' can be
multilib-aware, i.e, can be under multilib.type where type can be either
first, both, lib32, lib64, or prefer32.
Native modules listed in multilib.first are installed only for the first
ABI of the device. Similarily, multilib.both are for both of the ABIs,
while multilib.lib32 and multilib.lib64 are 32 and 64-bit ABI only,
respectively. multilib.prefer32 is for 32-bit only when 32-bit ABI is
available.
Another change is that the binaries property, when not within multilib,
targets only the first ABI.
Test: m apex.test on ...
1) aosp_arm64 without TARGET_PREFER_32_BIT_EXECUTABLES=true
2) aosp_arm64 with TARGET_PREFER_32_BIT_EXECUTABLES=true
3) aosp_arm
in all cases, vold, surfaceflinger and drmserver are all intalled under
./bin directory of the APEX. And native libraries are installed under
both ./lib and ./lib64 directories in the case of 1) and 2).
Change-Id: Idd7f8526a61bceca89d43c0c69ccedb471b67d31
2018-10-24 14:09:55 +02:00
|
|
|
}
|
|
|
|
|
}
|
2018-10-12 14:49:38 +02:00
|
|
|
}
|
2018-10-10 07:01:00 +02:00
|
|
|
|
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...)
|
|
|
|
|
|
2019-10-16 20:03:10 +02:00
|
|
|
ctx.AddFarVariationDependencies(ctx.Config().AndroidCommonTarget.Variations(),
|
|
|
|
|
javaLibTag, a.properties.Java_libs...)
|
2018-10-10 07:01:00 +02:00
|
|
|
|
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")
|
|
|
|
|
}
|
|
|
|
|
|
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))
|
2018-10-30 13:20:05 +01:00
|
|
|
|
2019-02-11 03:38:15 +01:00
|
|
|
cert := android.SrcIsModule(a.getCertString(ctx))
|
2019-02-02 05:13:47 +01:00
|
|
|
if cert != "" {
|
|
|
|
|
ctx.AddDependency(ctx.Module(), certificateTag, cert)
|
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)
|
|
|
|
|
}
|
2018-10-10 07:01:00 +02:00
|
|
|
}
|
|
|
|
|
|
2019-11-15 10:40:32 +01:00
|
|
|
func (a *apexBundle) OverridablePropertiesDepsMutator(ctx android.BottomUpMutatorContext) {
|
|
|
|
|
ctx.AddFarVariationDependencies(ctx.Config().AndroidCommonTarget.Variations(),
|
|
|
|
|
androidAppTag, a.overridableProperties.Apps...)
|
2020-04-24 14:16:36 +02:00
|
|
|
ctx.AddFarVariationDependencies(ctx.Config().AndroidCommonTarget.Variations(),
|
|
|
|
|
rroTag, a.overridableProperties.Rros...)
|
2019-11-15 10:40:32 +01:00
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
|
}
|
|
|
|
|
|
2019-06-06 23:33:29 +02:00
|
|
|
func (a *apexBundle) getCertString(ctx android.BaseModuleContext) string {
|
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)
|
2019-02-11 03:38:15 +01:00
|
|
|
if overridden {
|
2019-02-28 17:22:30 +01:00
|
|
|
return ":" + certificate
|
2019-02-11 03:38:15 +01:00
|
|
|
}
|
|
|
|
|
return String(a.properties.Certificate)
|
|
|
|
|
}
|
|
|
|
|
|
2019-05-29 23:40:35 +02:00
|
|
|
func (a *apexBundle) OutputFiles(tag string) (android.Paths, error) {
|
|
|
|
|
switch tag {
|
|
|
|
|
case "":
|
2019-10-22 06:58:29 +02:00
|
|
|
return android.Paths{a.outputFile}, nil
|
2019-05-29 23:40:35 +02:00
|
|
|
default:
|
|
|
|
|
return nil, fmt.Errorf("unsupported module reference tag %q", tag)
|
2018-12-20 01:54:35 +01:00
|
|
|
}
|
2018-11-27 13:27:08 +01:00
|
|
|
}
|
|
|
|
|
|
2018-12-13 15:14:57 +01:00
|
|
|
func (a *apexBundle) installable() bool {
|
2019-08-09 07:44:36 +02:00
|
|
|
return !a.properties.PreventInstall && (a.properties.Installable == nil || proptools.Bool(a.properties.Installable))
|
2018-12-13 15:14:57 +01:00
|
|
|
}
|
|
|
|
|
|
2019-12-07 18:30:22 +01:00
|
|
|
func (a *apexBundle) testOnlyShouldSkipHashtreeGeneration() bool {
|
|
|
|
|
return proptools.Bool(a.properties.Test_only_no_hashtree)
|
|
|
|
|
}
|
|
|
|
|
|
2020-04-27 19:21:11 +02:00
|
|
|
func (a *apexBundle) testOnlyShouldSkipPayloadSign() bool {
|
|
|
|
|
return proptools.Bool(a.properties.Test_only_unsigned_payload)
|
|
|
|
|
}
|
|
|
|
|
|
2019-01-05 03:15:24 +01:00
|
|
|
func (a *apexBundle) getImageVariation(config android.DeviceConfig) string {
|
2019-10-18 09:26:59 +02:00
|
|
|
if a.vndkApex {
|
2019-11-19 01:00:16 +01:00
|
|
|
return cc.VendorVariationPrefix + a.vndkVersion(config)
|
2019-10-18 09:26:59 +02:00
|
|
|
}
|
2019-01-05 03:15:24 +01:00
|
|
|
if config.VndkVersion() != "" && proptools.Bool(a.properties.Use_vendor) {
|
2019-11-19 01:00:16 +01:00
|
|
|
return cc.VendorVariationPrefix + config.PlatformVndkVersion()
|
2018-12-19 09:12:36 +01:00
|
|
|
} else {
|
2019-11-19 01:00:16 +01:00
|
|
|
return android.CoreVariation
|
2018-12-19 09:12:36 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-01-28 11:47:32 +01:00
|
|
|
func (a *apexBundle) IsSanitizerEnabled(ctx android.BaseModuleContext, sanitizerName string) bool {
|
2019-02-13 12:28:58 +01:00
|
|
|
if android.InList(sanitizerName, a.properties.SanitizerNames) {
|
|
|
|
|
return true
|
2019-02-09 03:50:56 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Then follow the global setting
|
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)
|
2018-12-18 18:47:14 +01:00
|
|
|
}
|
|
|
|
|
|
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{
|
|
|
|
|
{Mutator: "image", Variation: a.getImageVariation(ctx.DeviceConfig())},
|
|
|
|
|
{Mutator: "link", Variation: "shared"},
|
|
|
|
|
{Mutator: "version", Variation: ""}, // "" is the non-stub variant
|
|
|
|
|
}...), sharedLibTag, "libclang_rt.hwasan-aarch64-android")
|
|
|
|
|
break
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-04-09 15:56:02 +02:00
|
|
|
var _ cc.Coverage = (*apexBundle)(nil)
|
|
|
|
|
|
2019-08-09 07:44:36 +02:00
|
|
|
func (a *apexBundle) IsNativeCoverageNeeded(ctx android.BaseModuleContext) bool {
|
2019-12-07 00:22:41 +01:00
|
|
|
return ctx.Device() && (ctx.DeviceConfig().NativeCoverageEnabled() || ctx.DeviceConfig().ClangCoverageEnabled())
|
2019-08-09 07:44:36 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (a *apexBundle) PreventInstall() {
|
|
|
|
|
a.properties.PreventInstall = true
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func (a *apexBundle) HideFromMake() {
|
|
|
|
|
a.properties.HideFromMake = true
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-09 04:32:06 +01:00
|
|
|
func (a *apexBundle) MarkAsCoverageVariant(coverage bool) {
|
|
|
|
|
a.properties.IsCoverageVariant = coverage
|
|
|
|
|
}
|
|
|
|
|
|
2020-04-09 15:56:02 +02:00
|
|
|
func (a *apexBundle) EnableCoverageIfNeeded() {}
|
|
|
|
|
|
2019-11-18 07:39:01 +01:00
|
|
|
// TODO(jiyong) move apexFileFor* close to the apexFile type definition
|
2019-12-13 05:28:36 +01:00
|
|
|
func apexFileForNativeLibrary(ctx android.BaseModuleContext, ccMod *cc.Module, handleSpecialLibs bool) apexFile {
|
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.
|
2019-11-18 07:39:01 +01:00
|
|
|
var dirInApex string
|
2019-09-11 00:18:20 +02:00
|
|
|
switch ccMod.Arch().ArchType.Multilib {
|
2018-10-10 07:01:00 +02:00
|
|
|
case "lib32":
|
|
|
|
|
dirInApex = "lib"
|
|
|
|
|
case "lib64":
|
|
|
|
|
dirInApex = "lib64"
|
|
|
|
|
}
|
2019-09-17 23:45:31 +02:00
|
|
|
if ccMod.Target().NativeBridge == android.NativeBridgeEnabled {
|
2019-09-11 00:18:20 +02:00
|
|
|
dirInApex = filepath.Join(dirInApex, ccMod.Target().NativeBridgeRelativePath)
|
2018-10-10 07:01:00 +02:00
|
|
|
}
|
2020-02-06 09:33:20 +01:00
|
|
|
dirInApex = filepath.Join(dirInApex, ccMod.RelativeInstallPath())
|
2019-12-13 05:28:36 +01:00
|
|
|
if handleSpecialLibs && cc.InstallToBootstrap(ccMod.BaseModuleName(), ctx.Config()) {
|
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")
|
2018-12-20 14:10:17 +01:00
|
|
|
}
|
2018-10-10 07:01:00 +02:00
|
|
|
|
2019-11-18 07:39:01 +01:00
|
|
|
fileToCopy := ccMod.OutputFile().Path()
|
2019-12-13 05:28:36 +01:00
|
|
|
return newApexFile(ctx, fileToCopy, ccMod.Name(), dirInApex, nativeSharedLib, ccMod)
|
2018-10-10 07:01:00 +02:00
|
|
|
}
|
|
|
|
|
|
2019-12-13 05:28:36 +01:00
|
|
|
func apexFileForExecutable(ctx android.BaseModuleContext, cc *cc.Module) apexFile {
|
2020-02-06 09:33:20 +01:00
|
|
|
dirInApex := "bin"
|
2019-09-17 23:45:31 +02:00
|
|
|
if cc.Target().NativeBridge == android.NativeBridgeEnabled {
|
2019-07-11 10:23:53 +02:00
|
|
|
dirInApex = filepath.Join(dirInApex, cc.Target().NativeBridgeRelativePath)
|
2019-07-09 09:19:16 +02:00
|
|
|
}
|
2020-02-06 09:33:20 +01:00
|
|
|
dirInApex = filepath.Join(dirInApex, cc.RelativeInstallPath())
|
2019-11-18 07:39:01 +01:00
|
|
|
fileToCopy := cc.OutputFile().Path()
|
2019-12-13 05:28:36 +01:00
|
|
|
af := newApexFile(ctx, fileToCopy, cc.Name(), dirInApex, nativeExecutable, cc)
|
2019-11-18 07:39:01 +01:00
|
|
|
af.symlinks = cc.Symlinks()
|
2020-05-13 00:26:55 +02:00
|
|
|
af.dataPaths = cc.DataPaths()
|
2019-11-18 07:39:01 +01:00
|
|
|
return af
|
2018-10-10 07:01:00 +02:00
|
|
|
}
|
|
|
|
|
|
2019-12-13 05:28:36 +01:00
|
|
|
func apexFileForPyBinary(ctx android.BaseModuleContext, py *python.Module) apexFile {
|
2019-11-18 07:39:01 +01:00
|
|
|
dirInApex := "bin"
|
|
|
|
|
fileToCopy := py.HostToolPath().Path()
|
2019-12-13 05:28:36 +01:00
|
|
|
return newApexFile(ctx, fileToCopy, py.Name(), dirInApex, pyBinary, py)
|
2019-02-27 23:19:50 +01:00
|
|
|
}
|
2019-12-13 05:28:36 +01:00
|
|
|
func apexFileForGoBinary(ctx android.BaseModuleContext, depName string, gb bootstrap.GoBinaryTool) apexFile {
|
2019-11-18 07:39:01 +01:00
|
|
|
dirInApex := "bin"
|
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())
|
2019-11-18 07:39:01 +01:00
|
|
|
return apexFile{}
|
2019-02-27 23:19:50 +01:00
|
|
|
}
|
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.
|
2019-12-13 05:28:36 +01:00
|
|
|
return newApexFile(ctx, fileToCopy, depName, dirInApex, goBinary, nil)
|
2019-02-27 23:19:50 +01:00
|
|
|
}
|
|
|
|
|
|
2020-06-01 19:45:49 +02:00
|
|
|
func apexFileForShBinary(ctx android.BaseModuleContext, sh *sh.ShBinary) apexFile {
|
2019-11-18 07:39:01 +01:00
|
|
|
dirInApex := filepath.Join("bin", sh.SubDir())
|
|
|
|
|
fileToCopy := sh.OutputFile()
|
2019-12-13 05:28:36 +01:00
|
|
|
af := newApexFile(ctx, fileToCopy, sh.Name(), dirInApex, shBinary, sh)
|
2019-11-18 07:39:01 +01:00
|
|
|
af.symlinks = sh.Symlinks()
|
|
|
|
|
return af
|
2019-02-05 16:16:29 +01:00
|
|
|
}
|
|
|
|
|
|
2020-05-28 16:46:55 +02:00
|
|
|
type javaDependency interface {
|
2020-06-04 16:08:17 +02:00
|
|
|
DexJarBuildPath() android.Path
|
2020-06-01 14:39:15 +02:00
|
|
|
JacocoReportClassesFile() android.Path
|
2020-05-28 16:46:55 +02:00
|
|
|
Stem() string
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func apexFileForJavaLibrary(ctx android.BaseModuleContext, lib javaDependency, module android.Module) apexFile {
|
2019-11-18 07:39:01 +01:00
|
|
|
dirInApex := "javalib"
|
2020-06-04 16:08:17 +02:00
|
|
|
fileToCopy := lib.DexJarBuildPath()
|
2020-05-14 21:49:32 +02:00
|
|
|
af := newApexFile(ctx, fileToCopy, module.Name(), dirInApex, javaSharedLib, module)
|
2020-01-08 05:35:43 +01:00
|
|
|
af.jacocoReportClassesFile = lib.JacocoReportClassesFile()
|
2020-05-28 16:46:55 +02:00
|
|
|
af.stem = lib.Stem() + ".jar"
|
2020-01-08 05:35:43 +01:00
|
|
|
return af
|
2018-10-10 07:01:00 +02:00
|
|
|
}
|
|
|
|
|
|
2020-06-01 19:45:49 +02:00
|
|
|
func apexFileForPrebuiltEtc(ctx android.BaseModuleContext, prebuilt prebuilt_etc.PrebuiltEtcModule, depName string) apexFile {
|
2019-11-18 07:39:01 +01:00
|
|
|
dirInApex := filepath.Join("etc", prebuilt.SubDir())
|
|
|
|
|
fileToCopy := prebuilt.OutputFile()
|
2019-12-13 05:28:36 +01:00
|
|
|
return newApexFile(ctx, fileToCopy, depName, dirInApex, etc, prebuilt)
|
2019-08-27 06:55:42 +02:00
|
|
|
}
|
|
|
|
|
|
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)
|
|
|
|
|
}
|
|
|
|
|
|
2019-12-13 05:28:36 +01:00
|
|
|
func apexFileForAndroidApp(ctx android.BaseModuleContext, aapp interface {
|
2019-11-18 07:39:01 +01:00
|
|
|
android.Module
|
|
|
|
|
Privileged() bool
|
2020-03-23 12:21:11 +01:00
|
|
|
InstallApkName() string
|
2019-11-18 07:39:01 +01:00
|
|
|
OutputFile() android.Path
|
2020-01-08 05:35:43 +01:00
|
|
|
JacocoReportClassesFile() android.Path
|
2020-01-28 23:00:53 +01:00
|
|
|
Certificate() java.Certificate
|
2020-03-23 12:21:11 +01:00
|
|
|
}) apexFile {
|
2019-10-27 01:29:22 +02:00
|
|
|
appDir := "app"
|
2019-11-18 07:39:01 +01:00
|
|
|
if aapp.Privileged() {
|
2019-10-27 01:29:22 +02:00
|
|
|
appDir = "priv-app"
|
|
|
|
|
}
|
2020-03-23 12:21:11 +01:00
|
|
|
dirInApex := filepath.Join(appDir, aapp.InstallApkName())
|
2019-11-18 07:39:01 +01:00
|
|
|
fileToCopy := aapp.OutputFile()
|
2020-01-08 05:35:43 +01:00
|
|
|
af := newApexFile(ctx, fileToCopy, aapp.Name(), dirInApex, app, aapp)
|
|
|
|
|
af.jacocoReportClassesFile = aapp.JacocoReportClassesFile()
|
2020-01-28 23:00:53 +01:00
|
|
|
af.certificate = aapp.Certificate()
|
2020-02-28 08:51:07 +01:00
|
|
|
|
|
|
|
|
if app, ok := aapp.(interface {
|
|
|
|
|
OverriddenManifestPackageName() string
|
|
|
|
|
}); ok {
|
|
|
|
|
af.overriddenPackageName = app.OverriddenManifestPackageName()
|
|
|
|
|
}
|
2020-01-08 05:35:43 +01:00
|
|
|
return af
|
2019-10-27 01:29:22 +02:00
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-30 16:54:08 +02:00
|
|
|
// Function called while walking an APEX's payload dependencies.
|
|
|
|
|
//
|
|
|
|
|
// Return true if the `to` module should be visited, false otherwise.
|
|
|
|
|
type payloadDepsCallback func(ctx android.ModuleContext, from blueprint.Module, to android.ApexModule, externalDep bool) bool
|
|
|
|
|
|
2020-02-07 09:25:49 +01:00
|
|
|
// Visit dependencies that contributes to the payload of this APEX
|
2020-03-30 16:54:08 +02:00
|
|
|
func (a *apexBundle) walkPayloadDeps(ctx android.ModuleContext, do payloadDepsCallback) {
|
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
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Check for the direct dependencies that contribute to the payload
|
|
|
|
|
if dt, ok := ctx.OtherModuleDependencyTag(child).(dependencyTag); ok {
|
|
|
|
|
if dt.payload {
|
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
|
|
|
}
|
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
|
2020-03-09 22:23:13 +01:00
|
|
|
if am.ApexName() != "" {
|
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
|
|
|
}
|
|
|
|
|
|
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
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-26 14:45:42 +01:00
|
|
|
func (a *apexBundle) minSdkVersion(ctx android.BaseModuleContext) int {
|
|
|
|
|
ver := proptools.StringDefault(a.properties.Min_sdk_version, "current")
|
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())
|
2020-02-26 14:45:42 +01:00
|
|
|
}
|
2020-04-01 18:41:41 +02:00
|
|
|
return intVer
|
2020-02-26 14:45:42 +01:00
|
|
|
}
|
|
|
|
|
|
2020-04-28 15:57:42 +02:00
|
|
|
func (a *apexBundle) Updatable() bool {
|
|
|
|
|
return proptools.Bool(a.properties.Updatable)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
var _ android.ApexBundleDepsInfoIntf = (*apexBundle)(nil)
|
|
|
|
|
|
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
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-30 16:54:08 +02:00
|
|
|
a.walkPayloadDeps(ctx, func(ctx android.ModuleContext, from blueprint.Module, to android.ApexModule, externalDep bool) bool {
|
|
|
|
|
if externalDep {
|
|
|
|
|
// As soon as the dependency graph crosses the APEX boundary, don't go further.
|
|
|
|
|
return false
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-07 09:25:49 +01:00
|
|
|
apexName := ctx.ModuleName()
|
2020-03-09 22:23:13 +01:00
|
|
|
fromName := ctx.OtherModuleName(from)
|
|
|
|
|
toName := ctx.OtherModuleName(to)
|
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
|
|
|
|
|
}
|
|
|
|
|
|
2020-06-11 20:32:11 +02:00
|
|
|
if to.AvailableFor(apexName) || baselineApexAvailable(apexName, toName) {
|
2020-03-30 16:54:08 +02:00
|
|
|
return true
|
2020-02-07 09:25:49 +01:00
|
|
|
}
|
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))
|
2020-03-30 16:54:08 +02:00
|
|
|
// Visit this module's dependencies to check and report any issues with their availability.
|
|
|
|
|
return true
|
2020-02-07 09:25:49 +01:00
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
2020-04-27 05:10:30 +02:00
|
|
|
func (a *apexBundle) checkUpdatable(ctx android.ModuleContext) {
|
2020-04-28 15:57:42 +02:00
|
|
|
if a.Updatable() {
|
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")
|
|
|
|
|
}
|
2020-04-15 18:29:42 +02:00
|
|
|
|
|
|
|
|
a.checkJavaStableSdkVersion(ctx)
|
2020-04-27 05:10:30 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
a.walkPayloadDeps(ctx, func(ctx android.ModuleContext, from blueprint.Module, to android.ApexModule, externalDep bool) bool {
|
|
|
|
|
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
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
2018-10-10 07:01:00 +02:00
|
|
|
func (a *apexBundle) GenerateAndroidBuildActions(ctx android.ModuleContext) {
|
2019-10-22 06:58:29 +02:00
|
|
|
buildFlattenedAsDefault := ctx.Config().FlattenApex() && !ctx.Config().UnbundledBuild()
|
|
|
|
|
switch a.properties.ApexType {
|
|
|
|
|
case imageApex:
|
|
|
|
|
if buildFlattenedAsDefault {
|
|
|
|
|
a.suffix = imageApexSuffix
|
|
|
|
|
} else {
|
|
|
|
|
a.suffix = ""
|
|
|
|
|
a.primaryApexType = true
|
2019-12-05 08:27:44 +01:00
|
|
|
|
|
|
|
|
if ctx.Config().InstallExtraFlattenedApexes() {
|
2020-01-09 04:32:06 +01:00
|
|
|
a.requiredDeps = append(a.requiredDeps, a.Name()+flattenedSuffix)
|
2019-12-05 08:27:44 +01:00
|
|
|
}
|
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
|
|
|
|
|
}
|
2018-11-30 02:12:15 +01:00
|
|
|
}
|
|
|
|
|
|
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)
|
2020-04-27 05:10:30 +02:00
|
|
|
a.checkUpdatable(ctx)
|
2020-05-10 08:16:24 +02:00
|
|
|
a.checkStaticLinkingToStubLibraries(ctx)
|
2020-02-07 09:25:49 +01:00
|
|
|
|
2019-01-30 03:31:59 +01:00
|
|
|
handleSpecialLibs := !android.Bool(a.properties.Ignore_system_library_special_case)
|
|
|
|
|
|
2019-08-01 10:41:43 +02:00
|
|
|
// native lib dependencies
|
|
|
|
|
var provideNativeLibs []string
|
|
|
|
|
var requireNativeLibs []string
|
|
|
|
|
|
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...)
|
|
|
|
|
})
|
|
|
|
|
|
2019-11-18 07:39:01 +01:00
|
|
|
var filesInfo []apexFile
|
2020-02-07 09:25:49 +01:00
|
|
|
// TODO(jiyong) do this using walkPayloadDeps
|
2019-02-27 23:19:50 +01:00
|
|
|
ctx.WalkDepsBlueprint(func(child, parent blueprint.Module) bool {
|
2019-07-29 17:22:59 +02:00
|
|
|
depTag := ctx.OtherModuleDependencyTag(child)
|
2020-04-07 16:25:44 +02:00
|
|
|
if _, ok := depTag.(android.ExcludeFromApexContentsTag); ok {
|
|
|
|
|
return false
|
|
|
|
|
}
|
2019-07-29 17:22:59 +02:00
|
|
|
depName := ctx.OtherModuleName(child)
|
2019-11-18 07:39:01 +01:00
|
|
|
if _, isDirectDep := parent.(*apexBundle); isDirectDep {
|
2018-10-10 07:01:00 +02:00
|
|
|
switch depTag {
|
2020-02-27 05:50:06 +01:00
|
|
|
case sharedLibTag, jniLibTag:
|
|
|
|
|
isJniLib := depTag == jniLibTag
|
2020-02-06 09:42:40 +01:00
|
|
|
if c, ok := child.(*cc.Module); ok {
|
2020-02-27 05:50:06 +01:00
|
|
|
fi := apexFileForNativeLibrary(ctx, c, handleSpecialLibs)
|
|
|
|
|
fi.isJniLib = isJniLib
|
|
|
|
|
filesInfo = append(filesInfo, fi)
|
2020-05-29 14:29:20 +02:00
|
|
|
// bootstrap bionic libs are treated as provided by system
|
|
|
|
|
if c.HasStubsVariants() && !cc.InstallToBootstrap(c.BaseModuleName(), ctx.Config()) {
|
|
|
|
|
provideNativeLibs = append(provideNativeLibs, fi.Stem())
|
|
|
|
|
}
|
2019-11-18 07:39:01 +01:00
|
|
|
return true // track transitive dependencies
|
2018-10-12 14:49:38 +02:00
|
|
|
} else {
|
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)
|
2018-10-10 07:01:00 +02:00
|
|
|
}
|
|
|
|
|
case executableTag:
|
|
|
|
|
if cc, ok := child.(*cc.Module); ok {
|
2019-12-13 05:28:36 +01:00
|
|
|
filesInfo = append(filesInfo, apexFileForExecutable(ctx, cc))
|
2019-11-18 07:39:01 +01:00
|
|
|
return true // track transitive dependencies
|
2020-06-01 19:45:49 +02:00
|
|
|
} else if sh, ok := child.(*sh.ShBinary); ok {
|
2019-12-13 05:28:36 +01:00
|
|
|
filesInfo = append(filesInfo, apexFileForShBinary(ctx, sh))
|
2019-02-27 23:19:50 +01:00
|
|
|
} else if py, ok := child.(*python.Module); ok && py.HostToolPath().Valid() {
|
2019-12-13 05:28:36 +01:00
|
|
|
filesInfo = append(filesInfo, apexFileForPyBinary(ctx, py))
|
2019-02-27 23:19:50 +01:00
|
|
|
} else if gb, ok := child.(bootstrap.GoBinaryTool); ok && a.Host() {
|
2019-11-18 07:39:01 +01:00
|
|
|
filesInfo = append(filesInfo, apexFileForGoBinary(ctx, depName, gb))
|
2018-10-12 14:49:38 +02:00
|
|
|
} else {
|
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)
|
2018-10-10 07:01:00 +02:00
|
|
|
}
|
|
|
|
|
case javaLibTag:
|
2020-06-01 14:39:15 +02:00
|
|
|
switch child.(type) {
|
|
|
|
|
case *java.Library, *java.SdkLibrary, *java.DexImport:
|
|
|
|
|
af := apexFileForJavaLibrary(ctx, child.(javaDependency), child.(android.Module))
|
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
|
2020-06-01 14:39:15 +02:00
|
|
|
default:
|
2019-08-09 13:39:45 +02:00
|
|
|
ctx.PropertyErrorf("java_libs", "%q of type %q is not supported", depName, ctx.OtherModuleType(child))
|
2018-10-10 07:01:00 +02:00
|
|
|
}
|
2019-11-18 07:39:01 +01:00
|
|
|
case androidAppTag:
|
|
|
|
|
if ap, ok := child.(*java.AndroidApp); ok {
|
2020-03-23 12:21:11 +01:00
|
|
|
filesInfo = append(filesInfo, apexFileForAndroidApp(ctx, ap))
|
2019-11-18 07:39:01 +01:00
|
|
|
return true // track transitive dependencies
|
|
|
|
|
} else if ap, ok := child.(*java.AndroidAppImport); ok {
|
2020-03-23 12:21:11 +01:00
|
|
|
filesInfo = append(filesInfo, apexFileForAndroidApp(ctx, ap))
|
2019-12-20 23:58:03 +01:00
|
|
|
} else if ap, ok := child.(*java.AndroidTestHelperApp); ok {
|
2020-03-23 12:21:11 +01:00
|
|
|
filesInfo = append(filesInfo, apexFileForAndroidApp(ctx, ap))
|
2020-05-28 01:36:07 +02:00
|
|
|
} else if ap, ok := child.(*java.AndroidAppSet); ok {
|
|
|
|
|
appDir := "app"
|
|
|
|
|
if ap.Privileged() {
|
|
|
|
|
appDir = "priv-app"
|
|
|
|
|
}
|
|
|
|
|
af := newApexFile(ctx, ap.OutputFile(), ap.Name(),
|
|
|
|
|
filepath.Join(appDir, ap.BaseModuleName()), appSet, ap)
|
|
|
|
|
af.certificate = java.PresignedCertificate
|
|
|
|
|
filesInfo = append(filesInfo, af)
|
2019-11-18 07:39:01 +01:00
|
|
|
} else {
|
|
|
|
|
ctx.PropertyErrorf("apps", "%q is not an android_app module", depName)
|
|
|
|
|
}
|
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)
|
|
|
|
|
}
|
2018-10-10 07:01:00 +02:00
|
|
|
case prebuiltTag:
|
2020-06-01 19:45:49 +02:00
|
|
|
if prebuilt, ok := child.(prebuilt_etc.PrebuiltEtcModule); ok {
|
2019-12-13 05:28:36 +01:00
|
|
|
filesInfo = append(filesInfo, apexFileForPrebuiltEtc(ctx, prebuilt, depName))
|
2020-01-27 18:01:16 +01:00
|
|
|
} else if prebuilt, ok := child.(java.PlatformCompatConfigIntf); ok {
|
|
|
|
|
filesInfo = append(filesInfo, apexFileForCompatConfig(ctx, prebuilt, depName))
|
2018-10-12 14:49:38 +02:00
|
|
|
} else {
|
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)
|
2018-10-12 14:49:38 +02:00
|
|
|
}
|
2019-06-26 13:48:34 +02:00
|
|
|
case testTag:
|
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).
|
2019-06-28 16:41:19 +02:00
|
|
|
} else {
|
2019-07-29 17:22:59 +02:00
|
|
|
// Single-output test module (where `test_per_src: false`).
|
2019-12-13 05:28:36 +01:00
|
|
|
af := apexFileForExecutable(ctx, ccTest)
|
2019-11-18 07:39:01 +01:00
|
|
|
af.class = nativeTest
|
|
|
|
|
filesInfo = append(filesInfo, af)
|
2019-06-28 16:41:19 +02:00
|
|
|
}
|
2020-05-04 03:31:32 +02:00
|
|
|
return true // track transitive dependencies
|
2019-06-26 13:48:34 +02:00
|
|
|
} else {
|
|
|
|
|
ctx.PropertyErrorf("tests", "%q is not a cc module", depName)
|
|
|
|
|
}
|
2018-10-12 14:49:38 +02:00
|
|
|
case keyTag:
|
|
|
|
|
if key, ok := child.(*apexKey); ok {
|
2019-02-18 07:25:04 +01:00
|
|
|
a.private_key_file = key.private_key_file
|
|
|
|
|
a.public_key_file = key.public_key_file
|
2018-10-12 14:49:38 +02:00
|
|
|
} else {
|
|
|
|
|
ctx.PropertyErrorf("key", "%q is not an apex_key module", depName)
|
2018-10-10 07:01:00 +02:00
|
|
|
}
|
2019-11-18 07:39:01 +01:00
|
|
|
return false
|
2018-10-30 13:20:05 +01:00
|
|
|
case certificateTag:
|
|
|
|
|
if dep, ok := child.(*java.AndroidAppCertificate); ok {
|
2019-02-18 07:25:04 +01:00
|
|
|
a.container_certificate_file = dep.Certificate.Pem
|
|
|
|
|
a.container_private_key_file = dep.Certificate.Key
|
2018-10-30 13:20:05 +01:00
|
|
|
} else {
|
|
|
|
|
ctx.ModuleErrorf("certificate dependency %q must be an android_app_certificate module", depName)
|
|
|
|
|
}
|
2019-07-26 16:20:40 +02:00
|
|
|
case android.PrebuiltDepTag:
|
|
|
|
|
// If the prebuilt is force disabled, remember to delete the prebuilt file
|
|
|
|
|
// that might have been installed in the previous builds
|
|
|
|
|
if prebuilt, ok := child.(*Prebuilt); ok && prebuilt.isForceDisabled() {
|
|
|
|
|
a.prebuiltFileToDelete = prebuilt.InstallFilename()
|
|
|
|
|
}
|
2018-10-10 07:01:00 +02:00
|
|
|
}
|
2019-10-28 21:08:31 +01:00
|
|
|
} else if !a.vndkApex {
|
2018-10-10 07:01:00 +02:00
|
|
|
// indirect dependencies
|
2019-08-20 10:30:57 +02:00
|
|
|
if am, ok := child.(android.ApexModule); ok {
|
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`).
|
2019-11-11 02:14:32 +01:00
|
|
|
if cc.IsSharedDepTag(depTag) || cc.IsRuntimeDepTag(depTag) {
|
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
|
|
|
|
|
}
|
2020-05-29 14:29:20 +02:00
|
|
|
af := apexFileForNativeLibrary(ctx, cc, handleSpecialLibs)
|
|
|
|
|
af.transitiveDep = true
|
2019-12-17 04:47:13 +01:00
|
|
|
if !a.Host() && !android.DirectlyInApex(ctx.ModuleName(), ctx.OtherModuleName(cc)) && (cc.IsStubs() || cc.HasStubsVariants()) {
|
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.
|
2020-05-06 09:59:59 +02:00
|
|
|
if !android.DirectlyInAnyApex(ctx, cc.Name()) && !android.InList(cc.BaseModuleName(), a.requiredDeps) {
|
|
|
|
|
a.requiredDeps = append(a.requiredDeps, cc.BaseModuleName())
|
2019-07-29 17:22:59 +02:00
|
|
|
}
|
2020-05-29 14:29:20 +02:00
|
|
|
requireNativeLibs = append(requireNativeLibs, af.Stem())
|
2019-07-29 17:22:59 +02:00
|
|
|
// Don't track further
|
|
|
|
|
return false
|
2019-02-20 13:49:26 +01:00
|
|
|
}
|
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
|
|
|
}
|
2019-07-29 17:22:59 +02:00
|
|
|
} else if cc.IsTestPerSrcDepTag(depTag) {
|
|
|
|
|
if cc, ok := child.(*cc.Module); ok {
|
2019-12-13 05:28:36 +01:00
|
|
|
af := apexFileForExecutable(ctx, cc)
|
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).
|
2019-11-18 07:39:01 +01:00
|
|
|
af.moduleName = filepath.Base(af.builtFile.String())
|
2020-01-14 01:22:18 +01:00
|
|
|
// these are not considered transitive dep
|
|
|
|
|
af.transitiveDep = false
|
2019-11-18 07:39:01 +01:00
|
|
|
filesInfo = append(filesInfo, af)
|
|
|
|
|
return true // track transitive dependencies
|
2019-07-29 17:22:59 +02:00
|
|
|
}
|
2019-11-11 02:14:32 +01:00
|
|
|
} else if java.IsJniDepTag(depTag) {
|
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
|
2020-02-17 09:28:10 +01:00
|
|
|
} else if java.IsXmlPermissionsFileDepTag(depTag) {
|
2020-06-01 19:45:49 +02:00
|
|
|
if prebuilt, ok := child.(prebuilt_etc.PrebuiltEtcModule); ok {
|
2020-02-17 09:28:10 +01:00
|
|
|
filesInfo = append(filesInfo, apexFileForPrebuiltEtc(ctx, prebuilt, depName))
|
|
|
|
|
}
|
2019-08-20 10:30:57 +02:00
|
|
|
} else if am.CanHaveApexVariants() && am.IsInstallableToApex() {
|
2020-05-07 09:12:13 +02:00
|
|
|
ctx.ModuleErrorf("unexpected tag %s for indirect dependency %q", android.PrettyPrintTag(depTag), depName)
|
2018-10-10 07:01:00 +02:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return false
|
|
|
|
|
})
|
|
|
|
|
|
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 {
|
2020-03-18 19:00:41 +01:00
|
|
|
for arch, files := range java.DexpreoptedArtApexJars(ctx) {
|
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())
|
2019-12-13 05:28:36 +01:00
|
|
|
af := newApexFile(ctx, f, localModule, dirInApex, etc, nil)
|
2019-11-18 07:39:01 +01:00
|
|
|
filesInfo = append(filesInfo, af)
|
2019-11-08 11:51:01 +01:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2019-02-18 07:25:04 +01:00
|
|
|
if a.private_key_file == nil {
|
2018-11-08 21:52:26 +01:00
|
|
|
ctx.PropertyErrorf("key", "private_key for %q could not be found", String(a.properties.Key))
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
|
2018-11-07 18:50:25 +01:00
|
|
|
// remove duplicates in filesInfo
|
|
|
|
|
removeDup := func(filesInfo []apexFile) []apexFile {
|
2020-01-14 01:22:18 +01:00
|
|
|
encountered := make(map[string]apexFile)
|
2018-11-07 18:50:25 +01:00
|
|
|
for _, f := range filesInfo {
|
2019-08-23 04:17:39 +02:00
|
|
|
dest := filepath.Join(f.installDir, f.builtFile.Base())
|
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
|
2018-11-07 18:50:25 +01:00
|
|
|
}
|
|
|
|
|
}
|
2020-01-14 01:22:18 +01:00
|
|
|
var result []apexFile
|
|
|
|
|
for _, v := range encountered {
|
|
|
|
|
result = append(result, v)
|
|
|
|
|
}
|
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
|
2018-11-30 02:12:15 +01:00
|
|
|
|
2019-11-19 18:26:02 +01:00
|
|
|
if a.properties.ApexType != zipApex {
|
|
|
|
|
if a.properties.File_contexts == nil {
|
|
|
|
|
a.fileContexts = android.PathForSource(ctx, "system/sepolicy/apex", ctx.ModuleName()+"-file_contexts")
|
|
|
|
|
} else {
|
|
|
|
|
a.fileContexts = android.PathForModuleSrc(ctx, *a.properties.File_contexts)
|
|
|
|
|
if a.Platform() {
|
|
|
|
|
if matched, err := path.Match("system/sepolicy/**/*", a.fileContexts.String()); err != nil || !matched {
|
|
|
|
|
ctx.PropertyErrorf("file_contexts", "should be under system/sepolicy, but %q", a.fileContexts)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if !android.ExistentPathForSource(ctx, a.fileContexts.String()).Valid() {
|
|
|
|
|
ctx.PropertyErrorf("file_contexts", "cannot find file_contexts file: %q", a.fileContexts)
|
|
|
|
|
return
|
|
|
|
|
}
|
|
|
|
|
}
|
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)
|
2019-11-19 18:26:02 +01:00
|
|
|
|
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)
|
2020-04-28 15:57:42 +02:00
|
|
|
if a.Updatable() && a.properties.ApexType == imageApex {
|
2020-02-19 08:29:35 +01:00
|
|
|
a.linkToSystemLib = false
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
|
|
}
|
|
|
|
|
|
2019-09-26 17:38:03 +02:00
|
|
|
// prepare apex_manifest.json
|
2019-11-01 18:52:25 +01:00
|
|
|
a.buildManifest(ctx, provideNativeLibs, requireNativeLibs)
|
|
|
|
|
|
|
|
|
|
a.setCertificateAndPrivateKey(ctx)
|
|
|
|
|
if a.properties.ApexType == flattenedApex {
|
|
|
|
|
a.buildFlattenedApex(ctx)
|
|
|
|
|
} else {
|
|
|
|
|
a.buildUnflattenedApex(ctx)
|
|
|
|
|
}
|
|
|
|
|
|
2020-01-07 17:57:58 +01:00
|
|
|
a.compatSymlinks = makeCompatSymlinks(a.BaseModuleName(), ctx)
|
2020-01-09 04:32:06 +01:00
|
|
|
|
|
|
|
|
a.buildApexDependencyInfo(ctx)
|
2019-11-01 18:52:25 +01:00
|
|
|
}
|
|
|
|
|
|
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)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
}
|
|
|
|
|
|
2020-06-11 20:32:11 +02:00
|
|
|
func baselineApexAvailable(apex, moduleName string) bool {
|
2020-01-10 16:12:39 +01:00
|
|
|
key := apex
|
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
|
|
|
|
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
|
2020-01-10 16:12:39 +01:00
|
|
|
}
|
|
|
|
|
|
2020-03-06 13:30:13 +01:00
|
|
|
key = android.AvailableToAnyApex
|
2020-06-11 20:32:11 +02:00
|
|
|
if val, ok := apexAvailBaseline[key]; ok && android.InList(moduleName, val) {
|
2020-01-10 16:12:39 +01:00
|
|
|
return true
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return false
|
|
|
|
|
}
|
|
|
|
|
|
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"
|
|
|
|
|
}
|
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"
|
|
|
|
|
}
|
2020-03-06 13:30:13 +01:00
|
|
|
return moduleName
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-23 04:17:39 +02:00
|
|
|
func newApexBundle() *apexBundle {
|
2019-10-22 06:58:29 +02:00
|
|
|
module := &apexBundle{}
|
2018-10-10 07:01:00 +02:00
|
|
|
module.AddProperties(&module.properties)
|
2019-01-30 03:07:33 +01:00
|
|
|
module.AddProperties(&module.targetProperties)
|
2019-11-15 10:40:32 +01:00
|
|
|
module.AddProperties(&module.overridableProperties)
|
2018-11-30 02:12:15 +01:00
|
|
|
android.InitAndroidMultiTargetsArchModule(module, android.HostAndDeviceSupported, android.MultilibCommon)
|
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)
|
2019-12-20 02:32:06 +01:00
|
|
|
android.InitOverridableModule(module, &module.overridableProperties.Overrides)
|
2018-10-10 07:01:00 +02:00
|
|
|
return module
|
|
|
|
|
}
|
2019-02-07 08:27:23 +01:00
|
|
|
|
2019-11-08 11:51:01 +01:00
|
|
|
func ApexBundleFactory(testApex bool, artApex bool) android.Module {
|
2019-08-23 04:17:39 +02:00
|
|
|
bundle := newApexBundle()
|
|
|
|
|
bundle.testApex = testApex
|
2019-11-08 11:51:01 +01:00
|
|
|
bundle.artApex = artApex
|
2019-08-23 04:17:39 +02:00
|
|
|
return bundle
|
|
|
|
|
}
|
|
|
|
|
|
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.
|
2019-08-23 04:17:39 +02:00
|
|
|
func testApexBundleFactory() android.Module {
|
|
|
|
|
bundle := newApexBundle()
|
|
|
|
|
bundle.testApex = true
|
|
|
|
|
return bundle
|
|
|
|
|
}
|
|
|
|
|
|
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 {
|
2019-08-23 04:17:39 +02:00
|
|
|
return newApexBundle()
|
|
|
|
|
}
|
|
|
|
|
|
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{},
|
2019-12-16 14:32:06 +01:00
|
|
|
&overridableProperties{},
|
2019-02-07 08:27:23 +01:00
|
|
|
)
|
|
|
|
|
|
|
|
|
|
android.InitDefaultsModule(module)
|
|
|
|
|
return module
|
|
|
|
|
}
|
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
|
|
|
|
|
}
|
